First! The System That Grew While You Waited

A problem appears, and the people closest to it usually notice first because they are the people who have to continue working while it exists. The organisation notices too, eventually. A request is made, requirements are gathered, funding is found, priorities are negotiated, procurement happens, security asks reasonable questions and development begins. All perfectly defensible. Unfortunately, the problem has not agreed to wait.

So the people experiencing it adapt. Sometimes that means a spreadsheet, a form, a tracker or a shared folder. Increasingly it means ClickUp, Airtable, Notion, Power Apps, AppSheet, Zapier, or one of the almost infinite number of SaaS products that can be persuaded to behave like something they were never quite intended to be. A few forms appear, then some automations, a dashboard, perhaps an integration or two. Before long, the team has not really created a workaround. It has created a system.

This is where delay becomes more than lost time. The problem continues to evolve while the formal solution is being built. People alter their behaviour around it, invent practices, connect things together and become progressively better at living without whatever was originally requested.

By the time the organisation returns, it may no longer be addressing the problem it left behind. There is already something there, and quite often it works.

The Vernacular System

I have started thinking of these as vernacular systems. The term describes how they came into being rather than how sophisticated they are. They emerge from within the work itself, built by people close to the problem using whatever happens to be available.

Their great advantage is context. The person building one knows which exceptions occur constantly despite being described as exceptions. They know which information matters, which official steps everyone quietly routes around, what needs to happen by Friday, and what makes entering the data worthwhile in the first place.

That makes vernacular systems unusually adaptable. Need another field? Add one. The process changed? Change the workflow. Someone needs a different view? Make one. A reporting requirement changed on Tuesday? There is a fair chance something will be working by Wednesday.

What looks undisciplined from the centre can be exactly what makes the system useful locally. A vernacular system can be technically poor and extremely well adapted.

It can also be a complete nightmare.

Flexibility becomes inconsistency. Context becomes opacity. Local optimisation becomes fragmentation. Business rules live inside one person's head. Copies proliferate, permissions drift, integrations depend on accounts nobody owns, and manual effort quietly accumulates behind what appears to be automation.

Local does not mean benign either. A vernacular system can preserve bad practice as effectively as good practice. It can reflect the preferences of one influential person, institutionalise a workaround for a broken upstream process, or make its creator so central that continuity becomes impossible when they leave. Those risks are often exactly why formalisation becomes necessary.

But they do not make the system worthless. It is usually the first serious attempt to give shape to the need, and contains evidence about context, priorities, exceptions and local judgement. It is not necessarily failed formalisation. Often, it is pre-formalisation.

When Adaptation Becomes Entrenchment

Usefulness accumulates. So do familiarity, knowledge and dependence. Another person starts using the system, another process depends on its output, a weekly meeting begins with one of its reports, and somebody learns the peculiar sequence of clicks required to make the thing behave.

There is something like a network effect here, although the network can be very small. Sometimes the locale is one influential person. What matters is not simply the number of users, but how much work, knowledge and authority have accumulated around the system.

Given enough time, it becomes socially inhabited.

Customs emerge. Never change that field after Thursday. Ask Sarah before running the report. This tab is the authoritative one. Ignore that status because nobody has used it correctly for years. If the automation breaks, there is a manual route involving a shared mailbox and a spreadsheet nobody remembers creating.

None of this necessarily exists in the system itself. It exists in the culture around it. Eventually there are origin stories, cautionary tales, local heroes and things nobody touches because nobody remembers what will happen if they do. The vernacular system has acquired folklore.

At that point, replacement is no longer simply migration. You are changing an artefact and part of the culture that makes it work.

The creator has evolved with it too. They have become the person who knows how this works. The attachment is rarely to the tool itself, but to what the tool represents: someone saw a problem, understood it, solved it when nobody else did, and other people began relying on what they made. That brings agency, competence, authority and sometimes prestige. More deeply, it can touch professional identity.

