Reversing the disablement cycle
Gregor Hohpe
Retired from big tech. Not retired from riding the Architect Elevator to make IT and architecture a better place. Have opinions on EA, platforms, integration, cloud, serverless.
When setting to out to change an organization, you will find that existing processes and ways of doing things are not just habitual, but actually self-reinforcing. To some extent, this is to be expected: organizational structures and processes that have existed for a long time must be stable against disturbance. Generally that's a good thing - who would want to work in a place where processes change every other day? However, when you are looking to change such a system, most likely because the environment necessitates a different way of working, a self-reinforcing system can put up an unexpectedly strong resistance.
The Disablement Cycle
One example of a self-reinforcing system is what we call the Disablement Cycle, a pattern commonly found in environments that feature a lot of approval processes. Such environments carry a lot of friction, meaning that getting anything done takes a lot of effort and thus costs more money. This, in turn, means that projects become more expensive. The natural reaction to more money being at stake is to add more controls. Doing so, however, adds even more friction, feeding the disablement cycle. Organizations that are subjected to this cycle are commonly referred to as those "where it's impossible to get anything done."
Everyone is doing the right thing
One of the reason that this cycle is so widespread, and so difficult to break, is that each involved party is doing the right and logical thing - within their context:
- If a project asks for a lot of money, it's logical to add additional checks and controls to reduce the risk to the organization. Who'd want to approve a $1 Mio project without any oversight?
- If the overhead for projects due to friction is high, it's more efficient to make bigger projects. If all approvals, reviews, and the associated preparation for a project amount to $100k, it makes little sense to start a $100k project because the "tax" due to process friction would be 100% on top of the project cost. If you bundle all your ideas into a single project for $1 Mio you only pay a 10% "tax". So it's the right thing to do - you are actually saving the company money.
Stopping the vicious cycle
Because each party is doing the right thing, you can't just tell people: "can't you see that you are doing it wrong?" Because they aren't doing anything wrong within their scope of work. There isn't an easy recipe to break this cycle, but two factors can help:
- External pressure generally helps people question existing ways of working, but when such pressure builds up it may already be too late.
- Establishing a broader end-to-end view and set of responsibilities can help. Once people see (and are rewarded for) end-to-end results, they will stop optimizing for their local portion of the cycle and start optimizing for overall success.
The Enablement Cycle
The amazing thing is that once the disablement cycle is stopped, the positive Enablement Cycle also becomes self-supporting: if overhead is low, its easy to get a project started, meaning project costs are also lower. Hence, fewer controls are needed. Abandoning controls in turn reduces friction, which incentivizes people to start smaller projects. Over time, the organization can run small projects quite efficiently and without much risk to the organization.
This means that while stopping the disablement cycle is quite tough, you only need to get things slightly spinning in the right direction because once you get to that point, the cycle becomes self-supporting again, but in the right direction.
Credits
Thanks to Jean-Francois Landreau for first sharing this insight with me.
Don't miss a post!
If you like what you read, please share with your network and follow me on LinkedIn or Twitter. You can also find more thoughts and anecdotes from the trenches of IT Transformation in my book:
- DRM-free e-Book (Kindle, iPad, Android, PDF): architectelevator.com
- Print-on demand via Amazon US, Amazon UK, Amazon Europe
??Cloud, DevSecOps, Platform & DevEx leader,??????, 20+y Agilist??♂?, 12x AWS Certified??, 3x K8S Certified??, Books Contributor??, 15+y as green as possible
6 年Some of the other anti-patterns observed around the disablement cycle are: 1- Over-specialization making it very difficult to progress quickly on anything because you need to involve that many different experts, sometime not able to understand each other. The person able to liaise the experts becomes a super-hero with as high risk of burn-out. 2- Projects over products and the impact it has on technical debt. People are incentivised to finish at dates and tend to accumulate technical debt as they don't have to pay it when the project is finished. After a few projects on the same assets you stand still for a long period of time because of the technical debt. If the assets are treated as products, you limit this risk. 3- Ignorance of the non functional requirements. People running projects often have ignorance of the production. Once a nice demo is done, their job is done even if the demo can only support one user at a time instead of the xx number of users expected on production. The projects stand still for a while once the demo has been done.
Lead developer, IT Architect at Ritense
6 年Great post. It made me realise that I worked at a place where both cycles were in place. Projects above a certain amount triggered the controls which made it a slow and cumbersome route. Most of the projects were actually chopped up in small steps to fly below the radar. This was so successful, that the majority of the projects followed this route.?
The point about project costs also applies to code change cycles. If it's difficult to make a change, then people try to batch up lots of changes so that the average cost per change unit decreases.? However that requires more process because there's so much in a single change-set.? So that then makes changes harder so people increase the batch size again.? The words "batch size" point to this being a problem where we can apply the Lean principle of reducing batch size as far as possible, preferably to a single item, and that's exactly what the Enablement Cycle is doing.
Securing your Cloud Journey
6 年Thanks Gregor! Do you have a recommendation to further dive into organizational anti-patterns?
Transforming business ideas into working software
6 年Absolutely true. Have experienced this in all corporate environments I've been involved with. Usually one of the main reasons to leave.