Splitting an Engineering team

My experiences from our recent team split

Wanna skip the context? Jump right to “kick-off”.

The context

In 2020, I started at Signavio. With the outline proposed in the planning, our group in Engineering would grow significantly. Going into this phase of hypergrowth, I first handed off a team to a new colleague in October 2020, to keep my focus on two teams.

Hiring for two teams in my case meant hiring for four different pipelines, and supporting in leadership pipelines in a few other categories. Breaking down the numbers, I had between two to four interviews per week on average. This resulted in 18 new team members I hired between October 2020 and October 2021, and I commissioned 4 consultants on top. Ultimately, I have done or will do about 12 onboardings in that time with my teams.

In July 2021, I had the opportunity to hand over another team, which meant I was able to fully focus on the other team. Here, a team split had not only become necessary, but was part of the plan.

How did I split this team and what did it involve? Let’s break it down.

The team

At the end of 2020, the team consisted of one PO, one QA, two frontend and four backend engineers. It was clear by then that the team would ultimately undergo two splits over the course of 2021 — and need the adequate folks to be enabled to do that. All positions were planned into the hiring.

Growing consistently leads to a scenario where you don’t invite applicants until a certain stage and choose the best candidate out of those. You consistently get applications and consistently hire according to the needs of the department, group, team and individual position.

Bearing in mind that other groups and teams have just as urgent hiring demands this needs a careful balancing.

The hiring success

While I did sign candidates in 2020, resignation periods and other factors led to our first new starter on January 1. In January, I onboarded a designer, in February a backend engineer, in March three more backend engineers (one an internal hire and one an intern), in April one frontend engineer and in May two more frontend engineers. June was a quieter period for me individually, but the PO for one of the upcoming split teams joined. In July, I welcomed another backend engineer.

For the coming months, we have two consultants, one frontend engineer, two backend engineers and a designer scheduled to start. They were all mapped into the team splits and the teams could, resource-wise, be started without them. Furthermore, we will welcome two consultants.

I did not list the hires of my other team here. But they are, of course, planned into the split that that team will undergo.

Changing the makeup of an organization

With the setup described above, we started out with one team member using she/her pronouns and me (my pronouns are also she/her) and one team member using both he/him and they/them pronouns. This equated to a ratio of women in the team of 22%, and a ratio of 33% for all those not using he/him exclusively.

With the hiring, including our intern, we drove this up to 40% (44% for all not-exclusively-he/him pronouns).

The preparation on a group level

Early on, we realized that if we were to execute team splits very individually we would miss out on swarm intelligence. That is why we set up a basic framework of how we would approach every split in our group (we have four groups in Engineering overall, with several teams each). Individual choices still applied, where necessary, and proved to be valuable to adapt the framework to the teams.

When you split a team you can do it the following ways:

  • Grow the team to super size and split it 50/50.
  • Grow the team a bit larger and/or to super size and split off a kernel group.

There is also the option to set up teams completely from scratch, often with one experienced member joining to ensure a knowledge and skills transfer.

We were very aware of the fact that specifically in our group and with the required knowledge of the domain and the product the last option was not viable. So we went for the growth of the teams, having new joiners onboard in them and get a sense of their new environment before going into the respective teams.

This brought its own challenges. A significant number of folks in our teams are introverts by self-definition and -representation. Large team settings can add more context to the existing environment and increase stress levels.

It was therefore imperative to “catch” the earliest possible timeline for the splits. Coincidentally, the other team (at this point we had 3) grew to the extent that we more or less conducted the splits at the same time. This led to great exchanges and insights along the way. We are planning to rinse and repeat this towards the end of the year for both of these team spheres. Having lessons from two team areas will help a great deal.

Our basic splitting framework consists of 3 tracks with different owners, executed one after the other:

  • Tech Track with deliverables: Tech Lead
  • Product Track with deliverables: Product Owner
  • People Track with deliverables: People Lead

The People Lead of the team(s) owns the effort overall and guides the track owners through the process.

The kick-off

In April, three points became very obvious:

  • The team was getting too large to ensure effective communication. We weren’t at a stage, though, to confidently support a split.
  • With more folks onboarding, we should start planning the split in May.
  • The internship of our colleague would end before we would execute the split, which is why I didn’t plan them into the new team setup.

In May, there was the big question of how the team split could actually look like in terms of working items. In our case, it was evident that we would continue working on the same product — and had to untangle the future teams accordingly. A 50/50 split was most likely.

Oftentimes, you look at a new tech, focus or product you will be working on. In such cases, the actual split seems the easier part, but the definition of what is to come is challenging.

Nonetheless, we will have some new angles in the two teams. To get a better understanding of those, the POs had initially mapped out a first proposal with our group lead. This was funneled into team sessions we had with them.

All in all, we held two sessions with the whole team, talking about existing and upcoming items and first ideas of how they could be split. The team was able to ask their questions and contribute their thoughts.

Backed by this, we went into the split period.

The actual split

The actual split planning and execution started in early June. Time-wise, I estimated 6–8 weeks until we would have all tracks finalized.

