Splitting a Team's Developers
Tech companies evolve all the time due to new market needs and so their Software Engineering teams
When a tech company grows, the roles and responsibilities change and adapt accordingly. Today, you needed a team of 4 developers, but for the next year, due to the incoming roadmap, you will need more to accommodate the work and the expectations. At some point, your team will grow not only in responsibilities but also in the number of team members in a way that the management of the team is not effective or efficient.
When I say “management of the team is not effective or efficient”, what do I mean?
I mean that, potentially, you could end up with a broad ownership that could be difficult to handle. Having a big team could attract many responsibilities, taking profit from its size. Many responsibilities will make your priorities more challenging because the probability of “colliding” between them will increase.
I mean about the number of 1-1s you will have to have with your team members. Having too many people will involve too many 1-1s and so too many actionable to follow up in a successful manner. The 1-1s are important and so their outcomes.
I mean that some team members could fall (unconsciously) in their comfort zone. For example, “only doing frontend stuff” because the amount of work to be shipped by the team allows that; specialized people stay in their specialty area only, avoiding growing in other areas they asked during the 1-1s.
In this issue, I explain the journey that I witnessed to split a Software Engineer teams.
We cover:
When is a team too large?
How to prepare for the split?
Perform the split
See also a couple of articles related to team management:
1. When is a team too large?
You can find a lot of literature about what is the ideal number for a software engineer team or an Agile team. In today’s issue, I will not go into the analysis about how to find this magic number that, at then, is solved by one of those magical answers as well, which is, “it depends”.
From my experience, I can state that
3 team members could not be considered a team itself. In my opinion, this size is too small and will bring several complications, for example, at the time to distribute the vacations, or affording some big project.
7 team members are to me the limit for an agile Software Development team. Beyond that, my experience says is better to split, avoiding facing the management issues I’ve mentioned above.
At this stage, since my numbers could not fit your use case, maybe we can focus on the signals that you can watch to detect if it’s time to split your team.
A large set of topics/services/systems (codebase at the end) owned by the team.
Part of the team focuses on one wing of the services/systems, meanwhile the other part of the team focuses on the other wing of the codebase.
People are able to stay in their comfort zone (implementing only UI for example).
2. How to prepare for the split?
Once you detect the signals above, open the conversation during retros or specific meetings, talk to your team, and ask for feedback about the amount of responsibilities that the team has and its size.
This should happen in a natural way. Ideally, the team members themselves could manifest the need to split the team since part of the team focuses on one wing of the ownership and the other part on the other wing. Of course, human beings do not like changes, and a team split is not a difference, so the team will be affected even if they tell you otherwise.
It is important that, besides the feedback the team members could give you (even they may have suggestions about splitting the team), you come up with a split plan. This means you should have your own list about “who” goes to “which” team. This will release the team members of this difficult choice of taking a side, which is fair and expected.
Don’t get me wrong, your list should be created based on several aspects, among which I would highlight:
The career path of the team members.
Roadmap for the resultant teams.
The impact (transfer knowledge, training, etc) of having person X in team Y.
Once you have your list, I would recommend scheduling a 1-1 with each team member. In that meeting, you have to explain in which team you envision that person to be part of and why. I had passed through a team split, on which these conversations did not happen, and the feedback later was pretty loud and clear: the team members wanted to be acknowledged, whether they agreed or not with the decision made.
The last stage before the real split, is to put in place a sharing knowledge plan and make it happen. It should be short and it should be intentional. You have to be sure that, once the split is done, there are no dependencies between the 2 new resultant teams.
3. Perform the split
Put an “end of life” date. A date in the calendar on which both teams will start working independently. Ideally, this should happen when a sprint finishes or at the end of the working week. So the “next day” is a new begining.
I’ve witnessed a team split that tried to be progressive. It did not work well, because the ownership lines could mix all the time. You could end up having questions like “So, we still keep this service, but not this other one, and until when?”
Setting a clear date, on which the new team starts to work, and the old/shrunken team starts too, will avoid confusion and send a clear message.
If the team is working in the office, whether 100% on-site or hybrid mode, you have the possibility to redistribute the 2 new teams in different areas of the office. For me, this is not a must-have. Most likely the team members keep the relationship and a re-distribution of desks could be seen as a ”why this if we are happy together?”. We are humans, not ChatGPT.
To be fair, when I said in the previous chapter “[…] to put in place a sharing knowledge plan and make it happen […] there are no dependencies between the 2 new resultant teams“, this never happened to me in a clear way. Do not get frustrated because you missed a training or whatever; most likely will happen, so just focus on reducing this impact.
Finally, after the split, I would suggest you to get feedback about how the overall process was for the team members, understand if the people are happy and, if someone is not, ask what should happen to make her/him happy again.
Final words
A team split is one of the most complicated experiences to pass through as a Team Lead. It’s a natural situation that happens in companies in growth mode. Your team members will suffer, in some manner, so your job is to make it as snooze as possible, taking into account the business needs too.
Did you manage some team split? Have you been moved from one team to another because of a team split? I would love to hear about your experience, so, please, write down a comment and I will read it!