How successful companies go blind — and why engineers see it first

What happened

Ian Reppel's essay *How Successful Companies Go Blind* hit the front page of Hacker News this week with 201 points and a comment thread full of engineers nodding in painful recognition. The piece isn't strictly novel — it sits in a lineage running from Clayton Christensen through Andy Grove — but Reppel does something the earlier work mostly didn't: he explains the blindness as a signal-processing problem rather than a leadership failure.

The core argument runs like this. A company wins because it optimizes hard against a specific set of inputs — a customer segment, a distribution channel, a cost structure. Success doesn't just reward the optimization; it rewrites the org's sensory apparatus so that inputs which contradict the winning model get filtered out before they reach anyone with decision authority. The KPIs go green, the quarterly reviews get shorter, and the questions from the board narrow to variations on "how do we do more of what's working."

Reppel walks through the mechanism in three stages: product-market fit becomes identity, identity becomes strategy, and strategy becomes an immune system. By the third stage, the company is structurally incapable of processing signal that says the winning model is decaying. It's not that leadership is stupid. It's that the reporting lines, dashboards, incentive plans, and hiring filters have all been tuned to amplify one kind of signal and suppress every other.

Why it matters

The reason this essay is resonating with developers specifically — and not, say, MBAs — is that engineers occupy the one seat in the org where the contradictory signal is impossible to filter. The codebase does not lie about which assumptions have quietly become wrong. The auth system that was fine at 10k users is now a nightmare at 10M. The monolith that shipped features weekly in 2019 now takes six weeks to land a checkbox. The vendor that was "strategic" three years ago is now a single point of failure with a support queue measured in weeks. None of this shows up on the CEO's dashboard, but it shows up in every retro, every on-call rotation, every migration doc that gets started and abandoned.

Compare this to how the same signal is handled in domains with tighter feedback loops. Trading desks blow up in hours; the P&L is honest by design. Aircraft manufacturers investigate every anomaly because the alternative is a Congressional hearing. Software companies, by contrast, can run on inertia for years — the revenue keeps landing on renewal cycles even after the product has stopped mattering. That lag between decay and consequence is exactly the window in which blindness accumulates.

A thread of comments on the HN post makes a sharper version of the point: the people most likely to see the decay are also the people least incentivized to escalate it. Senior engineers who flag the problem get labeled "negative." Staff engineers who propose the rewrite get told to focus on Q3 deliverables. The ones who eventually leave take the diagnosis with them, and the ones who stay learn to stop mentioning it. By the time a strategy consultant is hired to "assess platform risk," the engineers who could have answered the question honestly have been gone for two years.

Reppel doesn't quite name this dynamic, but it's the piece his framework needs. Organizational blindness isn't a passive failure to see — it's an active pruning of the humans who see. The immune system he describes at the strategy layer runs, in practice, through performance reviews and reorg cycles.

What this means for your stack

The uncomfortable implication for senior developers is that the classic engineering response — write a better tech-radar deck, cite more benchmarks, propose a cleaner migration — is aimed at the wrong layer. The problem isn't that leadership hasn't seen your evidence. It's that the reporting apparatus was designed to make evidence like yours structurally illegible. A better slide won't fix that.

What does work, in the companies that avoid the pattern, is building *institutional* channels for engineering signal that don't route through the org chart. A few concrete examples from the comment thread and adjacent literature: standing architecture-review boards with the authority to veto product commitments, not just annotate them; incident retros that get read by the CFO, not just the SRE lead; and staff-plus engineer time explicitly allocated to writing decision memos aimed at the board. These sound bureaucratic, and they are — but the alternative is that the only surviving signal about your platform's health is the one leadership already agrees with.

For individual engineers, the practical takeaway is smaller and more actionable. Write things down. Not in Slack, where they scroll off in a day. Not in Notion, where they get lost in a reorg. Write them in the codebase — in ADRs, in postmortems checked into git, in commit messages that explain the constraint you were working around. The code is the one artifact in the company that survives every reorg and every strategy pivot, and it is the only place where an honest record of what you actually knew will still be readable to your successor. You are not writing for your current leadership. You are writing for the engineer who inherits this system in 2029 and needs to prove to *their* leadership that the decay was visible and documented years earlier.

This reframes a lot of the tedious documentation work that senior engineers grumble about. The DR runbook, the architecture decision record, the deprecation notice nobody reads — these aren't compliance theater. They're the audit trail that makes the invisible visible on a long enough timeline. They are, in Reppel's framework, the countermeasure to the immune system.

Looking ahead

The essay's timing is not accidental. We are watching, in real time, a cohort of once-dominant tech companies discover that the assumptions they optimized against in 2015 no longer hold — the ad market has fragmented, the platform lock-ins have loosened, the AI stack has rewritten the cost curve on every product they ship. The interesting question isn't which of them will fail; it's which of them still have engineering cultures where the contradicting signal can travel upward without being killed on the way. Reppel doesn't answer that question, but he gives you a diagnostic. If your last three architecture proposals died in review with the phrase "not aligned with strategy," you already have your answer.