It usually starts small enough that no one questions it. A message dropped into Slack, almost as an aside, something that doesn’t seem to require any ceremony: “Can someone check this quickly?” There’s no explicit urgency, no structured context, no indication that this will take more than a few minutes. If anything, it feels efficient. Faster than opening a ticket, lighter than scheduling a meeting. Just a quick check, something that can be resolved in the flow of work.
Someone picks it up. Maybe not immediately, but soon enough to preserve the illusion of momentum. They open the link, scan the numbers, try to understand what they’re looking at. And that’s where the first quiet friction appears: the context isn’t given, it has to be reconstructed. A dashboard here, a screenshot there, a sentence or two attempting to explain why this exists in the first place. But what exactly is being asked? Is this about validating accuracy, completeness, or the reasoning behind a decision that may have already been made somewhere else?
Without that clarity, the only viable move is to respond with another question. And at that moment, almost imperceptibly, time stops behaving in a straight line.
The answer doesn’t come immediately. It comes when it can—ten minutes later, thirty, maybe after another meeting. When it does arrive, it resolves part of the ambiguity, but not all of it. It’s always enough to keep going, rarely enough to finish. So the person checking goes a bit deeper, pulls in another source, cross-references something they vaguely remember seeing before. They find a discrepancy, or at least something that doesn’t fully line up. What started as a simple verification is now a small investigation.
Someone else gets pulled in, not because they should be, but because it seems like the fastest path forward in the moment: “Hey, do you know why this number is different here?” That person joins without the original context, reconstructing everything from even thinner fragments. They answer based on memory, which helps—but also introduces another layer of ambiguity. The conversation stretches, branches, starts to exist in multiple places at once.
Meanwhile, the original reason for the “quick check” is sitting idle. Sometimes it’s critical, sometimes it isn’t. It might be blocking a deploy, delaying a campaign, or simply occupying mental space in the background. The specific impact varies, but the effect is the same: something that was meant to unblock progress is quietly introducing latency.
By the time it resolves, two hours have passed. No one logs it as work. No one tracks it as a delay. There’s no ticket, no metric, no postmortem—no artifact that makes that time visible. What remains is a diffuse sense of fragmentation, the feeling that the day moved slower than it should have, despite being full.
What looks like speed in chat is actually operational amnesia — and the cost never shows up in a single thread.
The issue is that this isn’t an exception. It’s a pattern. And it doesn’t happen because people are careless or underperforming. It happens because the system makes this behavior the path of least resistance. These “quick checks” are, in reality, decisions without a clear home. They don’t belong to a defined process, they’re not captured by a specific tool, and they don’t have explicit ownership. They exist in the ambiguous space between “this should be obvious” and “someone needs to look at this more closely.”
And anything that lives in that space inevitably ends up in chat.
The problem isn’t the legitimacy of the question. In most cases, something genuinely does need to be verified. The problem is how that verification happens—without sufficient context, without explicit criteria, and without a clear definition of what “done” actually means. Every time this occurs, you’re not just answering a question; you’re spinning up a process from scratch. Context has to be assembled manually, criteria are inferred in real time, and responsibility is negotiated on the fly.
None of this is visible, but all of it consumes time.
That consumption doesn’t show up as major interruptions. It manifests as continuous fragmentation of attention—the cost of stepping into someone else’s partially formed problem, holding it long enough to move it forward, and then attempting to return to your own work. Repeated across a day, across a team, this creates an operation that appears busy on the surface but moves unevenly—fast in short bursts, then stalled in pockets of ambiguity.
What makes this particularly difficult to address is that each instance feels trivial. It’s just a question. Just a check. Just a handful of messages. In isolation, none of it seems worth fixing. But collectively, these moments define the tempo of the organization. They determine whether work flows or constantly resets.
The typical response is to add more structure elsewhere—more dashboards, more documentation, more formalized workflows. But these micro-decisions don’t fit neatly into those systems. They are too dynamic, too context-dependent, too reliant on judgment. So they continue to leak out, returning to the same place every time: chat.
And chat, by design, is a poor environment for this kind of work—not because it’s inefficient as a tool, but because it strips decisions of the very properties they need to become faster over time: clear inputs, explicit criteria, defined ownership, and, critically, memory. Without those, every “quick check” becomes a small act of reinvention. And reinvention, even at a small scale, is expensive—not because of the effort in any single instance, but because of how often it repeats.
This is why, almost inevitably, these flows begin to concentrate around the same people. The strongest operators—the ones with the most context, the best pattern recognition, the sharpest judgment—are pulled into these decisions because they can resolve them quickly. But that creates a secondary effect: their time becomes consumed by a continuous stream of low-visibility, high-friction decisions. It’s not that they are the only ones capable of making these calls; it’s that the system offers no alternative.
At that point, the issue is no longer about isolated inefficiencies. It becomes structural. This isn’t a talent problem, and it’s not exactly a process problem in the traditional sense. What’s missing is a way to treat decisions as first-class units of work—something that carries context, makes criteria explicit, defines ownership, and accumulates learning over time. Right now, each of these moments exists as an isolated event. Nothing connects, nothing compounds, nothing gets easier the next time.
The result is a form of operational amnesia. The same questions resurface, the same ambiguities have to be resolved, and the same people get pulled back into the loop. What looks like speed—handling things quickly in chat—is actually masking a system that fails to retain knowledge and therefore never builds momentum.
At some point, the problem stops being the two hours lost in a single thread. It becomes the realization that this is how decisions are made across the entire operation: informally, repeatedly, and without ever becoming easier the next time. And that’s where the real cost emerges—not as a single measurable loss, but as a constant, underlying drag that slows everything down.
