[RBM] - Roadmap blindness
Hello, today's last subject is based on your questions and discussion over the Tech Leaders Meetup. This time we will tackle the subject of things written in stone—those immutable plans that seem carved into organizational DNA with the permanence of ancient hieroglyphics. In my experience working on modernization projects across various industries and company sizes, I've noticed that the ability to change and adapt disappears just after project kickoff, as if flexibility was somehow sacrificed on the altar of planning ceremonies and stakeholder approval processes. Let's talk about how to avoid what we can call "Roadmap blindness"—that dangerous tunnel vision that keeps teams marching toward outdated objectives like soldiers following orders from a war that ended months ago.
The Sacred Document Syndrome
I've conducted multiple projects in the modernization area that started with well-structured plans that looked impressive on paper and even more impressive in PowerPoint presentations to executive leadership. The typical approach I've observed involves comprehensive audit phases that can stretch for weeks, detailed recommendations that fill dozens of pages, extensive roadmapping sessions with color-coded timelines and dependency charts, and finally the realization phase where the rubber meets the road. However, I've noticed something particularly striking: even those companies that were highly agile and adaptive in their day-to-day project realization—companies that could pivot their product features based on user feedback within days—often treat their roadmaps like sacred documents from waterfall methodology. These roadmaps become untouchable, unchangeable, and absolute, treated with the reverence typically reserved for constitutional amendments or religious texts.
This phenomenon creates a fascinating paradox where organizations that pride themselves on being data-driven and responsive to market changes suddenly become rigid and inflexible when it comes to their transformation strategies. The University of San Diego created a great graphic that illustrates how continuous improvement should actually look in real life, moving beyond the static planning mentality that has dominated corporate culture for decades.
Applying Continuous Improvement to Organizational Transformation
Even though their model is designed for personal development and individual growth trajectories, I've found that the same fundamental stages can be implemented for every continuous process of organizational learning and transformation. The first three foundational stages—followed by Vision, Goal Setting, and Design—represent our Roadmap creation steps. These are crucial for establishing direction and creating alignment among stakeholders, but they're just the beginning of what should be an ongoing journey rather than a destination. Then we should design a particular solution with careful attention to both technical requirements and human factors, model it carefully through prototyping and pilot programs, and implement it with clear success metrics that go beyond simple completion percentages.
Next, and this is where I've seen most organizations fail spectacularly, we should validate our progress through rigorous measurement and actively seek feedback from stakeholders at all levels—not just the C-suite executives who approved the original plan. We need to reflect honestly on what we've learned, including the uncomfortable truths about what isn't working, and analyze what changes will be needed to maintain the pace of implementation while staying aligned with evolving business needs, market conditions, and technological capabilities.
The Reality of Continuous Learning in Practice
In my experience working with companies ranging from scrappy startups to global enterprises, this approach requires continuous evaluation of what we have been doing, whether it actually works in practice beyond the theoretical models we created, if it delivers the value we initially expected to see in our business cases, and what modifications will be needed to keep moving forward effectively without losing momentum or stakeholder confidence. This is the only way I've found to make the modernization process one of continuous learning, which should be the real goal of such digital transformation initiatives rather than simply checking boxes on a predetermined list.
I've observed that a process of continuous learning gives us the option to always keep our roadmap in an updated state that reflects where we actually want to be—based on current market realities, technological possibilities, and organizational capabilities—not where we thought we wanted to be months ago when we had less information and different constraints. As I mentioned earlier, I've noticed many companies stick rigidly with their original roadmaps, treating them like contracts written in blood, which in reality means they're producing legacy systems and outdated solutions from the very moment of creation. It's like building a house using architectural plans from the 1950s and wondering why it doesn't meet modern energy efficiency standards or lifestyle needs.
Flexibility at Every Level
I've found it important to maintain this flexibility not only from the top-level perspective of the overall roadmap and strategic direction but also for smaller projects and initiatives themselves, including the tactical decisions that happen at the team level every day. Sometimes, even after we start implementing specific projects and have invested significant time and resources, I've discovered moments when a project is no longer needed due to changing market conditions, when the form we originally envisioned no longer fits current requirements, or when new technologies have emerged that make our planned approach obsolete.
In such cases, I've learned that we should conduct a thorough reflection stage without the fear of admitting that our original assumptions were incorrect, and analyze how both the change process and the roadmap should be modified to better serve our objectives and deliver real business value. Later on, we should update our designs both for the whole transformation initiative and for particular projects that may need course correction, always keeping in mind that adaptation is a sign of intelligence, not failure.
Structuring the Revalidation Process
You might ask whom to engage in this revalidation initiative and how to structure this ongoing assessment without creating bureaucratic overhead that slows down progress. From my experience, having the Transformation Committee that I proposed in a previous article, we should be able to take care of roadmap updating in a systematic and accountable way that balances strategic oversight with operational flexibility. I've found that the same reflective activity should be conducted on the team level with regular retrospectives and lessons-learned sessions, and I would propose to coordinate this together with the transformation committee to ensure alignment across all levels of the organization. It doesn't need to be synchronous across all teams—different teams may have different cadences based on their project timelines—but I've noticed it needs to be confirmed and validated with the committee to maintain strategic coherence and prevent teams from drifting too far from the overall vision.
The key is creating a structured yet flexible framework that encourages honest assessment and rapid adaptation while maintaining accountability and strategic direction. This means establishing clear criteria for when changes should be considered, creating safe spaces for teams to report challenges and propose modifications, and developing processes that can quickly evaluate and implement necessary adjustments.
What do you think about this problem? Have you encountered similar challenges with roadmap rigidity in your own transformation projects? I'd love to hear about your experiences with balancing planning discipline and adaptive flexibility in the comments below.