Dealing with split heads in product teams – 6 best practices

What’s the number one symptom of a slow, bureaucratic, corporate environment? For me it’s the existence of split heads. These are people that are part of multiple teams. Their existence is the result of team staffing that is treated as a math problem and done via spreadsheets. If I regularly encounter people that need to split their time between different teams in an organization, I already know that I will find a host of other issues. There is often no point in lamenting, though. If you are responsible for a project or product in the corporate setting you simply need to figure out how to move forward. 

That is what I will cover today. I will give some background on split heads and their effects on teams. I will also share the best practices I have found most effective in dealing with team members that need to split their time between different teams.  


The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 


What is a split head?

If you are responsible for a product or project in the corporate setting, you have likely encountered a team set-up similar to the following.

  • Person A – 30% capacity for the team
  • Person B – 80%
  • Person C – 40%
  • Person D – 10%
  • Person E – 100%
  • Person F – 60%

This is the result of a negotiation between departments. When setting up a team, they negotiate how much each will contribute. In the end each faction commits a specific amount of people to the project. The commitment includes the percentage of their time those individuals will spend working for the team. The rest of their time is spent on other activities or projects.

Each team member needs to split their time and attention between multiple responsibilities. Thus, the name split heads.

The effects of team members that are part of multiple teams

While corporate incentives often dictate that team members end up as split heads, the approach has significant downsides. This has nothing to do with the people themselves. They are put into an impossible position. Still, the existence of split heads leads to a loss of efficiency for the team members individually and for the team as a whole. It also makes it hard to create a real team spirit.

Loss in individual efficiency

The explanation for the dip in efficiency on the individual level is straightforward. The members are part of several teams and thus need to frequently context switch. They are forced to multitask and multitasking doesn’t work. Context switching leads to a high cognitive load on the brain. It needs to “warm up” to a new topic before it can fully function. This warm up period is the productivity loss that causes a decrease in individual efficiency. 

Loss in team efficiency

Moreover, team members being only partly present means communication within the team becomes more difficult. The team needs to spend deliberate effort to try and make it work. More often than not they don’t succeed. Communication is inefficient with lots of waiting for answers or key people missing for important decisions. Collaboration suffers, as does team efficiency. 

Weird team dynamics

Additionally, having split heads in the team has strange effects on team dynamic. It essentially leads to teams within teams. Some members are almost always present and thus get to know each other. Others will only be tangentially involved. It’s really hard to foster a real team spirit and a sense of ownership.

Practical advice on dealing with split heads

Regardless of the negative effects, split heads are unfortunately the norm in many companies, particularly in large corporations. Lamenting this fact doesn’t help anyone. Many project leaders or product people don’t have a choice. They need to create progress. I have been in this situation multiple times and found six best practices to be consistently helpful: 

  • Negotiate a smaller team
  • Define core team members
  • Define team hours or days
  • Sit jointly
  • Meet regularly in person
  • Asynchronous collaboration

All of the best practices are aimed at one (or both) of the following goals: reduce efficiency loss by minimizing context switching and create a real team spirit. 

Negotiate a smaller team

This may seem counterintuitive at first. But you can try to decrease the overall team size in favor of less people with a higher percentage of time allotted. Eight people with 25% capacity for a team is not the same as two people with 100%, although they both equal two total headcount when doing capacity planning. 

This is a negotiation with the line managers, often department heads. It is important to stress that you will need less people overall. For example, instead of seven people with 50% capacity each, try to argue for two people with 100%. You are asking for 1,5 headcounts less (2 vs. 50% * 7 = 3,5). This can be very convincing.

In real life the two full time people are surely more effective than seven split heads. The focus this will bring, the increase in efficiency, and improvement in communication and collaboration far outweighs the “1,5 people” you are losing in overall capacity. 

In this scenario, you may run into the issue that you are in need of specific skills only one of the split heads can provide. There are two ways around this.

One, align upfront that the team will approach the person with the specific skills every once in a while for help in such a way that the impact on regular work is minimal. As long as it doesn’t happen too often, this approach works. My experience is that people or departments like to help. They just don’t like to be part of endless alignment, planning, or coordination meetings. 

Two, don’t underestimate how quickly motivated people can learn missing skills. People tend to come up with exceptional solutions even if – or precisely because – they are not the experts.

Define core team members 

I really like Derek Sivers’ Hell Yeah or No framework. Basically, it says “if you feel anything less than “hell yeah!” about something, say no.”. That can be applied to the team members as well. Those that are a “hell yeah” about what you are doing are the core product team.

