In a previous post I discussed the need to give a quantified, tangible form to the flows of work in order to understand what people really do, which is a prerequisite if we want to help them work better.
This was impossible a few years ago, but today we have a lot of data and mechanisms to understand what is going on and what is not, and many tools provide them to the employee himself, to his manager, to HR…
But none of them being perfect or exhaustive, this is the opportunity to take stock of the needs.
What do we want to measure?
The idea, as I said, is to measure flows of work, or in other words, flows and stocks of information, in order to understand how work is done and the possible friction points. I insist on measuring work, not people.
I want to make this clear because it is easy and dangerous to switch from one to the other. So-and-so doesn’t respond quickly to emails, doesn’t attend all or too many meetings, so we have a problem with So-and-so. Too easy and too fast conclusion. And yet Microsoft had not been far from bringing the wolf into the fold.
Because most of the time the problem is not so-and-so but the way we work collectively. So-and-so is a symptom, not the problem. Let’s not forget that in business 94% of the problems come from the system, not from individuals.
At what level to measure
At the individual or collective level? Given my previous remark, you will understand that this question makes sense.
However, I would say both: at the macro level to understand the system, at the individual level to identify the places where it makes the organization dysfunctional.
And then because generic numbers can be meaningless. An average employee receives 50 emails a day. Fair enough. But the reality is that some receive 20 and others 150 and that’s what interests us. And to understand why, you need to know who.
To whom the data should be provided?
To the employee himself to start with. But on two conditions: that he understands what they mean, how to use them to improve things at his level, who to contact to get help and who has access to them.
Indeed, when you see the amount of information that can be obtained on a person’s activity, he can legitimately wonder what interpretation his manager would make of it.
It is precisely for this reason that I think that initially the manager should only have the aggregate data of his team (x emails per day, x hours of meetings etc.). This will allow him (or not) to identify global points of vigilance without giving him the means to stigmatize certain people and to make a mistake.
Then, when they are trained and have more maturity, they can be given a finer view, but I find it difficult to trust them spontaneously on the subject or, rather, to trust the system that pushes them to look at performance only from the point of view of the individual.
Finally, all the data must be accessible to the people in charge of managing the improvement project.
What data do we need?
Here I will be half practical and half theoretical.
Practical because there are obvious, existing things that are not open to discussion.
Theoretical because I will assume that everyone uses the tools at their disposal and uses them well. I’m also going to assume that we have access to secondary data from a large number of applications. And we know that in most cases both of these assumptions are false.
Number of emails received, number of attachments or shared documents.
Number of emails for which you are the only recipient, for which you are a main recipient, for which you are a copy.
Number of invitations received.
Number of “spontaneous” meetings (you are contacted by video or audio without a meeting having been scheduled).
Number of messages (chat) received. Individual or collective.
Number of tasks assigned to the person. By him or by others. In the different tools used for this in the business
Processing of flows
Number of emails read, answered (and therefore those that are not read or are read without giving rise to an action).
Number of tasks completed (and therefore remaining)
Number of received documents read and/or edited. (and therefore those that are not processed).
Participation in the business’ social network: messages posted, read, commented.
The same as incoming flows but when the person is the sender.
Nothing more than network discovery but it is about discovering the work flows in the business, which are the preferential and usual circuits, the “exceptional” circuits (when the person has a problem?) if they are individual or mass exchanges (many people copied or participants to a discussion etc.)
There are two paths to explore.
The first one is about performance – I don’t need to explain to you that the objective is to detect all the places where the organization does not work smoothly. It is one thing for something to get stuck in one place, but it is another to understand why. Slow decisions? Lack of information to move forward? Too much work for one person or a team? Tendency of some to pass the monkey? Acute meeting fatigue? Lack of personnel?
Today, these are things that we perceive and report on, but that we do not know how to quantify or objectify, and above all, that we never treat in a systemic way, only at the individual level. So we might as well say that we don’t treat anything.
And since when we talk about workload, we are never far from mental load, this is also an opportunity to identify people who are subject to too much informational pressure, and therefore to too much implicit pressure.
The main problem in the so-called knowledge-based professions is that we only see problems (quality, meeting deadlines) when they happen, and for good reason: we can’t tell what people do or how they work.
Do they lack information? Are they penalized by slow decisions? Do overloaded people slow down the whole team? Do the right people have the right information? Is too much time wasted in meetings or processing unnecessary information? Is the information and mental load bearable?
So many things that we can quantify (or almost) today but that we don’t really do and even less to have a systemic answer to work organization problems.