Every Management Failure Is a Retrieval Failure

A CRM migration goes sideways. The client agreed to a platform switch during discovery — moving from a legacy system to a modern stack — but nobody verified that the client’s stakeholders understood what “platform switch” actually meant in practice — a discovery gap that would compound through the entire engagement. The business analyst coordinating between the client and the development team doesn’t have deep technical background, so requirements arrive translated into approximations. Close enough to act on, not precise enough to build against. The development team builds what they were told. The client expected something else.

Six weeks in, the client’s primary contact goes quiet — other priorities, internal reorg, the usual. When they re-engage, they’re looking at something they didn’t ask for, built on assumptions nobody validated. The one senior engineer who could have caught the misalignment early was splitting time across four other active projects and only got pulled in when the integration tests started failing.

At the postmortem, a detail surfaces: the client had submitted a detailed list of issues — workflows that didn’t match their process, fields mapped incorrectly, reports that pulled the wrong data. The list went to the BA. The BA never escalated it. The engineering lead didn’t know it existed. The project sponsor didn’t know it existed. The issues lived in an email thread that reached exactly one person, and that person didn’t have the technical context to assess severity or the process to route them.

The conclusion was “communication breakdown.”

The information existed. Someone knew. Multiple people, actually. The BA had the issue list. The client had the concerns. The discovery document had the original agreement. None of it reached the person who could act on it, at the moment they needed to act.

Every piece of information needed to prevent the failure was already captured. The system just couldn’t deliver it.

That’s a retrieval failure — not a knowledge failure, not a competence failure. The information existed inside the organization. The system had no mechanism to surface it to the right person at the right time. And it happens everywhere, constantly, at every scale.

The pattern that keeps showing up

The incident changes — missed deadline, shipped the wrong thing, client blindsided by a decision they thought they’d weighed in on — but the postmortem converges on the same shape. The knowledge was captured. It lived in a Slack thread from two weeks ago, a task comment in the wrong project, a meeting summary that went to the wrong distribution list. The system had the data. The system couldn’t deliver it. KM research has been documenting this for decades — the same causal factors keep appearing: inadequate organizational structure, improper planning and coordination, problems with culture, and technology implementations that prioritize capture over retrieval.

This is why status meetings exist. The retrieval system is broken, and humans are patching it manually. “Going around the room” is a retrieval protocol. It’s just an expensive, slow, and unreliable one. And when the standup drifts — when it becomes forty-five minutes of self-congratulatory posturing or water-cooler tangents because the person running it isn’t zealous about forward motion — even that manual patch stops working.

The pattern holds at every scale. A solo founder who can’t remember where they left off on a project last Tuesday? Retrieval failure. A two-hundred-person engineering org where marketing doesn’t know what the development team shipped last week? Same failure mode, different blast radius.

Three ways retrieval breaks

Retrieval failures often fall into one of three patterns, and all three were present in that CRM migration.

State scattered across tools.

The project lives in Jira, the decision lives in email, the context lives in someone’s head. No single source of truth, so every handoff requires a human to manually reconstruct context.

In the migration project, there was no central repository for documentation — artifacts lived in various discrete locations, and the BA didn’t have governance documents or clear project folders for managing them. If you wanted the full picture, you had to assemble it yourself from fragments, and nobody had time to do that.

Knowledge locked to individuals.

Ask Sarah, she knows how that works. Sarah is a single point of failure with an unassuming job title, and nobody realizes it until she’s on vacation during an incident. Sarah might leave, and then what? Your org chart doesn’t show this — it shows reporting lines, not where institutional knowledge actually lives.

In the failed migration project, the one senior engineer who understood the integration architecture was splitting time across four other projects — brought in only when something was already broken, never embedded in the workflow early enough to prevent the break. Constant context-switching, and then an expectation to dig through wildly disorganized task comments to find the state of a project they’d barely been aware of, and were never consulted on at any point before kickoff. An architecture failure masquerading as a staffing decision.

Retrieval requires the requester to know what to ask for.

If you don’t know a decision was made, you can’t look it up. The system only works for people who already have context.

That issue list the client submitted? The engineering lead didn’t know it existed, and you can’t retrieve what you don’t know is there — and a system that depends on someone remembering to surface information is a system that will silently drop critical knowledge every time someone forgets, gets busy, or doesn’t realize the information matters.

All three are architecture problems that are commonly identified as people problems.

Documentation without retrieval is theater

In the words of the great, late Admiral Ackbar: “It’s a trap.”

But it looks like a solution.

The organization sets up the wiki, writes the runbooks, creates the project folders — and then thinks the job is done. The information is documented. It’s all right there. Anyone can go look it up.

Except, no one ever does, because looking it up has a cost: the activation energy required to context-switch, open the right tool, navigate to the right page, parse through noise, and extract what you need. Research on task switching shows that even brief mental blocks created by shifting between tasks can cost as much as 40% of someone’s productive time — and the costs increase with task complexity. When that cost is high enough, people make decisions with incomplete information instead (not all that dissimilar to an LLM confabulating content when it lacks context). Not because they’re lazy or unmotivated — because the friction of retrieval exceeds the perceived risk of guessing. And most of the time, the guess is good enough.

Most of the time.

In the migration project, even if every artifact had been perfectly documented — the discovery agreement, the client feedback, the issue list, the integration constraints — it wouldn’t have mattered without a mechanism to push that information to the right person at the right time. The BA had the issues. The documentation existed. Nobody else saw it, because nobody else knew to look, and there was no process that forced it to surface.

Documentation without retrieval is performative execution.

You did the thing that looks like governance without building the mechanism that makes it work. And when the project fails, you can point to the wiki and say “it was all documented.” Which is true… and also completely beside the point.