If I temporarily repair a leaking pipe and later call a plumber, I am unlikely to experience the plumber's arrival as an assault on my sense of self. I am not a plumber. The person who created a vernacular system at work is usually not claiming to be an IT professional either. They built it because they understand their profession.

The tracker expresses their understanding of the operation. The workflow reflects how they understand cases to move. The categories encode their judgement about which distinctions matter. The technology is incidental. What it represents is domain expertise.

Then IT arrives and begins talking about entities, fields, statuses, workflows, permissions and business rules. These sound technical, but each makes a claim about what the work is and how it should be represented.

A digital system does not merely support a professional domain. It encodes a view of it.

IT rarely owns that domain, yet formalisation gives it considerable influence over its representation. The practitioner who previously understood the work and controlled its representation may now retain the first while losing much of the second.

That is a more credible source of resistance than the usual suggestion that people simply dislike change.

The Friction Spot

There is a familiar diagram in design thinking where three overlapping circles represent desirability, viability and feasibility. Somewhere in the middle sits the sweet spot.

This problem has its own three circles, but the overlap is rather less sweet.

There is the practitioner, who understands the work, its context and the immediate utility they need. There is the sponsor, often the person who initiated the formal solution, who sees problems the practitioner may have little reason to care about - organisational visibility, consistency, duplication, risk, strategic reporting or scale. And there is IT, which understands how to make something coherent, secure, supportable and sustainable.

All three perspectives are legitimate. They simply want different things. The practitioner wants something that helps now and remains adaptable. The sponsor wants value beyond the local environment. IT wants something that can survive becoming a formal system.

The overlap is a friction spot.

It is not a meeting of equals either. The sponsor has the power to mandate. IT has the power to formalise. The practitioner often has the least authority over the decision itself but retains something enormously important - the power to enact it.

A sponsor can require adoption and IT can deploy a system. Neither can fully compel the quality of what happens next.

Friction Is The Terrain

Organisations tend to be suspicious of friction. A project where everyone agrees is reassuring. A workshop where nobody objects feels productive. Requirements are signed off, stakeholders are aligned and the little status indicator turns green.

Sometimes that means genuine agreement. Sometimes it means we have not understood enough yet.

The right practitioner may not be in the room. Assumptions may not have been exposed. Nobody may have reached the exceptions. Or the people with the least power may simply have learned that disagreement is unrewarding.

Silence is not agreement.

Friction gives the problem shape. A practitioner resisting a workflow may show where abstraction is rubbing against reality. A sponsor demanding consistency may expose where local optimisation has stopped serving the wider organisation. IT pushing back against a particular freedom may identify the point where flexibility begins threatening integrity.

Healthy friction gives us enough resistance to investigate. What is the vernacular system doing unusually well? Which practices reflect genuine context? Which are historical accidents? What will we lose if we standardise this? Where are the risks if we do not?

The objective is not to preserve the vernacular system intact. It is to understand it before destroying the evidence.

That has started to suggest a few principles in my own work. One is that we should not think of ourselves as replacing vernacular systems so much as conceptually building upon them. Frontline solutions contain domain expertise, lived experience and pragmatism that deserve to be understood before they are discarded.

Another is that standardisation is not automatically improvement. Some variation is dangerous fragmentation, but some carries context that matters. The work is distinguishing between them rather than assuming consistency is inherently superior.

Agency matters too. Someone who could previously adapt their tools as the work changed experiences a genuine loss when they become the passive operator of somebody else's interpretation. My instinct is therefore to preserve as much local ability to shape the formal system as integrity allows.

This is also where empathy has to become more tangible than listening exercises and requirements workshops. If the system contains useful local custom, some of that custom should survive. Not necessarily the spreadsheet, workflow or SaaS stack, but the understanding embedded within it.

There is a difference between customisation and the adoption of custom. Customisation says that people may alter parts of the new system. Adoption of custom says that we observed how they worked, understood why some of it mattered, and allowed that knowledge to shape what came next.

One provides options. The other acknowledges authorship.

