Operational enablement for a scaleup after the founder-CEO transition

Business context

The new CEO had asked a question the leadership team did not yet have a good answer to: how do we know the engineering organisation is on track? There was no quarterly planning that anyone trusted. There was no delivery dashboard. There was no ceremony for deciding which of the 60 things on the roadmap would actually ship this quarter. Things shipped. It was just not clear why those things rather than the other things.

The business itself was in good shape — a venture-backed scaleup of roughly 120 people, revenue solidly into eight figures, growing at a pace that was commercially wonderful and operationally painful. The founder-CEO had stepped into an executive chair role and an experienced commercial CEO had been recruited from outside. The existing CTO, promoted from within during the early years, was technically excellent but — by his own admission — had not done the corporate CTO role before and was finding the transition difficult.

The challenge

This was not a technology problem. The platform was fine, the team was good, and the product was winning in the market. The problem was that the operational rhythm that works at 20 people stops working at 120, and the muscle memory required to fix it is not the same muscle memory that gets a company from zero to product-market fit.

The risk was classic: that the new CEO would lose patience, replace the CTO, and start the fourth quarter with six months of organisational disruption during the most important trading period of the year. Everyone involved wanted a better outcome than that.

My role

Advisory CTO, two days per month plus on-call availability, working directly with the internal CTO as a coach and sounding board, and with the CEO as an independent view on technology organisation health. Explicitly not an interim-CTO brief — the internal CTO remained in role, and the engagement was designed around making him successful, not replacing him.

What I did

Installed a planning rhythm. The first deliverable was embarrassingly basic: a quarterly planning cycle, with inputs, outputs, a clear decision forum, and a cadence for communicating the plan to the rest of the business. It took two quarters to settle and the third to feel natural. By quarter four, the engineering leadership was running it unassisted and the CEO had stopped asking what the team was working on because he already knew.

Incident response discipline. Introduced a proper on-call rotation, an incident command structure, and a weekly incident review. Mean time to resolve dropped from 3.5 hours to 42 minutes not because the team got smarter, but because they stopped having to invent the response process each time. The weekly review — 30 minutes, blameless, every Monday — did more for platform reliability than any tooling change.

Coaching the internal CTO. The more interesting work was in weekly one-on-ones with the internal CTO. The pattern was consistent: he knew what good looked like; he didn’t yet have the reps for what good-at-120-people looks like. Most sessions focused on specific situations — how to structure a tough conversation with an underperforming lead, how to prepare a board update that answered the actual question, how to say no to the commercial team without damaging the relationship. Less glamorous than architecture work. Arguably more valuable.

Organisational design. Helped restructure the engineering organisation from six product-aligned teams into four product teams plus a platform team plus a security-and-compliance pod. This was driven entirely by the observation that three of the six original teams were spending more than half their sprint capacity on infrastructure and platform work that would have been better done by a dedicated function. The restructure happened in one quarter, with no one leaving involuntarily.

Executive reporting discipline. The CTO had been spending three days a month preparing reports for the board, the CEO, and various executive forums. Consolidated this into a single monthly technology health document — four pages, consistent metrics, written for the audience rather than by accretion — that replaced three different formats. Freed up most of his reporting time for the work he was hired to do.

Outcomes

The engineering organisation developed a repeatable operating rhythm that survived the engagement. The quarterly planning, the incident review, the monthly reporting — all of it was running without external input by month nine, which was the point. Production incident resolution came down from 3.5 hours to 42 minutes. Engineering attrition, which had been a quiet but real concern, dropped from 28% to under 9% over the engagement period as the team felt the organisation growing up around them.

The internal CTO stayed in role, grew into it, and was subsequently promoted. The CEO got the answers he was asking for. The commercial outcome was the boring one: the business kept growing, the team kept shipping, and no one lost their job because the transition went badly. That was always the brief.