A roadmap for your team

I’ve worked with many product teams in my career, and I think a lot about how we build and lead teams. A team is not just a group of individuals, it’s more than that. But we treat teams as a cluster of individuals, doing work together. In doing so, we miss an opportunity to take our teams to the next level. In order to look at teams through a more holistic lens, we need to find tools that support the team to develop as an entity in its own right. The roadmap is one powerful way to support this type of team growth.

Why a?Roadmap?

A product roadmap lays out the journey we are going to take. The destination is always far off — it’s our vision. We make a roadmap because we know that we can’t build our vision all at once.

We also have a vision of what we need teams to be. But with teams, we try to get to this outcome all at once, using organizational structure as our primary tool. We make incremental improvements to our processes, and we invest in individuals. If this were a product, it would be like building up front, doing a big launch, and then making small tweaks and adding features afterward.

Teams need stepping stones to get to their goals. A simple roadmap is a great tool to clarify the path.

The Team?Roadmap

I first used this approach when working with a large, distributed team. The org, a Fortune 500 company, had restructured its software teams and introduced Agile methodologies. Their focus was on creating autonomous, self-organizing teams. But as I observed their teams, it felt like they had started at the end. They had given teams the lofty goal of autonomy and left them to it. People had taken team autonomy to mean individual autonomy. Engineers would pick and choose what they would work on; there was no agreement on what it meant to work on the most important thing first. As a result, there was no cohesion in what was being delivered, and teams were stepping on each other’s toes. It was a bit of a mess.

Starting at the end assumes that every team can become whatever your desired end-state is, overnight. But that’s rarely realistic. Teams need to grow into new skillsets. They need time working together, and with other teams, to figure out how to do good work in the organizational context. And an org chart plus a tactical process won’t give them those things.

Creating Your?Roadmap

For the Not Yet Autonomous team we’ve been talking about, I created a roadmap to help us understand where we wanted to go as a team, and how we were going to get there. It was a simple, directional guide that the whole team was bought into.

We started with the big goal. “Autonomy” was something the team was already bought into because of the work leadership had done to align the org, so that’s what we used.

Next, we identified areas we could improve. Interestingly for a team that was seeking autonomy, the problems that surfaced were all about working with others. It was pretty clear that, in order for our team to be autonomous in a way that supported business goals, we needed to work better with other teams. An autonomous team in a silo, doing whatever it wants, can be appropriate in some circumstances. An R&D team is a great example. But a team that is part of a larger group all working on the same business-critical application cannot work that way without having deleterious effects on the software, the progress of other teams, and ultimately the business. For this team, the first milestone on the roadmap was Collaboration.

The other area that stood out was around alignment. The reason that people worked on whatever took their fancy was because it wasn’t clear how they should align their work to the organizational vision. We took Alignment as the next milestone. Putting it after collaboration made sense to us for two reasons. First, better collaboration was going to deliver immediate tactical benefits to our team and others. It would deliver a lot of incremental value. Second, we felt that building better working relationships across teams would make it easier to build alignment to organizational goals, because the teams could support each other in creating and supporting shared goals.

That was it, a simple, three-step roadmap. This was enough to focus incremental improvements for the team. Collaboration previously wasn’t on the team’s radar; stating it as an area for improvement meant that people were more likely to notice when it wasn’t happening, and bring ideas to the table to make it better.

Next Steps

Once your roadmap is in place, you can dig deeper to identify concrete ways to shift the needle on your roadmap items. Try creating a few milestones that you think will take 2–4 weeks each to achieve. Focus on the first one. Measure your progress. Then move on. This can bring structure to your retro practices, and gives the team a sense of achievement.

Giving teams a vision of how we’ll work together is important. But if you want teams to achieve that vision, giving them stepping stones to get there is essential.