Engineering Roadmap is not just Technical Debt
If your roadmap is all reactive, you will always be putting out fires
In my experience (anecdotal evidence, for sure), engineering tends to neglect the need for an engineering roadmap.
Consequently, engineering often shows unprepared for market and business challenges, often surprising business/product-side stakeholders with requests to delay the start of critical initiatives.
What is an Engineering Roadmap?
Simply put, an Engineering Roadmap is a prioritized list of projects, initiatives, objectively identifiable deliverables to address organizational needs identified by the engineering team or department.
The closest I’ve seen from an Engineering Roadmap so far is a list of technical debt plus the desire to migrate to new technology or architecture.
This is NOT a roadmap. This is a list of issues and concerns.
From Reactive to Proactive
A proper roadmap anticipates needs. It tells you where you would like to be at a certain point in time.
Surely no roadmap will tell you that you will want to have accumulated X amount of technical debt. Therefore, you include in your roadmap plans to pay certain technical debts in time for product initiatives to start on a better stage.
As in the example before, you will have a list of initiatives (not issues) that you will execute at a certain time (according to the priorities set by engineering).
The priorities, of course, can take into account the product roadmap but should also include productivity concerns, knowledge management, and technology changes.
Examples of items that are part of an engineering roadmap:
- Define and implement the often neglected non-functional requirements.
- Update technologies (like programming languages or versions), frameworks and libraries, platform updates, etc. These things not only improve the performance of the system but also reduce security threats, improve development productivity, staff satisfaction (leading to less turnover), etc.
- Infrastructure updates. I’m not talking about that old infrastructure that should have been replaced already. This is technical debt (which I’m listing down below). I’m talking about considering how your user base has been increasing and allocating more resources BEFORE you have a problem. I’m talking about that new service that you know you will need before going live with a feature planned 6 months from now, so you have the proper time to try different vendors, integrate to existing services, etc., without delays or increased costs.
- Architectural changes lead to an increase in quality and productivity and improve the support for new features. These changes are often larger items that won’t fit within a product-driven initiative and will cost the business. This cost will be in terms of delayed time-to-market or a heavy increase in technical debt leading to productivity and quality losses, with the possible loss of customers driven by lower satisfaction rates.
- Technical debt. I’m not talking about the technical debt payment that should be included in the product-driven initiatives (click on the link to know more). I’m talking about larger groups of technical debt under a current theme in a particular component or area, as well as larger technical debt that would have an unacceptable impact on these product-driven initiatives.
If you are thinking about things like test automation gaps, processes optimization, addressing some outdated piece of technology, these are all technical debt. If you think otherwise or would like to expand your perception and capacity to identify technical debt, look no further:
SEM Blog | How much technical debt do you own?
- Knowledge Management! That’s right! If you know that there will be a cross-team initiative, you can start having learning sessions with both teams on topics they need each other to learn. Even more, if you intend to adopt new technology, a new architecture paradigm, or even to implement some new feature that requires more business knowledge, you can anticipate these needs.
Have your staff ready for the changes right when they need this knowledge. That will bring you to an organizational-level training plan! Who should know what by when? Can you train internally? Should you hire instructors or find a course? Is a book enough? Maybe you need to hire a specialist.
If you like this post, please share it (you can use the buttons in the end of this post). It will help me a lot and keep me motivated to write more. Also, subscribe to get notified of new posts when they come out.
I hope you liked this post and that it’s helpful to you. If you have suggestions of what else should be in an Engineering Roadmap or want to share your experience with having (or not having) one, sound off in the comments!
The bottom line is that Engineering Roadmaps shouldn’t be a list of technical debt, which is a reactive response.
If you know what lies ahead, you can plan to be proactive. It will improve your results, reduce costs, increase overall satisfaction, and mitigate or eliminate unnecessary risks.
Cheers!