20 min read
You have ten engineers who could ship the next quarter alone.
You have forty more who, through no fault of their own, cannot.
The question on your desk this quarter, no matter how the budget memo phrases it, is where the AI investment lands. Across the floor, to bring the floor up. Or into the ceiling, to push it higher. Most CTOs answer “across the floor” without thinking. It is the safer answer, the more egalitarian answer, the answer your CHRO wants to hear. On the math, it is wrong, and the org chart you currently run is the residue of avoiding that math for a decade.
I want to walk through it, because AI just turned the lights on in a room you have been navigating in the dark since at least 2015.
The 20% Got Faster. The 80% Did Not.
Pareto applies to engineering output the way it applies to sales pipelines and bug reports. Twenty percent of your engineers produce roughly eighty percent of the work that ships and stays shipped. Capers Jones has been measuring this since the early eighties. DORA tells the same story from a different angle. Every honest engineering manager you have ever met has rank-ordered their team in their head and could name, right now, the four people they would not survive losing.
Most readers also read: The Engineers Who Can’t Use AI Agents Don’t Have a Tools Problem
AI did not change that distribution. It widened it.
Your top 20% with frontier model access is now producing five to ten times what your bottom 20% produces on the work that the company actually pays them for: architecture decisions, cross-system migrations, ambiguous requirements that need judgment. The gap was always there. It is now visible in commit history, in cycle time, in the Slack channel where the same four names answer every hard question. (If you doubt this, look at the team that shipped six months of work in five days when somebody in finance accidentally turned the rate limits off. They were already those people. Tokens just unblocked them.)
So here is the question your board is actually asking, even when they phrase it as “AI strategy.”
Do you spread the investment to bring the floor up, or do you concentrate it to push the ceiling higher?
The Coach Picked Matt B.
Track is the family sport. My uncle was an All-American. My older brother ran in college. I ran cross country and track in high school and went to college on an academic scholarship, which is the polite way of saying I knew exactly where I stood in the family rankings.
We had a kid on our team named Matt B. who could run the 400 yard dash faster than our 4×100 relay team’s total time. Matt B. was not on the relay. The coach kept him off it on purpose. Matt B. ran the individual events, the 100, the 200, and the 400, where his time was the whole answer and there was no handoff to fumble.
The relay was Matt S., Dan, me, and Ben C. Four of us. Three handoffs. Three sets of fresh legs taking the baton from the runner before. Matt B. could beat the four of us alone, on a single set of legs and lungs.
The relay team lost regularly. The handoffs were the entire problem. Sloppy baton exchanges. A second leg slow out of the corner. An anchor who cracked under pressure twice in a season. (I was the second leg one of those years. I have opinions about the corner.)
The coach had a choice about where to spend his attention. Drill the relay (handoff drills, baton work, conditioning the second leg, mental work for the anchor) and try to claw the four of us into a finals spot. Or invest the season in Matt B., where the leverage was: race film, recovery protocols, race-week tapering, individual-event strategy, so he could win the 100, the 200, and the 400 against the rest of the conference.
He picked Matt B.
He did not solve the relay’s handoff problem by putting Matt B. on the relay. That would have wasted Matt B. on a system bottleneck the four of us were the bottleneck of. He held Matt B. out of the team event entirely, deliberately, so the season’s attention concentrated on the races Matt B. could win alone. The relay would finish where it always finished. Matt B. would win three individual events. The math was the math.
The team won points at conference and regionals because Matt B. took the 100, the 200, and the 400. The relay team finished where it always finished. Nobody on the relay improved much that season. The four of us went to college on grades, on loans, or on something other than a stopwatch.
I had opinions about that coach for about a year. Then I read his job description.
The coach also has the trophy.
What Race Are You Actually Running?
The decision was downstream of a different question. The coach did not pick “individual over team” as a philosophy. He picked the race he was going to win. State meets are scored by total points, individual events score the same as relays, and given his roster his points lived in individual events. Everything else followed from that.
Most CTOs have never asked the equivalent question of their own roadmap.
You inherited a relay org. Specialized teams, handoffs between frontend and backend, separate platform and product engineering, security review as a gate, QA as a phase, release management as a function. Every handoff is a baton pass. Every ceremony is a baton-passing drill. You spent a decade trying to make those handoffs cleaner, because the relay was the race.
It is no longer the race.
The work that creates the most enterprise value today is distance work. Multi-system migrations. Long-context refactors. Production incidents that touch six services. Compliance rewrites that require holding the whole regulatory map in one head. These are 1500m races. They reward sustained individual judgment, not coordinated handoffs. A single senior engineer with frontier model access, a clean local environment, and ownership of the full vertical slice can finish them in days. A relay team will spend the same week scheduling the kickoff meeting.
You have been training relay teams to win distance races, and you have been losing.
Not Every Product Needs to Go Fast
The corollary to “what race are you running” is “what race is each product running.”
Most CTOs treat the roadmap like a single race. It is not. Your roadmap is a portfolio. Some of those products are in races that need to be won this quarter, the strategic bets, the new market entries, the platform rewrites your CEO has staked the year on. Others are mature products doing their job, generating revenue, requiring careful maintenance and the occasional feature, but not racing anyone. Others are in decline and just need to be carried responsibly until end-of-life.
Different races. Different runners.
Put the fast people on the products that need to win. The strategic bets. The market entries. The rewrites that, if shipped, change the company’s quarter. Let the operating org carry the products that need stewardship rather than acceleration. Mature platforms. Maintenance work. Compliance and reliability. Internal tools. The systems doing their job that need to keep doing their job for the next three years without drama. Those products are not under-served by being run by the operating org. They are correctly served. They do not need a Matt B. They need a Matt S., a Dan, a Ben C., and the discipline of a team that ships small, ships safely, stays on call, and does not break the things customers already pay for.
The strategic mistake most CTOs make is staffing every product with the same shape of team, then wondering why the strategic bets ship slowly and the mature products burn out the senior engineers who get pulled onto them every time something breaks. Stop staffing every product like every product is the same race. Match the runner to the race, the team to the product, and the budget to the team. The roadmap is a portfolio. Treat it like one.
$500K. Two Ways to Spend It.
Napkin math, the way I always do it, and you can correct it in your head if your numbers are different.
Fifty-engineer org. Loaded cost $250K per head, $12.5M in annual labor. Pull $500K out of next year’s tooling budget and call it the AI investment. Two options.
Option one. Spread the $500K across all fifty. Ten thousand per head in tokens, training, licenses. The bottom 20% improves a little, mostly on the parts of the work that were not the constraint. The middle 60% improves a bit more. The top 20% improves modestly, because you rate-limited the people who would have used twice the budget. Total weighted output gain, call it on the order of 25 to 30 percent on activity, which is not the same as 25 to 30 percent on outcomes that ship.
Option two. Spend the same $500K on the top ten, and understand that the money is the smaller half of the play. The bigger half is the assignment and the permission.
Put these ten people on the three problems on your roadmap that, if solved, change the company’s quarter. Not the cleanup tickets the senior engineers always end up doing because nobody else can. Not the platform paper cuts. The top-tier problems your strategy actually depends on, the ones currently stuck in a steering committee. Hand them over.
Then give those ten engineers permission to win. Frontier model access with the largest context window money can buy, no rate limits, removed ceremonies, direct executive air cover, and the explicit promise that nobody is going to ask them to attend a backlog grooming meeting for the next twelve months. Permission to ship without queueing for seven approvals. Permission to refactor what is in the way. Permission to say no to the meeting. Permission to be as good as they actually are.
Their output on the work that drives revenue moves into a different range, somewhere between two and four times what they shipped last quarter, because the constraint was never their skill, it was the system around them and the assignments they were not allowed to take. (The system also includes the codebase. A senior engineer in a clean modular stack ships at the top of that range. The same engineer in a twelve-year-old monolith ships at the bottom of it. AI does not fix the monolith.) The other forty engineers see no direct improvement from this lever and need a separate one, which I will get to.
I will be candid. The percentages above are illustrative and your mileage will vary. The shape of the gap will not. I have watched the option-two outcome land in directionally similar form at five companies in the last eighteen months, including the team that shipped six months of work in five days when somebody in finance accidentally took the rate limits off. If your CFO needs a model rather than a frame, build a bear/base/bull case off your own baseline and pre-register what you are going to measure before you start. The frame will hold.
Your CFO will look at option two and say it is risky. It concentrates value creation in ten people. What if they leave?
It is the right concern, and the right answer is not “they have always been the ten people” (which is true, and rhetorical, and not a plan). The right answer is to price retention into the option-two budget. Top-quartile comp, equity refresh, and a meaningful uplift on the people you are formalizing as critical: budget another $150-300K per engineer per year against the gain. Net it. Option two still wins by a wide margin. But the line item belongs in the model.
You Cannot Train Your Way From Relay to Distance This Quarter
This is the part that breaks executives.
Our relay team did not need more practice for the season we were in. We needed to be different athletes, and a season was not enough time. You can drill cornering for sixteen weeks and gain a tenth of a second. You cannot drill the second-leg sprinter into a Matt B. before regionals. I would know. I was the second leg.
Your relay org has the same problem on this quarter’s clock. The middle 60% of your engineering team is composed of capable specialists who were hired for a relay. They know one segment well. They were never asked to carry distance, and most of them did not optimize their careers for it. Training, tooling, and AI access will improve them at the margin in the next ninety days. None of it will turn them into the kind of engineer who can hold an eight-service migration in their head and ship it in a week, in the timeframe your board is asking about.
Some of them, given nine to twelve months of frontier access, deep ownership, and a real mentor, will absolutely cross into the distance unit. I have watched it happen. It happens slower than your competitive window, and the people who make the jump are usually not the ones the org currently labels as high-potential. So plan for it on a multi-quarter horizon, not a sixty-day one, and do not let the long-horizon answer become the short-horizon excuse.
This is not a judgment on those engineers. It is a judgment on the org you built and on the clock you are running against. You staffed for a relay. The race changed. The roster did not, and it will not in time.
Say this plainly, because it is true: the middle 60% are good people. Most of them are kind people. They show up. They mentor the juniors. They are the ones who answer Slack at eleven at night when production is on fire and the distance unit is asleep. Once you have decided what shape your org actually needs to be in, and once you have funded the operating org on its own thesis, most of them will eventually grow into the new shape. Not this quarter. Maybe not this fiscal year. But eventually, with a published door, real ownership, and clarity about where they are running to, the people you have are mostly the people you need. The mistake is asking them to make that jump in the dark, on a timeline they cannot see, while you yourself have not committed to the destination.
The CHRO answer (reskilling, internal mobility, AI literacy programs) is the relay coach saying he is going to drill harder on the handoffs. It is a real thing you can do, and you should do it as a parallel investment, on a parallel timeline. It will not produce the outcome you owe the board this year, but it is the investment that makes the org honest five years out.
You Have Two Orgs. You Are Pretending You Have One.
Here is what the actual answer looks like, and I am stating it directly because hedging on this point has cost the executives I work with real money.
You do not have one engineering organization. You have two, and you have been pretending it was one for a decade because the alternative was politically expensive.
The Distance Unit
The first org is a small, senior, distance-running unit. Ten to twenty engineers in a fifty-person team. They own the hard problems end-to-end. Frontier model access with no rate limits. No standups. No sprint planning. Full vertical ownership. A direct line to the CTO. They are measured on outcomes shipped, not activity logged, and they are paid in the top quartile of the market for their level. You build them deliberately. You do not let them assemble themselves by accident in the corner of the org chart.
You also do not let them ship into a vacuum. Whatever the distance unit builds has to land in the operating organization on day one without breaking it, which means a real handoff contract: documentation the platform team will accept, on-call rotation that includes the distance engineer for the first thirty days post-ship, and an explicit operability bar before “shipped” counts. Skunkworks that cannot be operated by the rest of the org are not wins, they are technical debt with a different cost center. Every distance leader I have watched succeed has built that handoff in deliberately, not bolted it on later.
The Operating Org
The second org is the operating organization. The other thirty to forty engineers run the platforms, hold the production line, handle the predictable work, keep the lights on. This org is not a consolation prize and it is not “tier two.” It is the org that determines whether your customers experience your company as reliable, and reliability is the asset your distance unit is allowed to bet on.
The operating org gets its own AI investment, on its own thesis, with its own KPIs. The distance unit’s thesis is feature leverage. The operating org’s thesis is reliability leverage. AI for incident response, runbook automation, on-call summarization, regression triage, platform self-service so product teams stop filing tickets to do trivial things. Different work, different metric set: MTTR, change-failure rate, percentage of platform requests resolved without a human in the loop, hours of toil eliminated per quarter. Fund it at parity per head with what you spend on the distance unit. If you do not, the operating org reads the budget memo correctly, and your strongest forty engineers, the ones with options, are gone by Q3. Loaded cost on regretted attrition in that group is roughly 1.5x salary plus a year of recruiting drag, which is real money, and it is the cost most CTOs absorb without ever putting it on a slide.
(Trying to compress this org into the distance unit’s shape is one of the cleaner ways to lose its best people. See the post about Jim’s top AI dev, who quit the day his manager tried to flatten his output back into the team’s pace. The same dynamic runs in the other direction when you tell a great platform engineer she is now in tier two.)
The Door
The two orgs are not castes. They are postures, with a published door between them.
A clear door is the difference between a healthy two-org structure and a permanent two-tier system that your CHRO is correct to refuse. Publish the criteria for moving from operating into the distance unit (specific outcomes shipped, scope of ownership demonstrated, mentor signoff). Publish the rotation out: distance engineers do twelve-month tours, then rotate back into the operating org for at least a quarter to keep the unit from ossifying and to push distance-grade habits back into the platform. Both directions matter. The board sees a system, not a caste. The workforce sees a path.
The Conversation You Owe the Middle on Monday
If you do this, the middle 60% reads the org change before you finish the all-hands. Here is roughly what you say, and I will keep it in the voice you would actually use.
“We have decided to stop pretending that one engineering org structure works for both kinds of work we do. The work splits cleanly. We are going to staff it that way. We are funding two AI investments, not one, on two different theses. The distance unit is being formalized; the operating org is being funded at parity per head against a different metric set, because what you do is not less valuable, it is differently valuable, and we have under-invested in the tooling that makes your work compound. There is a published door between the two orgs in both directions. Comp bands are being adjusted up across the operating org as part of this, not just in the distance unit, because reliability work is what makes feature work bettable. If you have questions, your manager has them, your skip-level has them, I have them. We are not doing this in the dark.”
That is not a softening. It is the truth, said out loud, and most CTOs skip it because saying it commits you to actually funding the operating org at parity. If you are not willing to make that commitment, do not run the play.
Most executives I talk to have already accepted the two-org reality in their heads. They have a list of names. They know who their distance runners are. What they have not done is build the org around it, because the optics of formalizing it without the operating-org investment are uncomfortable, and they should be. Build both. Or build neither.
You can avoid the conversation. Most of your competitors will. The ones that do not are the ones you will lose to in 2027. (This is the same argument I made in the fifty million dollar question from a different angle: if you would not build the current org from scratch with the money and the people you already have, the only useful question is what you are going to do about it before someone else does.)
A Sixty-Day Pilot (Not an Experiment)
Here is what I would do this quarter if I were running your engineering org. Call it what it is, which is a pilot, not a controlled experiment. You are going to have selection effects (you picked the people you already think are best), novelty effects (no standups feels great in month one), and Hawthorne effects (they know the CTO is reading the weekly readout). That is fine. The point of the sixty days is not to publish in a journal, it is to generate a decision-grade signal you can act on in this fiscal year.
Pick your top ten engineers, or your top three or four if you are running a smaller team where pulling ten people would crater seven roadmaps. Rank by outcomes shipped in the last twelve months, not by seniority, not by performance review score. (Your performance review system is also a relay artifact, and we can have that conversation another day.) Acknowledge up front to their managers what is being borrowed and for how long, because pulling your strongest engineers off seven squads is a real cost and not one you can hand-wave past. Pre-negotiate the roadmap impact. Do not announce the pilot until the EM cost is on the table.
Give the pilot engineers frontier model access with no rate limits. Hand them full vertical ownership of the three most valuable problems on your roadmap. No standups. No sprint planning. A weekly thirty-minute readout to the CTO instead of two layers of middle management.
Define “outcomes shipped” before you start. Not story points. Not PR count. A short list, agreed in writing with the CFO and the head of product on day zero, of revenue-attributed features merged and accepted by the receiving team, P0 incident cycle-time reductions held for thirty days, or migration milestones hit and operable by the platform team. Pre-register the metric. The pre-registration matters more than the metric, because it is what stops you from moving the goalposts to the result you wanted.
Run it for sixty days. Measure outcomes shipped against the same ten engineers’ baseline from the prior sixty days, and against the rest of the organization’s same sixty days. If you can construct a small honest control cohort (engineers of comparable seniority kept on the existing system), do that too. It is not a clean control. It is better than no control at all.
If the delta on the pre-registered metric is not in the range of two to four times the baseline, you have learned something real, either about the play or about the math I just walked you through, and the dinner is on me. In my experience the delta lands. The interesting question is not whether it lands, it is what you do with the data.
If the delta is what I think it will be, you now have a number your CFO and your board can read. You can have the org design conversation with the case for the operating-org investment in parallel (parity per head, reliability KPIs, see above), and you can have it in this fiscal year instead of the next one.
The Trophy Is Still in the Case
The coach picked the race he could win, picked the athlete who could win it, funded the rest of the team enough to keep them in the program, and built the season around that math. The relay team felt slighted. The trophy is still in the case.
Twenty-some years later, Matt B. is a nurse. Ben is a lawyer. Matt S. writes code for a living. Dan is a Major. The medal count was a state-meet metric, not a life metric. The coach was right about the season. The season was not the whole game.
The race changed when AI changed the economics of distance work. The engineer on your team who can carry seven systems in her head and ship a quarter of work in a week is your Matt B. The platform engineer who keeps your production environment available enough to bet on what she ships is the rest of the team that gets to keep running. Both get funded. Both get a thesis. Neither gets pretended out of existence.
You can spread your AI budget thin across fifty engineers and make everyone fractionally better at handing off batons. You can pour it into ten people and let them carry the strategic bets. You can do the harder, more honest version, which is to build two orgs on two theses, fund both at the level the work actually requires, and put a published door between them so the people in the operating org can see the path.
The honest version is the most expensive. If you can fund all of it, the distance unit at frontier, the operating org at parity, real comp adjustments across both, and the conditions for every engineer in the building to be as good as they actually are, then do it. That is the right answer in every business case I have run. It is also the answer most boards will not write the check for in this fiscal year.
If you cannot fund all of it, the decision is yours.
Not the CFO’s, who will tell you what is affordable. Not the CHRO’s, who will tell you what is comfortable. Not the board’s, which will tell you what is impressive in a deck. Yours. You decide where the dollars land. You decide which engineers get the assignment and the permission. You decide which products get the fast people and which products get the team built for stewardship. You decide what gets funded enough to win and what gets funded enough to keep running.
The call you make about where the AI investment lands is the call you make about what your company will be in 2027. Make it deliberately. Make it on the math. Make it knowing that not deciding is also a decision, and it is the decision most of your competitors will make by default.
The trophy is still in the case because the coach decided.
You do not get to skip the decision and keep the trophy.
