Where Decisions Go to Die

"Why do we use Redis for sessions?"

Slack

Meetings

Linear

GitHub

Notion

The code knows we use Redis. Not why.

The 7-tool problem

Last month, a new engineer at a company I advise asked a simple question: "Why do we use Redis for session storage instead of PostgreSQL?"

The answer existed. It just wasn't in one place.

It started in a Slack thread six months ago, when the backend lead mentioned they were hitting performance issues. The discussion continued in a 30-minute call that wasn't recorded. Someone created a Linear ticket to "evaluate caching options." The actual decision was made in a PR comment: "Let's go with Redis—see discussion." The PR was merged with a commit message that said "Add Redis session store."

The code was clean. The tests passed. But the why—the performance numbers, the alternatives considered, the trade-offs evaluated—had evaporated.

This is what researchers call knowledge vaporization. And it happens every day, in every team, across every tool you use.

The journey of a decision

Every technical decision follows a predictable path:

💡 Idea (someone's head)
    ↓
💬 Discussion (Slack thread)
    ↓
📞 Meeting (Zoom/Meet call)
    ↓
📋 Ticket (Linear/Jira)
    ↓
🔀 Implementation (GitHub PR)
    ↓
💻 Code (repository)
    ↓
📄 Documentation (maybe Notion)

Here's the problem: only the last two steps survive. The code persists. The documentation (if someone writes it) persists. Everything else—the discussion, the meeting, the context, the alternatives considered—disappears into the void.

The decision happened. But the reasoning is gone.

This isn't a new problem

Software architecture researchers have been studying this for decades. In 2005, Jansen and Bosch published a landmark paper introducing the concept of Architectural Knowledge—the idea that software architecture isn't just the code, but also the decisions that shaped it.

Their key finding: most architectural knowledge is never captured. It "vaporizes" almost immediately after decisions are made.

"Architecture decisions are often made informally, in hallway conversations or meetings, and are rarely documented. The knowledge behind these decisions—the alternatives considered, the trade-offs evaluated, the constraints that drove the choice—is lost within days or weeks."

— Jansen & Bosch, "Software Architecture as a Set of Architectural Design Decisions" (2005)

This was before Slack. Before GitHub. Before Linear. Before the explosion of tools we use today.

The problem has only gotten worse.

The research is damning

Study	Finding
Gloria Mark, UC Irvine (2008)	Workers need 23 minutes to recover context after an interruption
McKinsey Global Institute	Knowledge workers spend 9.3 hours/week searching for information
Gartner (2023)	47% of workers struggle to find information they need; 32% make wrong decisions due to lack of context
Slack Workforce Lab (2023)	33% of work time is spent searching for information
Qatalog & Cornell (2021)	Workers toggle between apps 1,200 times per day

The average engineering team uses 7+ tools for collaboration: Slack, GitHub, Linear/Jira, Notion/Confluence, Google Meet/Zoom, email, and documentation sites. Each tool captures a fragment of the decision. None captures the whole picture.

The cost is staggering

Let me put numbers to this.

For a single decision:

Slack discussion: 15-30 messages across 2-3 people
Meeting: 30-60 minutes, 3-5 participants
Linear ticket: 200 words of context
PR review: 5-20 comments
Final artifact: 50 lines of code + 3-line commit message

The ratio of context-to-artifact is roughly 100:1. For every line of code that survives, 100x more context was generated and lost.

At scale:

Metric	Impact
Time to onboard new engineer	3-6 months (much of it re-discovering decisions)
Senior engineer time answering questions	15-20% of their week
Decisions re-made due to lost context	~30% (industry estimate)
Cost of context switching	$450B annually in the US economy

When I was CTO at Bemmbo, our senior engineers spent roughly 2 hours per day answering questions from the team. Not because they wanted to be bottlenecks—because they were the only ones who remembered why we built things a certain way.

Why documentation doesn't fix this

The obvious answer is "just write it down." Create ADRs (Architecture Decision Records). Maintain a wiki. Document everything.

Here's why that fails:

1. The people who know don't have time

The engineers making decisions are the same engineers building features, reviewing PRs, debugging production issues, and attending meetings. Documentation is always deprioritized.

Nonaka and Takeuchi, in their seminal work "The Knowledge-Creating Company" (1995), distinguished between tacit knowledge (in people's heads) and explicit knowledge (written down). Their research showed that converting tacit to explicit knowledge requires significant effort—effort that rarely happens in fast-moving teams.

2. ADRs only capture "big" decisions

Architecture Decision Records are great for major choices: "We're switching from MongoDB to PostgreSQL." But most knowledge loss happens in the small decisions:

Why does this API return a 403 instead of a 401?
Why is this field nullable?
Why do we retry this operation exactly 3 times?

These decisions are too small for formal documentation, but too important to lose.

3. Documentation decays instantly

Code changes. Documentation doesn't update itself. Within months, even well-maintained docs diverge from reality. Engineers learn to distrust documentation—and default to asking the person who wrote the code.

4. Wikis become graveyards

Every company has a Confluence or Notion workspace with hundreds of pages. Most of them haven't been viewed in months. The search is terrible. The organization is worse. Engineers learn it's faster to interrupt a colleague than to dig through the knowledge base.

The real problem: decisions don't live where we search

Think about how you search for information:

GitHub indexes code—you can find what exists
Notion indexes documents—you can find what someone wrote
Slack indexes messages—but search is terrible and context is fragmented
Linear indexes tickets—but only the description, not the discussion
Your memory indexes everything—but it doesn't scale

None of these tools index decisions. None of them can answer "why did we build it this way?"

The answer to that question is scattered across 4-5 different systems, connected only by timestamps and the memories of people who might not work here anymore.

A different framing

In 1999, Hansen, Nohria, and Tierney published "What's Your Strategy for Managing Knowledge?" in Harvard Business Review. They identified two strategies:

Codification: Capture knowledge in documents and databases (the wiki approach)
Personalization: Connect people who have knowledge with people who need it (the "ask Sarah" approach)

Most companies default to personalization—not because it's better, but because codification is too expensive. The friction of documenting every decision is higher than the cost of interrupting colleagues.

But what if you didn't have to choose? What if decisions could be captured where they happen, without requiring anyone to stop and document them?

That's the question we're exploring with Emisso.

The path forward

The solution isn't more documentation. It's capturing decisions in the flow of work—in the Slack threads, in the PR comments, in the meeting transcripts—and connecting them to the code they produced.

When someone asks "why do we use Redis for sessions?", the answer shouldn't require:

Searching through 6 months of Slack history
Finding the right PR among hundreds
Interrupting the engineer who made the decision
Hoping someone remembers

It should be one query away.