We recently reached the size of 14 people in Development, and our goal is to get to 16 developers/designers in the next couple of months.

An interesting question we faced and discussed in this context is that of “optimal team size”. In the past year we’ve typically worked in teams of three or four, but now with more staff, we’d have more options like larger teams, and also we could of course always go back to tiny teams.

No too much change, please

We’ve ruled out working solo or in pairs, or setting up ad-hoc teams all the time. Everyone here loves a bit of stability in an otherwise very agile setting, everyone enjoys having “their” desk in “their team”, and everyone likes to have a team lead on their team that will help them grow their careers. These ideals can’t be woven in if everyone switches teams frequently, or when teams just consist of two people.

The middle ground

In theory, I believe that the best team & size is three full-stack developers who each have a complementary focus area: One specializes in frontend, one in backend, one in design. Also, they never get sick, never go on vacation, yet miraculously they never burn out, and of course they only resign once a replacement has been found and trained for six months. 🙂

With this being unrealistic, I believe four is the best pragmatic team size. Even if one person is on vacation our out sick, there are still three people left. At four people it’s also far more likely to find team members who can complement another, especially if one person is simply more specialized and not entirely fullstack. There are also more diverse pair-programming options, and the project management vs team leadership efforts can be distributed better. Also, four people in a room means more chances to just have a chat and a laugh.

Speaking of which, communication overhead increases significantly when making the step from three to four. But we feel it’s offset by avoiding the sad experience of a team reduced to two while someone is out sick or even resigns. Also, very many developers simply don’t want to be team leads, so teams of four (rather than three) reduces that problem a bit.

How about supersizing that?

In our experience a team of five is too large to be working efficiently on a single core task. Teams of five (or six) tend to fall into sub-teams quickly. And once that happens, happiness suffers because “we’re not really working as a team anymore”. Team-splits can happen in teams of four already, but at five it seems to become the norm.

Some companies like to have one (non-coding) Team Lead/ Dev Manager for eight or ten people. We’ve been there ourselves 3 years ago, and I was a Dev Manager for larger teams at previous companies too. But the challenge around work allocation came up exactly the same way, and larger teams were typically split into subteams after a while, dedicated group- or tech-leads were established, so it was usually only a matter of time to start the process anew.

And since we like our Team Leads to be half-time developers who are not entirely detached from the code, four is just the most pragmatic approach in our opinion. A team of five will always just be an interim solution, for instance when onboarding someone new.

Enter Team Fika

So with all that discussed, and with 2 new people onboarded in the past two months, we’re now finally getting close to setting up Team 4. In one month Peter will return from his honeymoon, leave Team Outlaw, and lead the newly founded “Team Fika” (swedish for grabbing a coffee and some cookies). He’ll be joined by Sharmeen and Timur, and we’re actively looking to grow this team to four as well, while also filling the gaps left behind in Team Outlaw.

So, if you’re interested and like our approach to empowered teams, check out our careers pages!