Growing Teams without the Pain

tl;dr

A unit, I was supporting, recently transitioned from a setup with two engineering teams to three engineering teams. A structured process was used to prepare the change in team structure, achieve the highest possible support for the necessary decisions, and assist with the actual transition.

This article describes the context, the reasoning behind the approach and the actual steps which have been taken.

Background

When I started working with the unit, I was told how it all started with a handful of people and only recently got significant traction.

A couple of months later, two big partners went live with the system. By that time the undertaking had fully transitioned from an R&D project to a key asset of the company. The next big step will be the full migration of existing partners from the legacy solution to the new system this year. In order to achieve this next milestone, the decision was made to grow the team further.

With the number of people reaching …, we were going beyond effective team sizes and this meant, going from two to three teams.

This may sound simple, just set up the team, assign people and get going. But since we are talking about people and not AWS instances, things need to be done a bit differently if you want to avoid incidents.

Considerations

This part of the blog will illustrate some considerations which went into the approach we chose.

How not to grow

A seemingly obvious approach would be to hire new people and put them in a new team. Yet we never seriously considered this approach. Why?

An (agile) team is not just a bunch of people. Every team develops a body of experiential knowledge — by doing things and learning from the experience. This knowledge cannot completely be captured in any form of documentation or transferred by training. Yet this kind of knowledge is crucial to becoming an effective contributor. The most effective way to onboard is, to pair someone new (to the topic) with someone experienced. Forming a team with just new people would make this kind of learning practically impossible. As a consequence, such a team would inevitably struggle to become productive.

But there is more. Besides the work-related knowledge, interpersonal relationships are at least as important. Learning how others tick, who is good at what, and how to best deal with them is key for effective collaboration. Again, a new team formed in isolation would not only have to do this relationship-building internally but with the other teams as well. Relationship building is never smooth. This approach would make it unnecessarily hard and almost certainly cause misunderstandings and friction.

A better approach

If we rule out starting a team from scratch, another option is to fill up the existing teams with new joiners and then spin off a new team, consisting of veterans and team members who have recently joined.

This approach is better, but not ideal: First, people have bonded over time. Asking them to leave the existing team and go to a new one will likely feel unpleasant and few team members will volunteer. Another aspect is that we are not starting with one team, but two. Just splitting one team and leaving the other intact will likely lead to disappointment. Taking people out from both teams may seem to be fairer but still leaves us with the “having to leave the team” stigma to deal with.

We decided to go a different way. The decision was made to end the two existing teams and form three new ones out of the existing team members. The reasoning behind this solution is that with this approach, everyone is in the same situation. Nobody has to leave a team or everyone — depending on how you look at it. It might be counterintuitive to make the transition uncomfortable for more people. While this is true, the objective here is to ensure fair treatment for everyone, not maximize comfort.

Same same but different

A further aspect to consider: The teams developed slightly different practices over time — within the common process framework. The individual variation is a good thing. It means that teams take ownership of how they work and adjust the processes to their needs.

Nevertheless, with the decision to form three new teams, composed of people from both previous teams, the new teams would have to deal with two sets of working practices. From a coach’s perspective, this is also an opportunity to question the previous approaches and take the best of both worlds.

Important is to do this mix and match respectfully. Avoid any “we do it the right way, you are wrong” — but instead try to understand the logic behind the other approach and then agree on what to do in the future. And this can be one of the old approaches or very well something new, which emerged out of the conversation.

Can’t avoid the Storm

Everyone who studies teamwork and team dynamics, will sooner rather than later stumble over Tuckman’s stages of group development. The core message of this model is, that any team will go through different phases before it becomes performant. There are some additional insights that are important:

• A team cannot skip phases, just move through them faster (it may get stuck in a phase and never get to performant though),
• Any change to the composition resets the process to a degree and the team has to find itself again.

Our transition from two to three teams is certainly more than a small change. Thus, we have to expect the teams to need some time to form, learn to work with each other, and get performant.

Approach

With these considerations in mind, we went into designing the approach for the transition. I will describe what we did in three phases:

• Before
• Switching the teams
• Aftermath

Before

With the way we organized the change, we wanted to

• Ensure a transparent process to allow everyone to understand what is going on
• Allow everyone involved to share their perspectives
• Take these perspectives into account as much as possible when making decisions
• Minimize time investment for team members, especially meetings

The decision-making approach we used was the same for all phases:

• Come with a proposal for what to do
• Align between the Staff Engineers before involving the whole team
• Share the proposal and ask for feedback
• Integrate the feedback and repeat if necessary
• Conclude the process and move on

The main question to decide was the composition of the three new teams. Before went on to do that, the first step was to share the process for deciding on the team composition and ask for objections regarding the process itself. This may appear bureaucratic but is very intentional. We weren’t sure how emotional the team composition discussion may get, yet we wanted to involve everyone and not decide over the heads of the team members.

