Digital Was Never the Problem

 

Why aging organizations fail at technology, and why it is almost never the technology

Fifth in a weekly series on how institutions fail and how they come back.

Twenty-five years ago I helped install a working system inside a factory that died anyway. Nine years ago I ran a training with no strategic purpose whatsoever, and it turned out to be the thing that carried an organization through a digitization it never asked for. The difference between those two stories has nothing to do with software.

The question

There were diapers on the desk. Four or five brands, cut open, laid out across the table so the layers could be compared. Somebody in that room had been doing real product analysis, the unglamorous kind, with a blade and a ruler.

I was there because the invoicing had just been automated. A software firm I had brought in a few weeks earlier had installed a stock and sales system, and for the first time in the history of that company the sales invoices came out of a machine instead of out of a person.

The room was full. The company accountant, a man in his late sixties. A member of the owning family, himself somewhere near sixty. Somebody from marketing whom I never met again. And the question came from the ownership side of the table, in the plain and reasonable tone people use when they think they are asking about efficiency.

Now that the computers are in and the invoices come out by themselves, does that mean we need fewer people in that department?

I was twenty-one. I did not answer. I did not have anything to answer with.

It took me most of my working life to understand what I had watched in that room. Not incompetence. Not backwardness. Those were capable people who took their market seriously enough to dissect their competitors' products on a Tuesday afternoon. And the first question they asked of a new system was a headcount question.

That is the whole subject of this piece.

Six hectares of legacy

The first time I went to the site, I went with the owner of the audit firm I worked for. He told me nothing on the way. Not why we were going, not what my role was, not what he wanted from me. That was how he worked, and at twenty-one I read it as normal.

The complex was the largest producer of tissue and paper products in the country at the time. Roughly six hectares, several buildings, a business old enough that the buildings themselves were the legacy. My mandate from the firm was to produce a diagnosis, and later to sit as third party auditor.

We walked in through the operations offices, where the sales invoices were produced, continuously, on an old dot matrix system. Five people worked there. The youngest was a woman in her mid-forties who already handled the old system well and was openly looking forward to the new one. The rest were past fifty and they were frightened.

I want to be careful here, because memory flatters a narrative. I remember that whole building as old, and I remember the staff as old, and I am not certain the second impression was not borrowed from the first. The tile was from another century. The walls were a dark, gloomy grey. The desks were old, the chairs were old, and the rooms had that specific smell of paper and dust and decades. I was twenty-one and everything past forty looked like the end of something.

The production floors were different. Those were serious. High ceilings, machinery that ran jumbo rolls holding hundreds of metres of product, and one line where molten raw material was scooped by hand with a delicacy and a calculation you cannot fake. The people on those floors knew exactly what they were doing. They were craftsmen. They also knew the place that fed their families was declining, and you could hear it in how they talked about the top of the house. There is a particular bitterness in someone who brings their best every single day into a building where the people above them are not doing the same.

My first contribution was automation. I brought in a software engineering firm that was doing pioneering work at the time, and they installed the stock and sales system and trained the staff on it.

Then I built the cost analysis. Product by product, across the range, essentially alone with some help from interns, one of whom is now my wife. It took months.

The numbers were correct

The study came back and it was correct.

I know it was correct because one person in that entire complex was able to confirm it. He was a younger member of the owning family, working inside the plant rather than above it. He was the only person on that site with a computer of his own. He already knew the costs roughly before I showed him anything. He read the analysis, confirmed the numbers, and accepted every recommendation in it.

Nothing happened.

The company was carrying heavy debt. The family was not aligned. And nobody at the top was prepared to take a business of that size, with that much history in it, and rebuild it.

I left the audit firm not long after and I did not follow up, which is a pattern I have written about elsewhere and am not proud of. Within a few years their products were gone from the shelves. I do not know the precise ending and I am not going to invent one.

What automation cannot buy

Here is what I need you to notice about that story.

The technology worked. The system was specified correctly, installed correctly, and the staff were trained on it. The invoices came out. The cost analysis was accurate and it was confirmed by the one person qualified to confirm it. Every technical element of that project succeeded.

The company died anyway.

Automation produces information. It cannot produce the willingness to act on information. Those are two different capabilities and organizations routinely buy the first while believing they have purchased the second.

And now go back to the question in the first room, because it explains the rest.