There is also the exchange of value. Organisations frequently ask practitioners to produce structured information because it creates strategic value elsewhere. The practitioner bears much of the cost of producing it. If little tactical value returns to them, indifference should not be surprising. In my context, that suggests another useful principle: when asking the frontline to create strategic value, return some immediate value to the people doing the work.

These are answers I find useful. They are not necessarily yours.

The questions travel better. How will we treat what already exists? How much agency can survive formalisation? How will we distinguish useful variation from dangerous fragmentation? What do we owe the people whose professional domain we are encoding? How will we respond when they disagree?

The point is not that every organisation should arrive at the same principles. It is that these tensions deserve to be answered deliberately rather than being resolved silently by a methodology, an architecture or whoever happens to hold the most authority.

Compliance Is Not Commitment

Formal authority has limits.

An organisation can mandate a system, make fields compulsory, block incomplete workflows, measure adoption and produce an impressive dashboard showing 97 per cent compliance. It cannot mandate care.

Practitioners are remarkably good at learning the minimum a system requires. Choose the nearest category. Enter the shortest acceptable description. Put something plausible in the mandatory field. Learn which information is actually checked and which merely needs to exist.

The workflow completes, the database is populated, and the data may be technically impeccable. The information can still be rubbish.

We solved malformed data decades ago. We did not solve indifferent data.

Modern systems are very good at enforcing types, formats, relationships and required values. That is data integrity. Information integrity depends on whether the person providing the information believes doing so properly is worth their attention.

Garbage in, garbage out is often less a technical problem than an organisational one. The database may be perfectly clean. The organisation has simply created conditions in which people supply the minimum viable truth.

The sponsor can mandate and IT can validate, but the practitioner still controls the quality of their attention. Mandates can compel participation. They cannot compel care.

The usual response can make matters worse. Poor information produces more controls and more mandatory fields. The organisation tightens the system because it does not trust the people entering the data. Those people give it less discretionary effort because they increasingly resent the system. Each side receives fresh evidence that the other was the problem all along.

Trust Debt

The cost then extends beyond the current project.

If an organisation is slow to respond once, people may tolerate it. If it happens repeatedly, they learn. The lesson can be simple: when something matters, we need to solve it ourselves.

That lesson changes the next interaction. People wait less before adapting, invest earlier in a local response and involve the formal organisation later. Eventually they may stop involving it at all.

Demand has not disappeared. It has become invisible.

From the centre, this can look encouraging. There are fewer requests, so perhaps things are improving. Meanwhile another improbable arrangement of SaaS, automation and spreadsheets has quietly become operational infrastructure.

This is trust debt. Unlike most of the costs of replacing an entrenched system, it does not simply get paid down. People learn a new tool. Data gets migrated. New expertise develops. Trust debt accumulates, and it compounds.

A disappointing intervention changes expectations about the next one. A failure by one formal team can contaminate the reception of another. People stop judging each initiative entirely on its own merits and begin to see it as another thing coming from them.

The "them" matters. Trust debt attaches easily to an out-group - IT, headquarters, management, consultants, the central office, whoever happens to represent somewhere else.

Once that happens, future initiatives begin with a credibility deficit inherited from the past. Slow delivery therefore costs more than deferred value. It gives the problem time to evolve, the vernacular response time to adapt and the surrounding culture time to establish itself.

Eventually, the thing you are arriving to solve no longer exists in its original form. You are no longer fulfilling demand. You are displacing an adaptation.

The Window

There is a window in which a formal solution still arrives primarily as help. Miss it and change remains perfectly possible, but becomes more expensive in time, money and morale.

The mistake is imagining that the formal solution is still competing with the problem it was originally asked to solve.

It is not.

That problem has already been adapted around. What now exists is a locally evolved response, shaped by context, reinforced by use and woven into the social fabric of the work around it. Its weaknesses may be substantial. So may the reasons people are reluctant to surrender it.

People do not wait passively for institutions to solve their problems. They adapt. Delay gives that adaptation time to become richer, stranger and harder to replace.

So before asking why people will not adopt the solution, there may be a more useful question.

What did they have to build while they were waiting for it?