Scaling tech teams with self-selection
How do you organize teams efficiently in a start-up that has grown from 2 to 20 developers? This was a question that we had discussed for too long. Let me tell you the story of Insurello.
Insurello was founded in Stockholm, Sweden in 2016 with a vision of claiming Fair Compensation for All. Have you ever been in an accident or had a personal injury? Did you know that you most likely have an insurance covering your incident and a right to compensation? Neither did I when I joined the company in late 2018. Coming from a background in fintech, payments, and challenging the status quo of the incumbent banks, I immediately fell for the vision and business model - challenging the position held by insurance companies.
I joined the company as Head of Product; owning all things product related, as well as contributing to the leadership team and overall growth of the company. Like most setups within product management, Product and Tech were in close collaboration. It wasn’t that hard, given that we were 2 developers and I, but we set off on a growth journey.
There were a few tenets that was set early in our organisation. Our ways of working included mob programming, and like most early-stage start-ups we recruited full-stack developers. We selected a tech stack and planned an architecture that we believed in, both from a technical perspective but also from what we believed we could use as a kicker in recruitment processes. We believe in functional programming (especially Elm and F#), with an event sourced architecture.
Mob programming not only worked as a means for continuous delivery of new services and functionalities, but also as an excellent environment for onboarding. Recruiting was going well. By Summer of 2019 we would close in on what we felt like a limit for number of developers in one mob – 6. Discussions were vivid as to what we should do. Was mob programming the best way of working going forward? Was it the right choice now? The answer to both questions was yes. We split the mob in two and suddenly, we could parallelize work.
We grew the tech team with more developers, a data scientist, and a UX designer. The mobs budded off and split into more mobs organically. Things were working well, and we could keep multiple initiatives going in parallel. However, we got to a point where the weekly planning sessions and retros grew to about 20 people, and the sole product resource started becoming the bottleneck.
So, we made the decision to bring on more product managers. I am a firm believer in the power of dedicated product teams, preferably cross-functional and capable of achieving their mission autonomously. I cannot take full credit for this belief, as this was mostly based on my experience from having spent time at Klarna as well as Marty Cagan’s “INSPIRED: How to Create Tech Products Customers Love".
This belief and my previous experience are what brought on the need for a more structured organisation – a product manager without a team is (nearly) useless, but a product manager with a team of developers make magic happen together.
What teams would we create?
We saw several different possibilities but settled for three different teams based on what the highest priorities were for us as a company at the time. The three teams would have overlapping responsibilities but would set their roadmaps based on their individual missions, to achieve the top priority company-level OKRs.
How do we create the new teams?
Given the culture of high autonomy of the existing mobs, a self-selection made most sense for us and was something that we were eager to test. The three Product managers got a head start with crafting vision documents (kudos to Klarna where I picked this up, who in turn picked this up from Amazon, Intel, and a few others) for what their domains would set out to achieve. The vision documents were sent out about a week before the self-selection ceremony was to take place, so that future team members could make an informed decision as to which team they would like to join.
Given that everyone had read the vision documents before the meeting, we started off with a quick recap presentation and Q&A session on the vision documents. We then proceeded with agreeing on a few acceptance criteria for the self-selection. The acceptance criteria were:
1. 5 team members per team (three teams)
2. Balanced seniority level within the teams
We also agreed that we would do as many rounds of selection as it would take to get a good balance in the teams.
A simple online form was then sent out to everyone, whilst in the meeting, with a single question: “Which team do you choose?”. Once everyone had submitted their answer, the results were presented to the entire group as an auto-generated spreadsheet.
The first round resulted in a skewed distribution of members between different teams – and one team especially had too many members, so we did a re-run.
The second round also resulted in a skewed distribution. This time another team got too many members. Another re-run.
The third round was just right. Or rather, close enough. 4 members in one team, 6 in another, and 5 in the third. Given that we had a couple more recruits joining in the next few weeks, this was no biggie. Seniority level was well balanced.
Reflections from the process
You may wonder if the people who switched from the overstocked teams to other teams in next rounds were disappointed with the outcome, and this was something we reflected on. Many of the “switchers” did not have a strong preference for one team vs the other, so they basically just picked the other when they saw that one was overstocked.
Another point worth noting is that we only did self-selection for developers. We have kept data scientists and UX as “floating” resources – catering to all teams’ needs where required. The long-term ambition is however to have dedicated UX, UI and Analytics competences within the teams that require these.
Being a fan of theatrics, I did not pass up on the opportunity of burning colored paper to simulate black or white smoke in between selection rounds – inspired by the chimney of the Sistine Chapel in conclave. Joking aside - this was not only a fun process but resulted in motivated, well balanced teams.
Worth mentioning is that this was all done remotely, via video call and screen sharing. This was by no means a disadvantage.