It has taken me many years to recognise that one of the main differences between me and many others in the software development world, and part of what makes me good at software engineering management, is that I don’t just look at the piece of work in front of me, but also the one behind that (and beyond that, too).

I have previously heard several people in software engineering (and adjacent) roles say that roadmaps are only for product managers.

I think the opposite is true. An engineering manager can’t treat the roadmap of work as someone else’s problem. This is a hard thing to grasp for a freshly promoted developer who has been used to having this kind of thing dealt with for them.

At the team-scale, developers are used to:

• Talking with the product team about what their priorities are
• Building and prioritising the backlog accordingly
• Estimating the work
• Taking that work through to completion

What they don’t typically do is have a wider view on what that estimate means for the broader product timeline. A Product or Delivery manager will take care of that for them, and the only time an estimate might come up again is in a sprint retro that reviews velocity predictions (although I’ve seen very few of these).

But as a manager it’s important to be realistic about what is achievable in what kind of timeframe, what your margin of error is, and what the impact of that error might be.

If a task has been broken down to be deliverable inside of a week then you might accrue a day’s delay (and who knows, it might even be on time or early!) and that’s an off-by-one error which doesn’t seem too bad - but it’s also easy to see that the equivalent 20% error margin on a piece of much longer work (or a greater number of pieces) is a real problem.

This is part of why developers are generally so bad at planning for high-level, unrefined, quarterly deliveries. Ok, we’ve made a prediction for what we can do in this 12-week period, but if we overrun that by 20% when something is well-understood then we’re suddenly at over 14 weeks of work and whilst this might not be a problem inside of a delivery team (“just an extra sprint to wrap things up”), it certainly is once you realise that not only does your next quarter now only contains 10 weeks’ worth of developer time, but this compounds over the rest of the year and you’ve also lost your aligned planning between different streams of work.

So, rather than focus on why an estimate might be out by a fifth in the first place, it seems that the more valuable skill for a manager is being able to understand why that matters - to look beyond that one team’s needs and understand why the impact of that delay might be important to the bigger picture, and to be able to come up with ways of either communicating about it proactively, mitigating it or choosing to not start the work in the first place.

I am happy for a product manager to have a list of features they want, ideally in some prioritised order, but it should be the engineering teams owning and driving the roadmap for delivery of those features. And most importantly they should also be accountable for it.

In many places I’ve worked the engineering leads have been quite happy for delivery or product managers to take accountability for overall delivery - after all, when things are going well it means they get the credit! - but as a result of ongoing misalignment over the roadmap the relationships sour over time, trust between the different professions dissolves and there needs to be a periodic clearing of the figurative board whilst everything is reset.

It’s only by being accountable and deeply involved in the roadmap that engineering leads get better at planning, improve their communication and management skills and are able to build up high levels of trust in the other management professions around them.

The sooner managers treat planning with the same rigour they give to code and architecture, the stronger and more trusted their teams will become.

Planning isn’t bureaucracy - it’s the engineering of time.