Are flexible team structures good or bad?

On the one hand, (mostly) management wants flexibility in team structures so that the right people can work on the most important issues. On the other hand, stability over time is necessary to build a high performance team.

What do we do with this clash of objectives?

Flexibility - Where does the need come from?

The need to build teams flexibly arises precisely when the skills needed to address a topic do not match the skills of the team.

Required skills vs. skills of the team.

Figure 1: Required skills vs. skills of the team.

Example (Figure 1): The new topic has a low yellow and a high red share of tasks. The team consists of 3 yellow and one red members. If nothing changes in the task and the team composition, this will inevitably lead to an overload of red and an insufficient workload for yellow.

There are several ways to respond to this now:

  • Accept idle time. The topic is addressed by the team, even if it takes longer and individual team members can contribute nothing or very little. Our experience: Idle time is difficult for everyone, because each person wants to contribute something meaningful to the team goal. Many times other things are then started, which leads to a lack of focus.

  • The team finds opportunities for everyone to contribute, for example through testing, user interviews, or other activities. Our experience: This is limited. People want to work in their area of expertise and primarily look for tasks there. Here too, the risk of defocusing exists.

  • Development of team members so that yellow members can also take on red tasks (“Fullstack”). Our experience: This is not easily possible in every team and every codebase and not every team member wants this.

So the obvious solution is to assemble the team according to the requirements of the given task.

Dynamic team structures as an anti-pattern.

The authors of Team Topologies - Matthew Skelton and Manuel Pais - describe dynamic team structures as anti-pattern [1]:

“The other common anti-pattern is shuffling team members. This leads to extremely volatile team assembled on a project basis and disassembled immediately afterward, perhaps leaving one or two engineers behind to handle the “gardening” and maintenance phases of the applications(s).”

We can only agree with this in the scenario described here.

For a new project / topic, management puts together a team with the right skills from a pool of all employees. The team exists only for the duration of the project and is dissolved afterwards. Maintenance is left to one or two engineers.

Flexible team structures as anti-pattern.

Figure 2: Flexible team structures as anti-pattern.

Among other things, this has the following effect:

  • Employees feel alienated, with all consequences: Burnout, low motivation, no ownership.
  • No focus on a specific domain/area to develop really high expertise there.
  • No (or only a very loose) personal bond between team members.
  • No identification with the product, the team and the code.
  • Last but not least, no own ideas emerge within the team.

This brings us to the question: Is there a way to use flexible team structures without having to accept these undesirable consequences?

Dynamic team structures as a pattern

One way to resolve many of the disadvantages mentioned above is to have a fixed framework in which teams can form and dissolve. The following constraints have proven to be helpful for us:

  • Flexibility occurs only a group of about 30 people in which all participants know each other well and personal relationships are already established.
  • A domain with a clear purpose is defined, for which the whole group is responsible.
  • The domain also implies a clear ownership of code.
  • Teams are formed in a self-organized manner, e.g. through self-selection.
  • There is a fixed cycle according to which the allocation takes place, e.g. 3 months based on the OKR rhythm of the company.
Example of a fixed framework with flexible teams.

Figure 3: Example of a fixed framework with flexible teams.

Figure 3 provides an example showing how dynamic teams can work.

The entire domain in which the company operates is divided into three independent subdomains. Each domain has its own code and teams with all the skills needed to be productive in that domain.

Each domain has about 30 team members to start three to four cross-functional teams.

The domain is divided into the three to four teams in a self-selection process.

We have described our own experiences with dynamic focus teams at Chrono24 here.

Conclusion

In order to enable dynamic team structures, you need a fixed, clearly defined framework in which teams can form autonomously. Only then can the biggest disadvantages be eliminated and flexibility be leveraged.

Nevertheless, dynamic team structures are always only the second choice when - as in fast-growing companies - fixed team structures are not feasible.

References

[1]: Team Topologies

Webinar: Scaling software development as a SaaS company without becoming consumed in the growth process.

The webinar addressed exactly the pain points that are occurring as we grow. With an ever-increasing number of employees on the Dev & Product team, we've had to find out for ourselves how difficult it is to set up a sensible structure that brings out the maximum efficiency and performance in everyone, while also leading to a healthy working atmosphere.
Pascal von Briel, Co-Founder & CPO @ exporto GmbH