By checking support for the process first, we allowed everyone to raise objections regarding the transparency or fairness of the process. This helped to avoid engaging in a process discussion later if someone would be unhappy with the decision about the actual team composition.

Tipp: Sorting out process discussions before a potentially difficult subject matter helps to focus on each aspect individually and avoids mixing them.

No concerns regarding the process were raised so we went on with the decision on the team composition. As mentioned, the approach was the same: The Staff Engineers created the first draft of how the new teams would look like, shared it with the teams, and asked for feedback. After the feedback period was over, the decided team structure was announced.

Fun fact: During both processes, no objections were raised. This can be read in a way that the process was overkill and attempted to preempt issues that didn’t exist. This can also mean, that the very act of asking team members for their perspective was important. Feeling seen and heard might have been enough for people to be able to support the proposal.

The process may look complicated, but the actual time investment wasn’t big (especially compared with a workshop involving the whole team). The potential cost of having to sort out grievances later was much higher in time and loss of goodwill. Overall, the approach taken was successful and I would recommend it again.

Switching the teams

The actual switch from the old to the new team structure actually took me by surprise. I didn’t follow the proceedings closely after sharing my input initially. So when I was getting approached to prepare the team switch workshop, I had to scramble and set something up.

We reserved almost half a day for the workshop. The overall agenda consisted of two main parts:

• Looking back and appreciating the past experience
• Looking forward and setting up the new structure for success.

Looking back

The Senior Product Owner started with an overview of the history of the unit. How it all got started as a research project, then turned into full-blown product development, and now being one of the key assets of the company. He also shared how the next steps will look like.

The Engineering Manager continued. He spoke about every individual member of the unit and what he appreciated about each of them.

We continued with a part in which the team members went to breakout rooms and had a conversation about their remarkable experiences as part of the unit. We came back together and the groups told the best anecdotes to the whole. group. As it happened we had three new joiners participating in the session. There is probably no more effective (even though exhausting) way of onboarding someone to a team than this event.

I agreed with the Engineering Manager beforehand that we will not call this part a funeral. But the team members immediately saw through it and call the session what it was — a funeral for the two teams which would be discontinued that day.

Looking forward

After we had said goodbye to the previous teams, it was time to welcome the new ones. One part of this step was to sort out organizational questions, to the least of which were the names of the new teams.

The second (and final) part was to define common working principles for the new teams. You are probably aware of the idea of a Working Agreement and what we did here is very similar. I called it principles because I wanted to avoid unduly limiting rules but also vague statements.

I don’t like rules because they unintentionally invite people to stop thinking and do as told. Also, rules tend to never quite cover the real-life case. This leads to a situation where team members have to decide to follow the rule and do something which does not really make sense, break the rule or trigger a rule discussion. None of these options is really good.

At the end are vague guidelines that express something like “we communicate well”. Statements like this are too unspecific to apply and open to interpretation.

What I am looking for in a working agreement are principles that describe how certain situations should be handled. The details of how a principle is applied are at the discretion of the people facing the situation. But, and this is important, it is possible to evaluate later if the principle was applied or not.

So we went into breakout rooms again and the participants talked about what principles they would find useful. We then mixed the groups and compared ideas. At the last step, we worked with the whole group to agree on a shared set of principles. At the core of this activity was the MinSpec liberating structure. The idea is to start wide and collect all ideas but then trim the list down to the absolute minimum required.

Aftermath

Even though the workshop seems to have contributed to a good start, the real work started afterwards. Immediately after the teams gathered and planned their first Sprint in the new setup. And, while everyone has worked within the same framework previously, a lot of details needed and still need to be figured out. As mentioned above, this process is entirely normal and cannot be skipped.

One thing I like about agile is that it comes with retrospectives as a standard practice. Regular reflection is one of the best instruments to facilitate the process of a team growing together. And reflection is what we do in retrospectives.

Since we have not one new team but three, we decided to experiment with a different approach to retrospectives than before and have the retrospectives for all three teams in parallel. The purpose of this approach is to allow for reflection on the team level but also maintain a degree of shared understanding what are the concerns in the other teams and what might be issues that need to be addressed together.

Wrapping Up

At the beginning of this article, I have explained why any changes to the composition of a team cause a process of adjusting and (re-)forming. It is my sincere hope that it also came across why it makes sense to not just let these changes happen and hope for the best but work to create conditions under which it is easier for teams to form and become performing.

I wrote about the changes in the units engineering team composition and how we worked to smoothen the process as much as possible (while also acknowledging that there is a lockdown and a lot of things we would like to do are just not possible).

A core aspect of the approach was to facilitate a clear and transparent process that balances participation with structure and efficiency. Also, teams are after all humans working together. Thus, catering to emotional needs is a vital part of any team structure change.

I am very grateful for the opportunity I had to assist with this change of team structure for the unit. 🙏