I am currently in Scotland visiting family and while driving around my childhood home, I noticed how grown up it all had become. Then I remembered – the person that was keeping the roads cut had died – enterprise stability in the countryside had been compromised (I wrote about Hugh in an older LI article and how he taught me to reverse tractor trailers).
Our big man was long gone, but his loss was still being felt by everyone on the local roads. We had all forgotten what he was doing, even though we benefited from it each day by being able to have a longer view down the road. He was making us safer without us even realizing it. Until he wasn’t.
There was a recent post on Reddit about someone who was fired, and it took a few weeks for management to realize they were the ones that were keeping the enterprise stable. They did it without complaint or fanfare. The thread was filled of such similar stories.
This happens a lot. Leadership works under an assumption that systems are stable and operational, forgetting, what it really takes to keep an enterprise running. It is never a release’n’forget and onto the next shiny thing.
It is something we look for during technical due diligence: who is that one person that knows how all the pieces fit together and what to do to keep things alive. Smaller organizations do not have the luxury of having multiple people covering for each other.
We have seen it in a deal that even when we do identify the “key-man” that there is little to no appetite to keep them engaged post transaction from the sellers. Sometimes its greed, more often than not, it is a complete lack of appreciation of what it takes.
Keeping an enterprise running, particularly a legacy one where little or no documentation exists, is a full time effort. Like the duck gliding smoothly across the water making it look effortless, masks the sheer amount of paddling/thrashing that goes under the surface.
CTOs can keep advising and communicating but sometimes making it look effortless can be counterproductive. Leadership starts to question budget, develops a hubris on the stability they enjoy, without due consideration on the real effort. Until it is too late.
This is a fault on both sides. CTOs are the first step here, and even though it is not sexy at the board level, constant reminders that cutting the grass doesn’t just magically happen. It can be repetitive particularly as you run towards new projects to hopefully make the old grass easier to cut.
Technical debt is something that is often misaligned to temporary code that needs to be replaced. While that is indeed one interpretation, another is the effort that is required for the parts of an enterprise to work together in a seamless manner. Imagine using a file folder to move files from one subsystem to another.
That is technical debt, as it needs to be maintained, ensure there is enough space available, both systems have the folder mounted, and is read-write (or read-only for one side). That all needs to be maintained continually, and it is usually this small stuff that slips through the documentation crack (if there is even documentation in the first place – not unusual for smaller teams). Legacy systems are full of such duct-tape and glue to keep things running.
When enterprise stability is compromised, it most always follows Occam’s razor principal – it is the piece with the least complexity that will have brought it down.
There is no magic formulae to make this all go away. No matter how good your new system is, be rest assured even the new grass will need constant tending.
So the question remains: who is cutting your grass?
Leave a Reply