Your Roadmap Is a Lie You Tell Yourselves Every Quarter

It was 2:15 on a Thursday afternoon, and I was staring at a system architecture diagram that looked like someone had played Pictionary while blindfolded. Three different database technologies, one API, and access patterns on the endpoints so inconsistent they might as well have been written by different companies. The tech lead sat across from me, arms crossed, and I could feel the air conditioning struggling against the heat of too many people crammed into a glass-walled meeting room. He wasn’t defensive — he was tired. Every decision on that diagram had been the right one at the time. That was the problem.

This is what happens when smart people make good decisions without a shared destination. Not bad engineering — directionless engineering. And it’s quietly rotting your system from the inside out.

The Planning Fallacy We’ve All Bought Into

As Paddy Mayne — the legendary SAS co-founder — told his men before a raid: “You must ask why, because if you know why you are carrying out your mission, when things fuck up — as they inevitably will — you will know how to achieve what you set out to achieve in a different way.”

He was talking about blowing up German airfields in the Sahara, but he might as well have been talking about your Q3 technical roadmap.

We love saying “no plan survives first contact” in engineering. We use it to justify why our technical roadmap bears no resemblance to what we actually delivered. We wear our adaptability like a badge of honour. But Mayne’s point wasn’t that plans don’t matter — it’s that understanding the purpose behind the plan is what lets you adapt when everything goes sideways. His raids succeeded not because every step was scripted, but because every soldier understood the objective deeply enough to improvise toward it.

Our problem is that the plan was the objective. So when reality shredded it — as it always does — we had nothing left to steer by. We didn’t throw out the map and keep the compass. We threw out both and called it agile.

The Agile Manifesto tells us to value “responding to change over following a plan.” Brilliant. Essential. But responding to change requires knowing why you were doing what you were doing in the first place. Without that, you’re not responding — you’re reacting. There’s a difference, and it’s the difference between a team navigating rough seas and a team adrift.

Technical Roadmaps Are Fiction. That’s Not the Problem.

Let’s get the obvious out of the way: your Q3 technical roadmap is fiction. You know it. Your tech lead knows it. Your engineering manager suspects it but doesn’t want to hear it. By week four of the quarter, half the items have been deprioritised in favour of product work, descoped because “we’ll get to it next quarter,” or revealed to be three times more complex than the original estimate suggested.

This isn’t a failure of planning. It’s a failure of what we’re planning.

Task-level technical roadmaps — “migrate to the new API in Q2, upgrade the database in Q3, refactor the auth service in Q4” — try to predict specific technical outputs months in advance. That’s like trying to predict the exact route you’ll drive to work next Tuesday — which lane changes, which traffic lights. You can’t. But you absolutely know you’re driving to the office, not the airport. You know the destination.

Engineering teams need a destination. Not a task list of technical improvements — a picture of what the system should look like. An architectural north star.

What a North Star Actually Is (and Isn’t)

A north star isn’t a detailed technical specification. It’s not an architecture diagram that maps every service and endpoint. It’s a shared understanding of the system’s trajectory — where you want it to be in two to three years and, critically, what principles guide the decisions you make along the way.

The basketball coach John Wooden put it simply: “When you improve a little each day, eventually big things occur. Not tomorrow, not the next day, but eventually a big gain is made.” He was talking about fundamentals, not game plans. The north star is the same idea applied to systems — not a play-by-play, but a direction that makes each small decision compound toward something coherent.

Here’s the practical version. Every sprint, every PR, every “quick fix” gets evaluated against one question: is this taking us closer to the north star or further from it?

Some sprints, the answer is “further, and that’s fine — the product need is urgent.” But you know you’re doing it. You’re taking on deliberate debt with eyes open, not sleepwalking into a mess. And because you know, you can course-correct.

Three Database Technologies and a Moment of Clarity

Let me go back to that Thursday afternoon meeting room.

I looked at the system diagram and asked the team a simple question: “Where do you want this system to be in two years? Six database technologies?”

They laughed. I wasn’t joking.

Each database had been adopted for sound reasons. A new requirement came in, a new database technology happened to be available that suited it perfectly, so they used it. Logical. Reasonable. And the accumulation of those reasonable decisions had produced a system where every endpoint had different access patterns, different operational characteristics, and different failure modes. The cognitive load on the team was enormous. Onboarding a new engineer meant learning three completely different data paradigms just to understand one service.

I told them they needed to think about where they wanted this to be long-term. Was it realistic — or desirable — to keep maintaining three different database technologies? No, they agreed, it wasn’t. So we sat down and worked through which technology could serve most of their needs. Could we reduce from three to two? Maybe even one?

We weighed system performance against complexity. I told them I was comfortable dropping a database technology and accepting a five percent increase in response time if it meant dramatically reducing system complexity. Simplicity is its own performance optimisation — fewer moving parts means fewer things that break at 3 AM.

In the end, we didn’t even sacrifice response time. We consolidated to a single database technology and set the system on a road to a better future. It took multiple quarters to migrate incrementally. Along the way, new technologies became available — they always do — but those were evaluated as tech spikes, shadow-tested against the north star. Product work followed the default path unless the north star couldn’t support it. It always could.

That’s not a roadmap. That’s a compass.

The Reverse Question That Keeps You Honest

