A New Tool Accelerates the Service You Already Have

Most of the people who will run it already know whether that's good news.

If you've sat through a system rollout that made the difficult parts of the job more difficult, and you never said so in a meeting, you read the situation correctly. The instinct to keep it to yourself was reasonable too. In an interview study of professionals, Frances Milliken, Elizabeth Morrison, and Patricia Hewlin found that 85% had at some point felt unable to raise an issue that mattered to them with someone above them. That's not a workforce of cowards. It's what people do when they've learned that candor carries a cost and changes little.

The same finding, read from the other chair, is the more useful one. If you're the person who approves the purchase, the odds are that someone three levels down already knows what the new system is going to do to their week, and the odds are you'll never hear it from them. That gap isn't a failure of your leadership or their nerve. It's a property of hierarchies, it's well documented, and it's cheap to close once you know it's there.

What follows is the mechanism, the reason it stays out of sight, and a check you can run in a few days for less than the cost of the first workshop about the platform.

What a tool actually does to the work underneath it

Jim Collins ran into this from a different direction. In Good to Great, published in 2001, he and his research team spent five years screening 1,435 companies and found eleven that had gone from ordinary results to sustained exceptional ones. They expected technology to be part of the explanation. It was, but not the way anyone assumed. Every one of the eleven used technology carefully and well, and not one of them treated it as the cause of the turn. Collins's conclusion was that technology accelerates momentum that already exists; it doesn't create it. Worth naming the kind of study that is: a retrospective analysis of matched company pairs, chosen after the fact, not a controlled experiment. It's an observed pattern across a small sample, and it has held up as a description of the mechanism even where people argue about the sample.

The mechanism is the part the demo can't show you. Automation encodes the way the work is done today, then runs that version faster and at higher volume. On a sound process, that gives you more of a good thing, which is the case Collins's eleven represent. On a broken one, it gives you the same fault at speed, behind an interface polished enough to look authoritative whether or not the work underneath it holds.

So the question a purchase actually asks is narrower than "which platform." It's this: is the work underneath this tool worth running faster? You can hold any system up against that sentence, and it costs nothing to ask.

Why the answer is hard to see from where you sit

The reason is structural rather than personal. Information doesn't travel up a hierarchy intact, and it decays in a consistent direction.

Sidney Rosen and Abraham Tesser named the first piece of it in 1970 and called it the mum effect: people are reluctant to pass along unwelcome information, even when they had nothing to do with causing it. Morrison and Milliken described the collective version in 2000 as organizational silence, the learned withholding of candid assessment once an environment signals that speaking up carries risk and changes little. Each individual softening is small. Nobody lies. A qualifier gets added, a number gets rounded toward the comfortable end, an exception gets described as an exception rather than as the pattern.

Stack those small softenings across five or six levels and what lands on your desk is the most favorable version of the process rather than the truest one. If you've ever had the feeling that the status deck and the reality were two different documents, that feeling was accurate, and it was structural rather than personal.

Which is genuinely good news, for one reason: the information still exists. The organization already holds it. It was filtered on the way up, not destroyed. You can go get it.

The new system will also quiet the people who used to catch things

There's a second effect, and it's the one that turns a speed problem into a risk.

A confident system reduces the scrutiny of the people working alongside it. Linda Skitka, Kathleen Mosier, and Mark Burdick observed this in automated cockpits in the late 1990s and named it automation bias. A 2012 systematic review by Kate Goddard and colleagues put a number on it in clinical settings: working with decision-support systems, clinicians reversed their own correct judgments in favor of wrong machine advice in roughly 6% of cases. That number deserves its provenance, because it's the kind that usually doesn't have any. It's a rate pooled from controlled studies, published in a peer-reviewed journal, not a vendor projection.

Six percent sounds survivable until you notice who those 6% were. They were the people who had it right. The check that used to catch the error was a person, and the system talked them out of it.

So a tool laid over a broken process does two things at once. It multiplies the fault, and it quiets the person who used to catch it. That's why this is a question to settle before the purchase and not after.

The cheapest thing you can do is go and sit with the work

The check is not sophisticated, which is most of its appeal. Before you scope the tool, spend a few days beside the people doing the work, watching them do it in the order they actually do it.

This has two names because two traditions arrived at it independently. Hugh Beyer and Karen Holtzblatt set it out as contextual inquiry in Contextual Design in 1998. Toyota got there from the factory floor and called it genchi genbutsu, go and see the actual thing for yourself before deciding anything about it. Both are making the same claim: the work as performed and the work as described are different objects, and only one of them is the one you're about to automate.

While you're there, map two things that never survive the trip up.

Where the work actually goes, and who owns each step. In 2019 I spent six months inside a global pharmaceutical company's finance department, and that map is what surfaced five parallel submission channels running with no single accountable owner. Speed doesn't supply a missing owner. Every decision that built that arrangement had been locally reasonable, which is precisely why nobody above it could see what they were about to accelerate.

Where the errors start, as opposed to where they get noticed. Those are rarely the same place, and only the first one is fixable. At that company the process was failing on roughly a third to a half of its submissions, a rate measured from the floor across five international sites rather than read off a status deck.

Then apply the test. If a capable person can't make the process work reliably by hand, a tool will only make it fail faster, and the honest move is to fix the process first. If it's sound and merely slow, you've found something worth accelerating and the tool will build on a real strength. Either way you now know what you're buying, which you didn't the week before.

If your instinct right now is that a few days of watching won't tell you anything you don't already know, that instinct is worth respecting. It's also cheap to test. Run it once on the process you're most confident about.

Facing the number is the disciplined move

Collins has a second finding that matters more here than the technology one. The companies that made the turn all confronted the most uncomfortable facts about their current reality directly, while holding on to the belief that they'd prevail. He called that combination the Stockdale Paradox, after the admiral who described surviving captivity by refusing both denial and despair. Facing the brutal facts and keeping the faith aren't in tension. They're the same discipline.

A 30% to 50% error rate is a brutal fact. It's also the most valuable thing anyone in that building had, because it's specific, it's measured, and it points at exactly what to rebuild: one owned workflow instead of five orphaned channels, a named owner for each step, errors caught where they start rather than where they surface. That's a process worth accelerating. And the same figures that exposed the problem become the measures that prove the redesign worked and the tool is paying for itself.

None of that starts at the vendor, and none of it is a single decisive push. The diagnosis, the rebuild, and the measure compound on each other. The tool joins a flywheel that's already turning, which, per Collins's finding, is the only condition under which it reliably pays.

Before you scope the next one

There are a few versions of this, and any of them beats none. The full version is a week on the floor before you spend anything on the license. Two days with one team still changes what you know. Even a single morning spent watching one person complete one submission end to end will tell you more than the deck will.

Watch the work. Map who owns each step. Find where the errors start. Then decide whether what you have is worth running faster.

If it is, the tool builds on a real strength, and you'll be able to prove it with numbers you gathered yourself. If it isn't, you found that out for the price of a few days rather than a platform, and you know exactly what to build instead.

The question was never which tool to buy. It's what the tool will accelerate, and whether you've seen that thing for yourself or only the version that survived the trip to your desk.

---