Here’s a question I think about a lot when leading digital transformations and guiding agile teams.

“How should I think about team happiness? Why and how is team happiness important? How should I determine whether and to what extent the team is happy?” – I ask in Digital Trailblazer

When I hear from CIOs, IT Leaders, and other Digital Trailblazers about the struggles they face retaining talented DevOps engineers, data scientists, and product managers on their teams, I wonder whether and how they gauge their agile teams’ happiness.

Avoid asking open-ended questions

If you ask, “Are you happy?” you’re likely to get a myriad of answers. You’re asking about human emotion, and you’ll get all kinds of responses: the micro (“My commute sucked this morning”), personal issues (“My kids are fighting”), politics, gripes, etc.

Unfortunately, I’ve seen leaders do just that – ask vague questions and then overreact to the response. I’ll hear, “There’s poor morale in IT, and they’re not happy,” without any context on who, when, and how the question was asked.

What can Digital Trailblazers do to improve team happiness

Instead of asking a completely open-ended question, think about asking more pointed ones, such as:

• Are you happy with the team’s performance over the last sprint?
• Are you happy with the hybrid working model and how the team collaborates?
• Are you happy with the priorities and the tasks you are committing to?

These questions aim to seek people’s emotional responses to a specific context. From there, the Digital Trailblazer should look to find the opportunity or problem and ask a follow-up question, “How can we improve?”

So you may have a DevOps engineer say, “I am not happy because we’re not prioritizing enough work to reduce technical debt,” then I might respond, “How can we improve this next release? What one improvement would you prioritize?”

This even works if the response is that they are happy. So, for example, say someone answers, “Yes, I am happy with the team’s performance as we increased velocity and received positive feedback on the application’s UX improvements.” I might respond, “That’s great! How can we help other teams improve and experience similar results?”

Happiness comes from showing that you care and helping people see how their work, ideas, and feedback are creating an impact.

Should you use a happiness metric?

It may be tempting in large DevOps organizations to use a happiness metric, and here’s an example implementation. But you can see that the metric requires asking as many as five other contextual questions, which can be time-consuming on a survey. Some have asked whether happiness metrics are logical or laughable, describing them as white whale metrics. Others argue that measuring team morale is more important.

I believe happiness, morale, and trust are all part of winning teams and sustainable digital transformation programs. It’s one reason the leadership responsibilities in StarCIO’s Agile Planning identifies winning teams as a core tenant, giving it equal importance with delivering product roadmaps, technology standards, and reliable releases.

I believe surveying DevOps organizations and agile teams is important and will follow up with another post on what types of questions to ask on them. I’m just not a proponent of measuring and rolling up highly subjective measures based on individuals’ feelings or padding surveys with too many hard-to-answer questions.

To build trust in winning teams, ask people about their feelings in different contexts and discuss what can be improved.