The north star isn’t just a constraint on product work — it should actively enable it. If your architectural direction is well-chosen, each increment should reduce friction for future product delivery. Features should get easier to build, not harder. Deployment should get faster, not slower.

This gives you a powerful reverse question to ask regularly: “Is the north star making it easier to deliver the product work coming in?”

If the answer is yes, you’re on track. If the answer is no, that’s a signal to adjust the star — not to abandon it. Maybe the business has shifted. Maybe new capabilities have emerged. Maybe you were wrong about something. That’s fine. Small course corrections are healthy. What’s expensive — catastrophically expensive — is having no direction at all and waking up three years later wondering why a simple feature change touches twelve services.

The 80/90% Rule: Design for the Common, Tolerate the Exception

This is where most architects get it wrong, and I include past versions of myself in that criticism.

The instinct is to design a system that handles one hundred percent of use cases elegantly. Every edge case accounted for, every exception handled gracefully, every theoretical scenario anticipated. The result is over-engineered abstractions that nobody can understand, maintained by the one person who designed them (and even they’re starting to forget why half the configuration options exist).

The north star should target eighty to ninety percent of your use cases. The remaining edge cases? A bit of a hack is fine. Protect the overall simplicity of the system. A clean architecture that handles ninety percent of cases beautifully and ten percent with a slightly ugly workaround is infinitely better than a “universal” architecture that handles everything with equal mediocrity and takes a PhD to modify.

The architect Christopher Alexander — whose work on design patterns influenced the Gang of Four and, by extension, most of modern software design — warned against this exact trap: “When you build a thing you cannot merely build that thing in isolation, but must repair the world around it, and within it, so that the larger world at that one place becomes more coherent.” The key word is coherent, not complete. Coherence at ninety percent with acknowledged exceptions beats theoretical completeness that collapses under its own weight.

Why Long-Lived Teams Are the Only Ones That Can Hold a North Star

This is where architecture meets organisational design, and you can’t have one conversation without the other.

A north star only works when the people who set it are the same people living with the consequences. When a team owns a system for years, they develop the context to hold a direction. They understand the debt they’ve taken on and why. They remember which shortcuts were deliberate and which were accidental. They feel the friction of their own past decisions every day, which gives them both the motivation and the knowledge to improve things incrementally.

Project-based teams and rotating ownership can’t do this. They optimise for the current quarter, not the trajectory. They inherit systems without understanding the decisions behind them. They don’t know which workaround is load-bearing and which is genuinely temporary. So they either leave everything untouched — entropy wins — or they tear things out that turn out to be important — chaos wins.

There’s something deeper here too. When a team has autonomy over their system’s direction, they naturally own the outcomes more. The system becomes their system. Not in a territorial sense, but in the way a craftsperson owns their work. They take pride in the decisions around it — including the hard ones about technical debt. They’re not just executing someone else’s backlog; they’re shaping something they care about.

As the economist E.F. Schumacher noted, “Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.” Long-lived teams develop that courage because they’re the ones who have to live with the complexity. Short-lived teams can afford to add it because they won’t be around when the bill comes due.

The North Star Evolves, and That’s the Point

Your north star will change. The business will shift. New technologies will emerge. Requirements you didn’t anticipate will appear. That’s not a failure of the approach — it’s the approach working as intended.

The difference between a team with an evolving north star and a team without one is the difference between course correction and crisis management. Small adjustments to direction are cheap. Wholesale rewrites because nobody had a direction in the first place — those are the expensive failure mode. Those are the “we need to rewrite everything” conversations that happen when a system has accumulated years of locally rational, globally incoherent decisions.

The Agile Principle Nobody Quotes

Everyone quotes “responding to change over following a plan.” Almost nobody quotes principle number nine: “Continuous attention to technical excellence and good design enhances agility.”

That’s the north star argument, right there in the foundational document. The architecture enables the agility rather than constraining it. Technical excellence isn’t a luxury you invest in after you’ve shipped enough features — it’s the thing that makes shipping features sustainable.

We’ve confused “no plan” with “no direction.” We’ve confused “embracing change” with “having no opinions about where we’re going.” The contrarian truth isn’t that plans are useless — everyone already knows that. It’s that architectural vision is everything, and most teams have thrown it out along with the Gantt chart and called it agile.

The Bottom Line

Your Q3 technical roadmap is fiction. Stop pretending otherwise. But the answer isn’t to abandon direction — it’s to direct at the right level of abstraction.

Stop planning which technical tasks you’ll complete in which quarter. Start agreeing on what your system should look like in two years. Make that vision tangible enough that any engineer on the team can evaluate a PR against it. Revisit it regularly. Adjust it when the world changes. But have one.

Give it to a long-lived team with autonomy and ownership. Let them make the incremental decisions, sprint by sprint, that move the system toward coherence. Trust them to take on deliberate debt when the product demands it and to pay it down when the opportunity arises.

The alternative is what most teams have now: a technical roadmap nobody believes in, a backlog of improvements that grows faster than it shrinks, and a system that gets harder to change with every quarter that passes — all while proudly calling themselves agile.

Now, if you’ll excuse me, I need to go check on a database migration that’s been “almost done” for two quarters. But at least we know where we’re going — which is more than I can say for the system I over-engineered in 2019 trying to handle every edge case. Turns out the edge cases handled themselves. The complexity didn’t.