A CTO's first 90 days at a scaling startup
New CTOs lose the room in week 6 — almost always by changing the wrong thing first.
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 HR leaders 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.
- 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.
- 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.
Stephen M.R. Covey's 'Speed of Trust' frames trust as an account with deposits and withdrawals. A new CTO walks in with a starting balance set by the announcement, the predecessor's reputation, and the team's last 12 months of experience. Every change made before earning the right to make it is a withdrawal. Every visible win — small, shipped, attributed — is a deposit. The teams that 'lose the room in week 6' did so by making 4-5 simultaneous withdrawals before any deposits cleared. The math is brutal and predictable.
Layer on Daniel Kahneman's loss aversion: engineering teams feel the threat of a change roughly twice as strongly as the promise of its benefit. A 'small org tweak' you frame as 'evolution' will be heard as 'destabilization' by the team. The 90-day sequence isn't about being slow — it's about respecting the asymmetry. Once you've made deposits (listening, visible wins, published operating model), the same change feels like leadership instead of disruption.
A new CTO at a 140-engineer fintech, as one HR coach recounted, in 2024 inherited a monorepo that genuinely needed to be broken up. He spent days 1-30 doing 1:1s and listening. Days 31-60 he shipped a 30-minute deploy improvement (from 90 minutes) that every engineer felt the same week. Days 61-90 he replaced one director, kept everyone else, and published an engineering operating model. He announced the monorepo migration on day 132 with a written cost/benefit and an opt-in pilot. It shipped in 14 months with no attrition spike. The same announcement on day 30 would have triggered a 6-month resignation cascade.
- Days 1-30: Zero org changes. 1:1 every EM, 5 random ICs, top 3 customers.
- Days 31-60: Ship one small, visible technical win. Publish the engineering operating model in writing.
- Days 61-90: Make at most one org change. Replace at most one director. Announce the 12-month tech bet.
- Day 91+: Now you have permission to touch the architecture. Not before.
- Never replace the head of platform/infra in the first 60 days — the tribal knowledge tax is brutal.
- Never announce a re-platform in the first 90 days. Earn the right with a published cost/benefit first.
- Write down your 90-day plan on day 1 and revisit weekly. Drift is the failure mode.