If your team is measuring developer productivity by lines of code or number of commits, you're measuring the wrong thing. So what should you be looking at instead?

In Episode 5 of Making Software, I talked to Dennis Henry, Productivity Architect at Okta. Dennis has a master's degree in human factors, and he explained to me how he applies it to software engineering every day.

• The science of failure, applied to your codebase. Human factors studies how people interact with systems and how things go wrong. Dennis explains why "human error" is never the real root cause in production incidents, and what you should be looking for instead.

• A multi-model AI gateway for an entire company. Dennis built an internal platform that gives every Okta employee secure access to any Anthropic, OpenAI, and more models, that lives behind SSO with PII guardrails and MCP call auditing. He walks through why locking into one vendor right now is a mistake and how to architect around that.

• Improving Engineering Productivity Dennis constantly asks engineers: "What pisses you off? What makes you want to throw your keyboard across the room?" He makes the case that happy people make the best software, and that measuring sentiment matters more than measuring output.

• What to actually track. Lines of code? Terrible. Commits? Meaningless. Dennis argues for reliability, bug resolution time, customer experience, and whether your team feels like they have the tools to do their job. Qualitative over quantitative.

Productivity isn't about squeezing more output out of people. It's about removing the things that get in the way of meaningful work.

What's the worst productivity metric you've seen used on a team? Let me know in the comments!

Listen to the full episode

Available on YouTube.

Thanks for reading! 👋