From fifty to one hundred and fifty

Past fifty you're not running engineering.

You're running the thing that runs engineering, and almost everything you do now takes a quarter to have an effect.

The specific loss is direct contact.

You can no longer form your own view of most of the work, most of the people, or most of the decisions, because every single input now arrives through somebody else, which makes the quality of your organisation quite literally the quality of those people plus the clarity of what you have written down.

An uncomfortable amount of weight on two things.

Which is why both deserve most of your attention in this band.

The second layer

Somewhere in here you add directors.

It's the transition that catches most first-time CTOs.

Managing managers of managers is a different job again.

Your feedback loop stretches from days to quarters. You're assessing people on things you can't observe, using evidence collected by the people you're assessing.

And the org is now large enough that a director's group can be quietly struggling for two quarters before it reaches you.

Three inputs keep you honest.

Skip-levels, on a real cadence, with a fixed set of questions, so that you can compare across groups rather than collecting a pile of anecdotes you have no way of weighing against each other.

The 360 feedback everyone gets anyway, read carefully for the leaders.

And the numbers, per group. Lead time, incident load, attrition, hiring against plan. Not to manage by. Because a group whose numbers diverge from the others is a conversation you should be having.

The hiring decision here is the highest-stakes one in the band.

A weak director costs you a quarter of the organisation for a year, and the damage stays mostly invisible right up until the point where people start leaving and you find out from an exit conversation.

Prefer promoting people already operating at that scope. When you go outside, take longer than feels comfortable.

Planning across many teams, without a planning department

Ten teams need to point in the same direction.

The obvious solution, a planning process run centrally and quarterly, is the thing that turns a fast company into a slow one.

What I'd do instead.

A written strategy. One or two pages, updated when reality changes rather than on a schedule.

What we're doing, what we're not, and what has to be true for it to work. Every team should be able to explain how their current work connects to it, and if they can't, either the strategy is unclear or the work is wrong.

Team-level Now, Next, Later. Owned by the teams.

Not collected centrally into a master plan. Just visible, so anybody can look.

And a weekly cross-team conversation whose only agenda is dependencies and stuck decisions. Twenty minutes.

That's the seam where multi-team work actually fails, and almost nothing else about central planning earns its cost.

What you're avoiding is the quarterly planning event that eats a month of the organisation.

Genuinely tempting at this size, because coordination is real and an event feels like the answer. But the output doesn't survive contact anyway, and you just spent the most expensive attention in the company producing it.

One standard, many groups

Consistency is the thing that quietly goes in this band.

Two groups drift apart on testing, on review, on what "done" means. Nobody notices until an engineer moves between them and is confused.

Three mechanisms do most of the work.

Guilds, in the sense described in the embedded-versus-centralised lesson. The standard has an owner across teams, even though people report into teams.

Somebody owns what good testing looks like here, and their authority is over the standard rather than over anyone's schedule.

Shared paved roads.

The most effective consistency mechanism isn't a document at all. It's that everybody uses the same pipeline, the same service template and the same observability stack, so the standard is a property of the tooling rather than a claim in a wiki nobody opens.

Standards embedded in tooling hold. Standards written in a wiki drift.

And rotation.

People moving between teams carry the standard with them, and it's the only mechanism on this list that transfers judgment rather than rules, which is also exactly why it's the first thing cut when a quarter gets tight: a rotation is short-term expensive and long-term cheap.

What I wouldn't do is centralise enforcement into a review board.

That produces a queue, and then a game.

Platform becomes real

In this band platform stops being a rotation and becomes a team.

The trigger is still the same. Named pain that has recurred, not a headcount ratio.

Two things change at this size.

The platform team now has enough internal customers that product thinking becomes essential. Treat it as a product with users who can leave.

And the cost of getting it wrong rises, because a platform that's mandated and mediocre taxes everybody at once.

Keep it thin. Keep adoption voluntary, except where the blast radius crosses teams.

And measure it on whether teams that use it ship faster than teams that don't.

The failure to watch for is drift into a landfill.

The platform team accumulates orphaned systems because nobody else will take them, each adoption perfectly reasonable on its own, and the aggregate is a team that spends its days doing maintenance for other people's abandoned decisions.

What your job actually is now

Four things. Shorter list than it was.

Hiring and developing the leadership layer. Most of your leverage sits there.

Writing. The strategy, the standards, the decisions expensive to undo.

The only tool you have that reaches people you'll never talk to.

Deciding the small number of things only you can decide.

Then pushing everything else down, aggressively, including the things you'd enjoy.

And keeping your own contact with reality. Skip-levels, incidents, the demo, occasionally reading code, occasionally talking to a customer.

Not to do the work. To have an independent read on whether the things you're being told are actually true.

Everything else is somebody else's job.

The hardest part of this band is that quite a lot of the work you're good at now belongs to other people.