Down-to-earth guide to Engineering KPIs

Engineer Manager's guide to growth and lean processes

Sep 28, 2023

Ever since I started managing and leading teams the idea of measuring anything in the team fascinated me. Not because the numbers were so actionably, but rather because it was such a chaotic mess. It was beautiful.

Start measuring individual contributions, the team starts to game the KPIs. Numbers go up. Satisfaction goes down. Clients leave, employees become disgruntled. On the other hand, measure nothing and you may naïvely think that you’re doing your best by throwing your hands in the air and admitting defeat.

Clearly, the path out of this madness is somewhere in the middle. Or is it?

Why measure?

New employees will be looking to prove themselves and adapt to an exciting new opportunity while being held back by the peer group change and struggles during on-boarding.

Established members of your team seek to make their workplace their primary expression of their vocation— it matches their optimal work life balance and challenge curve and needs to be continuously stimulating by building new experiences.

Departing members of your team will seek greater or different paths elsewhere. They are re-evaluating their priorities in life and may require—in order to reshape themselves— an element of chaos and uncertainty. More than the current company and team can provide.

Without getting too sentimental, we measure in order to stay in the optimal state of learning.

This is at the heart of agile.

This is at the heart of lean.

This is extreme programming.

How does the team want to grow?

What do my team members want to learn?

What problem areas causes the most frustration?

What is my team desperate to overcome?

What are they afraid of?

What percentage of work hours does the team live and embody these questions? In essence that is what we measure.

“The point of being done is not to finish, but to get other things done.”
—Cult of done

🔵 typo —ship better software faster

Typo is a Software delivery intelligence platform that enables modern software teams with visibility, insights & tools to code better, deploy faster & stay aligned with business goals.

By seamlessly integrating with the dev tool stack (Git, Issue Tracker, CI/CD, Incident Management, Slack), Typo connects the dots between engineering signals & developer well-being to build efficient teams that deliver on time.

Typo helps tech teams deliver at every level:

For Leaders. Align engineering with business goals & support teams to deliver their best with developer well-being insights
For Managers. Identify delivery bottlenecks, predict release delays & drive continuous improvement with customized team goals & weekly progress reports
For Developers. Ship code faster with automated dev workflows in Slack & measure the impact of your work on team goals.

Learn more about Typo

^{Typo is a sponsor of Crafting Tech Teams}^🙏

What do YOU want to act on?

Every day you put on your Engineering Leader hat you have a choice to make.

“What kind of leader am I going to be today?”

Will you push for output? Are you annoyed by slow progress? Are you looking for ways to bypass your team’s lack of experience?

Or will you embody growth? Are you willing to be a dont-knower? Will you nurture your team to make mistakes more frequently? Provide a safer environment where they can learn and build experience faster?

Sometimes all it takes it a moment to zoom out and re-asses how you show up as a leader.

Sometimes you need to question silly industry practices like pull requests.

Why is your identity and personality important you may ask? Because you shouldn’t be tracking metrics that you are not ready and willing to respond to. You honor a metric and call it a success when you act on it and learn. Over time, you won’t need to track it anymore. If you continuously have to track a metric that you don’t act on, it’s time to track something else.

For example, Typo above has a great metric that estimates burnout and overwhelm in a developer. This metric won’t show up all the time—in fact, it’s mostly invisible unless it really needs to be highlighted, in which case it’s going to be a giant big 🔥 next to a developer. This is a sign of a good metric that you should act on immediately.

If you don’t act on it the 🔥 will stay and cause noise in the data. Get rid of it.

“You can develop a vision by taking the problems that beset you seriously.“—Jordan Peterson, See the world through a Story

Well-being

Recent research studies show a chaotic landscape of levers that you can control. This is the land of anxiety: too much choice. I’m confident claiming that well-being is the most universal and predictable axis on which engineering leaders can draw upon.

From the linked research paper from

Abi Noda

Improving job enthusiasm: Leaders can promote job enthusiasm by facilitating developers' growth through learning opportunities and recognition of exceptional work. For instance, one company in this study experimented with publicly recognizing developers who adopted tools and practices for structured code navigation.
Increasing support for new ideas: One proven strategy for fostering support of new ideas is to share best practices. “At Google, one way knowledge is shared is through an initiative called Testing on the Toilet, where engineers write short newsletters about testing or other technical knowledge.”
Increasing feedback about job performance: Research encourages leaders to provide feedback that is non-threatening, behaviorally-focused, and outcome-oriented. “At Google, one way that feedback is provided in this way is through blameless postmortems, where after a significant negative outcome occurs like a service outage, engineers collaboratively write a report that focuses on the behaviors that contributed to a root-cause, without blaming individual engineers.”