When more engineers make delivery slower

Add engineers to an unclear objective and you get more work to undo. How to tell whether your next hire will speed delivery up or slow it down.

More engineers can give you more software to put right.

We've seen teams follow the requirements and miss what the product needs to achieve. The team builds each feature but overlooks why someone would use it or what happens next. Add engineers before anyone settles those questions and more of the product rests on unchecked assumptions. An earlier first version counts for little if rework delays a product people can use.

What the requirement leaves out

A requirement can describe a feature in detail and leave its purpose unclear. Engineers need to see how the feature serves the business goal and helps users complete their task. That context shapes the design: it helps them spot an unnecessary step or suggest a simpler way to get the same result.

Before they remove a step, the engineer and product lead need to check why it exists and what depends on it. Both need room to question the design as they build, with the agreed goal to guide their choices. A longer specification will still leave questions open.

Google's DORA research programme recommends that engineers take part directly in user research. When engineers watch someone use the product, they see details that a summary can miss. Engineers also need access to the people who make product decisions; a task list alone leaves them ill-equipped to take ownership.

When extra capacity adds rework

Split an unclear requirement across several people and you leave them to fill in the gaps. Each choice may make sense on its own, yet fail when a user moves from one feature to the next. When those choices clash, the team has to rethink the product decision, change code and repeat work it thought it had finished.

As the same mistake spreads through the product, the team has more work to check and correct. If experienced people have to leave planned work to resolve it, the disruption spreads. The business pays for the original build and the correction. Any headcount plan that counts only the extra output misses part of the cost.

New evidence from users may justify a change to the product. Rework is harder to defend when the business goal was clear but never reached the team.

Keep judgement close to delivery

We expect the delivery lead to stay close to the work and spot choices that put the business goal at risk. They should walk through the product as a user would and discuss what happens at each step with the engineers. Their job runs from the first business discussion to the check that the product delivers the agreed result.

When an engineer hits a constraint, whoever agreed the work needs to help decide what changes. The lead may need to reduce the scope or bring in a specialist. Specialists also need clear authority to decide within agreed limits. Otherwise, close involvement becomes another source of delay.

Review the product with users early enough to act on what they tell you. DORA's customer feedback guidance warns that a feature built to specification is no proof of success. The team needs to check whether users can complete their task, then use those findings to plan the next change. A demo of separate features cannot show whether the whole journey works.

Before the next hire

A small team on a tight timetable needs product judgement and engineering expertise throughout delivery. Engineers should question assumptions and suggest alternatives, then work through the consequences with the product lead. People bring different strengths. The team still needs product and design skills, whether it has dedicated specialists or brings them in as needed.

Hire for the work that needs to move. If the team knows what to build but lacks the time or skills, another engineer can help. If people interpret the same goal in different ways, resolve that before you add more engineers. A product or technical lead may be the more useful hire.

If five engineers joined on Monday, what could they help you deliver sooner?

A credible answer names useful work they would own once they understand the product. It also explains which decisions they would need help to make. If the answer is only that they would clear more tickets, the case for those hires still needs work.