← Posts

The org chart assumed typing was the bottleneck

Team structure, headcount planning, and career ladders were all designed around a constraint that no longer binds.

5 min read

Engineering teams were designed around the cost of producing code. Team size, career ladders, and the ratio of senior to junior engineers all need another look now that production is no longer the main constraint. I am not saying this from a whiteboard. I am saying it from the last org I actually ran: a technology organization across three continents, engineering contractors in India, support in the Philippines, staff in the US. As CTO I owned hiring, retention, capacity planning, and vendor management. That org chart, like every org chart I have worked inside, assumed that typing was the bottleneck.

What the org chart was solving for

Team size is a communication-cost artifact: you add people until coordination costs more than the extra production is worth. The senior-to-junior ratio is a throughput calculation: seniors produce, and they also manufacture more producers. The ladder is a proxy for production capacity: titles mark how much of the expensive thing, correct code at volume, you can be trusted to emit or extract from others.

That design was an answer to a real constraint. Code took time. Time took headcount. Headcount needed a shape so managers could plan, finance could forecast, and people could see a path that looked like progress. I used that shape. I hired into it. I reported against it.

Distributed teams made the production assumption concrete: one round trip per day, no shoulder to look over, no clarifying at 2 PM. I learned to write specifications past the point that felt tedious, to define done before work started, and to review the artifact rather than the process. Those habits were how you got production out of a team you could not interrupt. But they were habits in service of production. The org chart counted producers, and review was a gate on the way to more output, not the thing the org was built around.

Which of those constraints just moved

Production capacity is no longer mainly a headcount question. A smaller group with agents can emit what used to require a larger one. That does not make the work free. It moves the cost.

Review capacity is the constraint that remains, and it does not scale the same way. You cannot parallelize judgment by adding readers. Verification is still human-speed, and it gets worse when the readers are far from the material. A senior person can only read so much plausible output in a day, and the output got cheaper faster than the reading did. The bottleneck moved from fingers to attention, and attention does not hire like fingers do.

The junior pipeline is the part of the ladder I do not see a clean replacement for. The rung that produced seniors was the rung that got automated: the production work that used to train people. Juniors became seniors by writing a lot of code that was a little too hard, in public, with someone who could still feel the material standing nearby. If that work is now the first thing the model does, the training loop loses its reps, and the senior bench becomes a stock that is not replenishing. I do not know if that is already happening at scale. I am saying the mechanism is obvious. We automated the apprenticeship's homework and kept the exam.

The offshore loop prepared me for agents more than I expected. Specify, wait, review the artifact. One round trip. A misunderstanding is your defect. That is already the agent loop. I assumed the CTO years would be the least relevant part of my background for this. So far they have been the most useful, not because of the title. Because of the constraint.

What I would build if I were staffing today

Fewer producers, more arbiters. The role that has no settled name yet is closer to an agentic operator than to a tech lead from 2016: someone who decides what the agents and the remaining humans should do, reads enough output to catch mistakes, and answers for the result. If I were drawing a chart now, I would draw around that job, not around a pyramid of typists with a manager on top.

I would still hire juniors. Not for cheap typing. Because I do not know another way to grow the next people who can arbitrate. I would hire them into a review-heavy practice, which is a worse apprenticeship than the one I got, and I would say that out loud in the offer. I would not pretend that reading generated diffs is the same education as writing the first ugly version.

I would not staff customer success and engineering as if they never meet. I held both, and holding both taught me that the org chart's walls were a production convenience. The expensive mistakes happen at the handoff. And I would plan headcount against review hours, not tickets closed. I do not have a formula for that. I planned the other way, because that was the job.

The part I do not know

Whether apprenticeship can be reconstructed at all. I do not know if reading agent output trains the muscle that writing used to train, or what a junior career looks like when the productive junior work is the first thing that disappears, or whether a small number of arbiters can cover a growing volume of generated work without the quality of the arbitration collapsing. That last question is hiding under every headcount plan I see, and I would not trust a staffing model that pretends it is settled.