5 things we’ve learned (so far) by doubling our engineering team

Originally posted on our ‘Base’ Medium account.
In September 2019, Base became Passenger.

In the (almost) 10 years I’ve been at Base, the engineering team has grown by a factor of 10. This year the team has almost doubled and we’ve taken on 3 new developers in less than a month.

Growing a team is exciting. Through growth comes new capabilities, opportunities and responsibilities. We decided to grow the team as we have great ambitions for our product, Passenger.

1. Minds need to change

It’s hard work though, and requires a shift to a growth mindset, where the opportunity cost of some decisions can be exponential. Investing 1 hour of time fixing a bug myself means I can’t spend that hour working on something that will make the team save a day between us.

2. Bottlenecks take time to remove

This has been our first problem in scaling: me. I’ve been a bottleneck for some things recently but we’ve now reached the point where I’m not needed for the majority of day-to-day tasks and I can focus on the team as a whole.

3. Communication and priorities must adapt

The next issue has been scaling communication. The need for communication is why the man-month is mythical and why doubling a team doesn’t half the delivery time. This is countered by the increase in flexibility from having more staff, which in turn allows us to be more effective.

For example, we’re now in the position where it’s easier to invest time in reducing our costs. New developers have been working on features that enable our customers to handle tasks themselves, where previously the tasks had taken a few minutes of time from a developer. As well as being a wise investment financially, our ethos of teamwork and camaraderie are strengthened by the fact that we can write and ship code to make our colleagues lives easier.

4. Documentation and processes are valuable

Onboarding lots of developers has also highlighted where our documentation is lacking. This is gradually improving and the speed at which a new developer can ship a new feature is a testament to this. Documentation is only kept alive through change and growth is my favourite way to encourage this.

As well as documentation, new staff also have to run through any processes, whether they are to do with development or management. This has given us feedback on our processes and an opportunity to evaluate how effective and suitable they are. For example, some existing processes around setting up tooling have had someone become a single point of failure, which we’re starting to fix.

A key part of onboarding new team members has been the support and mentoring. We’re not experts at this but the high value we place on quality means there is ample opportunity to pair on code and receive in-depth code review.

5. Everyone is different

We know that there’s a lot of domain-specific knowledge needed for Passenger, as well as a lot of technical specifics. Our approach is to gently push developers to learn at the speed at which they’re comfortable. There’s no pressure to be efficient during onboarding but we’re keen for all staff to grow and be challenged.

We’re still growing the team, both by “upskilling” existing staff and employing new staff. I’m expecting the next 10x growth to be just as fun.