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.
No comments:
Post a Comment
Comments on this blog are moderated and we do not accept comments that have links to other websites.