A roadmap for your team

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.

Flowchart: Collaboration to Alignment to Autonomy

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.

Rose Bryant-Smith

Executive, Director & Founder | Driving strategic impact | Building values-driven businesses

2 年

Great stuff Janet Brunckhorst - simple to understand and to communicate to colleagues. I look forward to applying it!

Christian Crumlish

Public servant, wrote Product Management for UX People, curator of Design in Product, songwriter in residence for At Swim-Two-Birds

2 年

I love this. It’s super timely! Thank you.

回复

要查看或添加评论,请登录

Janet Brunckhorst的更多文章

  • Learning from Operators

    Learning from Operators

    Recently, the Australian Energy Market Operator (AEMO) released its draft 2024 Integrated System Plan (PDF). It got me…

  • Finding Awe at?Work

    Finding Awe at?Work

    In product, you’ll hear people tell you to “fall in love with the problem”. I’m not going to tell you that’s wrong.

    3 条评论
  • Energy is a system, not a?project

    Energy is a system, not a?project

    Stop me if you’ve heard this one: “The problem is …” I hear this a lot in conversations about electrification. “The…

    3 条评论
  • Destructive creation: when feedback loops go?wrong

    Destructive creation: when feedback loops go?wrong

    In his bestselling book, Eric Ries says that the “Build-Measure-Learn feedback loop is at the core of the Lean Startup…

    1 条评论
  • Investing in the Value Chain of Climate

    Investing in the Value Chain of Climate

    I’ve been working on something: mapping the value chain of the energy transition, in order to inform my decisions about…

    3 条评论
  • Partner Leadership

    Partner Leadership

    My friend Uday Gajendar recently published this thoughtful piece on how we work together. In it, he talks about “a…

    4 条评论
  • Climate Finance Reading List

    Climate Finance Reading List

    I've been learning more about the challenges and opportunities for financing climate solutions. I started collecting…

    7 条评论
  • Team Entanglement and Disruptive Observation

    Team Entanglement and Disruptive Observation

    In his book High Output Management, Andy Grove illustrates a business as a simple “black box”, with inputs going in…

    1 条评论
  • Innovation Compost

    Innovation Compost

    I’ve been thinking about compost. Partly because I’ve been reading Merlin Sheldrake’s excellent book about fungi…

    1 条评论
  • Atomic Teams

    Atomic Teams

    In software, most of us work in some kind of team. Even when we’re called “individual contributors”, it’s understood…

社区洞察

其他会员也浏览了