RIP the org chart that assumed typing was the bottleneck

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.

At Life Happens I ran a technology organization across three continents. India-based contractors, typically five, peaking at fifteen for major projects. Support in the Philippines. About fifteen US W-2 staff company-wide. For part of that stretch I held engineering and customer success at the same time. As CTO I owned hiring, retention, performance, capacity planning, and vendor management for engineering. 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 to extract from others.

That design was not vanity. It was an answer to a real constraint. Code took time. Time took headcount. Headcount needed a shape so that 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 very concrete. One round trip per day. You cannot look over a shoulder. You cannot clarify at 2 PM. Whatever you left vague in the document comes back in the morning as work built on the wrong assumption, and you have burned a day. I learned to write specifications past the point that felt tedious, to define done before work started, and to treat a misunderstanding as my defect. I reviewed the artifact rather than trying to watch the process. Those habits were how you got production out of a team you could not interrupt.

They were still habits in service of production. The org chart counted producers. 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 just by adding readers. Verification is still human-speed. It gets worse if 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. 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. The org chart still looked like a production chart while the actual work was becoming a review chart. I assumed the CTO years would be the least relevant part of my background for this. So far they have been the most useful, and 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 decides what the agents and the remaining humans should do, reads enough output to catch mistakes, and answers for the result. Very little of that is software development in the old sense. It is accountability with a smaller authorship claim. 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 because I need 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 still rather have the person in the building than wait for a market that may not make them.

I would not staff customer success and engineering as if they never meet. I held both. I am not going to claim I hired customer success from zero. I will say that holding both functions taught me that the org chart's walls were a production convenience. That convenience is less valuable now. The expensive mistakes happen at the handoff.

I would plan headcount against review hours, not against 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 have a program to announce. I do not know if reading agent output trains the same muscle that writing used to train. I do not know what a junior career looks like if the productive junior work is the first thing that disappears. I do not know whether a smaller number of arbiters can cover a larger volume of generated work without the quality of the arbitration collapsing, which is the whole question hiding under every headcount plan I see.

I am still figuring that out. I would not trust a staffing model that pretends it is settled.

Related: Distributed teams, Agentic operator, Verification