One of the major mysteries in corporate life is this. In spite of all the experience and managerial talent thrown at knowledge work, why does it still function so badly? Why, with all the dysfunctions staring us straight in the face every day, are they so hard to fix? And why, in spite of the enormous efforts poured into improvement initiatives… don’t they ever seem to actually improve anything?
The answer to this riddle is not a secret – but it hasn’t traversed in a big way from the world of physical manufacturing to knowledge work yet. Here is what the desk tigers urgently need to learn from the grease monkeys…
Our mental models of work are shaped by physical manufacturing. If during our education we get to hear examples, e.g. in an economics or finance course, it typically involves a production plant making widgets. Work progresses conveyor-belt style through a fixed series of standardized steps. We don’t really have a different mental model for knowledge work, although knowledge work is different in every imaginable way. For starters, the product that is produced may be different for every “production run” (think about the report prepared by a financial analyst) or not even pre-defined in terms of what a successful outcome looks like (think creatives at an ad agency coming up with a campaign). The work process may not consist of a fixed series of steps (think a sales team participating in a competitive complex bid) and the steps may not be standardized (think lawyers negotiating a contract or legal settlement).
Because there is no obvious mental model for knowledge work, we miss a frame of reference to assess if things are going as well as they can reasonably be expected to, and where and how to intervene if something is off. [With the possible exception of Software Engineering, a field which is a little further along in understanding how to effectively organize, diagnose problems and remedy them.] Most companies have a rough idea of the kind of tasks that need to get done, and creates teams for each set of task. Those teams then organize around a high level process, with work moving along with a lot of back and forth communication to coordinate, info-share and problem solve. Within the teams, members who seem to do a good job and have gained some experience are bubbled up as team leaders. But team leaders are rarely trained in how to organize knowledge work, and most have nothing better than manufacturing as their mental model. These leaders mean well but run the wrong Operating System.
To illustrate how quickly that can lead to trouble, we need to look no further than a common practice encouraged in good companies with reasonably empowered teams: investing a sliver of team time in “continuous improvement”. That seems benign: we see something in our team we can do better, and we improve it. How could that possibly be bad? Let’s consider a simply 3 step knowledge work process, represented by 3 teams A, B and C each adding some value to a product.
Imagine you are the Finance person responsible for team A, and they come to you with an improvement proposal. They currently produce at a rate represented by one red brick. But you have encouraged them to become more efficient and productive, and they found a way to double their productivity to 2 red bricks per day. You ask them how big the investment is they need, but it gets better: they say it takes a few changes in their way of working that they are happy to take care of after working hours. Let’s say each team costs 10 money units per day, so obviously you are delighted! Production used to cost 10 per red brick, and now the cost will only be 5 per red brick. You are asked to approve this initiative, but it looks like a no brainer, right? What’s not to like – greatest continuous improvement initiative ever! You thank the team for their great initiative, and approve the recommended improvement project. But then in the next couple of days, this is what happens…
By the end of the week, you are a little confused… Team A totally delivered on their improvement initiative and produce 2 red bricks per day. On the first day, Team B nicely processes the red brick of the previous day, but on the second day they end up with a spare red brick. Likewise on day 3 and 4, they get more red bricks than they can process, and this intermediate work is beginning to pile up at Team B. Team C still continues to see the same red+yellow intermediate come through at a pace of one per day, and completes the work for customer delivery by adding their black brick.
This simple example already begs a couple of questions. If the pace of finished product and value delivery to the customer hasn’t changed, is this really an improvement? Actually if this hadn’t been knowledge work, and the red bricks had symbolized the manufacturing of actual physical intermediate products, it wouldn’t take too long for Finance to get upset about the excess inventory that’s being produced, and the working capital it consumes. But why would we be less upset about such overproduction happening just because it’s knowledge work? Is the inventory build-up any less wasted than for manufacturing, just because we can’t see it? And isn’t that, in fact, the problem – that we can’t see it. And if this kind of waste is already difficult to detect in a knowledge work simulation as simple as this one, do we dare imagine how much is currently going to waste in the far more complicated knowledge work processes in our real world…?
”
The most dangerous kind of waste is the waste we don’t recognize.
”
–Shigeo Shingo, a key figure in the Toyota Production System
As bleak as that picture is, it gets worse.
Let’s do another thought experiment. Imagine somebody is asked to step into an organization they don’t know, with complicated workflows and invisible intermediary deliverables and artefacts. Maybe they’re a new manager or invited as an advisor. Imagine they “arrive at the scene” cold in our little Lego workflow. What will their observation probably be? “There’s a problem with Team B. They cannot handle their workload. Their productivity problem is holding everything up.”
The observation that Team B cannot handle its workload is correct. But the diagnosis that they have a productivity problem is not correct. Remember that everything was fine with Team B before Team A made their local improvement. They didn’t change anything, they do exactly the same things they did before. Nevertheless for most observers, Team B will be held responsible for the situation. Our newly arrived imaginary advisor is not very likely to view this as a systems issue – although it is!
And nothing is so bad that a well meaning manager can’t make it even worse…!
Managers won’t stop at the (incorrect) observation that Team B has a problem. They’ll take action to do something about it. Most likely they’ll start spending time with the team to work on their “productivity problem”, asking them to prepare reports and participate in frequent management reviews. Mind you that this alone will consume time which will distract Team B from their actual productive work. Management may also run workshops to come up with… improvement ideas. Not system-wide improvement ideas, mind you. Improvement ideas at the local level of Team B only. It is entirely possible the manager asks for and receives investment budget, to improve the productivity of Team B. Take another look at our workflow: what will happen if Team B successfully manages to increase their production capacity to placing two yellow bricks per day? How much more will be shipped to the customer every day?
This phenomenon is well known and studied in the world of physical manufacturing. It is called the “Constraint” of the production flow, and this field has been brilliant pioneered and developed by Eliyahu Goldratt. The simple observation is that any given production flow, no matter how simple or complicated, cannot produce faster than its slowest part. In manufacturing, studying and addressing constraints is easier than for knowledge work. The production flows are stabler and more predictable than knowledge work, and bottleneck issues are literally visualized by work-in-progress inventory piling up in front of the slowest workstation in the chain.
Identifying and fixing problems in knowledge work is much harder, and still in its infancy as a managerial field. But step 1 in this long journey is awareness of this phenomenon, and step 2 asking the right question when stumbling upon a constrained team. Which almost nobody does As simple as these concepts are, in most knowledge work organizations the true nature of productivity limitations is hiding in plain sight.
Hiding in plain sight
Credits
Words
> Stefan Verstraeten
Ideas
> This entire article is an illustration of the Constraint concept, introduced by Eliyahu Goldratt in “The Goal” and other works
Photos
> Main page: Panopticon from the game “Control”
> Workflow Lego imagery produced by OpenAI’s Sora
> Lego manager: “Lego Office Manager Janice Swinebrick” from https://tmcfd.com/product/lego-office-manager-janice-swinebrick-minifig-with-pen-and-clipboard/
> Lego red bricks heap retrieved from amazon.com
Video
> The video of a snow leopard hiding in plain sight is adapted from https://www.youtube.com/shorts/EkpfkahguNw @spitiunited5471
> Charlie Chaplin in “Modern Times”
Ideas
0> Seems like there’s other people using Lego to illustrate workflow concepts… Introduction: How knowledge work differs from physical manufacturing
