A CTO's first 90 days at a scaling startup: what to break, what to leave alone.
New CTOs lose the room in week 6 — almost always by changing the wrong thing first. Here's the 90-day sequence used by three CTOs I coached through Series B handovers, and the two decisions every one of them regretted.
The most expensive mistake a new CTO makes isn't a technology choice. It's the order in which they make changes. Engineering organizations have a memory: every team remembers exactly which week the new leader lost the room, and once that week happens the next 18 months are spent rebuilding trust instead of building product. Across three CTO handovers I worked through in 2024–25 — all post-Series B, all 60–180 engineers — the same 90-day sequence kept the room. The two decisions every one of these CTOs later regretted were the same two.
The 90-day sequence that kept the room
- Meetings that have no decision owner.
- Performance reviews that aren't tied to a written rubric.
- On-call rotations that exclude managers.
- The deploy process if it's slower than 30 minutes end-to-end.
- The primary language or framework, no matter how outdated.
- The monorepo / polyrepo decision.
- The team topology, unless it's actively on fire.
- Anyone the previous CTO hired in the last 6 months.
The two decisions every CTO regretted
- Replacing the head of platform/infra in the first 60 days. In all three cases the incumbent held tribal knowledge the new CTO didn't know they needed for another 4 months. The right move was to keep them, partner with them, and reassess at day 120.
- Announcing a re-platform before earning the right to. Engineering teams will nod in the all-hands and quietly disengage. Re-platforms announced before day 90 had a 0/3 hit rate. Re-platforms announced after day 180, with a written cost/benefit, had a 3/3 hit rate.
HR & Operations leader scaling global remote teams across Nepal, the Philippines, Australia, and the US. Tech-leaning writing lives on Medium.