Surviving Team Splits in Software Engineering

It initially sounds pretty simple - you are part of a software development / engineering team, and it is going to become two (or three) teams instead. This usually happens because things are going great - the team has been growing, it owns more things, but attention is fragmented and so it is time to split.

You may be going through this right now and have just come to the realization that there are some...teething problems. You may have gone through this many times previously and now dread the next occurrence. However you got here, it doesn't take long to hit some bumps along the way.

I have been through this a couple of times in my career, and have some tips to share on how to not only survive it, but really lean into the change and make it a quick success!

What just happened?

There are usually two concerns involved with a team split:

1. The people - who from the original team is going to which new team,

2. The things the team owns - this can be summarized as the teams's responsibilities. In my line of work this was usually software services - both the code, and on-call responsibilities thereof. These can be anything so I will just refer to them as "things" for simplicity.

During the process of a split, defining which people go where is the easy part. Which things goes to which team sounds simple on the surface, but in my experience it can take weeks (sometimes months) of detangling responsibilities, setting up or migrating processes, or just re-discovering existing things that just don't show up all that often (until it does and everyone is asking "hey, doesn't the other team own that?")

What to do?

Take stock
The only way to develop the correct solution, is to first understand the problem. Taking stock in this context would be to exhaustively document which things belong to which team. In some cases the answer is "both teams", or "mostly this team - except for this process", or "no idea". It doesn't matter what the answer is, document it all. It isn't the well-defined easy stuff that it important here - it is everything else.

Formulate a plan
Now that everyone is on the same page about what things are in the wrong place, both places, or no place at all - you can come up with a plan to fix it. If some issues are as easy as just picking a team (where either team will do), then do it immediately and move onto the next issue. But what are some of the more difficult issues that might crop up? Here are some examples I have seen:

1. On-call responsibilities where the new team owning the code doesn't yet have enough expertise to go solely on-call for it.

2. A codebase that is made up of multiple distinct pieces of software, now owned by different teams but was coupled in ways that means changes cannot occur in one system without somehow affecting the operations of the other.

3. Operational tools, monitoring, or processes that pertains to different things, but was all bundled together under the name or label of "the team", and now has to be detangled back to their underlying things.

Some of these issues can't be fixed overnight, they need a deliberate set of steps to fix. These steps should be agreed upon, documented, and time allocated to make it happen.

Set limits
While executing on the plan, business still has to go on. This usually means some type of temporary quick and dirty solutions are put in place to keep everything from crumbling. Maybe one team continues handling customer engagement for another team's thing while the new owning team gets their process defined. Perhaps one team needs to handle all the things not yet discovered but that may suddenly require attention, until everything is cataloged and can be distributed.

Whatever the quick and dirties are, they usually need some form of time limit - else these temporary solutions can go on forever. As an example, lets assume two new teams share code reviews on a common library. The teams agree that one of the them will skill-up on the code and fully own it after 3 months. These time-frames are not easy to define and you may need to push them out if everything isn't quite ready yet, but at least there is a defined checkpoint.

Another situation I personally recall, was being on a team that still owned on-call responsibilities for some software that was now owned by our newly spawned sister-team. The new team was mostly new-hires directly out of college and one tenured engineer to guide them. We sat with our respective managers and agreed on a timeline to get the new folks trained up. If I recall we had to delay the transition once or twice, but there was always a well-defined limit and eventually the transition was successfully completed.

In conclusion

Getting through the rocky phase of team splits is easier with a methodical and deliberate approach. Use the steps above as a rough template to bring some order to the chaos.

Happy Coding.