Most CTOs are aware of the concept of bottlenecks or constraints. It sounds great on paper and I often encounter it in a technical setting. Too often, though, I’ve worked on projects where it didn’t seem to be considered when making strategic decisions. When to hire, when to invest in migration, which improvement project should be prioritised.
A quick refresher on what I’m talking about:
A chain is only as strong as its weakest link which is its ‘constraint’ or ‘bottleneck’. Improving anything other than the weakest link will not make the chain stronger, therefore if you want to improve the chain the first step is to find the weakest link.
Why doesn’t it seem that many people are using this framework strategically? It’s not because I worked in teams where no one else had heard of it. That theory is described in popular, in fact best-selling books like The Phoenix Project and The Goal. Nor was that theory disregarded because it’s a nice idea that doesn’t work in reality. Billion-dollar businesses have used it to improve their manufacturing practices—and with amazing results.
I don’t think it’s because it takes too much investment either. After joining The Scale Factory, I spent a few hours of downtime thinking about it and had two conversations with colleagues. From that reflection and discussion, I think I have a reasonable understanding of what actions will and won’t affect our own bottom line.
So is everyone basing decisions on constraints and just not telling me? I’m not so sure.
Linking constraints to priorities
There are 5 steps to improving a system using the theory of constraints:
1: Find the bottleneck
2: Reduce any waste associated with the bottleneck
3: Don’t start work until you know the bottleneck has time to finish it
4: Invest in the bottleneck
5: Start again; make sure you haven’t made a new bottleneck
In a software team the bottleneck is often a person. I’ve certainly felt like it was me before. In the ‘The Phoenix Project’ the bottleneck is called Brent. After realising this his managers forbade anyone from giving him new tasks without them being triaged. Only high priority work that only he could do was allowed. Long, low value meetings were definitely banned. This is a classic intervention at step 2 but I have never experienced anyone’s time being protected like this.
Step 3 means only starting work that bottleneck has time to work on. Since the bottleneck is the slowest part of the system this means that faster parts are going to have to intentionally slow down or carefully consider which tasks need the bottleneck and which don’t. Again, this isn’t something I’ve ever seen happen.
Of course, every company has tried step 4. Pay to win. Invest in more staff, or more hardware, or a migration to something shinier. These investments are constantly being approved but how many are affecting the weakest link?
I can’t speak for the whole industry but in my experience it is far more common to invest money in new capacity rather than understanding where your capacity is currently constrained and how to get the most from it.
Best practice prioritization
The worry I have is that ‘best practice’ (or its good friends ‘industry standard’ and ‘production grade’) drives decisions more than actual bottlenecks.
Often enough I hear about improvement initiatives justified with those terms and little else. Within an IT consultancy setting, we hear our customers ask for nothing more than that: ‘We would like you to make our infrastructure more production ready.’
Here’s the issue: Everything could be more ‘production ready’ so this can justify improving any part of your business, often to an arbitrarily high standard. Ultimately, there are so many improvements you can invest effort and money into.
If you can afford to apply best practice across the board then you will end up improving your bottleneck. Even then it will be inefficient. If you don’t have that luxury, there’s only one improvement to pick: the one that holds you back the most.
Quick fixes
Imagine a small team where 1 person’s time is the bottleneck. Here some low or no cost policy changes you can make:
- When they have code to review, their PRs are reviewed immediately. You could even formally assign another team member each day who’ll stop work and help out.
- The bottleneck is allowed to stop and reschedule any jobs that are ahead of theirs in the CI system’s queue (you could also reserve resources for the bottleneck team).
- The bottleneck doesn’t have to attend company check-ins. They have 5 minute chat with a colleague instead, who goes to the meeting as their proxy.
- Work can only be escalated to the bottleneck by a manager. No more disruptive Slack messages asking for a favour and no more prioritisations based on who is shouting the loudest.
You couldn’t run your whole team like this but you don’t have to. There’s just one team where this needs to apply: the team where the constraint lives. Nor does it have to be carved in stone. When the constraint shifts, find the team where the constraint has moved to and help them instead.
Imagine if these changes let you double the amount of high-value output from that team. Since your company is only as strong as its weakest link you have just doubled the strength of your company, and probably without buying anything or hiring anyone.
Next steps
You know what I’m going to say, right? Find out where your bottleneck is!
Once you think you know your bottleneck try making some policy changes around it. If you were right, you should notice a big difference. If not, you can reverse them. Before approving any improvement initiative, ask yourself ‘Is this going to help my bottleneck be more productive?’ If you don’t think it will then there’s a risk it won’t make the company more productive either.
There is plenty of material out there; even if a lot of it is written in manufacturing terms, it’s still valid. In fact for me, working in IT, it’s sometimes humbling to see how people who work in manufacturing look at constraints and work to address them.
Did this article give you an idea of where to focus improvements? I hope it made sense and maybe offered some pointers on where to look.
We’ve been an AWS SaaS Services Competency Partner since 2020. If you’re building SaaS on AWS, why not book a free health check to find out what the SaaS SI Partner of the Year can do for you?
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
