Engineering Team Roadmaps

• how do you balance engineering wants and needs vs. product demands?
• how do you get engineers to focus on meeting priorities?
• should roadmaps include technical investments?
• should sprints have allocations to both product and technical investments?

Most roadmaps for engineering teams commit the sin of only including new features and functionality. This does a major disservice to the engineering team.

Originally published on Medium

I had a colleague that used to repeat a phrase about 90% of the cost of software was the operating and maintenance rather than the building. The number may be wrong, but the point can’t be ignored. A large part of any software effort is in the maintenance and operating of what has already been built. The greenfield* aspects simply aren’t the majority of the total effort. So why do most roadmaps only represent the new and “coming soon” functionality?

I’ve been involved in quarterly planning where teams present their roadmap. The idea is that dependent or associated teams can predict and collaborate. Obviously, roadmaps are used to inform leadership of plans as well. We’re trying to predict the future and let others know our predictions. However, by only presenting new functionality, the roadmaps are leaving out a huge part of what most teams do. It may be a given that teams support the existing software, but if roadmaps are being used to convey to leadership where effort is going, roadmaps should include it. Maybe a roadmap of new functionality should be presented separately to leadership?

Most teams I have worked on commit a similar sin in Sprint Planning. How many teams actually reserve or commit time to support, paying down technical debt, upgrades, etc? Very few in my experience. Without consciously committing time either in a Sprint or on a roadmap, we’re essentially lying to ourselves. We’re painting a rosy picture that isn’t going to reflect reality. On some recent teams, we had everyone agree to 30% of total points should be going to paying down tech debt and maintenance. It was a good start. It was better that we had agreement from everyone and the visibility into the efforts.

Maybe we need to take a step back and double down on what a roadmap is. A roadmap is a best guess of a list of priorities. Some get elaborate and have timelines and aspirational goals. Ignore that. When you boil it down, a roadmap is just a list of priorities. Hopefully in order. Probably organized into sprints or quarters or some measure of timeline that inevitably won’t be met. That sounds pessimistic, but again, roadmaps don’t include the full picture. They represent aspiration outcomes based on things like dependencies. Most could and probably should be replaced with a list of priorities including the justifications of those priorities.

In many organizations, roadmaps are put together by people outside of engineering. They may even present those roadmaps without any input from engineering. Yes, I’ve experienced this. No, it was not pleasant. Feelings were hurt. You can imagine how it went. Needless to say, the roadmap wasn’t delivered as presented. Total waste of time and effort.

One step towards making roadmaps better may be a ceremony where all parties are represented. Meaning stakeholders from product and engineering and possibly even leadership if they can attend. Prep work should be done, especially by engineering. Typically, the majority of any given team is engineering. If that is the case, they have the biggest responsibility in setting proper expectations. Managers should being able to articulate with metrics what priorities exist. They may not perfectly line up with what the organization wants, but they can’t be ignored. If priorities can’t be ranked, then everything turns out to be a priority, which means nothing is a priority. This is demoralizing. Things spiral and engineers feel like they aren’t working towards a goal of shipping things that matter.

Roadmaps are not bad things. They can be motivational even. Roadmaps are an opportunity for managers to motivate their teams. Showing the teams there is a plan and it aligns with the greater business can be very motivating. Having the teams input on things like paying down technical debt represented on a roadmap can give a sense of validation, of being heard.

Carrying roadmap priorities into Sprints keeps everyone focused. It’s when the inevitable happens and teams have to veer off from the roadmap to spend two sprints on support fire-drills or shifting large pieces of a codebase, that focus can be lost and possibly never found again. My advice is to try and represent those items on the roadmap so you aren’t veering off, having to find your way back.

Roadmaps have been perceived as everything from vaporware to great things on many teams I have been a member of. Some teams seem them as a necessary evil required by old school organizations. Some teams see them as an exercise in collaboration. Those things are polar opposites. If your team is struggling to find focus and direction, you may want to take a step back and take a look at your roadmap. Do you have one? Does everyone have a shared understanding of the items on it? Is it clear what the priorities are? Is the short term defined with detail? Is the long term outlined? Is the real day to day efforts represented in some fashion or completely ignored? Does the focus of your Sprints align with the priorities listed on the roadmap?

If you are struggling to include items like support and tech debt on your roadmap, one tip is to list them as “technical investments”. Maybe they are designated differently than feature work. I can’t take credit for coining the term, but I’ve done this in the past and it resonated pretty well. The top half of the slide was new feature work, the bottom half was technical investments. Leadership was a little thrown off by the change in presentation, but once they understood, they appreciated the mindset of “investing” in our systems. It showed maturity on our part. It showed we understood systems require maintenance and we weren’t going to abandon it to do the dreaded “rewrite” in a year.

It can be refreshing to take a step back and exam your roadmap. After collecting some information from your team on their priorities, try representing them on your roadmap before your next presentation to other teams and leadership. And lastly, do a presentation to your own team. One last sin I have seen repeated over and over is teams not seeing their own roadmap. If an engineer ever says, “do we have a roadmap, I’ve not seen it”, it’s a sign that the team doesn’t know the priorities or how what they are being asked to build fits into the big picture. Don’t commit that sin!

• Did you know that greenfield comes from the construction industry referring to building in green fields? The origin being a literal meaning. Fields that were green meant they hadn’t been built in previously so you didn’t have to take into account or consider building around existing structures. Wikipedia