The No.1 Productivity Measure No One is Talking About...
Welcome back to The Modern Software Developer. In this month’s issue, I’m talking to software development leaders, new and old. I’m shining a light on the practice of trying to measure software developer productivity and the detrimental impact it might be having on your team’s wellbeing and performance.
The Traditional Route
For years, software development teams have relied on conventional productivity metrics to attempt to measure their success.
👉 Test Coverage Targets
👉 Sprint Velocity
👉 Features per quarter
👉 And many other similar metrics…
These have largely been an attempt to give those higher-ups a sense of control and confidence in the impact of their software development team - usually to try and justify their cost.
The measures themselves are not entirely useless… it’s what we do with them that is often the problem… Enter Godhart’s Law:
When a measure becomes a target, it ceases to be a good measure.
Probably the number one mistake being made the world over when it comes to measuring…
It worsens when those higher-ups want to try and measure individual developer productivity.
👉 How many commits did they make per day?
👉 How many points did they deliver this sprint?
👉 How many lines of code did they commit per day?
Even with the best intentions, these metrics tend to encourage developers to find ways of gaming the system, often with undesirable consequences. What does that mean for the metrics…
They simply don’t measure what those people who put them in place think is being measured…
The Marshmallow Experiment
Have you heard of the famous Marshmallow Experiment conducted by psychologist Walter Mischel?
Children were given a choice: eat one marshmallow immediately or wait for a while and receive two marshmallows as a reward.
The experiment was originally designed to test children's ability to resist instant gratification and demonstrate delayed gratification, often seen as an indicator of self-control and discipline.
👉 OK - Stay with me here… 👈
What if this experiment doesn't measure what we think it does?
What if, instead of measuring a child's self-control and discipline, it's actually measuring the trust the child has in the adults conducting the experiment…?
If a child thinks the adult might not keep their promise of providing two marshmallows later (perhaps based on prior experience of adults not keeping their promises…), they may choose to eat the one marshmallow in front of them. That has nothing to do with instant or delayed gratification or self-control…
I often wonder if we find ourselves in exactly the same situation when trying to measure developer productivity.
Like my speculation on the Marshmallow Experiment, are these metrics capturing what we truly believe they capture?
Or are they inadvertently measuring something entirely different… and, worse yet, producing the exact opposite result to what we want?
Sacrificing Wellbeing in Pursuit of Productivity
In the quest for productivity, the software development landscape has seen a troubling trend—a willingness to make sacrifices. The sacrifices in question, however, are not in the name of noble productivity gains but in the name of often compromising the wellbeing of software development teams…
Many development teams, eager to meet predefined productivity goals, have unknowingly entered into a trade-off. They have come to accept that achieving higher numbers on the productivity scoreboard may require sacrifices in software quality, not to mention team wellbeing.
When the trade-offs involve sacrificing the psychological safety, job satisfaction, and work-life balance of the developers, it’s clear to me that the balance has been completely lost, and we can’t, in all honesty, claim these metrics are helping measure productivity.
Developers may feel anxious at the thought of “being watched” and feel the pressure to prioritise quantity over quality. The primary focus becomes meeting arbitrary metrics, which can erode software quality and innovation.
The Pressure Cooker Environment:
In this environment, the development process can morph into an anxiety-inducing pressure cooker. Team members work tirelessly, often stretching their limits to meet predefined goals.
The fear of falling short of these metrics can stifle creativity, discourage open communication, and thwart the expression of new ideas.
The relentless focus on metrics creates an atmosphere where team members are more concerned about meeting individual numbers than collaborating and creating valuable software.
The Cost of Compromised Wellbeing:
This trade-off comes at a great cost. Sacrificing wellbeing can lead to a plethora of negative outcomes, both for the individuals and the collective.
As the pressure builds, team members may become susceptible to stress, burnout, and reduced job satisfaction. These consequences not only affect the individuals' wellbeing, but can also lead to a decrease in overall team satisfaction and productivity.
On top of that, you can expect your reputation to take a hit. Your best developers will leave, costing you a fortune. Getting good developers through the door again will be difficult once word gets out.
Ditch Traditional Metrics - Focus on Team Wellbeing
Focusing too much on productivity often seems to impact individual and team wellbeing negatively, and yet, if we switch our focus to wellbeing, we might just get the productivity we are looking for as a by-product…
When a software development team prioritises wellbeing, it experiences a profound transformation in its functioning. Team members who feel content, psychologically safe, and well-balanced in their work and personal lives foster a productive and harmonious environment.
Let's explore the intricate relationship between wellbeing and various aspects of team functioning:
1. Effective Collaboration:
Wellbeing is intrinsically linked to effective collaboration. When team members feel secure, they are more inclined to share ideas, trust their peers, and work cohesively towards shared goals. A culture of trust and mutual respect creates a fertile ground for collaborative efforts.
2. Open and Honest Communication:
Psychological safety, a critical component of wellbeing, paves the way for open and honest communication. Team members who feel psychologically safe are more likely to voice their thoughts, ideas, and concerns without fear of judgment or retribution. This fosters transparency and productive discussions.
3. Achieving Work/Life Balance:
A team with excellent wellbeing recognizes the importance of work/life balance. Team members who are content in their personal lives tend to be more focused and present during working hours. This balanced approach leads to improved productivity and a lower risk of burnout.
4. Igniting Creativity:
Happiness and wellbeing often go hand in hand with creativity. Content team members are more likely to think outside the box, explore innovative solutions, and propose fresh ideas. A team that values wellbeing becomes a hotbed of creativity, constantly pushing the boundaries of what's possible.
5. Fostering Innovation:
Innovation thrives in an environment where wellbeing is a priority. When team members are encouraged to take calculated risks and explore new approaches, innovation flourishes. Wellbeing facilitates a culture where failure is seen as a stepping stone to success, and this attitude propels the team to find new solutions and opportunities.
Thanks for reading The Modern Software Developer! Subscribe for free to receive new posts and support my work.
6. Positive Team Dynamics:
Team dynamics are significantly impacted by the wellbeing of its members. When team members are content and balanced, they exhibit positive energy and enthusiasm, which spreads to the entire team. This positivity enhances morale and teamwork.
7. High-Quality Deliverables:
A team that values wellbeing places a premium on the quality of its deliverables. Team members are meticulous in their work, focusing on adhering to best practices and minimizing technical debt. The result is high-quality software that not only meets functional requirements but is also maintainable and customer-satisfying.
8. Adaptability and Resilience:
A team that prioritizes wellbeing is more adaptable and resilient when faced with challenges. Team members are more open to change and better equipped to deal with adversity. They navigate uncertainty with a level-headed approach that fosters innovation and problem-solving.
9. Enhanced Problem-Solving:
Team members who feel content and secure are more likely to engage in effective problem-solving. They approach issues with a clear mind, collaborate to find solutions and learn from their experiences. This attitude facilitates continuous improvement.
10. Employee Retention and Satisfaction:
A team's wellbeing-focused approach contributes to employee retention and satisfaction. Team members who feel valued and content are more likely to remain in their roles, reducing turnover and preserving valuable expertise.
The relationship between wellbeing and various aspects of team functioning is undeniable. A team that places wellbeing at its core experiences improved collaboration, open communication, work/life balance, heightened creativity, and a culture of innovation.
This transformation not only enhances productivity but also ensures that team members find fulfilment and happiness in their work.
The question is, how many organisations are attempting to measure their team’s wellbeing…?
How Do You Measure Your Team’s Wellbeing?
Ok, so measuring a team’s wellbeing is hardly going to be straightforward, and it goes without saying that setting targets on such a measure would be a complete waste of time.
In my experience, developers are reluctant to open up about personal things at work, and there are some things we don’t share with our employer… just in case…
On top of that, developers can be suspicious towards their employer's motives and question how the information might be used.
This isn’t helped when measuring a team’s wellbeing is done with the sole focus of improving productivity… productivity should be a by-product.
If you care about your team, help them with their wellbeing, for them… not for you - many companies fail here…
Team Wellbeing Health Check
This is exactly the area that I hope to address with my 20+ years of software development experience…
No, I’m not writing a new app… I’m using that experience to empathise and support developers and leaders with their wellbeing.
This experience, along with being a Mindset Coach and a Personal Trainer (AND a caring human being…) has all gone into my Team Wellbeing Health Check so I can support leaders and teams to measure and, more importantly, improve their team’s wellbeing.
In keeping with the sentiment above, the specific measure is not what’s important...
What’s important is the act of measuring it, which shows your team you care by engaging with someone who is industry-specific and has a chance at understanding what they go through.
What’s important is you have a measure to work with and a process to promote meaningful conversations and introduce education and support.
What’s important is tracking this over time can allow you to determine whether the changes you’re implementing are having the desired effect.
Here’s How It Works:
The Team Wellbeing Health Check begins with an online questionnaire designed to measure various aspects of your team members' wellbeing. Questions encompass areas such as psychological safety, job satisfaction, work-life balance, and other factors crucial for individual wellbeing.
After gathering this data, each team member will receive their own personalised wellbeing report with tips for those areas that may need attention.
Beyond the questionnaire, team members engage in one-on-one meetings with me to delve deeper into their responses. These meetings provide a confidential space for team members to express their thoughts, concerns, and suggestions.
By engaging in open and honest conversations, we uncover valuable insights that inform the next steps in improving individual and team wellbeing.
Following the questionnaire and one-to-one meetings, I create an anonymised and aggregated report to reflect your team’s wellbeing as a whole, offering valuable insights for team leaders.
This report will highlight areas of strength and areas that may require improvement. With data in hand, I hold a session with the team leader to help and support them to make informed decisions to foster a more balanced and healthy work environment for their team.
Team wellbeing is not a one-time consideration; it's an ongoing commitment. The Team Wellbeing Health Check can be repeated each quarter, allowing teams to monitor changes in wellbeing over time.
This iterative approach supports individual team members to take responsibility for their own wellbeing journey while allowing you to determine whether the changes you’ve made are having the desired impact on your team.
It should be obvious that when people are happy and healthy, they perform at their best, but somewhere along the line, that message seems to have been lost in all the tech we have available to us…
Having written this, I’ve just had a random thought… is being productive enough, or is it only the “evidence of productivity” (or illusion of) that leaders and companies care about?
I guess I’ll sum up this newsletter issue with this:
👉 We often pursue productivity at the cost of both wellbeing and productivity itself…
👉 When we pursue wellbeing, the upside is potentially immeasurable…
If you’re ready to start measuring your team’s wellbeing, let’s talk. 👍
Thanks for reading The Modern Software Developer! Subscribe for free to receive new posts and support my work.
It's not selfish to put yourself first; there's nothing more important than your own wellbeing!
Know someone who might find this helpful? Do them a favour and share it with them.
Until next time...