Cadence as retrieval infrastructure

Governance sticks when someone on the team is zealous about forward motion. Not rigid, and not necessarily bureaucratic, but zealous in the sense that they live for making sure things progress — a project manager who cares about the process not because they care about the specific thing being built, but because they care about completion, clarity, and constant progress toward a goal.

Functionally, that person is a retrieval engine — the human version of the “going around the room” manual patch, except this one actually works because someone zealous is driving it. A mechanism that surfaces information at regular intervals — sprint reviews, standups, retrospectives — whether anyone remembers to ask for it or not. When the standup is run well, it’s a forced retrieval event. Information surfaces on a cadence.

The alternative is hoping someone remembers to send the email.

Or check their email.

The structural requirements are straightforward, and achievable:

1. Forced documentation at task boundaries — not as a bureaucratic checkbox, but with enough agency that people understand why it matters, because mandating documentation without a valid reason breeds resentment. Regular cadence checkpoints run by someone who keeps them tight and focused.
2. A queryable knowledge base — not just a loose collection of files in a folder, but something you can actually search and get answers from.
3. Present leadership, not the aloof and distant kind. People who are invested in the day-to-day, every day, not just the quarterly review.

None of this is new or particularly groundbreaking. The principles of good project governance have been documented for decades. Yet organizations keep failing at them anyway — the system requires humans to maintain it, and humans drift. Good people with good intentions will still let documentation go stale, skip the retro when the sprint runs long, and make decisions from memory when the retrieval cost feels too high.

So - do you build infrastructure that accounts for that drift — or continue telling people to communicate better?

The machine that doesn’t drift

If you’re familiar with this site at all, you knew we were going to get to AI.

I manage a fleet of AI agents across multiple projects. Each one has governance documents — the equivalent of an employee handbook that defines standards, patterns, boundaries, and institutional memory. The difference between an AI agent and a human team member is that the agent follows the governance documents every single session, without drift, and without exception.

I built the retrieval infrastructure to be mandatory. The agent reads its governance docs during the welcome sequence at session start. It logs what it did when sleeping at session end, and documents every task as it goes. There’s no option to skip it — the process is embedded in the workflow, not bolted on as an afterthought.

The result is that I can walk away from a project for weeks, come back, and the agent knows the current state — what was done, what’s pending, what broke. And this isn’t a result of the agent possessing perfect memory (it doesn’t — context windows are finite, and closing sessions can be like firing a close acquaintence), but because the retrieval system doesn’t depend on anyone remembering to update it — the system updates itself.

I’ve pushed this even further with a tool called pmem — a local RAG layer that indexes project documents, notes, governance, and lessons learned, and makes them queryable in natural language. Instead of searching through files to find a decision that was made three weeks ago, the agent just asks, and the retrieval system delivers the answer. The cost of retrieval drops to near zero (in tokens, time, and accuracy). And when the cost of retrieval is zero, retrieval actually happens — consistently, every time, without someone having to decide it’s worth the effort.

I even use this process to track projects that AI never even touches, outside of managing the state.

You don’t need AI to do this. Any system that makes querying state cheap and automatic will produce the same effect. The principle is the same whether the retrieval engine is an LLM, a well-structured dashboard, or a zealous project manager with a clipboard.

I built Panoptisana — an open-source Asana visibility tool — because Asana buries the very data you need to manage a project: task status, blockers, overdue items, the actual state of things, and GIDs for various elements, which are a requirement for effective automation. The information existed inside Asana, but retrieving it required navigating through nested projects, expanding task comments, trying to remember which project a task was in, and mentally assembling a picture from fragments.

The cost was too high, so people stopped doing it. Panoptisana surfaces that data in seconds. Panoptisana combined with my Claude Code PM instance and pmem is almost an unfair advantage.

Same problem, same fix: lower the cost of retrieval until it actually happens.

The fix isn’t “communicate better”

When someone says “we need to communicate better,” what they almost assuredly mean is: the system we’re using to store and retrieve shared state doesn’t work, and we’re blaming the humans instead of the infrastructure.

You could have the best communicators in the world on your team and still fail if the inputs are incomplete, the context is scattered across six tools, and the activation energy required to assemble a complete picture is higher than the activation energy required to just guess. Even when someone does communicate clearly — direct language, no hedging, the right level of urgency — it doesn’t matter if the person receiving it has to do archaeology before they can act on it. Parsing through HTML entities in a forwarded email, chasing context across projects that aren’t linked, reconstructing a timeline from disorganized task comments intermixed with Teams chat threads. An often insurmountable retrieval tax on every single action.

The organizations that succeed in this arena don’t have better communicators. They have functional retrieval infrastructure — systems, processes, cadence, and solid project documentation — that surfaces the right information at the right time regardless of whether any individual human remembers to do it manually.

Communication is a retrieval protocol.

Fix the protocol.

---

Sources: Multitasking: Switching Costs — APA summary of Rubinstein, Meyer & Evans (2001), Journal of Experimental Psychology: Human Perception and Performance (task switching costs up to 40% of productive time) · Knowledge Management Failure — synthesis of causal and resultant KM failure factors · Preventing Mistakes Through Effective KM Strategies — KM Institute (operational errors from lack of access to accurate information) · Facilitate the Daily Scrum — Scrum Alliance (standup facilitation as retrieval mechanism)

---

For the architectural methodology behind building retrieval systems: Governance Is Architecture. For the specific documents that make this work: The Governance Documents. For how retrieval architecture applies to cognitive load: Cognitive Offloading. For the ownership question that arises when your retrieval infrastructure becomes portable: Cognitive Property.