The Leader Who Listened First
Why the information that matters most never makes it into the document
Jordan is sitting with a member of staff who will use the new system every day. Not in a workshop. Not in a project meeting. In the room where the work actually happens, watching how it is done, listening to what is said about it.
The person Jordan is talking to says something that stops the conversation mid-note. Not a complaint — a small, specific observation. A workaround that everyone on the team uses, that nobody has mentioned in any survey or requirements session because it has become invisible through familiarity, and that had the visit not happened would have been absent from every document the technology decision was based on.
Jordan writes it down. It will change what is built.
What the standard process does not capture
The technology decision process here is not badly designed. The business case is thorough. The vendor shortlist is credible. The project workshops have run, and the requirements document reflects what was said in them. The governance process is in place.
What the formal process cannot capture is what is now being heard. The requirements document reflects what the previous system did — the starting point, not the need. The project workshops produced consensus around the visible problems, the ones that are easy to articulate in a meeting room to a project manager with a template. The satisfaction survey measured experience against the current system’s performance, not against what the work actually requires.
Each layer of mediation between the decision-maker and the person doing the work reduces the fidelity of what arrives. The user research output has been simplified for an executive audience. The support tickets have been categorised and aggregated. The workshop outputs have been translated into requirements language. By the time the information reaches the decision-maker, the texture has been processed out of it — the hesitation before an answer, the third thing said after the first two, the small specific observation that reveals the real constraint.
The visit was to hear what the processing had lost.
Going before the direction was fixed
The conditions that distinguish this kind of listening from the kind that confirms rather than informs are timing, directness, and repetition — and each runs against what the project calendar prefers.
The first condition is timing. Going before the strategy is fixed — before the vendor shortlist is final, before the requirements are locked, before the business case has closed around a particular direction — means the listening can still change things. Listening that happens after the direction is set validates rather than shapes. The project team hears what it hoped to hear, because the questions have been shaped by what is already being built, and the person being listened to can sense the direction and answers accordingly. The visit happened when it could still matter, which meant going when the schedule pressure made going feel like a distraction from the real work.
The second condition is directness. Going in person — not through a project manager or a user research agency — means sitting with the people, watching the work, hearing the words in the order and with the weight the speaker intended. There is a real role for structured user research in technology decisions. But there is something it cannot carry: the unprocessed signal that reaches a decision-maker only when the decision-maker is present to receive it.
The third condition is repetition. The first visit produced one set of things heard. The second produced different things, because the trust that had not existed in the first conversation had started to build. People answer differently when they know the person asking is genuinely interested rather than completing a process — and that knowledge does not form in a single visit.
In the third conversation, someone said something they had not said in the first two — not because they had withheld it, but because it had taken that long for the context to feel safe enough for honesty to reach what actually mattered. Single visits produce first answers. Repeated visits produce the ones underneath.
What was not in any document
The visit that mattered most was the third one.
The spreadsheet had come up in the first visit — the workaround every person on the team maintained alongside the current system, because the system could not hold notes in the right place at the right stage in the process. Three years in, nobody had mentioned it in any requirements session because it had become invisible through familiarity. The requirement was added on the way back.
The second visit changed a vendor criterion. Someone was working with three applications open simultaneously, constantly switching, returning to the system from a backgrounded state. The shortlisted vendors had been evaluated against their interfaces during structured demos — clean, navigable, well-presented.
The question of how each vendor’s product behaved when interrupted and resumed had never been asked. It was asked after that visit. Two vendors answered adequately. One did not. The shortlist changed.
What the third visit produced was different. Someone described the hardest part of their day — a step that happened immediately before they opened the system. Technically outside the system’s scope, but one the implementation could have absorbed if the handoff had been designed differently. That single observation reshaped the implementation in a way that addressed the friction at its source, rather than treating the system boundary as a fixed line. The first two visits had not produced it.
None of the changes were expensive. Each required someone to have been in the room. The requirements document that did not include the notes capability was not careless — it simply had no mechanism to surface what the direct conversation produced.
Together, the changes constituted a technology decision made on what was actually true, not on what the formal process had captured. Not complete information — that is never available. But closer to what was actually true than any document had been.
Three questions a leader cannot answer from data alone
Before a significant technology decision, there are questions that no amount of analysis will answer reliably without direct listening.
The first is whether the technology will genuinely help the people who most need it to work. Not the average user in the user story — the person whose day is hardest, whose work is most complex, whose need the requirements document has approximated but not named. That answer is in the room where the work happens. Direct listening — going there — is the only way to hear it. The leader who does not go will answer it from assumption, and the assumption will be derived from data simplified precisely where the difficulty is most real.
The second is whether the technology will genuinely add to what the people it serves can do — or substitute one set of constraints for another. The genuine gain in capability shows up in the specifics of what people find difficult and what they could do if that difficulty were removed. Those specifics are not in aggregated data. They emerged in the second visit, from a person describing a capability they currently lacked that the new system could provide if designed to carry it. That capability had not appeared in any document because no document had asked for it directly.
The third is what the system needs to adapt to — the actual range of people and circumstances it will encounter in use. The answer is not in the modal user’s profile. It is in the outlier’s experience, in the third conversation with the person who finally said the thing they had been circling. Going back is the only way to hear it. A leader who makes the decision without returning will design for the average and discover the outliers after the system is live, when adaptation costs considerably more.
My Opinion
I have sat in enough rooms to know that the gap between the requirements document and what is actually needed is structural, not accidental. At one university, a single conversation around a table surfaced needs nobody had articulated — and capabilities some groups had no idea others could use. I have run procurement exercises where, over four days, real teams put real problems in front of vendors and evaluated how they responded. The vendors that won were not the ones with the best product. They were the ones that listened before they pitched.
Questions worth taking into your next decision
The four questions below are not rhetorical. They are worth answering — for yourself, before the next decision closes.
Think of the last significant technology decision you were involved in making. When did you last speak directly — not through a survey, not through a user research report, but in person or by phone — to someone who would be affected by that decision? What did you hear, and what did it change?
If you lead technology decisions, what is the mechanism in your process that brings direct, unmediated human experience to you before the strategy is fixed? If that mechanism does not exist — what is stopping you from creating it?
Think of a technology decision you made that did not land as intended. At what point in the process would direct listening have changed the direction? Was that opportunity available and missed, or was the process not designed to create it?
Is direct listening a luxury that busy technology leaders cannot afford — or is it the one thing that makes everything else more efficient by ensuring the direction is right before the resources are committed?
A McKinsey and University of Oxford study of large IT projects found that budget overruns averaged 45 per cent — but shortfalls in delivered value averaged 56 per cent. Those are not the same problem. The value loss lands quietly, across years of implementation, workaround, and eventual replacement.
Jordan’s listening did not guarantee the right direction. It made the wrong direction less likely — at a cost in time that is negligible against the cost of not going at all.
Authors Note
Jordan is a fictional character. Their story is drawn from a combination of professional observation and personal proximity to real events. The experiences described are real. The person is not.
You’re reading The Next Evolution by Neil Catton, articles that explore the human world and the intersection of technology, they try and ask difficult questions - not to scare - but to inform. If someone forwarded this to you, you can subscribe free at neilcatton.substack.com.
Neil Catton is the author of The Next Evolution, The Cognitive Crucible and The Shadow System - available on Amazon, and writes at the intersection of technology, ethics, and human purpose.
Really enjoyed this. The reminder that listening is a leadership capability rather than just a communication skill really resonated.
I completely agree that actively engaging a broad set of stakeholders early helps uncover perspectives, assumptions and constraints that would otherwise be missed.
I would add that, even with the best listening and most complete engagement in the world, as you point out we rarely have complete information or fully formed requirements at the outset. That’s where I’ve found a lean, incremental approach so valuable. By delivering in small steps, you create opportunities to gather fast, real-world feedback, learn what actually matters, and adapt before investing too heavily.
To me, the combination of listening broadly and learning quickly through iteration is what gives leaders the best chance of making better decisions. Thanks for sharing this perspective.