We are going through the fourth industrial revolution- everything is digital and the world is technology driven no matter what we are doing. It’s common to see business intelligence, cloud related advertisements on TV , Billboards like direct consumer based products. Every company sees itself as a software company aiming to bring technology to the front and center. However many organizations, especially if they started as non-technology companies, have challenges bringing technology in their DNA because it’s not common to discuss and implement technology initiatives on their day to day – this kind of ‘tech-centric’ behavior is not natural to them.

What can be done to start making technology as the core function in the company ?

Assuming a technology team already exists, we can make a reasonable assumption that there exists a ‘Product Road map’ which the technology teams follow to build products. The product road map typically translates into product backlogs which are then turned into ‘technical’ solutions. This has almost become common knowledge.

While the tech team is implementing the product backlogs, it is very easy to get lost in the daily operations of releases, production support and feature enhancements. Technology evolves very fast and requires constant training, upgrade and alignment. One needs to take charge of that and make sure it’s part of road map and goals.

What is a Technology Road map ?

Product road maps are typically built by Product managers which are ‘Product’ features and priorities, with dates of expected releases. Product road maps can often be confused with Technology road maps. Unless the company culture organically has grown to include technical initiatives within product road maps, many technical initiatives may not make it to the product road map or backlog – which means they become a ‘nice-to-have’ and low priority items which get done only during free time – which may never happen !

Technology road maps include tool upgrades, platform upgrades, migrations, technology stack upgrades, technical debts, technical skills training, tools evaluations etc. Time and priority needs to be allocated to each of this. These type of items typically don’t get added to the Product road map, or even if they do get added their priority can get bumped down against product related priorities. The reason being ‘Product’ is directly related to the bread and butter, whereas the technology behind it is a support function however crucial it may be.

Technology road maps include tool upgrades, platform upgrades, migrations, technology stack upgrades, technical debts, technical skills training, tools evaluations etc. Time and priority needs to be allocated to each of this.

Below is an example of a simplest technology road map which has a mix of infrastructure, DevOps and Software Engineering timelines. This is a very high level road map created with no particular road map creation tool just for demonstration.

 

Each line item can be drilled down further into tasks. For each system there could be granular tasks associated. The chief product owner and and the technology head can get together and combine the product road map with the technology road map to come up with an integrated map.

How does one build a Technology Road map ?

1. Technology leaders, Engineering managers, Technical architects must all collaborate together to come up with a 2-5 year technology road map.  The road map should be based on business goals, product goals and the technology vision around the goals. When technology leads together contribute to this road map, there is shared accountability, as well as consensus.
2. If the company product line includes multiple systems, each system can have it’s own map. So, there can be a system specific road map and another high level road map which can apply to all the systems.
3. A technology road map can be a combination of networking, security initiatives along with all other technology items. For example you may decide that in the next five years you want to migrate your source control from TFS to Git. You may also have a need to decide that you want to take your MSMQ servers to the AWS or Azure cloud. For that you may have the need to move Active Directory to the cloud first. They all together will constitute a ‘IT Road map’ or ‘Technology Road map’.
4. Ultimately the Technology road map is owned by the CTO or the CIO . The road map is a vast matrix of technology initiatives over a period of 2 to 5 years with different categories and timelines. Each category might be a department or a system or a high level technical initiative.

How do you execute on the technology road map ?

The items in a technology road map must be further divided into tasks which can be integrated or weaved into the product road map.  The resource allocation as well as priority allocation has to happen accordingly with a shared accountability of product managers, engineering managers and project managers.

The product managers, project managers and the rest of the business stakeholders have to buy into technology road map. The tasks within the technology road map should get baked into the ‘Sprints’ or the cycle of ‘Product development’. This way technology becomes a mainstream function aligned with latest industry trends. No technical debts are accumulated, causing a disaster or halt which can be costly to the bottom line. Not paying timely attention to pure technology initiatives can lead to unrecoverable technical damage. The value of technology road map in this digital age is very high and mission critical.