I Split My Dev Team in Two. Here is How I Did It | by Bruno Zimpel

The 3 things I looked at before making the change

Photo by Marvin Meyer on Unsplash

Recently, my team doubled in size of developers and went from 3 to 11 projects running in parallel. It was not after long that we noticed that the “old” structure and organization within the team wouldn’t work for long.

Seeking to separate different fronts of the business, more flow of information across the board, and everyone be less overwhelmed with tasks and context-switching, I sat down with the more senior developers, and we discuss possible strategies.

After a couple of months running with this new configuration, the overall experience has been positive, so here I’m to share a little bit of the process and the results 🙂

For bureaucratic reasons not relevant to this discussion, the way that my team operates is that, for every new set of features of the product we’re responsible for, we receive a new project to be completed with our client. Delimited scope and timeline and, with the business people’s thumbs-up, we get to work.

With a small set of developers and projects running in parallel, although everyone had their responsibilities in each project, usually each team member was involved in all projects, and the flow of communication and knowledge within the squad ran smoothly, even with the historical maximum number (5) of projects running simultaneously.

After some changes in our internal process to do requirements gathering and move new projects forward faster, we improve substantially the sales flow but created a problem for the development team: more work to do. Unarguably a good problem to solve, but a problem nevertheless.

We doubled the team’s size and increased substantially the set of features being implemented at the same time. Having everyone involved in all projects would no longer work: we started seeing a lot of confusion between projects, peer review started taking a lot of time, people got overwhelmed with context-switching, and progressed slowed down by a lot.

Solution: break the team into two. Each senior dev would lead one of the “sub-teams”, and their responsibilities/scope of involvement would be limited.

On the other side of things, the team is still the same. The dailies are shared, the client and business context is the same, and, by far the most critical thing, the ever-growing codebase is still the same. And these things cannot be overlooked, otherwise, you’re setting yourself up for failure, creating an endless pit of technical debt.

Below are some of the “prerequisites” that I took into consideration before implementing this change in the team’s structure.

Not a requirement per se, but certainly not something that hurts: your new team leads have worked together before for a while. They know the codebase, the business, the client, the libraries, the internal processes, and how the team functions. More than that: they know where the team is moving towards.

First of all, this will reduce a lot of friction when the team splits. When the implementation of each subset of projects moves forward, we know that they won’t go in orthogonal directions.

Apart from that, the onboarding process of the new developers will be fairly similar, and we’re setting the same expectation for them regarding internal processes, responsibilities, and everything else.

“Yeah, they also have a common understanding of the code standards, so you also solved that problem!”. Well, maybe. But I wouldn’t rely only on their shared experience as a guarantee of a cohesive codebase when the team is split.

I strongly believe that, in whatever structure of teams you have, code standards — from linter and formatting definition, to naming conventions — should be documented. For this team restructure, this was no different. This leads us to the next section.

At my current company, a strong part of our culture is continual improvement. A big portion of that relies on documentation, peer review, and iteration: from the development to the hiring teams, we document our processes and subject them to peer review, and on this first iteration, we already can see gaps and/or points of improvement.

Usually, v1 is small, so we don’t have too much up-front cost, and we try to do it in a low-maintenance way. Time-consuming wise this doesn’t take much, and yields multiple benefits as we go by.

With frequency varying from case to case, we measure results, and iterate the process’ definition, always looking for ways to improve. On the other hand, if something changes, this is also documented, and we create this ever-growing knowledge base without too much friction.

Documentation also brings another benefit to the table. Since forever, but especially in the last few years during the pandemic, the software market is dynamic, and one way or the other, you’ll have to deal with personnel turnover. When you document things, you reduce the cost of onboarding a new team member.

Photo by Sigmund on Unsplash

In my team, the documentation is true for the processes, tooling, and lessons learned after each project/feature is complete. This is also present in our developer style guide, and it played a key role when we split the team.