When ownership asks, out loud, in front of the people it concerns, whether a new system means fewer staff, it has taught the entire organization something. It has taught them that the system is a threat. Whatever resistance follows is not fear of technology. It is self-preservation, and it is rational, and if I had been one of the men past fifty in that invoicing office I would have resisted too.

Management then reads that resistance as evidence that the staff cannot learn, and concludes that the people are the problem.

The loop closes on itself. The tool gets blamed or the workforce gets blamed, and the actual decision, which was made in about four seconds by whoever asked that question, never gets examined at all.

Seven copies of one truth

Now the other story, and it is shorter, because it happened in one room.

In 2016 I was working in a very different sector, in an organization holding records for tens of thousands of patients across a national network of clinics and dispensaries. Everything was on paper. The system worked like this: a template arrived, and for every delivery order it was photocopied seven times, one copy for each section that needed it. Data entry. Field officers. Warehouse. And so on down the line.

Seven copies of one truth, living in seven different filing cabinets, ageing at seven different speeds.

That year I ran a training. We had a small learning centre with twelve desktops, a room I had helped set up and taught in myself as a certified instructor years earlier. I hired a friend and colleague to come in and teach basic digital skills. Word, Excel, PowerPoint. Nothing clever.

The staff were sceptical. They asked what it was for and whether it was useful.

I have to be honest about my answer, because the honest version is the whole point. I had no plan to digitize anything. There was no strategy behind that training. I simply believed that people who work in an organization in 2016 should be able to use a computer, and I have been mocked internally more than once for treating staff development as a luxury an organization under pressure cannot afford.

A year later the ministry we answered to began digitizing its own systems, and we had no choice but to move with them. The decision was never ours to make. It arrived as a deadline.

There was resistance, and it was the resistance of competence rather than incapacity. These were people who had run one system for years, well, on cruise control, and were now being told the road had changed. But it turned quickly, for two reasons that I think are the most useful two sentences in this entire piece. The process genuinely became easier than the seven photocopies. And they discovered that the software was not magical.

That second one matters more than any change management framework I could sell you. Fear of technology is mostly fear of the unexplained. Twelve desktops and a colleague teaching Excel had already dismantled that a year earlier, for reasons that had nothing to do with the digitization that was coming.

Today that organization's records are fully digital.

I did not sequence that correctly on purpose. I got lucky, and the luck is instructive, because it points at the thing nobody budgets for. Readiness is a stock you build before you know what you will need it for. If you wait until the project has a name and a deadline, you are paying for the tool and the learning at the same moment, under time pressure, and one of them will lose.

The cost that keeps coming back

We were hunters and gatherers for most of our existence. Something like twelve thousand years ago that changed. Two hundred years ago our scientific discoveries began rewriting daily life. The last three decades produced a world that would be unrecognizable to someone who stopped paying attention in 1990.

I am forty-five years old, I work in this field, and the last six months of my own life have been an education I did not see coming.

So I understand the temptation to conclude that human beings cannot keep up, that the brain does not register change at this speed, and that an entire older generation is simply going to fall out of the conversation. I have thought it. I have written it down.

But my own evidence refuses to support it.

The craftsmen on that factory floor were savvy. The staff who moved a national paper archive into a digital system, most of them well past the age at which we assume people stop learning, absorbed a ministry-driven digitization within a couple of years. Nobody in either story failed because of their neurology.

What actually changed is the cost structure, not the brain.

For most of history, you learned your trade once and it lasted a working life. The cost of adoption was paid a single time, near the beginning, usually by an apprenticeship somebody else funded. Now that cost recurs, every few years, permanently, for everyone.

And organizations have not adjusted their accounting to it. The tool is treated as capital. It gets a line item, a procurement process, a contract, a signature, a place on the asset register. The learning is treated as an expense to be minimized. It gets a half day at go-live, delivered by the vendor, attended by whoever was free.

That is the whole failure, and it is a governance failure, which is the only reason any of this is worth writing about. Neurology would be a tragedy. A budgeting convention is a decision, and decisions can be changed.

Blaming the aging brain is just the modern version of blaming the staff. It is the same escape wearing a lab coat.

Five signs it is governance, not technology

If you want to know whether your digital problem is actually a digital problem, do not audit the software. Look for these.

- There is a parallel paper file, kept just in case. The system is live and nobody trusts it enough to be the only record. That is not a training gap. That is your staff telling you they do not believe the organization will stand behind the new process.

- One person knows the system, and everything routes through them. You have not digitized a process. You have converted an institutional dependency from paper into a single human being, and made it harder to see.

