To Be Flexible, Be Inflexible

Quick aside: I actually wrote this blog post, at least one by a similar title, 10 years ago. Going back and reading it, it didn’t quite hit the mark of what this idea has meant to me since, so I thought I would give it another go.

To lay a quick contextual foundation here, I’m really going to be talking about process. Systems get lumped in here too. But broken down, systems are made up of smaller processes. And I mean all processes; from computer code to project management processes to baking a cake.

Building flexibility into any process can be incredibly valuable and important when needing to control the capabilities of the outcomes of that process. And in most cases that flexibility is tactically implemented as variable input.

But flexibility comes at the cost of added complexity. Maybe in software there is a much higher tolerance for allowing systems to be very flexible; especially when the complexity is handled entirely by the computer. However, when that complexity involves people, it quickly acts against the ease and efficiency of executing the process.

So here’s the pay-off point: to pursue adding flexibility to any given process, you should also explicitly define what is inflexible; nail down the parts that don’t add as much value by making them variable. Shrink the change and limit the complexity. Doing so will lead to much more balanced, manageable processes, where more focused thoughtfulness can go into the few variable inputs required. This will ultimately generate higher-quality, specialized outcomes without putting undue stress on your operations.