The malicious behavior of non-constraints
Modern managers understand and execute the Theory of Constraints (TOC) to an extent where they can structure and balance their agile company portfolio against the capacity of the company’s constraint (bottleneck). This leads to slack time and lower resource allocation on non-constraints and to some strange feelings and behaviors of people working in non-constraint areas. In this article, I want to take a closer look on the feelings and behaviors of those people. Why? Because I truly believe that management needs to take these feelings and behaviors into consideration in addition to managing the constraint. Because if they don’t, people are going to abuse the TOC management framework until the organization is neither efficient nor effective any more.
Management’s top priority: Manage the constraint
The basic idea on which this article is based is the Theory of Constraints (TOC) which has been described in depth by Wolfgang Mewes in the 1960s and Eliyahu M. Goldratt in the 1980s. The TOC in short describes a management framework that helps to effectively and efficiently manage organizations. The core assumption behind the TOC is that the throughput of every process and every flow of work in every organization is limited by at least one step in the flow of work. If management wants to increase the overall throughput of this flow of work, it should identify the constraint and increase the throughput of this constraint.
This sounds trivial, right? It is. It is quite easy to understand and very hard to master. This article shows you just one – from my perspective insufficiently covered – reason why in practical application this is so hard to master.
I won’t dive deep into the theoretical foundation of the Theory of Constraints. I only want to describe the five basic steps of the management framework TOC by Eliyahu M. Goldratt:
- Identify the system’s constraints
- Decide how to exploit the system’s constraints
- Subordinate everything else to the above decision
- Elevate the system’s constraints
- If in the previous step a constraint is broken, go back to step 1, but do not allow inertia to cause a system constraint
Consequences of this management priority
As an ultimate consequence of the TOC, management has to deal with the constraint and with nothing else. By doing so, overall (economic) performance of the organization will be improved constantly. On the other hand, this means that non-constraints in an organization don’t receive management’s attention. Non-constraints also receive very limited funds – only as much as needed to not become a bottleneck itself. The underlying assumption is that these funds very likely will be wasted since they don’t increase the overall system’s throughput. It also means that non-constraints always have some capacity left since the overall throughput of the flow of work is only limited by the constraint. You can call this idle time if you want.
By following the TOC management principles, you cannot and you do not want to avoid this idle time. In contrast, you need idle time. Think it in terms of protective capacity: Whoever has some capacity left can adapt quickly to fluctuating demand. You can use idle time to work e.g. on small initiatives that don’t require the constraint’s capacity.
The feelings and behaviors of people at a non-constraint workplace
I have, as far as I know, never worked in a constraint workplace. Some years ago, I worked as head of a service department for information logistic services. The core task of this department was to ship invoices to clients of all European subsidiaries of this company. It also included scanning incoming documents for the same subsidiaries. The department was crucial for the company since almost all invoices were sent out by this department. The liquidity of the company depended on our work. Nevertheless, it was a non-constraint workplace. Back then I wasn’t aware of the TOC. I wasn’t able to accept that our department was by far not the most important part of the system. I was just a young and highly ambitious department head who wanted to prove his worth.
The top executives didn’t allocate the budget I wanted for all my fancy improvement projects and that upset me. They didn’t tell me why I could not get all the resources I requested. Above all, IT resources were reduced to a minimum. Without knowing it precisely I am almost sure that the IT’s capability to deliver software for supporting the organization’s delivery processes had been the constraint back then.
Since I didn’t understand why this made perfect sense from an overall organization’s perspective, I was quite dissatisfied and to some extent bored with my routine work, that lacked fancy projects and offered no possibility for bringing shiny new service ideas to life. So, I started to actively hack the system. I activated my network across the company, especially in the IT department, and started submarine projects to improve processes within my department. Without knowing it, I caused my peers in all the different departments to start multitasking. I consumed valuable resources that were needed elsewhere. My hacks were damaging the company without me realizing it.
I was bold enough to ask for performance bonuses when I had finished the submarine project against all odds and with almost no official funding by top executives – and I received them. I felt like I was achieving something. The department added services and increased capacity due to improvements. Instead of bringing the whole organization more money, it only increased the overall idle time of this department. But by starting more submarine projects, I unwittingly disguised the fact that my department, my team and I had been idle a good amount of time because my team was heavily involved in those submarine projects.
Now I know that this was local optimization. I understand that this was problematic. But it felt so right.
Interestingly, I worked overtime almost every day. I was pushing my team and other colleagues hard to achieve arbitrary deadlines because I desperately wanted to achieve something. Having slack time felt wrong. Or to rephrase it: It didn’t come to my mind that slack time would have been better for me and the company than being busy all the time.
While we were doing the ship building flow simulation in a recent training workshop, one participant stated: „I just cannot sit around doing nothing. This cannot be right. I need to do something. This is not efficient at all.“ And the participant was right. Having parts of your system being idle is not perfectly efficient. And it doesn’t need to be. When systems (and organizations are systems) are built to achieve throughput, then getting things done is more important than efficiently using all the resources in the system. Getting things done means being effective, not being efficient. I don’t need every step in the flow of work to be fully utilized to increase overall throughput. On the contrary: (Over-)Utilization is harming the organization’s overall performance, creates waste and exhausts employees. True, “the winner is always the most efficient at being effective” (Thanks, Steve Tendon for that quote). This doesn’t mean that everybody must run at full speed all the time.
Why this seriously matters
Since working as a consultant, I’ve seen my own old behavior repeatedly in my clients’ organizations. I’ve seen multitasking as a result and the negative effect it has on people and organizations. I’ve seen managers who were hacking the system themselves to achieve some kind of local optimization. This is always bad! Seriously, this behavior must be avoided. The optimization of the system’s parts don’t result in an optimized system. The flow through the parts of the system needs to be optimized which often means that the interactions between the system’s parts need to be optimized.
Employees search for mastery, autonomy and purpose as Daniel Pink expresses it. They spend lots of their lifetime in their jobs. So, it is understandable that they seek for these three drivers in their jobs. Moreover, employees want attention and acknowledgement by peers and managers. If managers only manage constraints, this might lead to artificial constraints all over the company just to receive some management attention. If managers acknowledge people only when they are being busy, all the employees in an organization will ultimately become busy. You will always get what you measure. This busy business creates waste, decreases overall throughput, and burns out employees.
It’s the management at ‚the top‘ of the organization that is responsible for setting the organization’s agenda. First, this means to find and manage the organization’s constraint. It’s easier said than done since everybody in the company is most likely busy all the time and thus working at full capacity. If everybody is busy all the time you can hardly see the systems bottleneck. So, management needs to reduce the overall work in progress (WIP) to a point where multitasking is (almost) avoided. This can be achieved by making the current work in progress visible (e.g. with task boards). Soon they are going to find the constraint of the organization. Most likely this will be the one part of the system that remains fully utilized even if the workload of the whole system is reduced dramatically. Of course, management then should follow steps two to five of the list above.
But that is not enough, unfortunately.
The whole organization needs to know where the constraint is. To be clear: Being the constraint is nothing bad because there will always be one. It is nobody’s fault to be the constraint. So, don’t blame anybody. It’s the process, the policies or the system design that creates the constraint. When the whole organization understands where the constraint is and how this constraint can be elevated, then it is the management’s obligation to avoid useless utilization for non-constraints.
This sounds obvious; however, I’ve seen it the other way round all too often to not mention it. Slack time has to be clearly allowed in the organization. Even jocular sentences like: „Oh, you are leaving already? Do you only work part time?“ create an environment in which employees might feel pushed to work harmfully and completely useless overtime. Management should lead by example and should acknowledge employees who use their slack time self-confidently.
Management then has to create a project (or initiative) portfolio for the overall organization in order to constantly balance the demand for change against the organization’s throughput and to avoid the reoccurrence of multitasking. This portfolio must be reworked constantly and needs to be communicated clearly within the whole organization. The underlying principles of portfolio decisions should be communicated as well. The organization’s health will increase significantly as soon as employees understand that this portfolio aims at increasing the value for the organization and at avoiding multitasking. 100% utilization is nothing to aim for.
The power of budget allocation
Management needs to allocate funds strictly and stick to its decision as long as it is needed. Funding is not meant to please people. It is all about effective resource allocation and the avoidance of multitasking. Whoever has no funds may not be allowed to use a team’s capacity. There is a role in Scrum that has the accountability to fend off those requests: the ScrumMaster. Consistent (management) behavior, that is visible in day-to-day decisions, will change the organization’s culture for the better over time.
From my personal experience, I can tell that working at a non-constraint workplace doesn’t feel right with a utilization mindset. This is especially true if the organizational culture seems to regard busyness as an indicator for performance. Employees seeking mastery, autonomy and purpose might hack your system in order to achieve their own (local) optimizations. This is natural and harmful at the same time. It’s the management’s challenge to behave in a way that allows a culture of adequate utilization to emerge. This prevents multitasking, frees employees’ schedules and increases the overall system’s throughput.