Scaling a Team in Two Parts: The Product and Manager

Gaining a Larger Workload as a Result of Scaling

Previously, I worked in a team that was called Cities. The team’s goal was to help Airbnb hosts comply with regulations as new cities passed regulations. As Airbnb worked actively with cities, the pace has increased from a few per quarter to many per quarter.

As with cities, the team started to scale as we hired more and more members. Alongside the hiring, we focused on building a platform for multiple people to work on projects together.

Learning to Scale Multiple Aspects at the Same Time

To Scale the Product:

In the beginning, each City regulation was hand implemented, but as regulations increased, we needed a faster way to implement these regulations. To scale, we standardized our offerings and platformed the product by making it config and content driven. This allowed us to express the product behavior as well as the content through some variables. It was indeed an example of upgrading a Cessna into a Boeing. This journey taught us a few things in building product platforms:

• It’s hard to foresee all use cases of the future and hence getting the balance is tricky. We learned to build incrementally where you treat every use case that is not supported as a new opportunity for use case expansion.
• It is hard and risky to build the platform in parallel and switch to the “new platform”. You have to start with the piece that is most often customized and make it modular. We also built the modularity in layers where with each new layer, we increased the configurability.
• Observability and Validations become increasingly important as the easier to launch, the easier to make a mistake, and the impact of such a mistake.

To Scale the Organization:

As the product started scaling, we hired a lot more people on the team and had to scale the organization to deliver effectively. We needed to organize ourselves into teams, introduce new processes and be comfortable with everyone not knowing everything that was going on in the team. The scaling of the organization proved to be harder than scaling the product. We have made mistakes and learned a few lessons as an organization.

• Separating the platform/tooling team with the product team ended up with a ton of challenges leading to the product team quickly burning out and unhappy. Each team has a balance of building the Platform as well as the product using that platform made a better approach
• Growing organizations will almost never have time for Platform work. When there is a time crunch, this often gets cut. Integrating Platform improvements into the product build helped with prioritization. So we would take x% more time to build better or refactor the existing platform to support the new use cases.
• Taking calculated risks like investing the potential time gains of platformization in that work at the beginning of the quarter to leverage those gains later in the quarter was helpful to make continuous progress on platformization
• Platform investments require conviction from leadership. Showing intermediate results will help in protecting time for such investments.

Scaling Myself as a Manager:

As the team grew, we first had two managers managing multiple teams. Eventually, I had to inherit the other team(s). Scaling myself was especially important as we scaling products, as mentioned above, required a tighter execution. With the two teams following different processes, the following helped in scaling myself:

• Don’t change any team process immediately. This was important to help each team continue to have the momentum in executing. While this made it harder for me to follow the two distinct processes, it was helpful for the team. Eventually, I changed the process where it made sense to standardize.
• Moved 1-1’s from weekly to bi-weekly and made 1-1’s more personable by listening to the team challenges. It is important to recognize what you want the most out of 1-1s so this time can be used more effectively. Things like work updates can be done async in slack. It is also ok to have different cadences for different people. Some people need more guidance and others less. Thus we can adjust based on the same.
• Information sharing is critical when running multiple teams that require close nit execution. A weekly update email with top of mind, meeting summary, and additional context was helpful in ensuring both teams had context and information from the other and avoided repetition of information in 1-1’s
• Delegate what you can. I was able to find engineers who are passionate about running different initiatives I was running originally opening my time.
• Block dedicated time to review the work of people async. This is crucial to ensure one has a good understanding of the work and gives continuous feedback. Doing an informal performance review once a quarter also helped with gathering and capturing the work and feedback to be later used in formal performance reviews.