From twenty to fifty

The transition in this band is that you stop being able to hold the whole picture, and no single day is the day it happens.

At twenty you can still, with effort, know roughly what everyone is working on and why. At fifty that's simply not available, and the leaders who struggle most here are the ones who keep trying, usually by attending more meetings.

What replaces personal knowledge is a system: written strategy, clear ownership, managers you trust, and a small number of numbers you look at. Building that system is the job of this band, and it's a different job from the one you were good at before.

Decision speed is what breaks

If you asked me what surprised me most about crossing thirty engineers, it's how much slower decisions got, with the same good people in the room.

Not quality. Not the hiring bar. Not communication, which everyone worries about and which mostly degrades gracefully. Decisions.

The mechanism is that decisions acquire participants. At fifteen people, the person who needs to decide something knows who else is affected and can ask them in five minutes. At forty, they're not sure who's affected, so they invite everyone who might be, and that means a meeting, and the meeting is next Thursday. Nothing unreasonable happened. The elapsed time went from an afternoon to eleven days.

The counter-moves are unglamorous and they work. Name the decider explicitly for anything contested. Classify by reversibility, and make the reversible ones fast and single-owner. And watch the calendar days between "raised" and "decided" for your last five consequential decisions, because it's the earliest measurable sign that this band is happening to you.

If you take one thing from this lesson: the thing to defend at this size is not quality, it's speed of judgment.

Managers, and what changes about your job

You'll add two to four managers in this band, and your job becomes managing them rather than the work.

The failure I'd warn about most: hiring several managers externally in a short period. Each one arrives with a fully-formed model of how engineering should run, from a company that was a different size than yours, and within six months you have three different operating models in one org and no way to tell which of the resulting problems came from which.

Prefer growing them internally where you can, add external ones one at a time with space between, and be explicit about which parts of the operating model are theirs to change and which are settled.

The other shift is informational. You now hear about the work through the person whose handling of it you're assessing, which is an awkward position and can't be fixed by trusting harder. It's fixed by having independent inputs: skip-level conversations on a real cadence, the 360 feedback everyone gets, the weekly demo where you see the work directly, and enough presence in incidents and reviews to have your own view.

The first process that's genuinely justified

Some process becomes correct in this band, and the same rule still applies: it should be traceable to a failure that has now happened at least twice.

What usually qualifies by fifty: a written hiring bar with someone outside the team holding the veto, because interviewing volume is high enough that drift is guaranteed. An incident process with named roles, because incidents now involve people who don't all know each other. Some form of levelling, once the same fairness argument has surfaced two or three times. And a real on-call rotation with a threshold that converts pain into roadmap capacity.

What still doesn't qualify: a formal review cycle, an architecture board, a project management office, or anything with the word "governance" in it.

The test I'd apply to every proposed rule is one sentence: name the failure this prevents and when it last happened. If nobody can, it doesn't go in.

Where the first platform pain shows up

Usually right here, and it announces itself as duplication.

Two teams have each built their own way to do the same thing, differently, and both got some of it wrong. That's the two-occurrence signal from the platform lesson, and it's the point at which centralising becomes cheaper than not.

The right response at this size is small: a rotation, or one or two engineers on the paved road for a quarter, with a named list. Not a department. A platform team formed here, before the pain is well understood, will build abstractions for problems the org doesn't have yet, and you'll spend two years politely routing around them.

Keeping engineering close to customers

This is the thing that silently degrades in this band and is very expensive to rebuild later.

At twenty engineers, some of them talk to customers by accident. At fifty there are layers, and every layer is a translation, and eventually you have engineers who have never watched anybody use the thing they build. The consequences show up as a thousand small decisions made slightly wrong, and as a gradual loss of the judgment that made the early team good.

Two mechanisms, both cheap. Every engineer does a support rotation, a day a month, actually reading tickets and responding. And engineers attend customer conversations as part of the discovery track, not as a treat.

Both get cut during busy quarters. Both are worth defending, and the argument to make is that they're an input to quality rather than a nice-to-have.

The culture drift starts here

Under twenty, culture transmits by contact. People absorb how things are done by sitting near people who do them.

Somewhere in this band, most of your engineers joined after the founding period, and the transmission chain gets long enough that the copy is a copy of a copy. Nothing dramatic happens. The standards just get slightly softer at each hop, and eighteen months later you notice that code review has become a formality and nobody quite knows when that happened.

The counter is to make the implicit explicit, once, in writing, before it drifts: how we do code review, what "done" means, what we expect from an on-call shift, how decisions get made. Not a values poster. A short set of operating norms with examples.

The other counter is your own behaviour, which is being read much more carefully than at twenty people, because fewer people have direct access to you and everyone is inferring from what they can see. What you ask about in the demo, what you let slide, how you respond to bad news: those set the standard for people you've never spoken to.