A roadmap that moves right every quarter
The plan at the start of the quarter looked reasonable. Three features, a couple of improvements, some cleanup. By week six, one feature is half done, the improvements have not started and the cleanup was never going to happen. The next planning session starts by moving everything along a column.
Your developers are not slacking. They are answering support questions, fixing whatever broke last night, reviewing each other's code, joining sales calls to explain the API and patching the thing that nobody else understands. The roadmap gets the time that is left.
It is not only headcount
The first instinct is to hire. Sometimes that is right. But in a small team the slip usually has more than one cause, and more people only fixes one of them.
| Cause | What it looks like | Would more developers help? |
|---|---|---|
| Unplanned work | Support, urgent bugs, interruptions eat half the week | Partly, if someone owns it |
| Fragile code | Every change takes longer because nothing is tested | Only if they also fix the foundation |
| Unclear priorities | Work switches as new requests arrive | No |
| Specialist gaps | A feature needs skills nobody on the team has | Yes, with the right skill |
| Genuine capacity | Everyone is productive and still behind | Yes |
Adding developers to a team with unclear priorities just produces more half-finished work. Adding them to a team where two people spend half their time on support can free those two people to build.
What the slipping costs
Customers who were told a feature was coming start asking when. Sales starts promising with caveats. The team feels permanently behind, which is tiring even when the work itself is fine. And the cleanup that would speed things up never gets scheduled, so each quarter is a little slower than the last.
There is a competitive cost too, although it is hard to see from inside. A rival with a similar product ships the integration your customers asked for first. Nobody tells you they chose the other supplier because of it; the renewal just does not come back.
And there is the people cost. Good developers want to finish things. A team that spends every quarter apologising for the last one starts to lose the people it can least afford to lose, which makes the next quarter worse again.
How we add capacity that actually helps
- Look at where the time goes. We review the last few weeks of tickets, commits and support with your team to see how much went to roadmap work and how much to everything else.
- Pick a workstream that can be split off. Good candidates have clear boundaries: an integration, a reporting module, the admin area, the bug and support queue, a mobile app that talks to your existing API.
- Add developers from SpiderHunts to that workstream. They work in your repository and tools, follow your review rules and join your planning.
- Protect your core team's focus. If our developer owns the support and bug queue, your people can plan roadmap work without constant interruption.
- Pay down the debt that slows everyone. Where fragile code keeps adding days to every change, we add tests and tidy the worst parts as part of normal work rather than as a separate project nobody approves.
- Review regularly and adjust. If a workstream finishes or the balance changes, the arrangement changes too.
Sometimes this review shows that capacity is not the main problem. If the real issue is priorities changing every week, we will tell you, because adding people would cost you money without moving the roadmap.
What a steadier quarter looks like
Your core developers spend most of their week on the product decisions only they can make. Separate workstreams move in parallel instead of queueing behind each other. Support and bugs have an owner. Planning becomes a matter of choosing what to build next, not deciding what to postpone again.
Quick check
- Most roadmap items finish later than planned, and it has been that way for several quarters.
- Your developers spend a large share of the week on support and urgent fixes.
- There are features waiting on skills nobody in the team has.
- Small changes take longer than they should because the code is fragile.
- You want more output without losing control of the product.