Wrong at scale

Every planning cycle produces the same ask: more people. It is the easiest request in product, because capacity is easy to count. Headcount, story points, the number of bets running at once. Easy to count, easy to defend, easy to grant.

When the product is itself a system, it is also usually the wrong ask. A system here means infrastructure, developer tools, platforms, APIs: the products other teams build their own products on top of.

Capacity is a stock: how much your org can do at once. Capability is a rate: how fast you can turn something you just learned into a shipped change, done well enough that the next change gets easier. A small team with high capability beats one twenty-five times its size with low capability, because the small team is running a tighter loop.

The two are easy to confuse because they look the same in a good quarter. When the plan is right, the org that ships more wins, and shipping more looks like a headcount problem. The difference shows up when the plan is wrong. For a systems company that is most quarters. The infrastructure under you changes. A partner becomes a competitor. The usage you designed for stops showing up. Then the winner is not whoever executes the old plan fastest. It is whoever notices first, decides first, and regroups without losing the quarter.

The loop is the unit of work

The winning sequence has a shape: notice, decide, regroup. Run on purpose instead of by accident, it is a loop with three capabilities. Each one can be built, and none of them is bought with headcount.

Sight

Sight is a picture of the future specific enough to rule options out. The key word is specific. Every team has a vision statement. Almost none have sight.

The tell is the roadmap. A team with sight can name the customers it will not serve, the work it will not take on, the products it will not build. A team without sight has a roadmap that is really a wish list. Everything is still possible, so nothing is decided. That feels safe. It is not. Every option you keep open is a decision you will have to make later, in a worse week, with less time.

This week: open your roadmap and write down three things it rules out: one customer you will not serve, one kind of work you will not take on, one product you will not build. If you cannot get to three, you have a wish list. Bring the three to your next planning meeting and say them out loud. The argument that follows is sight being built.

Conviction

Conviction is holding the trajectory through the quarter where the numbers argue against it. Every real strategy has that quarter. The new architecture is slower before it is faster. The new market buys less than the old one did. If you only stay the course when the numbers agree, you do not have a strategy. You have a dashboard with opinions.

And conviction is not stubbornness. Conviction means the bad quarter was in the plan: your picture told you it was coming and roughly what it would look like. Stubbornness is pushing through a bad quarter your picture never predicted.

This week: write the memo your future self will need. For the strategy you are holding right now, put down which quarter will look bad, which numbers will argue against you, and roughly what they will say. Date it and send it to your team. When the bad quarter arrives, that memo is the difference between holding course and hoping.

Adaptation

Adaptation is changing the route without moving the destination. Both halves matter, and teams fail in both directions. Some change nothing, because staying the course looks like leadership and the old plan has friends. Others move the goal every time the road gets hard and call it agility. After a real adaptation, the destination is the same and only the path changed. If you cannot say which one changed, you did not adapt. You drifted.

The hard part is telling signal from noise, because everything arrives looking urgent. Every outage, every competitor launch, every angry customer is an argument for changing the plan this week. The filter is one question: does this touch something your users will still care about next year?

Noise

A metric having a bad month.

Signal

Anything that moves what your users actually pay you for.

This week: ask the filter question out loud the next time something urgent lands. In the incident review, in the competitor-launch thread, in the escalation: will our users still care about this next year? Most of what feels urgent fails the question in the room. What passes it is your next real decision.

Your picture of the future supplies that filter, which is why the three run in order. Sight decides what is worth holding. Conviction holds it long enough to produce a real result. Adaptation reads the result and adjusts the route. Then the picture gets sharper, and the loop starts again.

That closed loop is why capability grows. Each pass makes the next one faster: course changes get cheaper because the destination was never in doubt, and decisions get quicker because the picture keeps improving. Capacity does none of this. More capacity just does more of whatever you were already doing, faster.

If what you were doing was wrong, you now get to be wrong at scale.

Hiring for the loop

Hiring is where most orgs buy capacity on purpose and get capability by accident.

The default interview measures output. What did you ship, how fast, how big. Those questions assume the problems this person will face at your company are the ones they already solved at the last one. In a systems company that assumption breaks in the first quarter. The problems will be new. What you actually need to know is what this person does with a problem they have never seen before.

What I have learned to look for sits underneath the resume: a plain love of figuring things out. The best engineers I have worked with are not the smartest people in the room in the abstract. They are smart the way people are smart about things they love. They cannot leave a problem alone. They ask the question behind the question in the first ten minutes. Hand them a broken system and they light up. That appetite is the raw material of capability, because a person who loves the problem runs the loop by themselves. They form a picture, they hold it through the ugly middle, and they change course without being told.

This week: change one interview. Replace “walk me through what you shipped” with a real problem from your own backlog, one that cannot be answered from memory, and then say as little as possible. Score the ten minutes after the candidate runs out of known answers: what questions they ask, whether they can leave it alone, whether they light up or stall. Write down their questions, not their answers. The questions are the aptitude.

That changes the manager’s job too. Hire for output and you have to point every person at every task, and the whole org moves at the speed of whoever does the pointing. Hire for appetite and the job becomes: show them the path, then let them loose.

Showing the path means saying the picture out loud, in three sentences your team can repeat without you in the room:

• Here is where we are going.
• Here is what we are not doing.
• Here is the quarter where this will look like a mistake.

If you cannot fill in the third sentence, the problem is not the team. Letting them loose means staying out of the route and saving your vetoes for the destination. The slowest orgs I have seen were not short of talent. They were full of people hired for their appetite and then managed like capacity.

What this looks like in practice

When we scaled an infrastructure platform through its steepest growth, the constraint was never how many engineers we had. It was how quickly we could see a change in how customers used the platform, decide what to do about it, and change the roadmap without chaos.

The clearest example was checkpointing: saving a complete copy of a running program, everything loaded and ready, so that the next start takes seconds instead of minutes. It is a very hard problem, and it does not fit in a quarter. Saying yes to it meant saying no to several easy wins.

What made the call possible was not that month’s numbers. It was the filter. We knew our users would still care about two things next year: paying less and going faster. Starting in seconds instead of a minute moves both at once. So checkpointing passed the filter, and we held on for multiple quarters while the problem argued back. The outages and competitor launches that arrived during those quarters did not pass the filter. They were the noise.

On paper the feature was capacity: more compute per dollar, faster starts. That is not what customers did with it. Once they stopped engineering around slow starts, they changed their own systems faster. They shipped models more often. They tried things they used to ration.

It looked like we were selling them capacity. We were selling them a tighter loop.

Checkpointing was about when to commit. Global routing was about how well. Everyone in our market shipped multi-region support, running the same product from data centers around the world, within a few quarters of each other. On a comparison page the feature looks identical. In production it was not.

We knew exactly who ours was for: teams running real-time workloads, where every millisecond counts, in industries with strict rules about where data can live. Knowing that decided everything early. Where the regions went, how data stayed where the law requires, what happens when a region fails. A feature built for a specific customer runs deep. The same feature built to fill a comparison page runs exactly as deep as the page. Feature parity is what a roadmap sees. Capability is what your customer’s traffic sees at two in the morning.

The teams that lost were not smaller, and their feature lists were not shorter. They were slower to change their minds, and shallower when they committed.

This is the whole argument. The rest of the writing here is footnotes to it.