Adjusting Goals to Teams?
This post was co-authored by my brother Stefan and me.
In my post Divide-Conquer-Integrate? I briefly touched on the issue of “building work around teams vs. building teams around work”. Today we want to take a deep dive into this topic.
Let’s start by looking at the following two scenarios:
Scenario 1
We have structured our org into a number of stable teams in our company, each taking care of a specific domain (e.g. sign-up, search, checkout, etc.). All teams work in synchronized, two-week sprints (i.e. all teams start and finish their sprints at the same time). In preparation for the next sprint, the product owners of the respective teams consider which goals they want to achieve with their teams in the next sprints and adjust their backlogs accordingly. Because there are dependencies between the teams, they periodically communicate with each other in order to deal with these dependencies as elegantly as possible. Most of the time, however, the teams work on their respective goals largely independently of each other.
Scenario 2
We have the same situation as in scenario 1, only this time we want to develop a new major feature that we know all our teams will have to collaborate on. In preparation, all product owners and some developers¹ meet to develop a common understanding of what exactly the new feature should look like and how it can be implemented. They then divide the overall scope of the feature into smaller packages, which are assigned to the respective teams (depending on which domain they fit into best). The teams then work on team tasks for several sprints and eventually integrate them with the other teams’ work. While the work is ongoing, the teams coordinate with each other to clarify any questions that arise, resolve dependencies, etc.
Both scenarios are likely to be common in many organizations that work in a more or less agile way. The first case involves feature development in independent teams. In the second case, we see a scaling mechanism in which several teams work together to develop a big feature. The fact that the teams in our examples use Scrum does not really matter. The similarity between the two scenarios that we want to highlight here is this: Both times, the goals and tasks are adapted to the existing team structures. That is, we take the structures as given and then think about how we can achieve our goals within these structures with as little friction as possible. There is of course nothing wrong with this approach in general. However, it has become so routine in many organizations that it is difficult to even think about other models.
So let's consider how the two scenarios could change if we were to pursue the opposite approach: adapting the team structures to the goals and tasks.
Scenario 1b
There are no fixed teams, but all our developers are part of a large pool. Every two weeks, there is a workshop where the entire pool meets to form temporary feature teams for the upcoming sprint. In preparation for the workshop, a list of goals is prepared, and for each goal there is a rough idea of how this goal could best be implemented. After questions have been discussed, small teams are formed in a facilitated process. Each of these teams will focus on one goal and the related work items. Care is taken to ensure that the required skills are represented in each team. At the end of the sprint, the results are presented, features go live and the teams rejoin the large pool.²
Scenario 2b
Similar to scenario 2, we have stable teams working on their own goals most of the time. However, this team structure is temporarily weakened every time we want to develop a large feature that requires substantial collaboration between multiple teams. As a first step we think about the skills and domain knowledge needed for building the new feature. Based on these insights, we form a new team, which will focus exclusively on the development of the new feature. The individual product teams remain in place, but often only with a skeleton crew, because they have temporarily “lost” individual members to the new team. They now have to consider how they can generate the greatest value under the given circumstances and set themselves goals for the upcoming sprints accordingly.
None of the scenarios is better or worse than the others. It all depends on the context. But like we have described above, we too rarely ask ourselves whether it would be appropriate to adapt the structures to the goals. We should therefore ask ourselves this question regularly:
Pros and Cons of the Two Approaches
The two approaches (adapting goals to structures vs. adapting structures to goals) form poles that create a field of tension. The main argument in favor of adapting goals to structures is that people need time before they become productive in new structures. The main argument in favor of adapting structures to goals is that it allows us to reduce overhead through dependency management and coordination.
We can visualize the two poles in a coordinate system. Depending on the extent to which we make use of temporary (fluid) teams, different costs arise. If we work with permanently fixed team structures, high costs will arise sooner or later due to the dependencies between teams. On the other hand, if we work with completely fluid teams and change the team composition frequently, we will incur high team-building costs.
The exact shape of the two curves will of course depend on the context. For instance, if the teams are each working on their own products that are rather independent from each other, we will see lower costs due to dependencies. In the end, it's all about finding our own sweet spot.
Team Focus and Split Heads
Another important aspect is the focus of the individual team members. Interestingly, decreased focus can become a problem in both approaches - but in different ways. If we form a temporary team to work on an important goal, we might need a specialist in this team. But this very person might also be essential to one of the remaining core teams (e.g. because only they are proficient in a specific technology). Then you quickly end up with the person being a member of both teams - a split head. Split heads are a very efficient way of destroying productivity. Constant context switching is toxic in knowledge work: we have to constantly reengage in different contexts and lose a lot of productive time as a result. This may be acceptable in exceptional cases. However, if we regularly work in teams with split heads, we can simply not expect high performance.
The problem of diminished focus is more subtle when working with stable teams (i.e. not adjusting our structures to our goals). Although here the specialists are only members of one product team, they are often repeatedly asked for help by other teams or even just by their own team members.
In order to maintain as much focus as possible, clear prioritization is necessary (in addition to an awareness that this problem exists in the first place). If we form a new, temporary team that needs our one specialist, then all work requiring this specialist expertise in the other teams should be deprioritized accordingly. Even if we decide not to set up a new team for the new feature, we need a clear priority: in all teams involved, work on the overarching feature should have the highest priority and trump most of the other work items, in order to avoid split focus. As simple as this prioritization sounds, many companies find it difficult because it makes it painfully clear that we can't develop everything at high speed at the same time.
When to Use Which Approach?
There is unfortunately no one right answer to the question of whether goals and tasks should be adjusted to structures or vice versa.³ But if we let go of old habits (“we've always had stable teams”) and beliefs (“fluid teams are better”), we can find solutions that offer the best cost-benefit ratio for our context. The following key questions can help:
What is our standard approach? Do we tend to adapt the structures to the goals or the other way around? What are the benefits we gain? What are the costs?
Where are we on the spectrum between extremely stable and extremely fluid teams? Do we suffer from excessive costs due to dependency management or repeated team building?
What would the opposite approach look like? For instance, if we have very stable teams and largely adapt the goals to the structures, what would it mean for us to have very fluid teams and adapt the structures to the goals? We can run through this as a thought experiment to gain more clarity about strengths and weaknesses and potential blind spots.
What about our focus on important new features? Do we have a tendency to produce “split heads”? What can we do to avoid them?
(You can find a German version of this post on it-agile’s blog.)
__________
¹ We use the term developer here in the sense of Scrum. This includes not only software engineers, but also designers, user researchers and all the skills we need to develop our product.
² The approach described here is very similar to the process proposed in FaST (Fluid Adaptive Software Technology).
³ In this form, the question is of course unnecessarily binary (either A or B). In practice, we will almost always find ourselves somewhere between these two extremes. The question then is rather in which cases we should move more in one direction or the other - and how far.
Mit vielen Teams viel schneller liefern
Im Juni halte ich zusammen mit meinem Bruder Stefan eine Schulung zum Thema Team-of-Teams. Ort und Termin: 11./12.06.2025 in Hamburg
Mehr Info
