Transformation

The bigger challenge in tech transformation isn’t the tech. It’s the transformation.

Technology has never been easier to get. What decides whether it changes anything is whether people pick it up, and keep picking it up.

3 October 2026 · Diametric Ideas · 7 min read

Picture a rollout that went exactly to plan. The system launched on the date promised. Training sessions were attended. The dashboard shows every account created and every licence assigned. And yet, three weeks later, the real work is still happening somewhere else: in a spreadsheet on someone’s desktop, in a group chat, in a notebook that one person trusts more than any screen.

Anyone who has been near a technology programme will recognise this scene. It rarely gets called a failure, because nothing visibly broke. The project is reported as delivered. But nothing was transformed, because transformation is not something a system can do on its own. It is something people do, or decline to do, once the system arrives.

At Diametric Ideas we think this is the most under-discussed fact in technology work. The bigger challenge in tech transformation is not the tech. It is the transformation.

The technology is the easy part

There was a time when getting the technology was the hard part. It was expensive, scarce and slow to install, and the people who could build it were few. A project that simply got the tool running counted as an achievement.

That time has passed. Capable software is now abundant. Cloud platforms, automation and AI tools are within reach of almost any organisation, in weeks rather than years, and often of the very person who needs the work done. The opportunities are everywhere, and they are real. We are enthusiastic about them.

But abundance moves the difficulty. When the tool is easy to get, the scarce thing is no longer capability. It is change. Will the people who do the work actually reorganise how they do it around the new thing? Will they want to? And if they do, will the result be better than what they had before? These are questions about people, habits, trust and incentives. No vendor sells a fix for them, and no amount of technical excellence answers them.

People are the original process designers

Watch how work really gets done in any organisation and you will find that people invent process constantly. Someone works out which of three forms gets approved quickly, and which of the three approvers to ask first. Someone keeps a private list of the customers who need a call rather than an email. Someone knows that the official procedure breaks on the last day of the month, and has a quiet workaround that never appears in a manual.

These shortcuts are easy to dismiss as rule-breaking or untidiness. We read them differently. A workaround is a small piece of design, made by the person who understands the problem best, tested daily against reality and refined until it works. It is the organisation learning in real time.

People also thrive in what looks, from the outside, like chaos. A busy team juggling interruptions, exceptions and shifting priorities is not malfunctioning. It is adapting, moment by moment, with a flexibility no written procedure can match. Much of the value that people create sits in exactly this fluidity: the judgement call, the improvised fix, the conversation in the corridor that saves a week.

From the outside it looks like chaos. From the inside it is skill.

What most transformation does to that

Now consider what a typical technology transformation sets out to do. It begins with a sensible aim: to make work consistent, visible and efficient. Then it reaches for the most direct route. Map the process, standardise it, and encode it in the system. The fluid, adaptive way people work is converted into fixed steps, mandatory fields and approval gates.

The intent is good. The result is often a process designed for the average case and imposed on work that is mostly made of exceptions. The system handles the ordinary situation neatly and has no way of handling the one that arrived this morning. So people do what they have always done. They find a way around. Except that now the way around is hidden, outside the system, and the organisation has lost sight of how its work actually happens.

Consider a field sales representative standing in a trader’s shop, ready to log an order. The new system asks for a 200-field form: outlet details, compliance entries, scheme codes, delivery preferences, line after line of mandatory fields. The trader has a queue of other customers and no time to spare. An order that took one sentence to agree now takes far longer to record. So the representative does what any sensible person would. They take the order the way they always have, and fill in the form later, in a rush, with whatever the validation will accept. The data that results is complete, neat and wrong.

There is a second cost, and it is a human one. When a transformation is framed around replacing effort, people hear a statement about their own worth. Whether or not anyone intended it, the message received is that the way you work is the problem. It is hard to be enthusiastic about adopting a tool that has been introduced as a verdict on you.

Adoption is the metric

If transformation depends on people, then the way we measure it has to change. Launch dates, licences issued and features shipped measure activity on the supply side. They tell you what was delivered. They say nothing about what changed.

We believe the true metric of transformation is adoption. Not adoption in the narrow sense of logins, but in the sense that matters. Do people reach for this tool when nobody is watching and nothing forces them to? Does it make the best person on the team faster, and let others work more like them? Has the way work gets done actually shifted, and is it better for it?

A system that everyone uses only because they must is a system that is complied with, not adopted. Compliance produces data entry. Adoption produces leverage. And only adoption makes technology transformative, because a tool changes an organisation only to the extent that it becomes part of how its people think and act.

Design around what already works

This is where we place our own focus. The technology opportunities are plentiful, and we are glad to work with them. Our attention goes to the transformation.

That starts with looking before designing. Before we propose a tool, we want to see how the work is done today, and especially the parts that people have invented. Where are the shortcuts? Who is trusted for what? What do the best performers do that nobody ever wrote down? These are not problems to be removed. They are the best evidence of what works, and so the best starting point for what comes next.

From there, we design ideas around what already works. We favour tools that mimic the way life and work actually behave: flexible rather than rigid, tolerant of exceptions, comfortable with the order in which people really do things, and speaking the vocabulary they already use. Structure is added where it helps and left out where it would only get in the way. A good tool of this kind feels less like a new system to be learnt and more like an extension of the person using it.

We also put real weight on capacity building. If tools are meant to empower fluidity, people need the confidence and the skills to shape them, question them and make them their own. A team that can adapt its own tools keeps the adaptability that made it effective in the first place, and carries it into whatever technology comes next.

The aim is not to replace jobs. It is to let people do what they do best, with more reach. When one person’s good way of working can be scaled, supported and shared, the organisation gains something that no standardised process could give it: the best of its people, multiplied.

What this looks like in practice

Take a sales representative at a consumer goods company, moving between outlets. Orders reach them the way orders have always reached field sales: in the fewest possible words. A message like “20 units of detergent 500 ml to ABC Trader in Kalkaji” is complete to anyone who knows the territory. To most systems, it is noise.

A transformation built around adoption treats that sentence as the interface. The representative sends it exactly as they would have, and the tool does the translating. It recognises the outlet, matches “detergent 500 ml” to the right SKU, applies the price and scheme that trader is entitled to, checks what is available, and returns a clean order record, all in real time. Where the message is ambiguous, because two pack variants fit, it asks one quick question rather than guessing or refusing.

Nobody had to learn a new way of working. The representative still speaks the language of the territory, and the organisation still gets accurate, priced, stock-aware data at the moment the order is placed. The messy message and the structured record were never really opposites. One is simply the other, translated.

That is the difference between a tool people are told to use and a tool they keep.

A better first question

The usual question at the start of a technology programme is what we should build or buy. We think a better one comes first: what are people already doing well, and how do we help more of it happen?

Technology will keep getting cheaper, faster and more capable. That makes the human side of transformation more important, not less, because it is the part that will still be hard. The organisations that gain the most will be the ones whose people adopt, adapt and extend what they are given.

If you are planning a transformation and the plan is mostly about the technology, we would like to talk. Start with the people. The rest follows.