There is a specific point in the growth of an engineering organization where the job stops being a larger version of the previous job and becomes a different one. For me it arrived somewhere past 60 people.
Below that, you can know every engineer, follow most technical decisions, and intervene directly when something drifts. Above it, every one of those habits becomes a bottleneck. The organization — now 90+ engineers across 12+ cross-functional squads spanning web, mobile, backend and platform, and the thing that determines whether it works is no longer my judgement. It is the quality of the judgement of the 12 engineering managers and tech leads between me and the work.
The transition nobody warns you about
The instinct that made you effective as a hands-on leader — see a problem, engage with it directly — becomes actively harmful at scale. Not because the intervention is wrong, but because of what it teaches.
Every time a director resolves something that belonged to a manager, three things happen. The immediate problem gets solved. The manager learns their judgement is provisional. And the organization learns that escalation is faster than ownership.
The third effect is the expensive one, and it compounds silently.
The discipline is to intervene in the system rather than the instance: if a decision was made badly, the useful question is what context that manager was missing, not what the right answer was.
Hiring managers is a different problem from hiring engineers
Engineering hiring has decades of accumulated practice behind it. Manager hiring, in most organizations, has almost none — and the failure mode is consistent: promoting the strongest engineer on a team and assuming leadership transfers.
Sometimes it does. Often what transfers is a strong sense of how the work should be done, combined with no framework for getting it done through other people. That produces a manager who is still, functionally, the team's best engineer, and a team that has quietly stopped growing.
What I look for instead:
- Can they be specific about someone else's growth? Strong manager candidates describe how a particular person improved and what they did to help. Weaker ones describe what their team shipped.
- Do they disagree well? A manager who cannot push back on me will not protect their team from me either.
- Can they hold ambiguity? Roadmaps at this scale are perpetually incomplete. Managers who need certainty before acting transmit their anxiety downward.
- Do they think in systems or in incidents? The tell is whether their instinct after a problem is to fix it or to ask why it was possible.
Squad structure is an architectural decision
Team boundaries become system boundaries. This is Conway's Law, and it is not a warning — it is a design tool, if you use it deliberately.
We organise squads around customer-facing capability rather than technology layer. A squad owns onboarding, or checkout, or search — end to end, across web, mobile and backend — rather than owning "the mobile app" or "the API".
The cost is real: it requires engineers comfortable across the stack, and it makes deep platform specialisation harder to sustain within a squad. We offset that with a small number of genuinely horizontal teams, including a dedicated performance team whose remit spans the whole estate.
The benefit is that a customer-visible change usually lives inside one team's boundary. Coordination cost is the dominant tax on large organizations, and capability-aligned squads are the most effective way I have found to reduce it.
The heuristic
If shipping a routine customer-facing improvement requires three teams to agree, the boundaries are wrong. That is an org design problem presenting as a delivery problem, and no amount of process will fix it.
What you actually control at this scale
Very little of the work, directly. What remains is more leveraged than it first appears:
Who you hire and promote. Every appointment is a statement about what the organization values, read far more carefully than anything said in an all-hands.
What gets measured. Teams optimise for what is visible. Choosing to publish per-release quality and footprint scorecards changed behaviour more than any amount of encouragement to care about quality did.
What you consistently refuse. Standards are defined by what you decline to ship, not by what you say you value.
How you respond to bad news. This one sets the ceiling on everything else. If the first reaction to a problem is to look for who caused it, you will get later, quieter, more expensive problems. If it is to ask what made it possible, you find out early enough to act.
The uncomfortable part
The transition costs something genuine. I am further from the code than I have been in twenty years, and the feedback loop on my own work has stretched from days to quarters. You stop being the person who solves the problem and become the person accountable for whether it was solvable.
What replaces it is a different kind of leverage: watching a manager you hired handle something you would have handled yourself two years ago, and handle it better than you would have. That is the actual output of the job at this scale — and it is only visible if you have stopped measuring yourself by what you personally shipped.