Lesson Learned #40
Understanding true workload is one of the most common deficiencies we see in companies and organizations across industries.
It’s very hard for people to assess their own workload, perhaps particularly for people with strong mathematics backgrounds, such as engineers and accountants. A key point is that “true workload” is not a picture of how many hours you actually put in at work; it’s how many hours are actually required. We once tried asking some software engineers to assess their own workload. Without exception they came back with an answer of exactly 40 hours of work per week. The problem is that “true workload” is not a picture of how many hours you physically put in at work: it’s how many hours are actually required. No one works at 100%. Everyone has operating problems of some kind or another (missing information, rework, etc). World-class productivity is generally considered to be about 85%, which means in a 40- hour workweek you have about 34 hours of work. And that’s “world class.” Many people work at productivity levels closer to 60% which means their true workload would be only about 24 hours. It’s understandably hard for people to assess their own workload and come up with only 24 hours in a 40- hour week.
The reason, of course, is that people see workload analysis as an indictment of their work ethic. While understandable, this simply isn’t true. People can work very hard and still be only about 60% productive. But if you are genuinely trying to improve the performance of a function, it’s virtually impossible to do so without some kind of assessment of the work that needs to be done in order to achieve certain outcomes. If you intentionally, or unintentionally, inflate the current workload, all you’re really doing is hiding operating problems – exactly the things you are trying to uncover and eliminate.
One of the ways we’ve learned to assess workload is to depersonalize the analysis. You aren’t actually interested in an individual’s workload; you’re interested in the work requirements of an entire process. Also, sometimes understanding workload is less important than understanding the effectiveness of the process. For example, you could increase the productivity of a salesperson by requiring them to go to more meetings, but it wouldn’t be useful if the meetings were with the wrong type of company.
No one likes their workload being assessed, but to improve performance it is, unfortunately, a critical step.
