The CTO Field Guide for the first 90 days

I needed a better image than an org chart for the preview


I've learned a lot about myself writing down diaries for each company I worked for. We are used to look only for stellar success or big failures but there is a lot in between. I wrote about my career change before if you are interested.

Put a plan together

My first recommendation: before starting the new gig or in the weekend before starting with your new position, put a plan together. It doesn't need to be too complex but at least a plan for starting.

A deck to help you organise your learning

Learning and Measuring

So, how do you say something is good or bad ? How do you put in a paper things that are obvious to you but not so obvious to the person you are talking to ? Apart from telepathy you can use known baselines and metrics from companies that you can relate and derive them.

Engineering Delivery Metrics

The first four metrics I've borrowed from the Accelerate book. We may say that they were not new but at this study you will find a good taxonomy and baseline.

  • Deployment Frequency
  • Lead time for changes
  • MTTR (Mean Time To Recover)
  • Change Rate Failure
  • Incidents count per week
  • Monthly/yearly cloud expenses total and per product line
  • Licenses costs
  • Support cost
  • Discounts due to enterprise deals

Team metrics

Here the term "metrics" is loose: look for and quantify how the team is working now, without prejudice or trying to change it. Map it well to try to find why it is like this, and what is the measure of success of each decision.

  • How the current organisation work ?
  • How many unhealthy teams: no manager, stretched managers, no product manager
  • Work distribution issues: work that should be done elsewhere, duplicated work, prioritisation
  • What is the priority definition between engineering and products ?
  • What is the decision making process (RFC, committee, go horse)?
  • Are there clear levelling for ICs(Individual contributors) and Managers ?

HR and Engineering Organisation insights

The questions below are to give you an insight of how HR interacts with the engineering team. There are companies where both teams seems to be at war and others where they work well. There are information that you will only learn in a neutral way by collaborating with your HR partner.

  • How is hiring organised ? Is everyone helping ? What are the goals ?
  • Are functions hidden (Infosec done by a SRE, prioritisation done by committees) ?
  • Any functions/procedures depends on a single individual ? (e.g. the person that knows legacy code or how to deploy, or point of contact to solve an issue)
  • Any team missing ? Infosec, SRE or Platform infrastructure, Engineering tools, Data engineering, Data Science, Product Engineering, Digital channels, Notifications teams ? The big rewrite team ? The team that should manage the legacy while the rewrite team is doing their thing ?
  • Is remote work allowed ? Is it successful ?

Operations questions

I'll use "Operations" as a generic fallback for day to day stuff that I have not covered above or covered only the metrics. These are questions you ask your peers outside of your team, your boss and if you have the chance, the person you are filling in for.

  • Is there an incident process ?
  • Is there an incident severity matrix, blameless postmortems and product feedback ?
  • How is productivity measured ? Any product vs engineering stale-matches ?
  • How are growth incentives aligned for maintenance and green field work ?


Joining an existing team is hard, specially if it is during or after a reorganisation. Reorganisations, or reorgs, are just a tool. Sometimes they are seen as punitive or meaningless but they are just a way of trying to tame the uncertainty of how a team should organise to achieve its objective.

  • How they will react to a new structure or a new high level executive ?
  • What “Lead by example” means in the company’s context ?
  • Which public forums the team have ? How they can be heard ? (all hands, town halls, teams gathering)
  • Unclear dotted lines: teams that have no clear boundaries.

Team structure

Every company you go you see a variation of the "Spotify Model". I won't even link because there are many posts around and I'm not sure even Spotify uses it anymore. The thing is that as it happened with Scrum, it layered roles and organisations over existing positions and teams.

  • Multidisciplinary tribes, layered teams
  • Pros: one stop shop for business verticals, quick reaction time to day to day business needs
  • Cons: amplify the cost of simple decisions, as business grows it requires more high level arbitration
  • Can’t prioritise and execute cross business or engineering tasks
  • Legacy product and code management is hard
Vertical tribes over a thin shared engineering horizontal and a catch all back office team
Vertical Tribes over a thin engineering horizontal and a catch all back office team
A balanced approach for fast product teams taking in account the engineering and business undifferentiated lifting
  • Keep tribes where it make sense
  • Invest on platforms, bottom heavy, light on product/customer interfaces
  • Identify shared efforts
  • Speak product language even for internal customers
  • Shared P&L

How (and where) delivery happens

I've mentioned the Accelerate book before and it provides a good framework to evaluate delivery. When I say delivery I mean the mix of running your systems and all activities connected to it, including building and shipping code and how it affects your customers.

  • Operate based on metrics
  • Invest on tooling for automation, deployment and metrics collection
  • Enable accessible CD through GitOps

Cost Management

I've mentioned cost management and investments in good infrastructure engineering yield good cost management.

Network cost diagram
AWS data transfer costs

Invest on visibility

I've mentioned adopting observability, the "You build, You Run" model but the last part missing is to drive incident management processes, automation to protect delivery. We have a tendency to slow down when quality suffers. But quality is subjective.

  • Publish weekly metrics reports, for everyone, start with the ones we discussed here.
  • Organise monthly postmortems and learning events
  • Get involved on incidents, be there, help coordinate, just watch, help write postmortems. Lead by example, and in this context the example is simple.
  • Distribute the metric and measurement efforts to all teams, with reports published weekly by them. Start your big meetings with hand picked metrics review. The good and bad ones. Work on the bad ones, rinse and repeat.


Being on the losing end of a leak or security incident hurts. You are not alone. It is not if, it is when. Working with security has a double burden: it is always critical and you have to deal with the worst kind of initiative all around. Be mindful of your mental health all the times.


You will probably manage a variety of Data teams combinations. Sometimes they will be close together, sometimes they will be far apart. It is important to note that companies will sometimes start something apart of the product/engineering team to do data science as an accelerator or valuation booster, not necessarily as part of the product.

  • Make people work together, avoid silos.
  • Understand the engineering required to run complex data work but abstract the day to day analytics.
  • Spend time and share objectives with your Infosec and Compliance teams, you will be looped into that anyway for a certification or notification.
  • Create discipline to pick your tooling and avoid big migrations (anything over 10TB is hard to migrate timely in the cloud)
  • Push work to the teams: analytics, data science, machine learning should be close to product, it doesn't work in a project office fashion. Look for Airbnb, Uber and Pinterest benchmarks. Break silos early on. Provide orthogonal structure and support tho.
  • Work on model deployment (for machine learning models) early on.
  • Be flexible on how you archive data. Migrating data is a pain in the cloud, duplicate it if needed (one archive sorted by date, same data sorted by user ID)
  • Too many of each building block (e.g. standardise databases and caches as much as possible)
  • Non partitioned databases
  • Unmanaged mix between events/serverless and batch processing
  • Building a scheduler (use Apache Airflow)
  • Building a log pipeline (use ELK, use Athena/S3)
  • Teams too far apart or disconnected

Closing advices

Is this a book ? Not yet. Not the authoritative source for what you should do. I've put down what helped me and not when it helped me, because I tried to abstract situations, companies and people.



[To Pedro] Just listen to your heart. That's what I do - Napoleon Dynamite |

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Gleicon Moraes

Gleicon Moraes

[To Pedro] Just listen to your heart. That's what I do - Napoleon Dynamite |