The Ten-Minute Test Before You Fund More Engineers

Somebody will ask you for more engineers this year, and they will make a good case. Releases are slipping, and the plan has slid two quarters. Before you fund it, read the document the team was building from. Ten minutes. It usually settles the question, and it usually settles it against the headcount.

Almost nobody asks for that document. Diligence asks for the architecture, the source code, the cloud bill, the org chart. It rarely asks to see the spec behind the last feature that shipped late, which is close to the only document that tells you whether engineering is actually your constraint.

A specification is not documentation. It is a record of decisions that have already been made. Every line of it is somebody upstream of the code settling a question. What happens when the card declines? Can an admin undo this? Those questions do not go away when nobody answers them. They get answered later, mid-build, by a developer who has never spoken to a customer, in whatever way is fastest to build. The thinness of a spec measures how many product decisions have been pushed down into engineering, where they cost more and get made worse.

Someone who provides three bullets and a screenshot is asking an engineering team to guess. Concise is fine. Ambiguous is expensive.

Use your own numbers to calculate the cost. Take an engineering team’s loaded cost for one sprint (two weeks of work), then multiply it by the fraction of that time that gets redone because the requirement moved after work started. At $50,000 a sprint, every 10% of rework is $5,000. Hold that rate across the year, and it is $130,000 of engineering capacity. At 25% rework, it is over $300,000, which is more engineering capacity than the hire they are asking you to approve. It stays invisible because rework is logged as development.

Now put the headcount request against that. If a quarter of the team’s output is rebuilt work, adding engineers buys more attempts at an unanswered question. You pay for the capacity, wait two months while the new people ramp up, and end up with the same slipped release and a larger burn.

In my first week at an enterprise software company, I asked the engineering team why features kept slipping. They had an example from that week. A new senior engineer had been handed a ticket that linked to other tickets, which pointed to documentation and Figma files that were supposed to add up to a feature. He spent half a day assembling that into something he could build from. An hour in, he found the feature already in the product. It had shipped a year earlier.

He found the ticket it was built from too, and it was the better-written of the two. Had he finished his version, it would have shipped less complete than the one already there.

Nobody in that story was slow.

It still reached me as a question about engineering speed.

The funding request arrives in a second form now, and it moves faster. Instead of six engineers, it is a tooling budget and a promise that AI coding agents will close the gap.

Run that through the same test. An agent can read the codebase, which tells it how the system behaves today. What it cannot read is why. It was not in the meeting when somebody explained that the invoice has to round that way, and it has never spoken to a customer. The spec is the only place its intent comes from. Hand it three bullets and a screenshot, and you get something plausible, and a lot of it. The guess did not go away. It got cheaper to produce and harder to catch.

Writing an unambiguous instruction has quietly become a scarce skill, and it is still staffed like a common one. It used to be a chore a good engineer could route around by walking down the hall to ask. Now it is the input, and everything downstream is capped by it. It is also the cheapest thing you will ever interview for. Ask a product leader to send you the last spec they wrote themselves and read it the same way.

A good CTO will give you a great objection to this, and it doesn’t sound wrong at all. Requirements change. Customers do not know what they want until they see it working. He’ll quote the Agile manifesto at you. Working software over comprehensive documentation. What you are asking for is a six-week requirements phase that will be wrong by the time it ships. That is waterfall wearing a new name.

The manifesto says over, not instead of. And the better half of that objection is right. Some questions cannot be answered until somebody uses the thing. But the test is whether the decisions that were already knowable got written down. Whether an admin can undo the charge was knowable, and nobody needed working software to settle that. Length was never my question. A good spec can be terse. The test is whether a developer could be wrong about it. Three bullets and a screenshot fails that test on ambiguity. He could build almost anything from it and still be inside the lines. A document nobody can be wrong about is a picture of a finished kitchen. It never says where the outlets go.

You should not have to be an engineer to read a functional spec.

Do this at your company this week. Pick the last two features that shipped late. Pull whatever the team was working from: a ticket, a Figma link, a Slack thread. Read it and ask whether you, personally, can tell what done means, and whether someone could have been wrong about it. You do not need anyone to walk you through it, and nobody has to be honest with you for it to work. That is what makes it worth running.

This is not a year three problem. It is producing rework right now, and it is being misread right now, and the misreading costs more. Slipping releases get answered with a new CTO or a bigger team, and both of those take a year to prove out. What will not matter before exit is which tracker they use, whether they run Scrum or Kanban, or which model their editors are wired to. Those get audited constantly and explain nothing. The spec sits upstream of all of it.

The fix is usually product capacity rather than engineering capacity. The problem is those roles are harder to approve because a product manager ships nothing you can point at, and slower to fill because good ones are increasingly scarce. It is not always capacity. Sometimes decisions aren’t being made because nobody owns them, and a second product manager just joins the same queue. You will also be telling a chief product officer that his function is the constraint, and he should fight you on it, because some of the time you will be wrong.

This test lies to you in one place. When the requirement is a number, there is nothing to specify. Cut latency in half, take 30% out of the cloud bill, get uptime to four nines. The ticket can be one line, and the acceptance criterion is the metric. A thin spec is right there. Ask those teams a different question.

The document that will settle it is ten minutes of reading and already written; ask for it. If it’s vague or (worse) they can’t produce it, you don’t need more engineers; you need product ownership.