What is a technology roadmap?
Your technology roadmap could be purely infrastructure-related, it could be organizational related, it could be related to how you plan to invest in and build the performance and tooling for your tech teams. It could be a 20 year directional map for where you want to take your organization. Or it could encompass all of these things.
Your technology roadmap ultimately starts with a business goal of something to be achieved. It should have high level projects or initiatives with a next level of detail describing what is needed to achieve the goal. You will need to think through who will do the work, how much it will cost, how long it will take to implement, and any other aspects that will require change in your organization.
Imagine building out the roadmap for a service like Uber. Their roadmap might include “build an application to schedule pickup” which is just a technology implementation. But an additional item on the roadmap might be something like “convince people it is safe to ride with strangers” and “taxis provide bad service”. Building a widget isn’t good enough without thinking through what needs to change to make way for your widget.
A more practical example might be implementing DevOps in your organization. You can build out automated delivery pipelines that your developers can use to ship code to production as that is just an implementation concern that has already been solved by the industry. But if you don’t get your IT team and database admins on board, your project is not very likely to succeed.
You might visualize your strategic technology roadmap across many years with high level themes and an end goal in mind.
Or you might visualize a more tactical delivery plan showing the initiatives and when you expect them to be completed.
Pinterest has many infographics for what a technology roadmap might look like and can inspire you about what your technology roadmap might look like.
Why do I need a technology roadmap?
While having a product roadmap is all about mapping out features and delivery dates for a product, a technology roadmap helps with strategizing the work that supports your products and organization. The technology roadmap organizes your infrastructure and tools to ensure that your product delivery goes off smoothly. There may be some overlap between your product and technology roadmaps as the technology often supports your product, but there may be other organizational items on the tech roadmap that don’t cross over with your product.
How do I build a technology roadmap?
1. Identify your goals
Start with the end in mind. Having a road map that doesn’t directly correlate to the long term goals and vision of the company isn’t useful. If your organization is looking to grow this year you might anticipate investment into scaling your IT systems or streamlining your onboarding process. You might need to tackle some performance related issues in your back office software.
Another goal might be to make improvements to support a certain organizational goal of “onboard 100,000 new users” in your company’s product. A similar need might be driven around increased revenue goals of 20%. In that case you may need to add servers to a cluster to increase the throughput and capability of your systems or perhaps offload some offline processing to cloud compute.
Or you may need to “decrease costs of our systems by X%”. This might cause you to increase performance capabilities in your software to achieve more throughput on less infrastructure (cheaper total cost of ownership through less hardware investment). Or you might quickly fix a backlog of technical debt to make your system more stable enabling you to reduce the team size of the software that is being supported.
Capture all of these high level ideas into a spreadsheet or tool like SmartSheet.
2. Seek input from everyone involved
EVERYONE!? Well, depending on the size of your organization, everyone might be 10 or 20 people. Everyone can be involved in that case. If your organization is 10,000 people then everyone might be localized to the various departmental leaders. Be sure to include all the appropriate stakeholders and decision makers.
Everyone will have different views of what is most important and will seek to prioritize their critical issues. Be sure to let your CEO’s vision of the world influence what gets done. In a perfect world, the organization would have a clear direction for where they are headed with each person in the boat rowing the appropriate oar.
Giving key people a chance to comment on the technology roadmap in the beginning increases the chance of the roadmap getting implemented. Collaboration is key.
3. Evaluate your current systems and map where you want to go
When discussing a technology roadmap you are also negotiating for a budget. This is the prime time to consider any licensing or hosting contracts that are coming up for renewal. Consider if you want to sign another 5 year contract for racked servers at the local co-lo facility or is this the right time to start migrating to the cloud? Building your roadmap is an appropriate time to question decisions made in the past to see if those decisions still align with the vision of the company.
Example: you might have 10 racked servers supporting your current customer’s workload, but in order to meet a business goal of doubling your customers you would need to double the number of servers you have. Instead you might consider targeting the current capacity by making strategic changes to the software to offload compute and long running processes to a cloud vendor. This would help you meet the current goal of doubling the throughput of your systems and if done right (with distributed systems) could allow you to double your customers again the following year for free, using scalable architecture.
4. Be willing to change
With a new budget and a clear view of the direction you are headed, view your landscape with a critical set of eyes looking for ways to achieve your goals. Perhaps you wrote a custom app because there wasn’t a product that satisfies your needs…but now there is! Consider ditching the custom software for something someone else is going to support. You might have a dev team that continues to give answers about delivery speed that just don’t make business sense. Bring in an outside set of fresh eyes to audit your systems, processes, and your team.
Change may be necessary to support improvements. Change can be culturally difficult to support. You may have team members that have their feet set in stone and are very emotional about wobbly tools and processes. Perhaps the people component will need to change to support the company’s goals and your technology roadmap.
5. Determine the priorities
Once you know your goals, have sought everyone’s ideas on how to get there, and are viewing the world with a fresh set of eyes – you can begin to determine what is critical, blocking, or simple. Prioritize your list of items continuously sourcing feedback from stakeholders.
At this point you may want to get into a tool like Smartsheet or similar project management product to start building a Gantt chart which will allow you to link items to their dependencies. This lets you visualize what has to be done first. Dependencies will automatically adjust your schedule as tasks become late.
6. Build out your timelines
With a prioritized list of items to complete in the coming year you can now look at the level of effort involved with each of those initiatives. Pull in the right technical people (or implementation team for non-technical projects) and get a t-shirt size estimate around that effort. In the grand scheme of items to build out, is this item small, medium, large, or extra large.
This should be a quick activity to verify how you think about an effort vs. how the team thinks about the same effort. You may find that you have some items that you thought would be implemented quickly but the team thinks it may take a very long time to pull off. With this input you can reassess your list of projects and possibly push a couple initiatives out to next year.
7. Plan out your budget
Now you should have a pretty good idea of what can be worked on, when it can be worked on, and possibly how long it might take to implement. This gives you a fair amount of information for assigning some form of required budget for that item. Work through the details of each item and get to an estimate for what is needed.
Once you have finished this step you will have the data you need when speaking with your budget approval team (boss, committee, CEO, etc.).
Some folks may wish to do this step before they start working on prioritization as budget decisions may change how urgent something is. If the cost of something is more than the value of that something, you may not do that work, look for a different way to implement it, or possibly buy in a service that solves the same problem.
8. Visualize your roadmap
Now you can begin to plan out the implementation of your projects. Use a tool like Smartsheet to build out a Gantt chart showing each of your project’s dependencies and overlay your team for each project to manage resource constraints for project delivery.
If you work in an agile software development environment, you don’t want to write out every detail of every feature for your implementation. Stick to high-level component delivery, marketing dates, and other high-level deadlines. Your agile team may pull in features on a different schedule while building out the software, but they should work towards your high-level schedule.
With a Gantt chart built out for the year you can now manage slipping dates or better, early deliveries. As your team delivers their projects you can see how that impacts the rest of your team’s schedule. This gives you a real-time view of how your road map is coming along.
9. Assign objectives and deadlines to those responsible
You need to assign accountability of the delivery to a manager or department head to ensure that someone is on the hook for the success of each of your projects.
Accountable delivery managers will help you push all projects forward. These are the people you will go to for updates about the projects. They will work with their teams (those responsible for delivery) to drive the success of their project(s). Meet with your managers often to identify as early as possible when the project needs some help.
10. Create a steering committee
Whether you are in a large or small organization you should create a steering committee or oversight team for your important projects. Rather than just managing an initiative yourself (or worse, several initiatives yourself), having a team be aware of what is going on reduces the need for you to have to be involved on a daily basis. In addition to sharing the management of an effort, having more eyes and viewpoints on a project allows you to see issues from different points of view or identify when balls are being dropped.
The additional value that a steering committee provides is that they are keeping their eye on the business goal for that project – why are we doing this effort in the first place. People involved in the day to day delivery of a project get wrapped around the axle of day to day issues and can quickly lose track of the original reason for performing that project. This can cause the delivery team to get off course now and then and need subtle course corrections along the way.
Need help creating a technology roadmap for your organization? Reach out anytime to firstname.lastname@example.org