Manage Morale, Not Metrics

Management is obsessed with measuring everything, and this obsession is sabotaging the quality solutions that software engineering teams can craft.

By Jeremy Duvall, founder, 7Factor Software
This article originally appeared on InfoWorld on July 25, 2022.

The business leaders who hire engineering firms such as mine like to see the numbers, the metrics that claim to quantify the value we create. While they may not understand the esoteric subtleties of refactoring to improve readability and conciseness, they can appreciate when code coverage increases from 85% to 90%. The numbers are going up! So something valuable must be happening, right?

The problem is that so many of these numbers are nonsense, and even the valid measures don’t work well as management tools. Metrics have their place, but they should follow where teams lead, in order to quantify the quality and worth of the solutions they’re creating. When metrics lead—when story points dictate where developers must follow—they actually get in the way of teams’ ability to innovate, create, and solve meaningful problems.

For truly valuable software solutions developed by effective engineering teams, leaders should instead be managing morale, developer satisfaction, and team focus, then trust in these to drive efficiency, quality, and a company culture in which everyone can thrive.

Managing metrics is inefficient and ineffective

Consider a fairly trivial example. An engineering team is consistently knocking out 20 tickets in each sprint. The metrics are great, the team is clearly killing it, and the product owner can report excellent progress to their stakeholders.

But then you look a little closer and discover that this team has been hitting those numbers by working a string of 60-hour weeks. They’re tired, burnt out, miss their friends and families, and aren’t even clear on the value of what they’re creating. Bleary-eyed and carpal tunneled, they’re treated like and feeling like commoditized robots, automatons assembling code along an endless line.

The metrics look great, but the morale is terrible.

Look closer still and you’ll almost certainly find that the quality of their code is suffering, and the potential value of their solutions is suppressed. You’ll find few or no automated tests, little refactoring, and lots of hacks. You’ll find more technical debt, problems with scaling, and disconnects between the desired user experience and the implemented code.

If your engineers care about quality—and you shouldn’t hire any who don’t—they know they’re doing inferior work, and their morale will further plummet.

Let this continue long enough, and you’ll soon suffer another cost: lost talent, and the delays and deficits of onboarding new engineers in the middle of a project.

But because you’re managing metrics instead of morale, you won’t see all these problems until it’s too late.

To manage morale, focus on mission, autonomy, and mastery

OK, I confess that I may have chosen the world “morale” in part because it alliterates with “manage” and “metrics,” leading to a poetically pleasing headline. I know “morale” is sometimes associated with celebratory office pizza parties and corporate kumbaya.

But I’m not talking here about toxic motivational nonsense dispensed to employees, coated in charisma, and reinforced with artificial incentives… incentives such as rewards for hitting arbitrary metrics.

I’m talking instead about morale that inspires your teams to invest sustainably in the success of each project.

As Daniel Pink wrote in his 2009 bestselling book, Drive: The Surprising Truth About What Motivates Us, true intrinsic motivation—invested morale, we might say—comes from autonomy, mastery, and purpose.

Transactional rewards tied to artificial metrics can compel basic compliance with an arbitrary process, but they’ll never unleash the full, focused potential of an effective software engineering team to innovate, solve meaningful problems, and create substantial new value. Instead, you need your engineers to invest in a project’s purpose, take ownership of the solution, and take pride in the quality of the solution that they craft.

Morale is rooted in mission (not metrics)

Long gone is the “Leave It to Beaver” workforce that would sit in a cubicle, compliantly doing whatever work they were given. Our field is now dominated by Millennials and Generation Z, and these generations are missional to their core. They reject purely transactional employment. Many want to work for companies that are principled and purpose-driven.

Really, all good developers—no matter their generation—are principled people who want to tackle interesting problems, craft quality code without technical debt, and produce valuable solutions to those whom they serve. (And again, don’t hire any developers who don’t have these qualities.)

You don’t need meaningless metrics to drive their desire. You do need to help your teams connect with each project’s mission, clear away any impediments to their success, and support them with everything they need to do their best work.

Respect your engineers enough to explain and discuss the purpose of the project. What are we trying to do? Why are we doing this? What’s the point? What’s the philosophy?

