When Anyone Can Ask, No One Is Accountable

When an organization faces a problem, the most natural answer often sounds the same: let's build something. It's fast, it's tailor-made, it feels under control. Repeated for years without criteria, it stops being a solution and becomes a habit. In one of the organizations I worked in, the habit had become a system.

Anyone could ask

The business was authorized to ask for anything. Every function reasoned in silos — commercial processes, supply chain — each with its own urgency and its own counterpart in IT. IT had to keep up with all of them.

A demand management function existed, but mostly on paper. It sat inside HR, understood little about technology, and was the only team authorized to speak with the business — nobody could say by whom. In practice its job was to collect requests, not to challenge them. The business, for its part, rejected any demand management model and any validation of requirements. It wanted results, not filters.

If nothing is written down, someone is always to blame

The outcome was predictable. If the software didn't work, it was IT's fault. If the application didn't meet the requirements, IT's fault. If, once delivered, the business realized it didn't need it after all, IT's fault again. Nothing was written, nothing was documented. Requests came verbally, and nobody in the business validated them.

Who could prove IT had gotten it wrong? Nobody. It was IT that had to prove it hadn't — which is impossible. The whole thing worked almost like a royal court: what mattered was who had access to whom, who had said what, in which meeting.

A verbal request that was never validated is not a requirement. It's an opinion.

The coffee machine doesn't scale

If demand management comes down to three people at the coffee machine saying something, and that something automatically becoming true, you have a problem. It can work in a company of ten people. It does not work in a company of ten thousand. The issue is the scalability model.

Personal interaction, well-being and emotional intelligence matter. I've written before that leadership is not only a technical activity, and many good ideas do start over coffee. But an idea born at the coffee machine is the beginning of a path, not the whole path. We cannot turn our delivery processes into coffee-machine conversations.

Applications nobody decided to have

Year after year, the result was a sprawl of custom applications that nobody had ever decided to have. Each one came from a reasonable request at a specific moment. Together, they answered to no strategy at all. We weren't a software product company, and we had neither the discipline nor the organization of one. The applications aged, the libraries underneath them became obsolete, and the knowledge stayed in the heads of the people who had written them.

Every custom application is a promise of maintenance that someone will have to honor for years. Nobody writes it into the business case.

The saving that costs the most

It's very easy to keep OPEX low: bring in contractors on time and material and build everything in-house. On a spreadsheet, it works. But time and material buys hours of work, not responsibility for the outcome. Eventually the model stops scaling — and it stops being sustainable for the people too.

The gargantua

When anyone can ask, no one is accountable. What you end up with is a kind of gargantua: something unmanageable, grown by accumulation and never designed by anyone. And then there are the people who have to work the nights — back to fifty-eight people on a call, two of them actually solving the problem, while panic sets in, as I described in The CIO Who Still Needs the Java.

Then comes the hero who saves the day, and often it's the same person who created the problem, perhaps on a library that has since gone obsolete. The thanks are sincere and deserved. But we end up rewarding the heroism needed to resolve a complexity we helped create.

And "we're different" — a phrase I discuss in another article — is very comfortable here. You see a digital storefront with an attractive face, while behind it everything runs on CICS, or an AS400, or a search engine that is anything but agile because it can't be integrated, or only at enormous cost. The age of a technology is not the problem; plenty of old systems run beautifully. The problem is a facade that promises a speed the back end cannot deliver.

Software is never free

Software is never free, even when nobody put it in the budget. Before saying yes to a new request, a few questions are worth asking:

• What is the actual business problem we are solving?
• Do we already have a capability that covers it?
• Who asked for this requirement, and who in the business validated it?
• What will it cost to keep alive in five years?
• Who owns it?
• Who answers when it goes down at night?

Software is a tool. The abuse begins when it becomes the only answer.