How to destroy team culture
(and what to do instead)
By Simon Hartley, Future of Teams · 4 min read
Why measuring productivity the wrong way quietly destroys team trust
About ten years ago, I was working as a tech lead for a large insurance company. My manager at the time, a great mentor, suggested I move into leadership. I resisted for a while, clinging to the comfort of my technical skills. But eventually, I said yes.
The shift was bigger than I expected. I realised I was now part of two teams: my peers in leadership (Team 1) and my delivery team of developers (Team 2). Both mattered, but I soon learned that leading well meant spending more time with Team 1 than I was comfortable with.
That realisation changed how I saw everything about productivity and culture.
When metrics become or are perceived as surveillance, culture decays. When they become signals for continuous improvement, culture thrives.
The burning question
Throughout my leadership career, one question has followed me: How do you measure productivity and performance for developers? And how do you improve output without burning people out?
I knew, from my time as a developer, that there are countless confounding factors. Focusing too much on individual metrics made Team 2 feel watched and distrusted. Focusing only on leadership goals made Team 1 think the engineers lacked accountability. And so, the conflict persisted.
At the leadership level, we live by OKRs, KPIs, and quarterly reviews. The focus is company performance, not code quality. But for developers, the “why” is grounded in building things that work well, run fast, and don’t break. The link between those outcomes and top-level metrics like revenue or churn isn’t always direct. Even the best teams are placing bets that their work will move the right company numbers. Often these teams are cross functional and therefore engineering is not solely responsible for all outcomes.
So, the challenge for engineering leaders is to find metrics that connect both worlds, metrics that improve how we deliver, not just how much we deliver.
Measuring the Wrong Things
Every time we try to quantify developer productivity, we risk measuring the wrong thing and sending the wrong message.
Traditional metrics like lines of code, commits per day, or hours logged appeal to a certain management logic. But they tell you nothing about actual value. They encourage performance theatre, not performance that drives outcomes.
You can hit every number and still not deliver on the outcomes that matter for the company, but you will likely be guaranteed to kill trust.
From Surveillance to Signals
The real job of metrics isn’t to track activity, it’s to understand which signals predict better outcomes.
Outcome metrics over output metrics
Measure what customers actually experience, not how many hours someone spent coding. Did the feature solve the problem? Did it ship on time? Did it work reliably?
Team metrics over individual metrics
Focus on team velocity, not individual story points. Measure how quickly the team delivers value, not how many commits a single developer made.
Leading indicators over lagging indicators
Track things like code review quality, test coverage, and deployment frequency. These predict future performance far better than lagging indicators like revenue or defect counts.
DORA tracks four metrics that matter, and that is a great starting point. But also consider which of those your team should initially focus on. Also consider SPACE metrics to ensure a balanced view of team health.
Both frameworks complement each other: DORA helps you ship faster; SPACE helps you sustain it.
DORA vs SPACE Comparison
| Framework | Focus | Example Metrics | Primary Purpose |
|---|---|---|---|
| DORA | Delivery performance | Deployment frequency, lead time, MTTR, change failure rate | Measures delivery speed and stability |
| SPACE | Developer experience and team health | Satisfaction, performance, activity, communication, efficiency | Ensures balance between productivity and well-being |
Practical Takeaways
Make Metrics a Conversation, Not a Weapon. The goal isn’t to catch people slacking off or to identify the “hardest workers.” It’s to help everyone do their best work.
- Transparency: Share metrics openly. Let teams see what’s being measured and why.
- Collaboration: Let engineers define what “productive” means in their context.
- Focus on improvement: Use data to spot bottlenecks, not blame.
- Don’t reinvent the Wheel: Use established best practice DORA and SPACE metrics
Closing Reflection
The wrong way to measure performance doesn’t just fail to improve output, it erodes trust.
When I began reviewing deployment frequency with teams instead of story points per person, discussions shifted from “which developer is the fastest” to “how can we ship safer, sooner.” Culture improved as a result.
Metrics should build trust, not fear. Measure progress, not people.