Organisational Antibodies

I used to think resistance to technology was mostly about technology. Then I worked in organisations.

Friction is not always accidental. Processes have owners. Platforms have sponsors. Suppliers have relationships. Reports justify meetings. Meetings justify roles. Sometimes an inefficient arrangement survives because somebody benefits from it surviving, even if nobody would ever describe it that way.

The bookings decision in the previous chapter reminded me that understanding the work is only part of the job. You also have to understand the organisation the answer is landing in.

That is a part of the approach I had underweighted at first. The intervention does not always have to win in order to change the outcome. Sometimes its job is to make the organisation a smarter customer.

This also means the practitioner needs a little emotional discipline. If you fall in love with your solution, every objection starts looking political. Sometimes it is political. Sometimes your idea is simply not as good as you think it is. The annoying skill is knowing the difference.

A useful question when friction stubbornly survives is, who benefits from the current arrangement, and what are they afraid of losing? Not as an accusation. As an attempt to understand the whole system.

Technology is rarely the whole system. People, incentives, status, history and trust are in there too. Pretending otherwise is how technically excellent projects end up in very expensive drawers.

The political part is awkward to write about because it is easy to make everybody else the villain. That would be both unfair and unhelpful. People protect decisions for all sorts of reasonable human reasons. They have relationships they trust. They have reputations attached to previous choices. They have teams who will carry the consequences if something goes wrong. What looks like irrational resistance from one side of the table can look like perfectly sensible risk management from the other.

The danger comes when we pretend those forces are not present. A technically superior answer does not float above an organisation untouched by history, hierarchy and friendship. It lands in the middle of all of them. If you want an idea to survive, you need enough curiosity to understand that landscape as well as you understand the workflow.

Once the direction was clear, I had to decide how personally to take it. Defending my own cleverness would have been easy. Keeping sight of what the business needed was more useful.

That is not surrender. It is remembering what the work was for. If I become emotionally attached to my own builds, I have simply invented another kind of vendor lock-in, only this time the vendor is me.

This is also why language matters. Telling a team that you are here to replace their system, their process or their supplier immediately creates a contest. Asking them to show you where the work hurts creates a conversation. The eventual answer may still challenge something they own, but at least the challenge has emerged from shared evidence rather than arriving as somebody else's conclusion.

This approach does not remove politics. Nothing involving people does. What it can do is make the argument smaller and more factual. Instead of debating a grand future state, you can point to a pilot, a changed behaviour or a piece of work that disappeared. Evidence does not make disagreement impossible. It simply gives everybody something more useful to disagree about.