The mission doesn’t have to be about saving the world. By all means, take any opportunity to work on projects that combat climate change, protect lives in public health crises, or move the needle toward justice along the arc of the moral universe. Noble missions such as these will be profoundly inspiring to your teams.

However, missions don’t have to be so grand to inspire investment. A mission can be “to implement good, ethical software that solves interesting problems.” It’s fine if the problem is “long-haul truckers are struggling to deposit their paychecks so their families can pay their household bills” or “an antiquated infrastructure is stifling innovation for a key control system for multifamily residential properties.” (Those are both real problems my company has helped clients solve.)

The problems don’t have to be global as long as the mission of crafting quality code to solve worthwhile problems is honored and substantively supported—and as long as arbitrary metrics aren’t allowed to compromise that mission.

Morale is activated in autonomy (not metrics)

A shared sense of mission is great, but its motivational power is undone if you then micromanage how a team contributes toward the fulfillment of that mission.

“We” may be transforming an industry, saving lives, or widening the horizon of human achievement. But if you make all the consequential decisions, then the daily experience of your engineers is reduced to closing out their quota of tickets to meet their metrics. They’re too far removed from the mission. That’s far less motivating to them, and you lose out on the full potential of their critical thinking and creativity.

Effective engineering teams are largely autonomous. You help them understand the mission and the particular needs of the stakeholders and users. You establish some basic ground rules and guard rails for the technical solution. Then you get out of their way and let them do what they do best, relying on their quality-driven ethos to guide them toward the best approach.

An autonomous team still needs smart oversight and good leadership. Developer anarchy doesn’t work, and chaos isn’t motivating. But trust your engineers to solve the problems you give them. Trust them to identify potential challenges and innovate better solutions. Trust them to manage the fulfillment of the project mission.

And if you can’t give your teams that trust, examine whether you’ve hired the wrong people, or aren’t leading the right people well, or are allowing arbitrary processes to get in the way of engineering. Metrics won’t solve these problems. A focus on autonomy within a shared commitment to quality will.

Morale improves with mastery (not metrics)

When we talk about “mastery,” it’s often about the skill sets of individual engineers and the opportunities they have to grow those skills. But mastery is also systemic. Organizational decisions and processes can either support or impede the ability of engineers and teams to do quality work they can be proud of.

Do your engineers have a clear sense of direction? Do they have the tools they need and uninterrupted time to use them well? Do they have a voice in setting timelines and the authority to make important decisions?

Do they have enough time to do the work right? To explore and learn? To rest, reflect, and restore? To deploy and measure their solutions properly?

Or is the tyranny of metrics driving them to submit what they know is sloppy code and hurry on to the next ticket? Are they distracted by needless meetings and arbitrary processes? Are they overworked and burnt out?

Abi Noda, co-founder and CEO of DX, gathers these systemic factors under the umbrella of “developer experience” (DX), which he says directly impacts developer effectiveness and business success. It’s a topic on which Noda co-authored, with Dr. Michaela Greiler and Margaret-Anne Storey, “An Actionable Framework for Understanding and Improving Developer Experience” (PDF) in the Journal of Transaction on Software Engineering. And a DX white paper asserts that neither output nor process metrics can accurately measure the developer experience.

In a culture of trust and respect, leaders begin with the assumption that their teams want to craft quality software. They don’t use metrics to measure or mandate that mastery. Instead, they have open, safe, honest conversations with their teams. What are we trying to do here? (Mission.) What’s getting in your way? (Autonomy.) How can we support you in doing your best work? (Mastery.)

These conversations are rooted in a shared understanding of purpose, and they lead to systemic changes designed to support each engineer and each team in their satisfaction and success.

Managing morale leads to better solutions, better retention, and a better company culture too

Morale is about so much more than a pleasant work environment and good employee satisfaction scores. When software engineers are invested in a project’s mission, trusted with the autonomy to solve it as they think best, and given the support they need to do their best work, they create demonstrably better, more valuable solutions.

They’re also much more likely to stay with your company. As word gets around, recruiting additional talent will become easier too.

And yes, managing morale also leads to a better company culture, a better community. One that you and everyone on your team will enjoy being a part of as, together, you apply the very best of your individual and collective talents to create truly transformative software solutions.