One team of 6 developers doing two projects serially or two teams of 3 developers working in parallel?

Question

Trying to keep an open mind on a request from senior leadership. Maybe I'm biased, so I'm seeking opinion/research that helps guide me. I am the Engineering Manager of a current team of 6.

Established SAAS company, with a mixture of small business and Enterprise clients. We have a large backlog of defects/tech debt. There is a little bit of bespoke work that needs doing from time to time for just two of our clients, but it's contractual so cannot be deferred when it is agreed to be done.

Leadership has a perception (fairly common, I know) that the software team does not do work fast enough, spends too long in discovery/design and needs to move faster with less focus on 'perfect' when 'good' will do. The team is good, likes to design and build robust, scalable, reliable and maintainable code to avoid building our backlog of tech debt.

Recently, we get more and more requests/demand from above to build and ship features that have been sold early (e.g. they're not finished yet) to customers as things we already have, so that tends to be an urgent priority. We also have some internal product discovery-led projects that will add features to our product.

The problem comes when two (or more) things are deemed to be urgent. e.g. we have to get both things done by the end of the month, for example. The suggestion/demand from above is that we split the team of 6 into two 3s. This way, they can both work on an independent project at the same time.

The problem here is distraction, however. We will periodically get a P1 bug fix, which has an SLA, so then one of the two teams has to pick it up. We will have someone off sick occasionally and sometimes on holiday, so occasionally we have teams of two. It's also common for a senior person to take one person from my team or another one and form a special short-term team to work on yet another side project.

If we are working on project A as a team of 6 before taking on project B, then we tend to have a core of 3-ish people on the main project. It's not always the same 3, it changes as people take on a support ticket or answer a salesperson query about technical aspects of our product, and then they merge back into the larger group. It's fluid and it works as the team self-organises. We also have capacity for one or two of them to cycle out to do the bespoke contractual work here and there. In teams of 3 there is always a possibility that it's firstly actually a team of two due to the aforementioned things and secondly there is no capacity to work on the side projects as they are so thinly stretched in the small team already.

In practice, when split into small teams, I see that morale suffers, collaboration drops, irritability rises, people cut corners to get things done and software quality diminishes. Although I don't have empirical evidence, it feels to me that by the time we've fixed the problems caused by rushing things in small teams, it's quicker AND better quality to have the team of 6 work on project A (along with the common side tasks) and finish it, then move onto project B, but I'm fighting a director and a CEO who both feel it's better to work in small teams (they even suggested three pairs).

All my instincts and online research for evidence lead me to believe the team of 6 working serially is better for culture, quality, morale, performance, mental health and, over a certain period, even speed. However, I want to make sure I'm not just doing confirmation bias. Am I missing something? Is there merit in the idea of two teams of three? If so, how do we equitably split the ongoing side interruptions that never go away?

Ideally I'd seek proper prioritisation from above as everything being a priority means nothing is a priority for us. However the CEO is quite controlling and used to be a developer so thinks he knows best. And maybe he does? I just know that our culture and happiness scores are plummeting when we're forced to split into small teams,, it results in poorer quality work too. It seems a false equivalence to think that parallel working gets things done faster, to me, but I may be wrong.

Answer 1

It sounds like you have good reason to believe a team of 3 is too small to function effectively.

The bus-factor represents a business risk, when it comes to absences/resignations as well as just having the right people around when urgent items come in. It seems like you've seen yourself that collaboration and culture just don't work in a 3-3 configuration either.

There are of course valid reasons to create two teams from one team: for example when a team gets too big (>10) or when the work they're responsible for becomes too much for team members to keep in their head ("cognitive load"). The reason your management seems to want to split the team seems more like they want to create a deliberate work-in-progress problem. To look at this from the lean perspective, this is a bad thing, which will mean work items take longer, urgent items (eg P1s) will be delayed and outcomes will be generally worse.

I would make that case: ie that sticking to the status quo will result in better quality work from a happier team, and will mean that the highest priority items get done quicker. I've made that case before and it's worked. I particularly leant hard on bus factor (eg "what if X quits", "what if no-one from the A team is in during an outage of the A system"). But I think I was working with people who trusted me to manage my team. Maybe that's not the case for you. Good luck though.

Answer 2

My suggestion would be to align teams to products, not projects. It's not clear to me whether the split you are considering would involve two teams working on the same product or not. If the projects in question are just different features, versions or fixes, potentially on different branches of the same product code base then I would be more inclined to have one team rather than two. If they are different products then that's a stronger reason to have different teams. In short, manage the product rather than the project.

Answer 3

You mentioned "culture and happiness scores". Are those real scores you measure somehow? Or do you mean this figuratively speaking?

Here are my thoughts on this:

(A) Management wants more "speed" or productivity: They have the fallacy that by splitting the team, they gain two teams which in their head doubles productivity. That is the famous example of "take nine women to birth a baby in one month". It has been tried (in software business, not with women). Doesn't work. Almost all literature since the 70s tell you that.

The truth is, management needs to hire more people to setup a new team, but they shun to invest more money. So they seek to "magically" double what they have. In fact, they demand more work for the same salary of the team members who in fact are doing the work and did a good job until now... That is like cutting the branch you are sitting on.

Also: They miss a keypoint here and that is overhead. Your team stems like 50% overhead 50% workload with say 6 members. If you split that, the overhead stays at 50% per sub-team. The overhead is not halved, it is doubled because each sub-team will now have to manage their overhead alone! In fact 3 people per sub-team are covering only 25% of the workload the 6 member team did. They do it in parallel yes, but you gain nothing in terms of speed or workload being done!

It is like:

• speed: 1.0 with 6 people -> 1 feature complete: after 10 hours
• speed: 0.5 with 3 people -> 1 feature complete: after 20 hours.
• two teams a 3 people -> 2 features complete after 20 hours.

That is the same as giving the 6 people team double the time and they also complete 2 features!

You gain nothing by splitting the team. You want more speed in parallel, you need a second team.

(B) Your CEO knows better: It might be true he has knowledge but his experience stems from a different time, a different team and maybe a different company and he is biased of his own skills. All this is not applicable in the current situation. Here it is: You are close to the team, you know the team and have a deep understanding of their skills, capacity concerning workload and you can even estimate the impacts on their happiness and productivity. That is invaluable. You are the expert here, not the CEO. And he better acknowledges that, or he is making your job and not his. If he is fond of you and your judgement (and he should be), then I'd say, you should go bold and position yourself against the CEO's opinion (if you are willing and able to find another position somewhere else in the worst case; have a backup plan).

(C) Don't forget the team: Did you ask them what they think is good for them? Do they agree that they can do what the CEO thinks is the way to go? This should give you the strongest backup data. It shouldn't get the taste of a mutiny though.

(D) Conduct a test phase: The team, you and the CEO etc. could agree upon gathering the necessary data on feasibility. Setup a time, 6 months or whatever, and split the teams. Develop a good sheet of key points to track during that time. E.g. happiness, productivity, days off because of holiday, sickdays, etc. how much switching and overhead was imposed on the team because the necessary people were not available etc. Make surveys about the "happiness" factor and the team's opinion if this mode is sustainable. Takes a bit of preparation of course.

(E) Trust your guts: The optimal size for a team is 5-6 people. If you manage to split them up depending on tasks to have them in 2x3 for some time, that is great and underlines your ability to "read" the team. This is like optimizing to get a kind of 1.25 factor of speed out of them. That is more than optimal already!

You said it yourself, split them up and you end up with 1 or 2 members on each team at times. That is like no work is done at all during this time. Overhead demands from outside (meetings, customer requests, etc.) stay the same - this is not reduced just because the team was shrunk to 1 by circumstance - but this one guy has to deal with all the overhead, which will take precedence over "real" work. Pairing also is not possible (you didn't mention if you are agile though).

(F) Literature:

• Brooks: The Mythical Man-Month.
• DeMarco, Lister: Peopleware.
• Thomas, Hunt: The Pragmatic Programmer.
• Martin: The Clean Coder.

Especially the last one/two put emphasis on "saying 'no' to the management if they demand non-sense".