Org Design Pitfall: Fragmented Resource Pools

Sometimes what we refer to as a “team” is merely a set of individuals who don't genuinely cooperate or deliver collectively. This blog post examines a common pitfall that numerous companies inadvertently grow into. In this post we will explore its origin, identify the issues it generates, and provide a model that helps you see find problems and solve it.

This tends to happen most often in small but growing businesses. The usual process is something like this: a leader in the company asks the Product Manager to create something. The PM plans it out, then works with a group of developers to build it. There might be a QA (quality assurance) person who checks the work, and maybe a DevOps person who gets the software ready to go. This process changes when the company starts to really grow, usually because they secured extra funding to kick off a major new project. Suddenly there are two groups of developers: the ones focusing on the new project, and the others who continue working on "almost everything." But regardless of these new roles, both groups continue to pull tasks from “upstream” PMs and pass their work “downstream” onto QA and then onto DevOps, thinking that’s how they did it before.

The Issue & Why It Stays Hidden

This way of scaling a business seems logical when you think in terms of an org chart, where it’s all about reporting lines. You're not getting to the heart of the matter: how people interact and work with each other.

If you've grown from one team to two teams, you'd expect to be able to do twice as much work, right? Even more if they can work together on some things. But it rarely work out like that. Commonly, issues that were invisible before at a smaller scale get amplified and make it impossible to get double the value from double the teams.

Let's look at how this problem comes down to having “groups of people with similar job titles” instead of actual teams.

“Team Topologies” is a different way to structure your organization, putting business outcomes before anything else (not reporting lines). Unfortunately when companies come into this growth case mentioned previously, they can mistakenly think their company has two teams of developers so those are the streams. (a “Stream” is a team that takes care of a "value stream" focused on the customer).

The problem is, this is a big work of fiction! Yes, sure, there are two groups of developers that do work on those topics, but this is an oversimplification. The problem is about all the interactions between groups that are not shown in this diagram. Simply put: the teams and team interactions don’t actually look like this.

The big mistake here is thinking that a “Stream” is just a group of developers assigned tasks from another group (“the product team” for example). But this doesn't cover the whole picture, and the real interactions among the teams are far more complex.

As startups grow, the original team usually notices things slowing down compared to the early days. In the past, one team handled everything. Now, different teams like "the Dev team" and "the Product team" juggle tasks and hand them over after following some more complex processes with more steps, more checks, more oversight, more external over-the-wall type stuff.

But even this mental model is not really what’s going on. It's based on the wrong idea that groups of developers are the main building blocks of a company's structure. This leads to thinking that a group of developers is a "stream", but this isn't true. Especially when you see how they actually interact. The key point missed here is that everyone on a value stream needs to work together (and what that means is also easily misunderstood). This model of “everyone works with everyone else, and we do it over-the-wall” just piles pressure on teams up-stream and down-stream at the same time, requiring that any one team must work with many other teams to create value. Nobody gets to be in an autonomous team.

“Everyone needs to collaborate with everyone else” sounds nice on a bumper-sticker. However, as orgs grow the problems become more noticeable. By the time they reach 4-5 teams the problems are easily noticed in day-to-day work. This flawed model for team growth adds strain, bottlenecks, and cognitive load on everyone. At the same time, it removes ownership from teams and reduces quality delivered to a customer.

Considering Dunbar's number (the human limit for interactions), this organizational “design” will either weaken cross-functional ties as the group expands, or creates a pseudo-team with assigned contact points from each job type, but this psudo-team can’t act as a proper team because their process forces handovers on everyone working on the value stream, never truly merging them into a a value-stream-aligned-team.

This subtle interplay between individuals is the key in distinguishing between waterfall orgs and ones set up for fast-flow. Not understanding this often traps organizations to inadvertently adopt waterfall practices by default.

The Reality: Unveiling the Trap

When we divide "teams" by their role or functions, no team actually has ownership from start to finish of a project, there is no real “stream-aligned team” because there is no actual team.

Instead, there are multiple enabling teams passing their work artifacts along for different parts of a project (projects are not value streams) and hand off their part to the next group. Each group is assigned tasks but really acts more like a service provider than a team. This “push it down the pipeline” workflow causes a lot of problems. It especially hinders the preservation of deep and shared context about the value stream, which causes issues with quality, accuracy, timeliness, and meaningful outcomes of work.

This is not a desirable state, but it is very easy to be fooled into thinking you have “two teams” instead of multiple resource pools handing artifacts over between teams.

How do we fix it?

Identifying what value streams the org needs is a key part of organisational design. However, without concentrating on the extra dimension of efficient interaction among team members you can never truly implement an effective org design; it just remains as simple drawing only.

Avoid defining people by their job titles and limiting their roles; instead, focus on encouraging seamless collaboration and end-to-end ownership.

John Cutler created two models to think about how teams work together and what their responsibilities are.

This chart shows two different orgs side-by-side. The left-side org has a hard barrier between “The Business” which decides everything from picking long-term business outcomes down to picking the specific problem to work on, and then it gets handed over to the “Product Owner” who is “inside the team” that solves the business problem and has a softer hand-over to the developers to figure out how to build it.

The other org on the right is very different, the business picks short-term outcomes and hands them over to a PM who explores the business case but then shares the problem solving of finding what metrics to influence and what what it means for the customer. After this, developers and designers work on finding a solution to that open-ended problem and have ownership down to the smaller details.

These are two very different cultures. The scope of decision making freedom for the team on the right is much greater, and the cross-functionality is might more cohesive. Inside the team they are not “handing over” artifacts down the line, they are collaborative and bridging context.

This model explains how “agile” and cross-functional a team can be. At the top you have a “team” (not really a team, just people chained to the same assembly line) with heavy handovers between stages in the discovery-delivery life-cycle. The teams become more “agile” as they go down the table: heavy external handovers become softer internal handovers, working in isolation on a task becomes cross-functional teamwork for any given development stage.

In this model the most agile team has no handovers and they start, work, and finish together (not as isolated units on different tasks, not throwing artifacts over the wall). Reminder: The term “Agile” has been heavily polluted, it is not about using any specific agile framework, agile is a word that means “able to move quickly and easily“.

When I need to solve this sort of organisational problem, I found I can intersect these two models into a richer image. Picture a new model with those two models on different axes. If you reduce the complexity of mandate levels, you have a gauge to determine a team's decision-making freedom. Using the agility model, you can see how well a team can work across different functions. Note, the chart I'll show you now isn't the exact one I use, but it is a stepping stone to help you better understand the one I do use.

Cleaning up the model, we get the "Function-Mandate Space" diagram, which visualizes the connection between cross-functionality and team mandate. I use this diagram when I need to quickly assess a team's (or an entire organization's) effectiveness. It can also help point out potential issues that need attention. The vertical axis shows the level of decision-making freedom a team has, while the horizontal axis presents the extent of cross-functional work within the team. To illustrate, I've marked examples at the extremes of each range in yellow.

The aim is to make changes that enhance your team's culture. This means pushing the team towards greater decision-making freedom and cross-functionality. Doing so enables the team to focus on delivering end-to-end value, which in turn, allows for the creation of a more efficient organizational structure, which finally allows you to properly create stream-aligned teams and get the full benefits out of Team Topologies.

A team should be a close-knit, cross-functional group that is responsible for and drives value from start to finish. Groups of people (resource pools; reporting lines; not-teams), on the other hand, are simply people grouped by job titles. When designing your company's value delivery process, avoid joining together these resource pools as a way to make change flow through your company. And remember, a team is much more than just a group of people who write code or perform other isolated tasks in the end-to-end process.