QAmood — On the trail of team satisfaction

In the past, many employees were mainly happy to have a job that allowed them to earn money and support their families. However, those times are long gone. Today there is an acute shortage of skilled workers — and employees can more or less choose their employer in many fields.

This leads to employees increasingly making demands on their employers that go beyond good pay. Because: Many companies can pay appropriately, but where do I really ENJOY working? Where am I satisfied?

This can be seen, for example, in the EY Job Study 2021. According to this study, almost a quarter of employers (23%), would be willing to forego parts of their salary for more free time. And companies also benefit from this, because according to a meta-analysis by Gallup, companies with high employee engagement have higher profitability and productivity.

So what?

In order to ensure long-term employee satisfaction, continuous, standardized, simple and anonymous measurement would be helpful. What’s the best way to realize that?

At QAware, employee satisfaction is already very high, because QAware is not without reason “Germany’s best employer 2023” of companies with 101–250 employees. Nevertheless, a small working group of 5 colleagues asked themselves how to easily measure employee satisfaction and visualize it over time and received a bit of an exploration budget for it.

The key questions were:

• What exactly should be measured? Satisfaction? Engagement? Financial support? → We agreed on the rather abstract word “satisfaction”
• Grouping in teams / projects? departments? Or “just” company-wide statistics? → Since project teams and project content play a key role in satisfaction, we continued to pursue the idea of grouping in project teams
• Are there already tools for this? → Yes, of course — but none of those meet all of our requirements.
• How can we ask for satisfaction — anonymously?
• How can we present the results to the team — also anonymously?

Explicitly out of scope were:

• Content research on the topic of “satisfaction” (emotion vs. mood vs. feeling etc.)
• Methods to increase satisfaction

Go for it!

To achieve quick and visible results within the limited budget, we initially focused on the basics:

• Development of a Slack bot, which — once invited to a Slack channel — asks the channel members (e.g. project members) the question of satisfaction on a daily basis.

Mr. Moody Slack bot

• Storage and pseudonymization in the backend, so that on the one hand no conclusions can be drawn about the person voting, but on the other hand nobody can vote multiple times.
• Presentation of the data from the last two weeks as a graph based on the measured average. Post the link to this graph regularly in the respective group.

• Usage in project teams on a voluntary basis with a request for feedback

Really great, but…

Mr. Moody has been used on various projects and the feedback from colleagues has been consistently positive, most notably:

• Lightweight approach via Slack messages
• Standardized and regular measurement

However, more important than the “yes, very cool idea” was the constructive feedback regarding the necessary further development. Especially for long-term use in projects, a whole range of other features would be required, such as:

• Display of min/max values in addition to the average
• Customizable questions and answers.
• Opportunity for optional additional free text answers — because THAT is where important information about (dis)satisfaction can be found
• Tagging of special dates in the timeline, e.g. Sprint planning
• Gamification to keep the motivation for long-term use high.
• Department or company-wide statistics (only with permissions for relevant people like business unit managers)
• Extension of the weekly status message with e.g. trend indicator and voting rate

One, two, many

The satisfaction is surveyed for project teams, so that an average “project satisfaction” can be found out. For people in several projects, however, this meant that they were asked the question “How are you today?” several times a day — just once per project.

Is their answer then the same (“I’m just not feeling well today”) or different? There are pros and cons for both variants, so that a generally satisfactory solution to the problem of “people being asked the same thing several times a day” was not trivial.

As you can see, you can see… what actually?

Another aspect was the question of the significance of the results. In smaller projects in particular, it was noticeable that the average values fluctuate greatly due to individual opinions and therefore only offer little meaningfulness for the overall satisfaction in a project.

Of course, you should also be able to identify and react to dissatisfaction in small teams — but experience has shown that this works better in team retrospectives, in which individual topics can then be discussed directly. The aim of QAmood, on the other hand, was to measure and illustrate a standardized and permanent average — and this is difficult in primarily small teams (<8 people).

You can see this particularly well in the following picture: the team mood on the right-hand side of the picture is at a low point, but triggered by just one person. This is of course an exception (e.g. during the holiday period when only a few teammates are present), but even with a few more votes it is still difficult to get significant results.

Now what?

There were many other ideas for expanding and optimizing QAmood. However, the implementation of these ideas would require significantly more budget than it would bring added value to the teams. Because (recap): In team retros, thanks to the good feedback culture at QAware, it is already possible to determine very well how the colleagues in the team are doing in detail.

For this reason, the further development of QAmood was paused after several months. On the one hand this is a pity, on the other hand every exploration is faced with this decision point at some time — and an honest “nice idea, but currently not cost-effectively implementable” creates the space for new explorations.

The project code is still available and could be used as base for further explorations in future. Team satisfaction is always a hot topic and we look forward to seeing what the future holds.

But for now: Our hands will not be free unless we let go of other things :)