Review: “Scaling Teams” by Alexander Grosse and David Loftesness

Teams that grow by 300% in 12 months almost never see a 300% increase in the output of the team. Typically such rapid growth leads to diminishing returns

The focus of the “Scaling Teams” is the needs of teams experiencing hyper-growth. It covers all stages of scaling teams from hiring, managing, organizing to culture and communications. The book is very concise however it provides references to additional information that can be used to dig deeper into a particular topic. I personally like that format as it allows to get fast answers and leaves the decision to the reader if more investment into the topic is required. I will cover a few parts of the book to give an idea.

Summary

Hiring

The book starts with the recommendation to consider alternatives to hiring first. It is always better to suspend hiring and understand what doesn’t work and how adding people will help with that problem.

The goal of any hiring process is to maximize the probability that a new hire will be a successful, long-term contributor to the team.

Key principles of hiring:

• Hire for talent — hires at the current stage will set the tone for hires in the later stages
• Hire for the team — building “A” team is more important than hiring only “A” players
• Minimize bias — biased interview process is a flawed interview process and restricts the company to access the wider talent pools in the future.
• Don’t cut corners — hiring poorly is often worse than not hiring at all as the cost of those decisions will be paid in the future and it will compound.
• Treat candidates with respect — every candidate should walk away from the interview wanting to work for the company.
• Know when to listen to your gut — gut feelings can be a source of bias and it is better to treat the gut feeling as an indicator to dig deeper into the candidate and own reactions.

The following metrics can help to evaluate the hiring process and do the calibration:

• median time between first contact and offer and for each stage of the process in between
• most common reasons given for no accepting an offer
• percentage of new hires by source
• percentage of candidates that make it through each stage of the pipeline

One of the important parts of the hiring process that is often being overlooked is the post-onboarding phase. Post-onboarding includes:

• surveys of new hires about their candidate experience
• performance data on how new hires are doing 6 and/or 12 months after their start date
• percentage of employees who refer candidates, and median number of referrals
• regretted versus non-regretted attrition

Organization

The main organizational design principles:

• Build delivery teams
• Embrace autonomy
• Establish purpose and measure success
• Deliver business value constantly
• Create a continuous learning culture (retrospectives)

People feel intrinsically motivated if they have autonomy, mastery, and purpose. The organizational design should enable these behaviors.

Delivery teams can be organized using the following approaches:

• platform — deep shared understanding of the technology. Pros: an easier approach to follow, very intuitive; high consistency of features on the platform. Cons: doesn’t scale well as there is one team per platform; hard to roll out features across platforms.
• features — deep understanding of the main features. Pros: easy to roll out change changes across platforms; output is tied to real user value. Cons: maintenance is hard when people move between the teams as you might not have the luxury to staff each feature properly given the scarcity of the skillset.
• company goals — focus on specific company goals. Pros: clear how the team contributes to the overall company success. Cons: core team might feel that they are not contributing to the company targets; conflict over the ownership; hard to scale
• customer — focus on specific customer groups. Pros: clear how teams deliver value to specific customer groups and a team can develop a deep understanding of customer needs. Cons: hard to scale as there are a limited number of customer groups.

The authors encourage to use the value stream mapping as a tool to determine how to organize a specific delivery team.

Delivery teams are optimized for bringing value to the customers so there will be inevitable work duplication and issues with knowledge sharing. In order to bridge this gap and leverage the economies of scale, the following organizational concepts can be used — chapters and guilds. Chapters are informal groups organized by skillset. Guilds are informal groups organized by interest. Chapters and Guilds help to connect the members with similar interests/skillsets across the organization and facilitate knowledge sharing.

My experience

The Jetlore engineering teams were organized around platforms. One of the challenges that we experienced when our infrastructure increased in size and complexity was the low iteration speed between ML and the core platform team. The ranking service was part of the core platform and the team was spread thin across other services and infrastructure components. ML team would either inner-source the work into the ranking service or wait until there was a capacity on the core team to incorporate their change-requests. The lack of having a dedicated team for the ranking service led to the situation where the code quality deteriorated and the cost of maintenance increased to the point where it was scary to make changes to the ranking service. Needless to say that the inner-sourcing model required a unique skill set for the ML team and that posed difficulties in the hiring process.

We hired a very strong leader for the ML team and after seeing the frustration of making changes to the ranking service, I decided to move some of the core platform engineers to the ML team together with the ownership of the service so that it can form an autonomous delivery team. The dedicated team allowed us to address the stability issues and enabled ML engineers to make faster iterations to the product. It was a good success story!

However, it introduced another organizational problem once the technical debt on the ranking service was addressed and the main ML feature requests in the backlog were implemented. The ML group didn’t report to the engineering organization so the move of the ranking service introduced the second engineering center that started to grow and expand beyond the original scope to keep systems engineers engaged. At the end of the day, we were able to manage the responsibilities across all teams but it did cause some confusion and friction across the engineering teams.

In retrospect, I think that the better solution would have been to break the monolithic core platform team into smaller teams owning different parts of the infrastructure with clear KPIs tied to the company goals. The engineering org would always grow faster than the ML org. ML engineers should have been added to the projects that required machine learning capabilities via the dotted lines. We had a great example of such collaboration when we were building the “purchased-with” ranking mode. At the same time, the ML engineers would share the expertise and leverage the economies of scale within their own org.

Another interesting observation was that the less there was dependency between the teams the more “us vs them” attitudes started to pop up resulting in silos across the organization. There was a clear gap in bringing the teams together and facilitating the communications between them. I think that having company-wide OKRs could have helped to engage teams better.

Verdict

Recommended for engineering managers