Your smartest engineers are making terrible decisions. Not because they're incompetent, but because they're operating in the dark.
It's not a character flaw. It's an information architecture problem.
The Information Asymmetry Problem
Consider a senior engineer designing a new service. They're talented. They're experienced. They know best practices.
What they don't know:
That a similar approach was tried three years ago and failed
That there's a constraint from a regulatory requirement decided last quarter
That another team is building something similar
That the performance characteristics of a dependency have changed
They make the best decision possible given the information they have. Unfortunately, the information they have is incomplete.
Why Information Fails to Flow
Information Silos
Teams optimize for local efficiency. The database team knows everything about database decisions. The frontend team knows everything about frontend decisions. Neither knows about the other.
Cross-cutting decisions fall into gaps.
Information Decay
Decisions made six months ago are half-remembered. Decisions made two years ago might as well not exist.
Context evaporates faster than code.
Information Overhead
There's too much documentation. Most of it is noise. Finding the relevant signal requires knowing what to look for.
If you knew what to look for, you wouldn't need to search.
Information Hoarding
Some information stays in heads because writing takes time, having information is power, or "they'll ask if they need to know."
Critical context remains inaccessible.
The Decision Quality Framework
McKinsey research identifies factors that separate good from bad decisions:
What Matters
What Doesn't Matter (as much as you'd think)
The Case Study: Knight Capital
Knight Capital Group, August 1, 2012
Deployed code that reactivated dormant functionality from eight years earlier. Executed over 4 million erroneous trades.
The engineers who deployed weren't incompetent. But they lacked information:
- What did the old code do?
- Why was it kept in the codebase?
- What flags controlled its activation?
Decisions made years earlier—and never documented—created a time bomb that destroyed the company.
The Pattern: Decisions Without Context
You've seen this pattern play out countless times:
The Pattern: Decisions Without Context
Without documented decisions: past failures teach no lessons, past successes aren't replicable, every decision starts from scratch.
Building an Information Architecture
Decision Records
- What was decided
- Why it was decided (constraints, goals)
- What alternatives were considered
- What tradeoffs were accepted
Decision Relationships
- Dependencies: "This decision assumes X from decision Y"
- Conflicts: "This contradicts decision Z"
- Supersession: "This replaces old decision Q"
Decision Currency
- Review dates: When should this be reconsidered?
- Validity conditions: Under what circumstances does this apply?
- Staleness indicators: What would trigger review?
The difference between a good and bad decision record:
Making Information Findable
Captured information that can't be found is useless. Invest in:
Search
- Full-text search across decisions
- Filtered by team, date, topic
- Semantic search (concepts, not just keywords)
Surfacing
- Relevant decisions appear when working on related code
- New engineers get recommended reading
- Stakeholders notified when related decisions change
Visualization
- Decision graphs showing relationships
- Timeline views showing evolution
- Dependency maps showing impacts
The Counterfactual
Imagine an engineer making a decision with full context versus without:
"I'm designing the new caching layer. Let me check what we've decided before...
Ah, there was a decision three years ago about caching strategy. They chose write-through but noted our workload might shift. Our workload has shifted—we're now 90% reads. And there's a decision from the platform team about Redis standardization.
Given this context, my proposal is..."
"I'm designing the new caching layer. I'll use what I learned at my last job..."
Same engineer. Different information. Different decision quality.
The Organizational Shift
Moving from "good engineers figure it out" to "good information enables good decisions" requires:
Cultural Shift
- Document decisions as they happen
- Treat documentation as deliverable, not overhead
- Recognize contributors to institutional memory
Process Shift
- Decision capture integrated into workflow
- Review cycles that revisit old decisions
- Onboarding that includes decision history
Tool Shift
- Searchable decision repository
- Relationship tracking between decisions
- Alerts when decisions might be affected by changes
Your engineers aren't making bad decisions because they're bad at deciding.
They're making bad decisions because they don't have the information they need.
Fix the information, and you fix the decisions.