Technical Roadmaps and Dev Sustainability

At a high level, most engineers are working on product backlogs, in some way, shape, or form. What happens if that product backlog dries up? Or, as a manager or leader, you need to fill a period of uncertainty? This post is going to take you on my journey over the years, and put forward a solution that can be applied to small projects, large projects, and even at an organisational unit level.

My first project

My second job out of University was Plusnet, a UK Internet Service Provider (ISP). I started in 2008 with all the enthusiasm in the world. My first biggish project was working with an engineer I admired and who subsequently shaped my outlook on engineering. The project was to pretty much re-write the features that allowed our customers to change their accounts and products. This was back when the codebase was transitioning from functional/legacy PHP code, into Object Oriented code with unit tests, and quality controls etc.

Over a period of time we delivered the project, and it was a success. We had uplifted the codebase into a more maintainable beast. It was easier and quicker for us to ship features to our customers.

However, I was constantly learning new ways of implementing things, or had subjective ideas of how I could make the code “better”. As you would expect, we all moved onto the next project. This is when I first started to identify “dev sustainability” work. Side note, I am 99% certain the “Dev Sustainability” phrase has come from a software engineering book that I cannot find, so cannot reference. If you know which book this is from, let me know so I can reference it here.

In my view, dev sustainability work is:

• Work engineers find during projects that never wins the “Deadline/Cost/Feature” war, so never gets prioritised.
• It’s implement the tool that makes your life easier.
• It’s implementing a feature that makes your life easier.
• It is not, in my opinion, what folks would classify as “Technical Debt”.

Over the 5 years I worked at Plusnet, I ended up working in that account change codebase from time to time. Each time, I opened my list and knocked off some of the “dev sustainability” tasks. It felt very rewarding I have to say. A guardian of the codebase.

The downside, I never shared the list!

My first team

I don’t know about you, but the first time I lead a team it was overwhelming. Engineers looking to me for direction, and answers. I needed to set the tone, direction, and ultimately keep engineers happy and productive.

If project priorities changed, or I had lead times on projects, what was I going to get engineers working on?

So I started to go back to keeping lists. A set of curated work I thought added value to my team, and the company. If someone needed “busy work” for any reason, I instantly had a “go to” backlog I knew inside out.

This was a very immature process and the work was still owned by me, not the team.

Many teams later

However, immature processes start to evolve. I switched companies and lead more teams. I started to put “dev sustainability” work in my teams backlogs. Clearly labelled. As part of the teams ways of working, we knew we could pull from this pool of work, if we had capacity or need. This was technically lead work, which the team all agreed on.

Suddenly, it went from my secret list, into the teams backlog. We could all contribute to it. Add items, refine items, complete items. Engineers felt engaged and empowered (or at least I hope they did).

I always use to say to my boss, “Don’t worry if you don’t have projects for us, my team can glide for about 3 weeks”. I use to say this for two reasons:

1. I had the dev sustainability backlog. As an engineer this is the fun work in my opinion. The “never never” work you always wanted to do, but was never prioritised.
2. Have you ever been in a position of people looking to you for work (or answers), and realising you don’t have any? I do, and I never want that experience again, ever. Nor do I want to be the person putting some other poor soul in that position. It’s awful.

Scaling to a Roadmap

Time moves on, and currently I’m an Individual Contributor (IC) with a sphere of influence over several teams. I recently recognised a gap of technically lead work in the teams I had sight of. I therefore proposed a “Technical Roadmap” solution to my bosses of our organisational unit.

This concept, when boiled down, is my original dev sustainability backlog concept, but on a grander scale. Items can be added to the Technical Roadmap under certain circumstances:

• Does the item set, or lead to, the strategic direction of the unit?
• Does the item have a broader reach than just a domain team?

Where this differs, slightly, is the positioning of this work. This is what “managers of managers” should look after. The Technical Roadmap for an organisational unit or business is a more broader list of work, not low level detail that Technical Leads or Engineers need for their team.

This process is now up and running, and this is how it is being run:

• The Technical Roadmap is in GitHub, a central hub for all engineers.
• We use the newly released Discussions feature to collate ideas from everyone.
• Anyone in the business can raise a discussion, outlining what the item covers, and why it is useful.
• If “leadership” agree, or we get a lot of engineering support, we agree to put the item on the roadmap as a GitHub Issue.
• This GitHub Issue is then added to the GitHub Project Board, with an accountable owner (usually an Engineering Manager).
• The GitHub Project covers a 6 month rolling period.
• We have regular meetings with senior management to review the backlog, progress made, and newly raised discussions.

So far, this process is working well, and engagement has been high. Teams who are needing to pull “none product work”, are able to pull down from the Technical Roadmap. Since it is all in GitHub, in a central location, all teams can benefit from the visibility of this content.

Summary

Whether you are an engineer, a Technical Lead, Engineering Manager, or higher, keeping a backlog of technical work is going to pay off. The next time you’re on a project, see if you can identify “dev sustainability” work, and get it on your backlog.