My Intro to T.O.C

As an Engineering Manager and senior member of an IT team within a large company, I’m constantly looking for ways to educate myself, my team and provide efficiency for my company. I’ve previously recommended The Phoenix Project as a book that anyone who visits my blog should go away and dive into; it has so much to offer in terms of opening doors to other interesting topics while being a very easy read.

My Desk

The Theory of Constraints is the single biggest mind blowing paradigm I have come across through the Phoenix Project.

Not only does TOC change the way you see your department, but it also gives almost anyone the starting point were they can begin to insert change into systems and see benefits almost immediately by combining TOC and Agile practises real change can begin. In this post I will try to introduce the topic, but also link to other items which will most definitely describe it a lot better than I am doing.

TOC is a management idea that came from a book called The Goal by Eliyahu Goldratt, which is basically about how a company or organisation can achieve its goals consistently. In the Phoenix Project, this philosophy is used to highlight how a failing IT system can improve its overall throughput by identifying items which are “bottlenecking” that failing system.

The main premise of the theory is that a system can be measured by three things; investment, operating costs and throughout.

Say for example I run an entire IT department (development & infrastructure);

  • Investment – items which I have already paid for up front (Servers, PCs, Monitors, Colleagues and software etc)
  • Operating Costs – heating, insurance, water, food… as well as any other things which are fluxing to make the system run
  • Throughput – how the system is measured… support tickets or development stories or something else

The Goal, as mentioned earlier, is to try and decrease the investment and operational costs while increasing throughput (after reading The Phoenix Project, the Goal would be my next recommendation).

All systems have bottlenecks; if they did not then the throughput of that system would be infinite, which is obviously not possible in anything that exists in the real world. Now this doesn’t mean that systems have hundreds of bottlenecks, there are generally only a few. However the real clincher to the theory is that to increase the output of your entire system; only working on the bottleneck will reap any rewards.

Increasing the flow of anything outside the bottleneck is a mirage…

Now to be honest, the above statement was the one that first confused me and then sent me into a spin. Surely if I have a massive IT department, and I improve it anywhere… it’s an improvement? However taking the above into consideration, a systems throughput is only at the limit of it’s bottleneck, therefore why bother doing anything else other than working the bottleneck first because it actually won’t increase the system.

So how do you find these constraints and what do you do with them? Good question.

A constraint is anything that prevents the system from achieving its goal or required throughput. For example, the recent constraint we exploited at work was our new starters process, which was very manual to get the job done.

Colleagues had to check for tickets, send emails and then hand over to another part of the system where SQL was used to create accounts and then it was passed somewhere else. That entire piece was automated via another member of the team by taking them off apiece of work to fix this part of the system.

Why move resource to fix your bottleneck? You do that because by subordinating other members of the team to help elevate the constraint, you are not actually affecting the throughput of your system by moving resource… because your throughput is that of the bottleneck!

Other types of bottlenecks from the TOC wiki page;

Types of (internal) constraints

Equipment: The way equipment is currently used limits the ability of the system to produce more salable goods/services.
People: Lack of skilled people limits the system. Mental models held by people can cause behaviour that becomes a constraint.
Policy: A written or unwritten policy prevents the system from making more.

So I feel that’s probably enough for this post… my goal was to try and introduce the topic to anyone who may not have heard about it before.

Here is also a video that describes it so much better than I probably just did also;

Surviving Your Inevitable Agile Transition - J.B. Rainsberger - YouTube