These are the ones that have a high percentage (>70%) of their time available for the team and also want to contribute. They are almost always present and do most of the work. They are the actual team. All others are outside of the core team and help when they are needed. They essentially act like service providers.

The outcome is similar to the last advice. You get a small team of dedicated people. This will lead to ownership, motivation, and fast delivery. Also, you don’t force the others to spend the little time they have available on overhead. No reviews, standups or other organizational meetings for them. You are liberating them to focus on actual work only when actually needed. That’s a win-win situation.

Defining a core team is easily done in practice. Simply ask who can and wants to be part of the core team. Whoever answers “Hell yeah!” is part of it. 

I did this both times we tried agile approaches in a large automotive organization. The first time we ended up with a core team of four people (designer, software developer, system engineer, Scrum master) who each were able to dedicate >75% of their time to the project. The others (sales, manufacturing, requirements engineer) were all at less than 50%. We reached out to them when we needed them and they mostly joined the reviews. The other four handled the day to day. We actually felt like a team.

The second time we ended up with a core team of three people (manufacturing, purchasing, project lead). The three of us drove the progress and we reached out to others (engineering, sales, logistics) when needed. Later on, the person from logistics became part of the core team as logistics took on a more important role.

Define team hours or days

Clearly defining time periods when team members will be working on the given project or product is an effective way to combat the difficulties in collaboration and communication caused by split heads. 

The best way to do this is to either declare the same time slot every day of the week (e.g. from 8-12 Monday through Friday) or specific full days in the week (e.g. every Monday & Tuesday all day) as dedicated to team work. A mix of the two can work. But I have found that it is often confusing. Either fixed hours or fixed days is best.

The team members need to jointly commit to these core hours or days. During this time, all of them will exclusively work on topics for the team. There is no context switching during these core time periods. There is no waiting for answers. There is only focused, dedicated collaboration.

Core work hours or days are even more effective if people have a dedicated project space where the members jointly sit. 

Sit jointly

In case you regularly work in an office, there is nothing more powerful in creating team spirit than sitting together as a team. Having a home base removes friction in communication and collaboration. It helps the team be more efficient. 

The space needs to be somewhere that is easily accessible. The split heads will need to come and go a lot. Having the space in some central location removes effort for people to actually come.  

Location trumps everything else. I was once able to organize the perfect team space. It had screens, whiteboards, proper desks, and everything else we needed. Team members rarely came, though. It was too far from their other work. We then switched to a container that had a few tables and chairs. It was really not much more than a broom cabinet. But it worked because it was close to everything. We set up some whiteboards and the place was always busy. 

Meet regularly in person

Sitting jointly is not possible in the case of remote work. Nevertheless, it is still possible to create a real team. But you need to be more deliberate about it compared to the in-person scenario where it happens more organically. 

For remote teams, I highly recommend regularly meeting in person, at least once per quarter. The goal of these meetings is to get to know one another better. Nevertheless, it doesn’t hurt to organize some sort of workshop with a specific goal. Simply working together in one place for a week or so with a few evening activities is also extremely effective. 

There are also plenty of ways to improve remote sessions. I won’t go deeper here since I have already written about team building in times of remote work.

Asynchronous collaboration

Team members having to split their time between several projects is often similar to having a team working in different time zones. In both cases, the team members work on the team’s topics whenever they can. If you can’t define core working days or hours, this will not be synchronous. Asynchronous collaboration and communication is the key. 

Asynchronous collaboration requires discipline. It requires thinking clearly about what to communicate in which manner. It means a lot of writing. This is great for clarity of thought but also takes time. Chances are that the split heads are already short on time. So, you need a strong team culture to make sure the members stay disciplined. 

Asynchronous collaboration is a huge topic that I can’t cover here in full. This guide from Gitlab covers it well. There are plenty of tools to help in asynchronous collaboration. Make sure you have the right ones available.

It’s not the fault of the split heads

Having split heads in the team is not great. It reduces efficiency and makes life more difficult for project leaders, product owners, Scrum Masters, or product managers. It’s easy to get frustrated, especially when the split heads cannot fulfill the X% that they have committed. 

Make sure not to let the frustration out on the team members that need to manage their time between multiple teams. It’s not their fault. They are put into an impossible situation. 

So when split heads are not able to fulfill their commitments to the team try to be as understanding as possible. Figure out a way to help them. This will pay dividends down the road. So much more than putting additional pressure on someone who is already struggling to juggle multiple responsibilities.

Coverphoto by balintseby on Freepik