‹Re:think› Community
timezone
+00:00 GMT
SIGN IN
  • Home
  • Events
  • Content
  • People
  • Messages
  • Channels
  • Help
Sign In
Event Insights
January 29, 2022

How to Organize Engineering Teams, Measure Developer Productivity, and More

How to Organize Engineering Teams, Measure Developer Productivity, and More

Panel Discussion Recap

Dennis Shiao
Dennis Shiao
How to Organize Engineering Teams, Measure Developer Productivity, and More

How to organize engineering teams?

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.

Clarity around ownership

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.”

When to reorganize teams?

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.

Metrics for developer productivity

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.

Benefits of scrum

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.

Benefits of partnering with Lohika

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:

  • Add a new perspective to DigiCert’s engineering process
  • Add new processes related to agile and scrum
  • Help automate the CI/CD pipeline
  • New CI/CD automation adopted across all DigiCert teams
  • Add cloud-native technologies
  • Scale teams and add new teams easier (as a result of the above)
Dive in
Related
blog
Scaling Engineering Organizations: Insights from Marqeta, Stitch Fix, Catalyst Software and Superhuman
By Dennis Shiao • Jan 29th, 2022 Views 115
blog
How Fintech Start-Up Engineering Leaders Manage Rapid Scaling
By Dennis Shiao • Jan 29th, 2022 Views 127
blog
Interviewing Best Practices for Engineering Leaders (from CTO Craft Con)
By Dennis Shiao • Jan 29th, 2022 Views 154
blog
Should There Be A Healthy Tension Between Product and Engineering Teams?
By Dennis Shiao • Jan 28th, 2022 Views 135