To keep an overview of our progress, I set up these artefacts:

  • A Confluence page with all tracks and deliverables to check off
  • A Miro board with all tracks and details visualized, as a single source of truth
  • A check-in meeting with the POs and Tech Leads every Monday and Thursday for the duration of June and July

As a first step, I checked in with the PO and Tech Lead of the existing team to provide a first, rough draft of the proposed item assignment and teams’ focus. I then made sure to check in with relevant stakeholders such as our group lead. Once given the get-go, we proceeded to map out the details. This took about two weeks.

While we did initially concept the tech and product track to happen subsequently, in our case they overlapped a great deal and took about another two weeks. Our PO and Tech Lead frequently synced with each other. Meanwhile, I made sure to keep all stakeholders in the loop to catch any early signals of non-assent.

Looking into how the architecture can be untangled, setting up work areas, team mission, objectives and defining challenges is no easy feat. This is why I actively encouraged and supported our PO and Tech Lead in delegating what they could. For instance, the Tech Lead consulted with two of the experienced engineers on the team and they contributed their ideas and suggestions.

Our PO collaborated with the PO that had just come on board. They would need to co-define all these items, as these would ultimately be in their responsibility. Our new Tech Lead only joined later, so we included them once they were set up sufficiently.

With this result, I addressed the team. Setting up one meeting for the frontend folks, one meeting for the backend crew and one meeting for design and QA, we went over the tracks. I explained the plans and motivated the team to add their comments and ideas. This was particularly crucial in ensuring that we take these decisions as a team and benefit from the wisdom of everyone. I hire my team members because they are experts and I trust them to shape the team split accordingly.

Meanwhile, the POs focused strongly on aligning the ideas with design. For this, we sat the POs, the designer and our design lead together to get all of their input.

For the two weeks following these meetings, we replied to the comments and added the suggestions in, sharpened the design concept and came up with the new, synced format for meetings, alignments and rituals.

I also started the People Track right after having consulted with the team. For this, I followed a methodology that combined

  • individual suitability
  • character and traits
  • personal interest and development

with the tech and product objectives. Around the beginning of July I proposed a first allocation of team members to the new teams.

Unsurprisingly, basing the allocation on methodology rather than coincidence all stakeholders and the vast majority of team members were happy with the setup. I checked in with the team members and asked them to review their assignment. After having everyone’s consent I proceeded to inform our admin colleagues about it.

With this, the very last stage of our team split had to be planned: the team workshops! Workshop is an inflated term for what we did, but it was essential to have a get-together. Due to holidays not all team members were able to make it to the gatherings, which is why I aligned with them beforehand to represent their interest if they so wished.

In the workshops, lasting just under 3 hours, we determined the new team names, talked about our team values and objectives and debated how we would represent our responsibilities to stakeholders going forward. With the team names set, our databases were updated and we now have two new teams!

The current state

Planning a team split is one thing. Actually executing all items is another. In our case, it will take us weeks to months to completely separate the systems and work areas. This particular aspect might be different for most team splits; here, we need to be a bit patient.

At the same time, the engineers have confirmed that they see it as a great technical challenge and something you probably only get to do once or twice in your career.

We also have the scenario that one PO and one Tech Lead are still new to the team.

I am confident that we will prevail and do a great job! Everything that I have seen so far convinces me of that.

I am so thankful to have had my colleagues on board with me. They drove their areas and the overall split so amazingly.

Lessons learned

There is a number of lessons to be learned:

  • Involving the team is crucial. While it is unrealistic to talk about every little item in detail buy-in and the opportunity to shape the team split can make or break the new teams.
  • Team identity is not what you define it to be. It is embodied in the team members as individuals and as a collective and will organically adapt over time.
  • A kick-off ritual or bonding experience helps immensely.
  • All involved folks should understand the technical and product challenges. If they don’t yet it’s best to prioritize that over other matters.
  • Keeping stakeholders in the loop ultimately ensures organizational support and makes them feel like they are part of the process.
The recognitions we as planners have received for the execution.

Are you thinking about or planning a team split? Have you conducted one and what are your experiences?

tech (people) {code} is about all things human in tech.

From and for project and product people, engineering managers, developers, and all those curious about the people code.

tech (people) {code} is on Twitter, LinkedIn, anchor.fm and YouTube.

--

--

--

Franziska Hauck is a coach, mediator, consultant and advocate. tech (people) {code} is her hub for all things human in tech.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to Use the Map Method in Ruby

VictoriaMetrics: achieving better compression for time series data than Gorilla

Intercompany Accounting Setup in Oracle Fusion/ PART I

THE SERVERLESS SERIES — Automating IT Engineers & Reshaping Tech Leadership

AG-Grid performance optimization, memory usage and speed/slowness considerations for Enterprise

Remembering Dennis Ritchie: The Father of C and UNIX.

How I went from failure to success in programming and what got me there

Useful Go Command [2]: golint

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Franziska Hauck

Franziska Hauck

Franziska Hauck is a coach, mediator, consultant and advocate. tech (people) {code} is her hub for all things human in tech.

More from Medium

Managing the software development team

Interviewing at Street Group: what to expect

From Forming to Performing

The wearing of many hats