Three states of an IT landscape, and only one gets attention
When an executive team talks about its IT, it mostly talks about whatever has just failed. That is understandable. A failure has a sender, a timestamp and a price tag. Things that work have none of those.
I distinguish three states that any part of an IT landscape can be in. The first is stable and explainable: it runs, someone can say why, there is a named deputy, the maintenance contract fits how the system is used today. That is the state you want everywhere, and it rightly needs little attention. The second state looks identical from the outside but is a different thing: it runs because workarounds, individual people or a contract nobody has looked at in years are holding it up. The third is visible failure: escalations, missed service commitments, complaints from the business.
Attention and budget almost always go to the third state. The second gets little, because in the reports it is indistinguishable from the first. Some of it turns into an outage eventually, at a moment nobody chose. Some of it keeps running for years. What separates the two cases is whether the organization knows about the dependency and has decided to live with it.
Attention follows visible failure. Part of the risk sits in what is still running.
How to recognize the second state
A simplified example: a business application that has not had an incident in years and appears in no status report. It is maintained by one person whose deputy nobody can name. The maintenance contract renews automatically, and nobody has checked whether the response times and the scope still match what the application carries today. It is not on the project list, because nothing is planned for it. By the usual metrics it is one of the healthiest parts of the IT estate.
The metrics are not wrong. They measure failures, and this part does not fail. What is missing is a second view: what keeps it running, and whether the organization can rely on that.
What executives can do
They can put a second question next to the usual one. The usual one is: what failed? The second one is: what runs here only because someone is holding it up? The answer is in no report, but the IT lead usually knows it off the top of their head. Often nobody has asked, because the question does not fit the report format.
The answer leads to a decision: resolve the dependency, or carry it knowingly, with a deputy, a reviewed contract and a date to look again. Both are defensible; some dependencies are not worth the effort it would take to resolve them. Not knowing is the hard one to defend.
A question for your next status meeting
Ask for one system that has had no incident in a year, and for the name of the person who would take it over if today's owner were out for six weeks. The time it takes to get an answer is a usable indication of which of the three states the system is in.
Which part of your IT is getting attention right now, and which part needs it?
Mathies Wähner · Interim Lead · IT Governance & Program Stabilization. New notes appear on LinkedIn first. Follow there →