Steve asked the panel about their criteria for organizing engineering teams. Sudhir says the criteria should be based on what stage the company is in. An early-stage startup will organize its engineering team differently than Google.
Sudhir read that the attrition rate for Google’s engineering team is 10%. They have 40,000+ engineers, which means that to backfill the 10% who depart, they need to hire 4,000+ engineers each year. And that doesn’t account for growth.
Google’s backfilling of 4,000+ engineers exceeds the total size of many Silicon Valley engineering teams. At DoorDash, Sudhir was excited to build the Data Platform team from scratch. He grew the team from zero members to eight teams of 8-12 people per team.
Sudhir used a sports analogy to explain team size: know what game you’re playing, then use that to determine team size. For example, in basketball, the team on the court is five players. In baseball, it’s nine players on the field.
Steve asked Sudhir and Wade how they get their teams to achieve clarity around ownership. Wade says to pay attention to system architecture and the structure of code. He’s a believer in Conway’s Law, which says that the design of your product reflects the structure of your organization.
When Wade’s team was building a platform called DigiCert ONE, they started with one scrum team working on one service. As they built more services, they spawned more scrum teams and each team became the owner of that service.
As an organization grows, it’s possible that two different services end up doing the same thing. In this scenario, Wade recommends consolidating those services and their corresponding teams into one. He calls this an “inverse Conway maneuver.”
Sudhir notes that no one likes to hear about reorgs, although sometimes they are necessary. Sudhir prefers to use data (i.e., metrics) to determine when it’s time to reorganize. When he worked at Netflix, a metric that applied to the entire company was “stream starts per second” (SPS). Leaders used that metric to decide when it was time to reorganize a given engineering team.
Sudhir references the “two pizza rule” from Jeff Bezos and Amazon. It says that a team is too big if two pizzas cannot feed everyone on the team. What’s the downside of having teams that are too large?
Communication issues. As a team grows in size, the ability to effectively communicate across the team suffers and as a result, the team becomes less productive.
Steve asked Wade and Sudhir what metrics they use to measure developer productivity. Wade says that for scrum teams, he measures product velocity and story points to determine how well a team is functioning and how effective it is at completing tasks.
Sudhir says that metrics can be tricky to manage, especially if they’re tied to recognition or bonuses. Define any metric, Sudhir says, and engineers will game the system to achieve it. One metric that Sudhir dislikes is pull requests or the number of check-ins.
Sudhir says that developers hate friction – when there’s a dependency on something or someone down the chain. A good goal for an engineering leader is to reduce friction. Figure out how to get others out of the way in order for engineers to get the job done.
Scrum teams are widely deployed at DigiCert. Wade likes scrum because it’s universally known. “Scrum is a universal language of productivity that’s understood across global disciplines,” says Wade.
When DigiCert engaged with Lohika, the onboarding process was seamless because of scrum. The Lohika engineers participated in daily standups, backlog grooming and backlog planning. There was a level of trust on how work was done. In addition, it was easy to measure velocity and all the project pieces fit together nicely.
Wade says that Lohika was able to breathe new life into their development lifecycle.
DigiCert ONE is a modern, holistic Enterprise PKI manager. It was built in just over a year in a collaboration between DigiCert and Lohika.
Wade mentions the following benefits in working with Lohika: