Software Engineering Managers: Measure Teams, Not Individuals! - Engineering Insights Podcast Ep. 3

Listen

Listen on anchor.fm.

Transcript

Hello and welcome to another episode of the Engineering Insights podcast by Haystack Analytics. I'm your host, Junade Ali. In today's episode, I hope to discuss why software engineering managers should measure team performance, not quantify or rank individual engineers.

At Haystack Analytics, we often get potential customers asking how they can create internal league tables of their engineers. Indeed, we often turn customers away for this very reason.

In this podcast, I'd like to explain our rationale for thinking that measuring individual software engineer performance is not only unhealthy, but can be erroneous.

In Project Oxygen, Google studied what makes great managers. This study was based on two key quantitate data sources; namely, manager performance ratings and manager feedback from Google’s annual employee survey. The research team quickly identified that teams with great managers were happier and more productive. But what specifically made these managers better?

The researchers found 10 key traits that define high-performing managers. This was validated using double-blind interviews of both the high-performing and low-performing managers.

Google found that great managers are excellent coaches, but they do not micromanage. One software engineering manager, Eric Clayberg, commented in a Harvard Business Review article that “Engineers hate being micromanaged on the technical side,” ... “but they love being closely managed on the career side.”

Software engineers aren't working in a call centre. Software engineering managers must be able to understand risk and mentor engineers individually. Engineering management is an interpersonal skill.

Google then went on to study team performance specifically in Project Aristotle. The researchers studied a total of 180 teams, including 115 project teams in engineering. They conducted hundreds of double-blind interviews and looked at existing survey data.

The researchers identified that a number of traits were not significantly connected with team effectiveness at Google. Individual performance of team members is one such metric. To repeat, Google's Project Aristotle researchers found that individual performance of team members is not significantly connected with team effectiveness.

So if this is the case, what traits do matter? Google identified that psychological safety was the most critical trait for team effectiveness. In teams with high psychological safety, team members feel safe to take risks as part of their team. In other words, they don't feel like they'll be punished for making a mistake, asking a question or offering a new idea.

In other words; no risk, no reward. To grow, you must feel safe being able to experiment and measure. To try new ideas and reserve judgement until you have the empirical data.

A similar principle exists at Amazon. James Anderson, manager of the Scottish Mortgage Investment Trust, a major investor in Amazon also felt that the ability to experiment was essential to Amazon's success. In an interview with Killik & Co he said: “You need to give your company the freedom to experiment. For instance Jeff Bezos’ “two-pizza principle” – that you should never have teams involved who can’t be fed on two pizzas. That’s how you get that type of experimentation.”

This is part of the reason why Cycle Time is such an essential metric for software engineering teams. The quicker developers can go from starting work on a feature to deploying it in a production environment, the quicker the company can experiment to grow, ultimately allowing the company to adapt to the customer's needs.

To grow you must experiment. To experiment, your organisation must be agile. No risk, no reward.

Thank you for joining me for this episode of the Engineering Insights podcast. We hope you'll join us next time for more resources for Engineering Managers and DevOps leaders.

The soundtrack used in this podcast has been WERQ spelled W E R Q by Kevin McLeod. This podcast has been recorded and produced in Edinburgh, Scotland for Haystack Analytics.

‍