Start Finishing: The One Rule to Survive Q4
Planning season has a familiar rhythm. Leadership commits to new initiatives.
Stakeholders promise new scope.
Someone asks if the team can take it on, and the answer is always yes in principle, while the current backlog quietly keeps not finishing.
I watched this happen inside an organisation with 30-plus developers, plenty of budget, and a delivery queue that still had not cleared its own carryover.
The team was not short of activity. It was short of finish.
This is the trap I call Start Finishing.
In delivery, we reward starting. Starting feels like progress. It creates visibility. It signals that work is being done.
But throughput is not starts. Throughput is completions.
A team that starts everything finishes very little. A team that finishes everything starts a lot.
In Operations Science, this is not a productivity argument. It is mathematics.
Little’s Law says flow depends on work-in-progress. If you keep pushing work into the system, WIP rises and wait time follows. The uncomfortable consequence is that adding more starts does not add throughput. It adds queue. Queueing happens every time a system accepts more demand than its constraint can process.
That is why the standard “start more, promise more” approach fails under planning pressure. It fills the pipeline with ambition and starves it of completion.
Let’s check the numbers.
In a recent engagement, the system was carrying roughly 94 tickets in WIP with a 71-day lead time. That is not a pipeline. That is a car park.
Notably, this was not caused by idle teams. It was caused by intake. Work was being pushed in faster than any downstream stage could convert it into a done ticket.
The conclusion was not “hire more people.” It was stop starting so much.
The first move was not a new deliverable. It was a cap: a WIP limit to force the team to finish items before pulling new ones.
Starting is a local decision. Finishing is a system decision.
Local decisions look correct at the point they are made. A stakeholder adds a ticket. A manager agrees it at planning. Each individual decision makes sense. But the aggregate is a system that accepts more than it can finish. That is the difference between Start More and Start Finishing.
- Start More feels good in the moment and hurts later.
- Start Finishing feels constrained in the moment and helps continuously.
The fix is structural, not motivational. It is not “teach people to finish.” It is about making starting the controlled part of the system.
- Set WIP limits per stage. Nobody pulls new work until the current WIP is within the limit.
- Make intake explicit. New work must cross a governed intake gate, not arrive by default at planning.
- Subordinate new work to real capacity. Commitment must be based on what can legitimately leave the system, not what can be accepted into it.
- Measure completion, not starts. Report throughput, lead time, and carryover - the metrics that show whether finishing is improving.
- Put a buffer in front of the constraint. Protect the rate-limiting step from feast and famine so the whole system beats to the drum of completion.
Why this matters for Q4
Q4 is the worst possible time to start more work. Budgets are being set, deadlines are being named, and every new initiative carries the political cost of pulling it back.
If the team carries inflated WIP into Q4, the season does not deliver faster. It delivers slower, under more visible scrutiny.
The strongest planning move is finish-first, not start-first.
At CHughes Consultancy, we combine the Psychology of People with the Physics of Flow to build engineering organisations that are mathematically efficient and culturally resilient.