- Training happened once, at go-live. Which means you budgeted the tool and not the adoption, and every person who joins after launch learns the system by rumour.

- The vendor is treated as the owner of the process. When an internal question about how the work should be done gets answered by an external contractor, the organization has outsourced a governance decision and called it technical support.

- Nobody can name whose decision the system exists to support. This is the most serious one and the least noticed. A system that does not serve an identified decision by an identified decision maker will produce reports that are filed, dashboards that are never opened, and correct numbers that change nothing. I have written one of those reports myself. It was accurate. It was confirmed. It sat there while the company went off the shelves.

Three words that are not the same thing

Most of the confusion in this field comes from using one word for three different projects. They carry different costs, different risks and different owners, and they have to happen in this order.

Digitizing means the record stops being paper. The seven photocopies become one file. Nothing about how the work is done changes at all. This is a data project. It is the cheapest of the three and the one most often mistaken for the whole job.

Automating means a machine now performs steps a person used to perform. The invoices come out by themselves. This is a labour project, whether or not anybody says so out loud, and it is the precise moment the headcount question walks into the room. Automating a process you have not first agreed to own does not remove the confusion inside it. It hardens that confusion into software and puts a licence fee on top of it.

Transforming means the process itself gets redesigned, because the constraint that shaped it no longer exists. This is the only one of the three that produces improvement, and it is entirely a governance project. It has almost nothing to do with the vendor.

Take the seven photocopies. Digitizing that means seven people now open the same file instead of holding seven separate pieces of paper, which is real progress. Transforming it means asking why seven sections each needed their own copy in the first place, which is a question about authority and trust and who is permitted to approve what. The first question can be answered by a supplier. The second can only be answered by whoever runs the organization. I have watched plenty of organizations, including ones I have worked inside, complete the first and quietly skip the second, then wonder why the new system feels as slow as the old one. The factory bought automation and called it modernization. It never reached the third word.

What actually needs signing

So when I say ask before you sign, I do not mean the software contract. By the time a contract is in front of you, the decisions that matter have already been made, and made badly. Five things belong in writing before procurement opens at all.

- A named process owner, and not from IT. One person inside the organization who owns the process the system will encode, and who has the authority to change it. IT owns the tool. Somebody else has to own the work. If you cannot name that person today, you are not ready to buy anything.

- A written answer to the headcount question. Whose work changes, and what happens to them. Answer it in writing before purchase, then say it out loud to the people concerned. If roles genuinely go, say so and manage it properly. If nobody loses their job, say that early, publicly, and more than once, because the silence in that gap gets filled with the worst available assumption, and you will spend the following two years calling the result resistance.

- An adoption budget with an actual number in it, spread over years. Not a training day at go-live. A recurring line for learning, sitting on the same side of the ledger as the licence, because it has the same life span. My own working rule, and I will own it as mine rather than dress it up as an industry standard, is that the first three years of learning should cost you at least what the first year of software costs. Organizations find that figure shocking, which tells you exactly how little they were previously spending on the only component that determines whether the rest of it works.

- Knowledge transfer and an exit, written into the vendor terms. Documentation you can read. Administrative rights held by you. Your data exportable in an open format. And at least two of your own people trained to configure the system, not merely to use it. The day your supplier is the only party who understands your process, you have outsourced a governance function and mislabelled it technical support.

A go-live test that is not technical. A system is not adopted when it passes acceptance testing. It is adopted when the parallel paper file disappears. Write that down as the criterion and put a date against it, because it is the only measure that tells you whether your people believe the organization will stand behind the new way of working.

Not one of those five is a technology decision. That is the entire point. Every one of them can be settled before a single supplier is contacted, and an organization that settles them properly will get more out of mediocre software than a competitor will get out of excellent software and no answers.

I have spent twenty-five years on both sides of this: the young analyst who installed the system that did not save the company, and the manager who accidentally trained a workforce a year before it needed the skill. What I know now is that the technology question is almost always the last and easiest one on the table.

If your organization is about to digitize something, or has already digitized something and cannot understand why nothing improved, that is the work I do. Digital transformation for organizations built for an earlier era, which in practice means governance, process ownership and adoption, with the software as the smallest part of it.

You can reach me through my profile here: https://www.linkedin.com/in/tonyelmir/

Next Wednesday: why reform efforts fail even when everyone agrees with them, and what an institutional immune system actually is.