Tripling an Engineering Team in Six Months - Part One: The Background Story
In my current employment as Delivery Manager at a software company I oversee the design and development teams (aka 'Engineering') that are building a brand new property management software-as-a-service platform. In 2016 we were acquired through a private investment consortium and given an injection of funding in order to 'go faster'. This blog series is a summary of the lessons I learned from tripling an engineering team in six months.
The Background Story
In March 2016 we officially kicked off what was internally known as the SaaS platform project - a completely new build of our 20+ year old existing product. We took this opportunity to reimagine how we worked (Kanban instead of Scrum, Spotify engineering model), the tools we chose (IntelliJ IDEA, Docker etc), and the technologies we wanted to use (AngularJS, Node, GraphQL, Kotlin).
At this point in time the team was approximately 20 people, spread between roles of business analysts, software engineers, quality assurance engineers, devops, UX/UI designers, and system architecture.
This was composed mostly from an existing team from a previous project so we had built a strong rapport and fantastic culture that enabled us to get up to speed quickly and begin hitting early milestones. I believe in management buzzword lingo this is called 'kicking goals'.
During this time, occurring mostly in the background, was the unsolicited offer for private investors to acquire 100% of the company. Unsolicited means we weren't actually on the market looking to sell. As such the initial offer was rejected but when they came back with a larger offer things began to get serious.
The deep due diligence began and, as the lead of the engineering team, I was brought in and grilled. What were we building? How were we building it? What were our processes? How did we measure success? Where we on track? When would we release? And so on.
I answered openly and honestly (I don't know any other way) and I also challenged them on some of their pre-existing assumptions. I didn't know at the time but the people I was talking to later became the CEO, CPO, and the Chair of the board of directors.
Somewhere between meetings their mindset switched from grilling me on the current state-of-play to challenging me to figure out how we could get to market faster. 'If you had more money to spend, how would you go faster?'
The CTO and I worked together on several plans. First we drew up our current team structure (which was our own methodology, loosely based on the Spotify Engineering model). It looked like this:
Two squads working harmoniously
So how would we go faster? The biggest challenge to us was to consider how adding more designers and developers would scale. We had also been used to operating on a bit of a shoe string budget so when we drew up plans to add a 3rd squad we were pessimistic.
Could we handle 50% increase in size?
The reception of this plan was…subdued. We thought we were being ambitious essentially asking for a 50% increase in team size. They thought we were being too cautious.
'It's ok. But how could you go EVEN faster?'
It clicked in my head. I saw where this was going so I asked the obvious question: 'How fast do you want to go?' Their response: 'We were thinking double what you've drawn up there.'
These guys meant business.
The CTO and I took this away and completely reassessed the plan. How could we grow in order to triple our current engineering team? What would six squads look like? Could that many squads realistically contribute to the same code base without stepping on each other's toes? How would we provide adequate management and support? How would we maintain our excellent culture and high quality standards?
It took a few iterations, and a lot of robust discussions, but we landed on a good plan.
Two tribes, six squads. As we later learned this was barely like what reality would be
This was more like it. We had managed to come up with a plan that enabled us to triple, at least on paper, the engineering team without opening up too many risks that come from jamming in more people without planning.
Two tribes, six squads. As we later learned this was barely like what reality would be.
Everyone liked it but...we weren't ready to go. The acquisition had not occurred yet so all these discussions had been theoretical only. There was still a chance they would withdraw the offer or even a chance they would do something else with the company. I waited with bated breath.
Finally in early November 2016 the deal was settled and the new owners officially took over. After installing a new CEO and CPO (as previously mentioned) they gave us the green light: go faster.
And fast we did go. Jump forward to May 2017 and the team was hovering around the 60-70 mark depending on the number of consultants we had on at any one time. As alluded to above, the actual six squad plan didn't quite work out as drawn. We had some roles that we thought we needed but didn't, and roles we never even imagined we would need become bleedingly obvious as we progressed. Some of the newly created roles include mobile engineers, market research, user testing, and a principal business analyst.
Regardless of the final structure we had managed to scale the team. We had tripled within six months! It was a fantastic achievement.
And amazingly, during this time of rapid growth we also managed to keep delivering features and making progress. We hit the beta release date and did it without sacrificing our high quality or losing our fantastic engineering culture.
We're not perfect and we certainly made some mistakes along the way. Most importantly there were scores of lessons learned along the way and that is what I aim to document in the rest of this series. So join me as a I take a deep dive in to my role in the recruitment process, and the lessons learned during the intense six months that saw our engineering team (more than) triple in size.
Below are the links to all posts in this series. You can sign up to email list to get alerted for new content and if you have any questions or want to get in touch you can email me or shout out on twitter.