The tool is not the workflow

There is a particular kind of meeting that happens in small companies at the end of a difficult quarter. The work has not been good enough. Nobody disputes this. What is disputed, gently and without anyone quite saying so, is why. And somewhere in the second half of that meeting a familiar sentence arrives: perhaps the problem is the tool. It is a generous sentence. It assigns blame to a vendor rather than a colleague, it suggests an action rather than an argument, and it can be acted on by the end of the week.

The quarterly purchase

The sentence is also, most of the time, wrong — and it is wrong in a way that is unusually hard to notice, because acting on it feels exactly like making progress.

A new tool arrives with its own momentum. There is an evaluation, which is enjoyable. There is a decision, which feels decisive. There is a migration, which generates visible activity and a sense of fresh start. For several weeks afterwards, output improves, and everyone involved is briefly convinced that the diagnosis was correct.

Then the improvement fades. Not dramatically, and never on a particular day, but the work settles back to roughly where it was, with the same weaknesses in the same places. The explanation reaches for the nearest available cause, which is now the new tool, and the cycle has somewhere to go next quarter.

What has actually happened is simpler. The brief improvement came from attention, not from software. For a few weeks, people were thinking about how they worked, because the unfamiliar interface forced them to. The tool did not supply that attention; it merely interrupted the autopilot long enough for attention to appear. When fluency returned, the autopilot came back with it, and the autopilot is the thing that was producing the output all along.

What a workflow actually is

The word workflow has been degraded by software marketing into something close to a synonym for interface. In the sense that matters here, it means something more specific and much less glamorous: the sequence of steps work passes through, who is responsible at each step, what each step is allowed to assume about the one before it, and what has to be true before the work is permitted to leave.

Almost none of that lives in a tool. The sequence lives in habit. The responsibilities live in an understanding, usually unwritten, that two people arrived at eighteen months ago. The assumptions live in nobody at all, which is why the same question gets asked at the same point in every project. And the standard — what has to be true before the work leaves — frequently does not exist in any retrievable form. It exists as a feeling in the senior person's chest when they look at a draft.

A tool can host a workflow. It can enforce a sequence, record a handoff, make an assumption explicit by requiring a field to be filled. But it cannot invent any of these things. Software given no workflow to host will faithfully host the absence of one, and it will do so with excellent notifications.

The standard is the hidden variable

Of the four parts, the acceptance standard does the most to determine quality, and it is the part least likely to be written down anywhere.

Consider what actually decides whether a piece of work is good. Not the speed at which it was produced, nor the sophistication of the instrument used, but the question asked of it at the end: is this good enough to go out? Everything upstream is in service of that question, and the question is only as useful as its specificity. A standard that says make it good is not a standard. A standard that names the three things that would send a draft back is a standard, and it will raise the floor of the work on whatever software happens to be open.

This is why the same team produces recognisably similar output across a decade of tool changes. The standard travelled; the tools did not matter. It is also why a team that writes down its standard for the first time often sees a jump in quality with no purchase involved at all, which is an awkward result for everyone who has just signed an annual contract.

The standard is unglamorous, free, and slow to produce. It requires someone senior to articulate a judgement they have been making silently for years, which is genuinely difficult and faintly embarrassing. A purchase order requires none of that.

Software given no workflow to host will faithfully host the absence of one — and it will do so with excellent notifications.

Why the demonstration always works

There is a structural reason the evaluation stage misleads, and it has nothing to do with anyone being dishonest.

A demonstration is a workflow. Somebody has thought carefully about which task to show, in what order, with what prepared material, ending at a point where the result looks finished. The sequence is deliberate, the handoffs are rehearsed, the assumptions are all satisfied in advance, and the acceptance standard is whatever makes the demonstration end well. Of course the output is good. The output is good because, for twenty minutes, a complete and well-designed workflow existed.

What gets bought afterwards is only the tool. The workflow stays behind, because it was never part of the product. It was part of the presentation.

This also explains the particular disappointment of a trial that goes well. During a trial, the work is deliberate: a specific task, chosen because it is representative, approached with unusual care, and judged against a standard that is unusually explicit because the whole point is to judge. The trial measures the team working attentively. Normal operation is the team working normally. The gap between the two is not the vendor's fault, and no amount of due diligence closes it, because the variable being changed in the trial was never the software.

The cost of moving

Against the hoped-for gain sits a bill that is almost never itemised, because most of it is not invoiced.

The visible part is the smallest part. Export, import, reconnect, re-permission: tedious, finite, and the only line anyone estimates. Beneath it sits the part that is paid for months.

• Institutional memory. The old system holds the record of why things were decided, scattered through comments, names and half-finished items. Migration carries the data and leaves the reasoning, and the reasoning was the valuable part.
• Fluency. Experienced people become slow again, and not only slower — more cautious, less willing to attempt the clever thing they knew the old system would tolerate.
• Reference rot. Links in documents, bookmarks, saved searches and the runbook nobody has opened since induction all quietly stop pointing at anything.
• Permission drift. The careful structure of who can see what gets rebuilt from memory in an afternoon, usually more permissively than before, and nobody audits it.
• The second migration. Whatever did not fit the new system stays in the old one for a while, and a while becomes permanently. Two systems is the most expensive state available, and most migrations end there.

