That's not a Road Map
Have you ever been shown a “road map” meant to outline business and engineering plans? What did it look like? I’ve encountered plenty, few were what they claimed to be. Many were simply a waste of time.
The truth is, I believe road maps are incredibly valuable and essential for effective development planning. They can help with being truly agile, making informed decisions, addressing technical debt, and fostering clear communication. Disagree? Perhaps you’re thinking of the kind of road maps I mentioned earlier. But that’s not what I’m talking about. Read on.
The Worst I’ve Seen
This is my “favorite” bad example. These so-called “road maps” typically outline where the business aims to be in financial terms over time. I say “aims” because this isn’t a forecast based on the current state; it’s simply the desired “plan”. Put another way, “We’ll be rich”. If that’s all it takes, I could draw up road maps for winning the lottery. Often, these maps fail to provide any real insight into how those “goals” will be achieved. Presumably, that’s left for others to figure out.
This isn’t a road map; it’s wishful thinking. Not only does it fail to outline the necessary steps, but it also creates an illusion of control where, in reality, there’s very little.
Typical “Road Map”
Does this look better than the previous example? It does illustrate what needs to be done. Let me highlight one word in “road map”:
Road »Map«
Do you see it? I emphasized the word “map”. Does this example resemble a map to you? A map of roads? No? It doesn’t, does it? At best, it looks more like a chosen route or path.
Now this is a Road Map!
Remember those folded paper maps that showed geographic locations, roads connecting them, and even the types of roads? They often included distances as well. These are real road maps - actual maps of actual roads. Now, compare that to the so - called “road maps” you’ve been presented with.
A real road map doesn’t tell you where to go. At best, it shows you where you could go - assuming you’re using a road-legal vehicle. But if you change the game and venture off-road, all bets are off. These maps won’t help with boats, aircraft, or hiking. And that’s not a bad thing - it simply means there are other ways to reach places you otherwise couldn’t.
Work Maps
In software development, we’re not traveling on highways - we navigate with keyboards and mice. Our progress isn’t measured in kilometers or miles but in the effort required to accomplish something. While time might seem like an obvious way to measure work, our journeys are rarely simple point-to-point trips. Engineers tackle multiple tasks simultaneously, often working toward several goals at once.
Instead of cities, towns, or landmarks, we have states - not in the territorial sense, but as conditions that describe different phases of work.
Instead of roads, we have work - the actions needed to transition from one state to another. But reaching a destination often requires more than one type of work. Some states demand multiple efforts in parallel, meaning several “work” lines must converge to move forward. These aren’t alternative routes; they’re necessary combinations.
We measure work in units - estimates of effort and, when relevant, in cost, including financial considerations.
“Wait, that sounds a lot like a workflow!” you might say. And you’d be right - almost. The key difference? Workflow diagrams emphasize tasks, often treating intermediary states as mere steps along the way. But here, we care about both - the states matter just as much as the work. Product and business leaders focus on the states, ensuring they align with strategic goals, while engineering focuses on the work needed to get there. Both sides care about effort and cost, making work maps a valuable tool for shared understanding.
Where Can I Get One?
Well, that’s the challenge - nobody makes or sells these maps. We’re all explorers, charting unknown territory, seeking out new problems to solve, new markets to enter - boldly going where no one has gone before. And making these maps? It’s no easy task:
- You can only map as far as you can see.
- The farther away something is, the less accurately you can chart it - or even recognize what it is.
- Nobody has ever been exactly where you are now. Even if others are heading in a similar direction, they can’t guide you much. And even if they could, they probably wouldn’t offer.
- Nobody, not even you, really cares about the route you took to get where you are at the moment. Past maps quickly lose relevance.
- The “world” is always changing. New “roads” and “cities” are constantly built and demolished. Some routes become faster with new technology, while others, once well-traveled, fall into disrepair.
Too difficult? Maybe. But the real question is: How detailed does your map need to be?
Trying to chart everything is futile - the landscape will shift many times before you’re even done sketching. Fortunately, we don’t need that much detail. We just need enough to guide us toward our general destination. Uncertainty about distant terrain is fine - we’re willing to take some risks. But this isn’t about wandering aimlessly, hoping luck will steer us right. It’s about managing those risks and making informed choices along the way.
Example
In this example:
- Blue circles with thick outlines represent the current state(s).
- Green rounded rectangles indicate states we’re considering as possible “destinations”.
- Pink/red non-rounded rectangles represent work that could be done, with a cost/effort value shown in the bottom right corner. Since this is just an illustration, the specific units aren’t important - feel free to use your own. The values are somewhat arbitrary but are based on actual past experiences.
- Arrows represent possible “routes” and are unidirectional, not bidirectional.
- Small solid circles act as junctions that require all incoming route arrows to be completed. In all other cases, completing any one route is enough to reach the desired state.
I’ve used shading to indicate increasing uncertainty (or “fogginess”) as we look further into the future. While not strictly necessary, it serves as a helpful visual cue. If shading isn’t available, relevant boxes could be marked with an increasing number of question marks or other indicators.
Notice that there are multiple paths (options) leading to various destination states. If you add up the effort values, you’ll see that different paths require different amounts of work, which in turn affects how reachable certain destinations become. Some paths may bring particular goals within closer reach, while others make them less accessible.
This example is quite detailed and may appear busy, making it less suitable for all audiences. If the level of detail isn’t needed in a discussion, a simplified version can be easily (even automatically) generated by rolling up (combining) work estimates:
What was that about tech debt?
What technical debt? Did I forget to include it in the example above? Maybe I did, maybe I didn’t. But what exactly is technical debt? It could involve certain tasks we’d like to complete - so what impact would those have? Would they speed up development, open up new possibilities, or improve quality?
Each of these requires effort and leads to specific outcomes, which we can illustrate on a “work map”. There’s no need to separate technical debt from other tasks - they all belong on the same map, equally visible and not swept under the rug. The effects of addressing (or ignoring) them become immediately clear, helping us make better planning decisions.
Parting words
Planning a journey requires at least some idea of where we want to go. Making good decisions means considering more than one option. And making the right decisions - even when we know our direction - requires evaluating those options not just for their immediate effects but for their long-term consequences as well.
This is where roadmaps, or rather work maps, come into play. They bring structure and clarity, enabling honest and effective communication between stakeholders. Yes, they take effort to create, but it’s effort you’d have to put in anyway if you want to be diligent. You don’t need to map out the entire universe - just enough to manage risks.
They aren’t rigid plans. They enable agile planning, making it easier to adjust and adapt as needed.
I highly recommend using them.
Next…
Continue to my post about common errors in Agile implementation or Divide & Conquer in Software Development.
Other posts dealing with similar topics