With time, we settled on different standards regarding different things. From commit messages to ease the peer-review process to standards on the Exception messages, all of this was documented, mostly by the more senior developers that worked together, as mentioned in the previous section. This developer guide went through peer-review then, and we keep iterating when new definitions are made.

We don’t expect all developers to know every small detail of the guide from end to end. But we do expect that it can serve as a reference that everyone in the squad can rely on and, from a higher perspective, will help the codebase to keep growing cohesively.

The next step, of course, is to leverage CI/CD pipelines as much as possible. In our case, we use GitLab CI and, for style and formatting, we added checkers to ensure some of the styling guidelines previously defined together. To name a few: mypyfor static type checking; isortfor sorting imports; black, for reformatting your code; and flake8for linter checking.

When the new developers came, this shared developer style guide was at their disposal as an explicit item in their onboarding checklist. And as new standards/definitions were needed, we iterate this guide and keep documenting this internally.

Well, but now that you have separate teams, how will you maintain these new standards and/or definitions in sync across the board? I’m glad you asked! This takes to the third and final step that you should take into consideration when pondering about splitting the team!

The we-can-talk-whenever-needed strategy usually only leads to two possible outcomes: you’ll be disrupted every 30 min to discuss something new or you won’t talk at all.

To avoid both, you can always allocate time and formalize a goal for a meeting, a similar strategy to 1–1 meetings. This is what we did once we split the team: twice a week, all devs will meet up, and in each call, one of the teams would present the progress, give an overview of where the project is, and also share useful tips they found during implementation.

In the worst-case scenario, they won’t have news things to share, and the meeting will be short, so not much to lose here. On the other side of things, this unlocks so much potential!

To give one example, I’ll need to give some context for two of the projects we’re running right now, but I’ll try to be brief and not in-depth technically.

On one of the projects, we’re implementing a solution to manage the creation of SSIDs, aka Service Set Identifier, aka the name of your wireless network. To achieve that, part of the work is to change some configurations on Wireless Controllers, such as this one from Ruckus.

On the other project, we’re working to build a solution to deploy changes to various types of Wireless Controllers, such as this Cisco one, simultaneously. The goal here is to save hours of manual labor, by automating doing changes in bulk.

Noticeably, both projects have different goals, but overlapping scopes. And the different teams can benefit from this overlap if — and this is a big if — they know about it. Fortunately, this was our case, because we had formal and frequent knowledge-sharing meetings scheduled.

In this example, the overlapping scope was related to the devices the changes would affect. Both projects deal with Wireless Controllers, so there is some common structure that can be implemented only once and re-used by both teams.

When they figured that, it was a matter of coming up with what the common structure would look like, and getting to work. They also come up with a way to share this code that wouldn’t affect the deliveries and validation of each project, not only saving both teams time (around a person-week. Yes, you read that right) but also some headache later down the line.

Splitting a big team and workload into sub-teams is not exactly re-inventing the wheel. However, I wouldn’t go carelessly down that route. To avoid future problems, I had three steps in mind, before dividing my team in two:

  • 1. Have the team leads work together for a while: If your team leads have a shared understanding of the processes, clients, and business context, it will make it easier for the new sub-team don’t drift too much apart.
  • 2. Document a development style guide: If you want your teams to be independent but still maintain a cohesive shared codebase, you shouldn’t rely only on good judgment. Make it explicitly documented.
  • 3. Schedule frequent knowledge-sharing meetings: Make sure your teams are intentionally and frequently sharing knowledge. This will avoid unnecessary technical debt further down the line, while also potentially saving time.

The preliminary results have been positive. Qualitatively, following up with each squad member during our 1–1s, they feel less overwhelmed than before. Quantitatively, we picked up the pace, and we’re now at a similar delivery rate that we had previously.

Looking back, I do think this change was a good call. Also, as we did it in a structured way, we were able to make the transition smoother and prevent some problems from arising, something I whole-heartily recommend if you find yourself in a similar position.

With the new structure, however, comes new challenges, such as measuring the performance of two different teams, dealing with resource allocation, and so on, but this is a topic for another time 🙂

Leave a Comment