with a focus on alignment, ownership, and trust.

Having read the article on measuring developer productivity by McKinsey & Company as well as a few follow-ups, with the most in-depth one being the two-part response by Gergely Orosz and Kent Beck, I deep-dived into what’s behind the urge of measurement — and found out that it’s the need to solve profound team leadership challenges.

Authors offer alternative measurement models as well as provide very specific evidence of why measuring and incentivizing effort, output, outcome, and impact may introduce bigger risks than when not measuring those. But the question stays valid, and if there is a question “how,” there should first be a question of “why.”

So I asked myself:

Why measure developer productivity?

There can be several reasons for that, originating either from a C-level executive or an engineering manager themselves:

• Relative cost of engineering is higher than expected
• The need to maintain a high-performing team
• Understanding which teams to invest in and scale
• Transparency of individual contribution to the team’s success
• Providing relevant growth opportunities for engineers.

The list is not exhaustive, but I noticed the commonalities in that all of those challenges have a similar solution: not interfering with the subsystem.

Formal measurements shift the focus of individual contributors from generating business value to gaming the system, as well as adding a burden of constant and precise control by the managers that are requesting it. It creates a race between introducing new KPIs and adapting to those with the least effort. This is also true for middle managers when the measurement is requested by the senior leadership.

The closed system metaphor

Imagine that an engineer is a closed system / a cell / a black box (system level 0). A team of engineers with their manager is also a closed system (system level 1). On the next level, a manager of multiple teams + the teams themselves form a new system (system level 2), and this system is led by an executive (together forming system level 3).

When a manager (system level 2) introduces measurement for the teams (system level 1), they interfere with how the system operates and thus downshift into system level 1.

Being interfered with, aka micromanaged, teams (system level 1) lose their ability to self-organize, create efficient processes, and deliver company value in the most effective way possible. The same idea can be projected into higher levels. This makes introducing KPIs a short-term remedy with delayed strategic side effects.

On the other hand, if system borders are respected and the manager sets and validates goals, i.e. performs constant alignment of expectations and lets teams do the work, fail, learn, iterate, and deliver — stronger teams with great ownership are formed, and no control is required. Outer system managers can address the above questions directly to the team manager (lower level systems) without interfering with those:

• Relative cost of engineering is higher than expected
  What do we lose if we downsize the team?
• The need to maintain a high-performing team
  Who on the team is the least performant? How fast are they developing? Have you considered replacing them?
• Understanding which teams to invest in and scale
  How will the impact of the team grow if we bring in additional headcount?
• Transparency of individual contribution to the team’s success
  Who is currently contributing to the team’s success most and in which way?
• Providing relevant growth opportunities for engineers
  Do all engineers have a growth plan and are they happy with it?

How is that possible to achieve?

Leading teams is a challenge: goals get misinterpreted, expectations mismatch, core values differ, managers fail, engineers fail, and market fit changes. Measuring productivity (not to be mistaken with measuring and calibrating performance) seems like a silver bullet to create a transparent process that scales. It does, but with downsides.

Companies are made of people, and the only way to constantly align and cultivate ownership is by building trust. There is no way to ask the above questions and rely on team’s manager answers without trust, at least some level of trust. Of course, overrides happen and interference should be exercised from time to time, but it is always good to keep in mind: if a system fails — it’s the manager of this system who needs help, not their subsystems (or engineers).

Building trust and exercising alignment are not straightforward investments, and are hardly measurable. But this is what differentiates great teams in the longer term.

Building Self-Guided Engineering Teams was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.