Stable Teams and Dynamic Structures

Balancing long-lived teams with short term coordination and alignment

Photo by Christophe Hautier on Unsplash

If you’ve read my previous posts, you know my fascination with teams, their interactions, and what this means in terms of outcomes.

I recently spoke with Chris Matts on some of the challenges I have been wrestling with and he challenged my thinking around static vs. dynamic structures and organizations.

There’s structures or dimensions that Chris suggested exploring (note: assume your organization is working in a product funded way)

• Organization (reporting lines e.g. an individual has a manager who helps them with their craft / professional development, career goals, etc.)
• Delivery or Release Vehicle (team structure related to a deployment target following a common release platform e.g. an iOS app / Android app / Desktop app e.g. think Squads in a Tribe, I’m not sure this is the same as a SAFe Release Train)
• Team of teams (temporary structure — like a value stream, but closer to a network of teams sharing a common goal)
• Product (the products within an organization in a hierarchy with owners, strategies, roadmaps, marketing, lifecycle etc.)
• Portfolio (backlog of work aligned to a common goal this may be aligned with a product or an external driver e.g. GDP, a regulatory need etc.)
• Metrics tree that link from the top of the organization to a level that a particular team is targeting to improve. These could be: Revenue, Cost and Risk. From there the metrics can then be broken down into products and then markets / segments etc.

As with every discussion I have with Chris, I tend to walk out of the conversation often with more questions than when I started. I often joke that he is my own personal Yoda (albeit a little taller).

After our chat, I wrote up a few points based on the discussion.

1. When moving from project to product, you fund products by funding teams and capacity rather than the products specifically. This is because products don’t work in isolation (in most cases) and depending on the dependencies your organization may have you will need to coordinate and prioritize work across the organization. If you only fund your product and not the teams specifically, you will end up constrained quite quickly. Treating teams as the atomic unit of capacity rather than individual days etc. or ‘man hours’ you can then have productive discussions across the organization to estimate, plan and prioritize work in sensible units (team weeks/months, your mileage may vary)
2. Many teams can work on one product if the product is engineered to enable independent delivery of value. This is a big if, but if you are working on large complex products that have many teams you simply cannot cope with the broader needs of your organization if you only have one team per product in every case. So based on organizational needs, you may end up with some teams constantly being needed by other teams that may not receive the same level of funding or visibility. An example frequently cited is the login team, it isn’t something most people are asking for from a user perspective but if you need to change or coordinate with the team responsible for login and there’s only one team you are going to have a large constraint on your hands.
3. In digital products, a value stream is not like in manufacturing, a value stream can be short-term or long lived around a shared need. Where value streams require infrequent interaction or interaction without frequent communication, teams can be part of a network or ecosystem. Value stream mapping exercises can be useful but do not fool yourself into thinking the value stream won't change as soon as you think you are finished. In the world of digital products and software, every time the underlying software is changing you are potentially at risk of the value stream no longer being the same. If you are taking an API-driven approach to enable your products to the wider organization, you may not even know who is depending on your product and why they are using it. That means you may be in a value stream you never knew existed. I keep referring to Team Topologies — Team API approach as a pragmatic way to manage this complexity and provide some level of expectation at a team-to-team level but make sure you are constantly challenging and evaluating this to ensure it is up to date and accurate.
4. Team of teams as a concept enables short to medium-term collaboration across departmental or organizational boundaries around a shared goal. If you’ve not read the book with the same title, I highly recommend it. I have only read it once and will be back a second time. I won't spoil the book but the premise is that complex/unpredictable work requires clear and effective communication to ensure people are equipped with the information needed to effectively make their own localized decisions. If you want your teams to be empowered, they must understand the goals and mission ahead of them or they will always need to be told what to do. Another enjoyable book is The Art of Action by Stephen Bungay which was referenced heavily by Henrik Kiberg at Crispe.se when he was helping Spotify and other organizations. He features the topic of alignment and autonomy which is a crucial concept in enabling people to make decisions when they are connected to a wider goal.
5. A portfolio of work should be used to align around a shared goal, this acts as a backlog that is visible across many teams contributing and allows for alignment and global prioritization. (Flight levels has a concept around this too for its level 2 flight level — coordination). Historically I’ve seen portfolios used for departments instead e.g. how much is your HR department going to spend on ‘technology delivery’ this year. That has typically manifested in most of that portfolio requiring funding for the technology teams aligned with the HR portfolio and some outsells so that they can have other teams support them with deliverables. That often was limited funding based on estimates of people's days and acting more like a way to force prioritization of dependencies. When you move away from funding projects, there is a very real risk that this type of coordination will become your Achilles heel unless you replace the funding carrot/stick with a clearly described approach and cadence for people to align and prioritize efforts around.
6. Product managers should be leading discussions with other fellow product managers to ensure that the value and prioritization are clear. Your product hierarchy/catalog is a way to navigate the organization. Consider creating a browsable interactive solution your organization uses and maintains to understand the products, the product managers, and other people working on the products. This type of knowledge/data is going to be the lifeblood of your organization if you want to effectively collaborate and ensure that you know what team is working on what product. Knowing who to invite to your planning and prioritizing activities is crucial if you have dependencies. Longer-term you want to fix the dependencies but in the short term you need to visualize them and get the support and collaboration you need, or you will end up with teams piling up work that cannot ever truly be ‘done’ because they are stuck waiting on other teams, they don’t have a relationship with to get other work done. This is a recipe for toxicity and blame games to occur. Understanding your organizational bottlenecks is key to managing your constraints, you can’t fix what you don’t understand.

Photo by Laurenz Kleinheider on Unsplash

Reflecting

This was initially meant to be a few short bullet points to help me remember the discussion but after writing them down I realized that the bullet points alone were abstract and not something that can be effectively understood by reading alone. Over time I plan to explore these topics further and turn the challenges into a series of patterns and a set of practices to support different options teams and organizations can take to identifying constraints, and dependencies and breaking them or at the very least elevating them to be understood and effectively managed. Blaming other teams for not being able to deliver when you need them, is rarely their fault, typically it is a flooded system of work or a lack of effective collaboration and prioritization. Consider talking to them and helping them (think inner source). Quite often that product with only one team working on it doesn’t have the capacity to effectively enable their offering to be more X as a Service (another reference to the Team of Topologies interactions).

As with all my knowledge, truly little of this is my own unique perspective, just a reflection on the books, discussions, and situations I’ve observed over the years. To amplify those who have done the challenging work I will endeavor to highlight the people behind the ideas and content. Not enough people reference or cite their sources (outside of academic circles). If you think I’ve missed any sources or people, please comment, and let me know so I can update the content fairly.

I’m interested in how you think about structures in your organization and how what I’ve covered above aligns or contradicts your thinking or some frameworks you reference? I genuinely believe that this topic needs greater exploration and sharing experiences and practices is an effective way to help us get to a shared set of heuristics and patterns that can be used.