The second system is never the last

There is a pattern worth naming in any organisation that has changed tools more than twice in the same category.

Each change is justified by the failure of the previous one, and each justification is sincere. The previous tool really was awkward in the way described. What goes unexamined is that the awkwardness was discovered in month four every time, at roughly the same point, in roughly the same place: wherever the work required a judgement that the workflow had never specified.

Software is unforgiving about unspecified judgements. It will present a field, a status, a choice of folder, and it will wait. If the workflow has no answer, each person supplies their own, and within a quarter the system contains several incompatible conventions. This reads, accurately, as the tool being a poor fit. It is more precisely the tool asking a question nobody had agreed on, which the next tool will also ask, in a different dialogue box.

The diagnostic question is therefore not which tool suits us but what did the last three tools all turn out to need from us that we never provided. The answer is usually one or two decisions that nobody wanted to own. A fourth purchase will surface them again.

Why the newest tools make this worse

All of the above predates the current generation of software by decades. What has changed recently is the size of the penalty for getting it wrong.

The older kind of tool was honest about the state of the work. A half-finished document looked half-finished. A thin argument read as thin, and a draft produced without thought announced itself in its first paragraph. The absence of a standard was therefore partially self-correcting: the work looked as unfinished as it was, and someone noticed.

The newer tools remove that signal. They raise the floor of surface quality while leaving the floor of judgement exactly where it was, which means weak work now arrives wearing the clothes of finished work. Sentences are well formed. Structure is present. The register is plausible. Everything that used to serve as a rough proxy for care has been decoupled from care, and the proxy is what most review processes were quietly relying on.

The consequence is not that output gets worse. It is that an explicit acceptance standard has gone from being a nice practice to being the only remaining check. A team with a written standard gains a great deal from these tools, because the standard still functions and the tedious part of the work has shrunk. A team without one loses its last warning light, and gains the ability to produce unacceptable work faster and in greater volume than before.

The tool changed. What it changed was the cost of not having a workflow.

When the tool is the answer

None of this argues that software does not matter, and the opposite error is just as expensive. There are cases where changing tools is precisely the right move, and they share a recognisable shape: the constraint is in the tool, not in the people, and it can be stated as a fact rather than a frustration.

The clearest case is a capability that simply is not present. If the work requires something the current system cannot do, no standard or sequence will conjure it, and persisting is a decision to keep doing the work badly. The second is a constraint that has become load-bearing in the wrong direction: a limit on who can be given access, a format that cannot be exported, a record that cannot be audited. The third is cost that has drifted out of proportion to use. The fourth is a tool that has stopped being maintained, where the risk is not quality but continuity.

What these have in common is that the problem survives being written down. A frustration that evaporates when it is stated precisely was never about the tool. A constraint that reads as clearly on paper as it felt in use is worth acting on — and a team that can write it down that clearly has, incidentally, done most of the work of specifying its own workflow.

The unglamorous alternative

The alternative to a purchase is a conversation that nobody enjoys, which is the main reason it is so rarely the thing that happens.

It consists of writing down what the work passes through, in order; who is responsible at each point; what each step may assume about the step before it; and the three or four conditions that would cause the work to be sent back. That is all. It can be done in an afternoon and it fits on a page. The difficulty is not the length but the content, because producing it means forcing judgements into the open where they can be disagreed with, and some of them will turn out to be inconsistent or indefensible.

The document also has an unhelpful quality: it is boring, and it produces no sensation of change. There is no launch, no migration, no moment at which anyone can be congratulated. It is a page, and the page makes the work better.

It has one further use. Once a workflow exists on paper, evaluating software becomes a far more honest exercise, because there is finally something concrete to evaluate against. A tool can be asked whether it supports this sequence, this handoff, this standard, rather than whether it feels modern. Most of the tools that would have been bought on feeling do not survive that question.

A tool is a claim about a workflow

Every piece of software embodies an opinion about how work should proceed. The opinion is visible in what the product makes easy, what it makes possible but awkward, and what it refuses to represent at all. Adopting a tool means adopting that opinion, usually without having read it.

When the opinion happens to match how a team already works, the tool feels intuitive, and everyone credits the design. When it does not, the tool feels obstructive, and everyone blames the vendor. Both reactions describe a relationship rather than a product, which is why the recommendations of other teams are so much less useful than they appear.

This suggests a modest discipline and an honest expectation. The discipline: before changing a tool, write down the workflow it is meant to serve, and check whether the stated problem survives the writing. The expectation: a better tool raises the ceiling of what good work can look like, while the standard raises the floor of what ordinary work looks like — and almost all output is ordinary work.

The quarterly meeting will come round again, and the generous sentence will be available as usual. It is worth noticing that it offers to replace an argument with a purchase. Arguments are slower, cheaper, and the only one of the two that has ever reliably changed what comes out.

How these essays are written, sourced and corrected is set out in our editorial policy; what this publication is for is on the about page.