This content originally appeared on DEV Community and was authored by Benito August
Your team might be “busy,” but are they actually shipping quality code? Let’s talk about the difference between activity and impact, and why it’s crucial for your team’s health and performance.
My frustration as a manager hit its peak when I faced a harsh reality: my project board was a fantasy.
I saw tickets in the “Done” column, but when it came to validation, the deliverables were broken, incomplete, or far from reality. My team was active, but they weren’t effective.
Without realizing it, I was the director of a full-blown “Productivity Theater,” and the script was being written by a set of deeply flawed metrics. This is a trap many leaders and teams are falling into in the remote era.
The Rise of “Productivity Theater”
“Productivity Theater” is the phenomenon where employees, feeling the pressure to appear busy, dedicate significant time and energy to simulating activity rather than producing effective work.
And it’s not a minor issue. A startling report from Visier (2023) found that 43% of employees spend more than 10 hours per week on this kind of performative work.
Why does this happen? The social psychologist Dr. Devon Price, in his book “Laziness Does Not Exist,” argues that our culture has ingrained in us a “Laziness Lie”—a belief system that equates our self-worth with our productivity. This pushes developers and knowledge workers to work until they’re sick and feel immense guilt for not “doing enough,” making it essential to look busy at all times.
Vanity Metrics: The Fuel for the Fire
This “theater” is fueled by a leader’s obsession with Vanity Metrics. These are metrics that are easy to measure but offer little to no real insight into performance or impact.
In a dev team, this looks like:
Hours logged online
Number of commits
Lines of code written
Frequency of Slack messages
This approach is fundamentally at odds with the nature of deep, valuable work. As Cal Newport explains in his book “Deep Work,” knowledge work is divided into two types:
Deep Work: “Activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.”
Shallow Work: “Non-cognitively demanding, logistical-style tasks, often performed while distracted. These efforts tend not to create much new value in the world and are easy to replicate.”
When you measure ‘keystrokes’ instead of quality, you are actively encouraging and rewarding Shallow Work, leading directly to burnout and poor outcomes.
The Solution: Shift from Activity to Impact
The change begins when we start asking different questions and measuring what truly matters. We need to shift our focus from Input (activity) to Output (results) and Outcome (impact).
Here’s a simple framework contrasting these approaches:
| Metric Type | Example | Why It’s Dangerous / Useful | Leader’s Focus |
|---|---|---|---|
| Input/Vanity | Hours Online | Dangerous: Fosters digital presenteeism, doesn’t reflect real focus, leads to burnout. | Trust your team with flexibility. |
| Input/Vanity | # of Commits/Messages | Dangerous: Promotes quantity over quality. A single, well-thought-out commit is worth more than 10 minor ones. | Encourage effective, asynchronous communication and meaningful code contributions. |
| Output/Outcome | Sprint Velocity / Cycle Time | Useful: Measures the actual pace of delivery and helps identify process bottlenecks. | Set clear goals (SMART), realistic deadlines, and track progress. |
| Output/Outcome | Code Quality (e.g., bug rate, test coverage) | Useful: Reflects the effectiveness and craftsmanship of the work, directly impacting user satisfaction and maintainability. | Define quality standards, implement code reviews, and offer constructive feedback. |
| Output/Outcome | Impact on Business OKRs | Useful: Directly links the team’s technical work to strategic business results. | Ensure team goals are aligned with company OKRs. |
What’s Your Experience?
This isn’t just a management theory; it’s a reality in our terminals and IDEs every day. The push for performative work is one of the biggest drains on developer morale and a direct path to burnout.
So, I’m asking you, the developers and tech leads in the trenches:
What’s the most absurd vanity metric you’ve been judged by? Lines of code? Number of PRs?
Or, on the flip side, what’s the most effective impact-based metric your team uses that you actually find valuable?
Share your stories (the good, the bad, and the ugly) in the comments below!
Closing Thought
Fighting against vanity metrics isn’t about working less; it’s about reclaiming our ability to work on what matters. It’s about creating an environment where deep, meaningful work is not only possible but is the only thing that’s truly valued.
References
Newport, C. (2016). Deep work: Rules for focused success in a distracted world.
Price, D. (2021). Laziness does not exist.
Tableau. (n.d.). What are vanity metrics?
Visier. (2023, March 1). Productivity survey shows performative work.
This content originally appeared on DEV Community and was authored by Benito August