Manage morale, not metrics, for more efficient engineering teams


Business leaders who hire engineering firms like mine like to see the numbers, the metrics that claim to quantify the value we create. While they may not understand the esoteric intricacies of refactoring to improve readability and conciseness, they can appreciate when code coverage goes from 85% to 90%. The numbers are climbing! So something precious has to happen, doesn’t it?

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

For truly valuable software solutions developed by effective engineering teams, leaders must instead manage morale, developer satisfaction, and team focus, and then trust them to drive efficiency, quality, and a culture company in which everyone can flourish.

Metrics management is inefficient and inefficient

Let’s take a fairly trivial example. A team of engineers systematically eliminates 20 tickets in each sprint. The metrics are great, the team is clearly killing it, and the product owner can report great progress to their stakeholders.

But then you look a little closer and find that this team hit those numbers by working a series of 60-hour weeks. They’re tired, exhausted, miss their friends and family, and they don’t even know exactly what they’re creating. Cloudy-eyed and carpal tunneled, they are treated and feel like unmarked robots, automatons assembling code along an endless line.

The metrics look good, but the morale is terrible.

Look even closer and you’ll almost certainly find that the quality of their code suffers and the potential value of their solutions is taken away. You will find little to no automated testing, little refactoring, and lots of hacks. You’ll find more technical debt, scaling issues, and disconnects between the desired user experience and the implemented code.

If your engineers care about quality, and you shouldn’t hire those who don’t, they know they’re doing substandard work and their morale will drop further.

Let this go on long enough, and you’ll soon incur another cost: the loss of talent, as well as the delays and shortfalls of onboarding new engineers in the middle of a project.

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

To manage morale, focus on mission, autonomy and mastery

OK, I admit that I may have chosen the word “moral” partly because it alliterates with “manage” and “metric”, leading to a poetically pleasing title. I know that “morale” is sometimes associated with office pizza parties and company 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 reaching arbitrary measures.

I’m talking more about the morale that inspires your teams to make a lasting investment in the success of each project.

As Daniel Pink wrote in his 2009 bestseller, Driving: The Surprising Truth About What Motivates Ustrue intrinsic motivation – invested morale, we might say – comes from autonomy, mastery and purpose.

Transactional rewards tied to artificial metrics may force basic compliance with an arbitrary process, but they will never unleash the full targeted potential of an effective software engineering team to innovate, solve meaningful problems, and create new value. substantial. Instead, you need your engineers to invest in the purpose of a project, take ownership of the solution, and take pride in the quality of the solution they’re building.

Morale is rooted in mission (not metrics)

The “Leave It to Beaver” workforce is long gone and used to sit in a cubicle, compliantly completing all the work given to them. Our field is now dominated by Millennials and Generation Z, and these generations are deeply missionary. They reject purely transactional employment. Many want to work for companies that are driven by principles and purpose.

Truly, all good developers, regardless of generation, are principled people who want to tackle interesting problems, create quality code without technical debt, and produce useful solutions for those they serve. (And again, don’t hire developers who don’t have these qualities.)

You don’t need meaningless measures to stimulate their desire. You do need to help your teams connect with each project’s mission, remove all barriers to their success, and support them with whatever they need to do their best.

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 is philosophy?

The mission doesn’t have to be to save the world. By all means, seize every opportunity to work on projects that fight climate change, protect lives during public health crises, or move the needle toward justice along the arc of the moral universe. Noble missions like these will be deeply inspiring to your teams.

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

Problems need not be global as long as the mission of creating great code to solve worthwhile problems is honored and substantially supported, and as long as arbitrary metrics are not allowed to compromise that mission.

Morale is activated in autonomy (no metric)

A shared sense of mission is great, but its motivating power is negated if you then manage how a team contributes to accomplishing that mission.

“We” can transform an industry, save lives or expand the horizon of human success. But if you make all consequent decisions, then your engineers’ daily experience is reduced to closing their ticket quota to meet their metrics. They are too far from the mission. It’s much less motivating for them and you lose all the potential of their critical thinking and creativity.

Effective engineering teams are largely self-sufficient. You help them understand the mission and the specific needs of stakeholders and users. You establish basic ground rules and safeguards for the technical solution. Then you step out of their way and let them do what they do best, relying on their quality-driven philosophy to guide them to the best approach.

An empowered team always needs smart oversight and good leadership. Developer anarchy does not work and chaos is not motivating. But trust your engineers to solve the problems you submit to them. Trust them to identify potential challenges and innovate better solutions. Trust them to manage the achievement of the project mission.

And if you can’t instill that trust in your teams, consider whether you’ve hired the wrong people, aren’t managing the right people well, or are letting arbitrary processes get in the way of engineering. Metrics will not solve these problems. The emphasis on autonomy within the framework of a common commitment to quality will be.

Morale improves with mastery (not metrics)

When we talk about “mastery”, we often refer to the skill sets of individual engineers and the opportunities they have to develop those skills. But control is also systemic. Organizational decisions and processes can support or hinder the ability of engineers and teams to perform quality work they can be proud of.

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

Do they have enough time to do the job well? Explore and learn? Rest, reflect and recharge? To properly deploy and measure their solutions?

Or does the tyranny of metrics drive them to submit what they know is sloppy code and rush to the next ticket? Are they distracted by unnecessary meetings and arbitrary processes? Are they overworked and exhausted?

Abi Noda, co-founder and CEO of DX, brings these systemic factors together under the umbrella of “developer experience” (DX), which he believes directly impacts developer effectiveness and the success of the company. This is 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 Software Engineering Transaction Log. And a DX white paper claims that neither output nor process metrics can accurately measure developer experience.

In a culture of trust and respect, leaders assume that their teams want to build great software. They do not use parameters to measure or impose this mastery. Instead, they have open, safe, and honest conversations with their teams. What are we trying to do here? (Mission.) What bothers you? (Autonomy.) How can we help you do your best work? (Mastery.)

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

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

Morale is more than a pleasant work environment and good employee satisfaction scores. When software engineers are invested in the mission of a project, given the autonomy to solve it the way they see fit best, and given the support they need to do their best, they create solutions that demonstrably better and more valuable.

They are also much more likely to stay with your business. As word spreads, recruiting additional talent will also become easier.

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

Copyright © 2022 IDG Communications, Inc.


About Author

Comments are closed.