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.

  • Hypothetically, if you split into 2 teams of 6, would each team be wholly cross-functional and have all of the skills needed to finish an arbitrary piece of work? Or would splitting introduce a forced allocation of work to a specific team because certain skills would only be on certain teams? But it also seems like the team structure - whether it's a large team of 6, a team of 6 using dynamic reteaming and fluid structures, or two teams of 3 - is a red herring. The real problems are in work intake, prioritization, and quality.
    – Thomas Owens
    Commented Mar 1 at 13:59
  • Hypothetically, yes. But there is always some expertise on a particular part of the system that some engineers have that the others don't, which is why, for me, it works better as one larger team as the implication is that you're all in this together, get together, work it out, share the info and solve it. You're right about the real problems, but they are currently insoluble due to the company structure and the way that the CEO operates. I'm trying to stop us losing developers, as they are so fed up with the proposals to split that I think I'll lose one or two from what is a small pool.
    – TheMook
    Commented Mar 1 at 22:53

2 Answers 2


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.

  • Thank you. This is the kind of input I'm looking for. It'd be useful if anyone has any links to academic or corporate research to back it up too, otherwise it becomes a 'you're saying you know better than me' type situation.
    – TheMook
    Commented Mar 2 at 11:43
  • There is evidence for lean being correct. dora.dev/research is the best evidence for "software delivery" (the part of the value chain after writing of code). Within software delivery, lean works best. So it's reasonable to assume lean is good elsewhere. When it comes to culture, leaning, collaboration etc. It's your job to observe that and you're closest to the team. Your finger is on the pulse and that should be worth something.
    – Nathan
    Commented Mar 2 at 21:20
  • That evidence also shows that "lets cut corners to get stuff done" attitude doesn't work, because the actual truth is that great technical capabilities enable great business outcomes. I think it's hard to change minds on that one though.
    – Nathan
    Commented Mar 2 at 21:21

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.

  • I appreciate the input, but I'm not in a position to do this. I'm experienced as an EM, but moved to this company within the last year. For several months up to Christmas I was allowed free rein to do what worked best for us and we had fantastic productivity, happiness, collaboration and work outcomes. Now the landscape has changed and I'm trying to regain some agency and autonomy for the team. I need to have a difficult conversation with my boss and the CEO to make our case for what we think works best. BUT... I'm open to the possibility that I'm wrong, so am looking for supporting evidence.
    – TheMook
    Commented Mar 1 at 22:55
  • 1
    @TheMook You were asking whether to have one team or two. My suggestion is that if you have one product then try one team and if you have two products then try two. If as you say, you don't have a choice anyway then I don't know what the point of your question is.
    – nvogel
    Commented Mar 2 at 4:02
  • We do have one product but it has many aspects. There are already two teams (of 6) that look after the broad division between teacher/pupil views, but within the pupil side alone, there are many discrete areas of specialism to do with GraphQL, legacy bespoke work, certain features, etc. I'm happy for my team of 6 to pair and mob where they feel is appropriate to share knowledge. What I don't want is to formally split them into two teams simultaneously working on two new features within our part of the product, for many of the reasons in Nathan's response.
    – TheMook
    Commented Mar 2 at 11:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.