Engineering results are sometimes hard to quantify. A roadmap changes everything.

Software engineering is hard and complicated. It’s even harder to convey the value to your company leaders.

How I started out

Back in 2017 I took over a new team in our company known as the Engineering Team (NGIN for short). Prior to forming that team there was a void in who was focused on our technical evolution.

This team was the answer to that void.

When I took over, the team had already accomplished a lot. They had taken our technology from outdated Webforms to a modern stack, while focusing on good design patterns and practices. In my mind this was the team to be on and I did everything in my power to align my career trajectory with them.

Finally after 3 years of focused effort I made the team. I had come from a previous team lead position so the goal was for me to transition into the lead of this team. I was extremely excited to join the team and couldn’t wait to hit the ground running and continue on their success. One of the things I wasn’t quite prepared for was the sheer amount of effort the team takes to be successful.

We had launched this new stack, but it was far from perfect.

Early challenges a roadmap solved

We were experiencing one of the hardest things about being on the bleeding edge of development for your company. We didn’t have anyone to ask for help when we were trying new things.

This is what I call Learning Debt.

Learning debt is a lot like technical debt. As you build new tools you learn things, but you want to keep moving, so you sometimes don’t take the time to totally understand something. It’s especially hard to time box learning when week to week you are deciding on what the top priorities are. We would find ourselves in a situation where we put out a new version of our stack, and by the time it is out there we learned so much that we are already trying to change it to a better version. I saw this as an unsustainable model and wanted to make sure we had some better direction on all these large obtuse initiatives.

Insert the Technical Roadmap.

The beginning of the Roadmap

I don’t recall exactly how I came up with the idea for a roadmap. It was probably inspired by a late night google search or some blog post I stumbled upon.

I had a few goals with the Roadmap:

1. Create a long term focus for the team.
2. Evaluate our teams previous efforts.
3. Allow for visibility into what the team is focusing on.
4. Make planning and workload easier to time box and understand when things are ahead or behind.
5. Collaborate with other teams and the business needs to prioritize value over cool factor.

The first Roadmap started with a half day meeting with the whole NGIN team followed by a team lunch. We set a goal to ignore our current and previous restrictions and decide how we want our technology to look 1 year from that meeting. I set the stage with some questions to help engage the team in thinking and they took it from there. Luckily we already had a great group of people that were forward thinking.

We filled a few whiteboards.

Ultimately the team came up with a lot of great ideas. I took these ideas back and ran them through my own value system.

The value system I use is:

5 - nice to have

4 - important but not urgent

3 - Efficiency gains once completed

2 - immediate issues resulting from not having this

1 - important and urgent

This helps me to prioritize the goals and creates an easy to convey importance scale for less technical decision makers. Now that I have my goals and my values for each it’s time to create the Roadmap.

The Roadmap format

Overview

In this section I summarize the goal of the document and goals of the team for this year. This is a great executive level overview of everything we plan to do and how it will impact the company in a positive way.

Responsibilities

The second section is a breack down of the responsibilities. First I list out the responsibilities and desired outcomes of the team. Then I keep a running list of all the applications and processes the team is managing. I also list anything that will be phased out or removed this year.

This helps convey the less important things that take up our time, but didn’t make the Roadmap.

Previous year review

This is probably the funnest part for me each year. I take some time to dig back through the year and call out all of our achievements. I look through old emails, Git commits and our companies internal news feed to pull together everything we accomplished last year. Fortunately this year I had a 2019 Roadmap that I used to help categorize our accomplishments.

I couldn’t believe how well we stuck to our plan.

Sure we didn’t get to everything and we did somethings that weren’t even mentioned, but overall it was a very positive exercise for me to actually put it all into writing. This is also one of the easiest ways to convey the value of our team to our leadership. Being that our work doesn’t directly drive revenue I feel an obligation to clearly state our value in tangible accomplishments. It’s helpful to list these out and hear people have the “Wow I forgot about that! That was super helpful last year.” feedback to the results.

The Year’s Plan

When listing out all of the goals we want to achieve for the year I try to limit them to 4 - 5 overarching buckets.

For instance this year our buckets are:

• Our Core Stack
• Emerging Business Areas
• Infrastructure
• Training and Standards

Inside of those buckets I have 3 - 5 sub-initiatives. As an example a sub-initiative to Our Core Stack is to complete our .Net Core 3.x migration from .Net Framework. Each sub-initiative follows a similar format to the whole document to this point. I state the overall goal as an executive level summary and the contine to split these sub-initiatives further with the goals for them as well.

What I don’t do with the Roadmap

The Roadmap is not a technical document.

I don’t try to explain our detailed plans or even the solutions to the items listed. The Roadmap serves two purposes for me:

1. It’s a way to convey our previous value and proposed value.
2. It’s a path that I can refer to throughout the year to stay on track.

Once I have this Roadmap it makes it much easier to do the quarterly planning, the monthly planning and inevitably the day to day planning. I take the items from this and sit down with the right people to clearly state the challenges and requirements. Then we can start to design the solutions.

The Best part of the Roadmap

The Roadmap is a great way to get everyone involved in Engineering.

If there is anything I learned by starting this process it’s that if I have an idea and a solution someone else probably has a better version of it. This clearly exposes to the entire company what our ideas are, and I continuously encourage everyone to contribute ideas and solutions for our goals. It’s much easier to get buy-in and valuable help when you can share your vision and big picture.

Final thoughts

I would strongly recommend that if you are involved in the technical vision for your company you take the time to write a Roadmap. It does take a lot of time and effort, especially in the beginning when you don’t have a framework, but it has been extremely valuable to me and my company.

If you are like me and you can’t always organize or convey your intentions, write them down.

Meet with your team, get their feedback, and organize it all into a cohesive view, most importantly share it. You’ll be surprised how much you stick to something when you put a commitment in writing and make it public. It helps you stay lean, deprioritize the things that don’t matter, and deliver on the things that do.

Discuss this on Changelog News