Team Management in the Context of Change. Lesson 2: Team formation

The second part of this series is about bringing people together into teams and all the things were considered, approaches that worked and did not work for us in the process of doing that. When we started the transformation journey with our customer, all of us had ideas on how our team set up should look. We spent about half of 2019 experimenting and trying to find the best team formation for us.

Skills and knowledge distribution

Our client has a few products, supported by a set of apps, which makes it a rather complex infrastructure. At first, we had specialised teams working on a specific app or a set of apps and we had some areas of the infrastructure nobody actively looked after.

With the new team formation, we made an attempt to create application-agnostic teams, so that any team would have a primary specialisation, but could pick up any project if required. We thought this would give us and our client more flexibility and a way to avoid knowledge gaps and bottlenecks in project delivery.

Being very confident with this approach, we took apart the existing teams at the time and set up a new team structure. Everyone was encouraged to expand their knowledge and challenged to pick up work on applications they’ve never worked on before. Naturally, we received a lot of pushback in the process.

It was hard — it took time to sort out who should be responsible for what, and we were slower in our delivery. People started telling us that when everybody is responsible for everything, nobody takes ownership, and we may lose full control over our infrastructure.

After a few months of learning and trying to function in the ‘application-agnostic’ way, we started to naturally drift back to application ownership. That is because ownership brings more quality and control on certain aspects, like branching, test coverage, etc.

At first glance, it might look like a bit of a waste of time, but I truly believe it was not. We had to take people out of their comfort zone and learn more, which they did. We were not moving back to where we’ve started, because we knew a lot more than we did before.

Experience level distribution

In the process of forming our teams, we paid a lot of attention to maintaining a healthy ratio between junior and senior specialists. My standpoint during those discussions was:

a) Every junior dev or QA should have someone to learn from.

b) Every senior dev or QA should have someone they can rely on and discuss things on the same level, i.e. another specialist with a similar level of experience.

This setup fosters the growth of all specialists in the team and does not leave the seniors in a position where they have to teach others all the time and do not have the capacity to build something themselves.

Addressing business needs

Being aware that there will be a lot of graphics related work in the project pipeline for the year 2019, we formed a separate JavaScript-only team, even in the context of aiming for an application-agnostic teams format.

After making that decision, we hesitated — it felt like we were being inconsistent, so we tried to mix some backend specialists into that team. Twice. They ended up either having no work or nobody to collaborate with, so we had to get back to the original decision (more on changing teams further in this article)

The lesson: whatever your philosophy or general direction is, you have to tailor it to your business context.

Different locations

The team in Vilnius was growing rapidly, but there were also some software engineers and quality assurance specialists on the customer side back in the UK. On the first stage of the team formation process, we wanted to leave the UK-based devs and QA in a separate team, so that we could have a set up that seemed more efficient — all people we are responsible for would be employees of the same company, working in the same location. However, when we presented our app-agnostic teams’ idea, keeping UK based colleagues in a separate team with their specific area of responsibility seemed counter-intuitive, and we did not have better arguments aside from the fact that it would be easier to manage.

At first, we were sceptical about how efficient working with employees from a different organisation would be, as we have different working practices, company culture, we are used to different tools, etc. Nevertheless, we had to follow it through and even find a way to sell this to our teams. We focused on the fact that the UK based team knew something we didn’t and that we should learn from each other.

The process of getting people from different locations, backgrounds and companies to come together into teams has been a colourful experience. We have success scenarios — like a team that managed to find ways of understanding each other and working well together; we also have more challenging cases, like a team where people tend to look for ways to work ‘around’ each other and not with each other (they do get things done as well!).

The lesson: to achieve efficient teamwork, all sides have to be interested and willing to collaborate.

It takes a lot of effort, time, determination and mental energy from a Scrum Master to guide the team through challenges and personal clashes, but in the end, it is worth it.

Changes in team formation

The general rule we have been following in our account was: keep the team structure stable for as long as you possibly can. You want to give them a chance to reach a level of team maturity where they can perform. As we all know, every change in the team brings them back into the forming phase.

However, there are situations where you have to make changes. Here are some examples from our experience:

• As mentioned before, we added JAVA devs to our JS-only team in an attempt to build project-agnostic teams. We thought this way they could do some backend related work as well. In reality, the JAVA specialist would have nothing to work on (as all other team members were busy building graphics), or the Scrum Master had to put in extra effort to find work for that one person specifically. It was challenging in many ways, and we ended up reassigning the JAVA specialists to different teams.
• We had a case where two junior/associate level specialists who joined at approximately the same time lacked confidence. We felt like they were ‘feeding’ each other’s helplessness, and that stopped them from growing professionally. Even though their mentors believed they would feel safer staying together, we decided to split them into two different teams. This decision put an end to the ‘I cannot do this’ narrative. They naturally focused more on stepping up to their colleagues’ level and received a lot of support in the process. Now they are high-performing specialists who train other newcomers.
• There was a team member who’s had a slightly bumpy road to professional maturity. They made mistakes and it broke the confidence of their teammates. This person worked very hard to improve, but their teammates wouldn’t trust them anymore. It resulted in tension and even some conflicts within the team, so we decided to reassign this person to another team, who would not have this bias based on past experiences. It worked — the team member keeps growing professionally to this day and there is no psychological tension in either of the teams.

When someone decides to leave the team, we also think whether team formation changes are required to maintain optimal delivery capacity but more on that in the next article.

Overall, team formation is a never-ending exercise — people move, projects evolve, and as a manager or a Scrum Master, you have to do the best you can to adapt to the constantly changing context in a way that has as little impact on your team’s health as possible.