Every organization is full of unmarked graves
The way a system handles mistakes tells you more about its values than anything it says about itself. Banking, git, and distributed databases all default to keeping history. Organizations are the one system that still believes in erasure.
Every system has to answer the same question eventually: what do you do with mistakes?
Not how you prevent them. Not how you detect them. What you do once they’ve already happened and everyone knows it. That’s where values live — not in the mission statement, but in the error-handling policy.
Banking figured this out five hundred years ago. When Luca Pacioli codified double-entry bookkeeping in 1494, he described a system with one inviolable rule: you never erase a line in the ledger. If you recorded the wrong amount, you don’t scratch it out. You add a new line that corrects it. Both lines exist forever — the mistake and the fix, side by side, visible to anyone who looks.
This seems like extra work until you realize what it buys you. Any auditor can reconstruct what happened and when. Any pattern of errors becomes visible because the original entries are still there to analyze. Keith Devlin, writing for the Mathematical Association of America, argues the system literally enabled modern capitalism: the Medici Bank used it to expand beyond traditional banking, Josiah Wedgwood used it to discover fixed versus variable costs, and by 1800 it was standard across Europe. Not bad for a system whose core insight is “never throw anything away.” (Though as we’ll see, even Pacioli’s ledger has a cost — a ledger that grows without curation eventually buries its own signal.)
Software engineers reinvented this principle independently, several times, without apparently reading any accounting history. Git, the version control system that runs most of the world’s software development, has two ways to undo a mistake. git revert adds a new commit that reverses the old one — both the mistake and the fix stay in the history forever. git reset pretends the mistake never happened. The community argues endlessly about which is correct, and the consensus essentially says: revert for anything anyone else has seen, reset only for your private drafts. Shared history is sacred.
Distributed databases use something called a “tombstone” — when you delete a record, it isn’t actually removed. A marker is placed where it used to be: this thing existed, and now it doesn’t. The tombstone stays because in an eventually consistent system, other machines need to know the deletion was intentional, not a glitch. Without it, a node that missed the memo would cheerfully replicate the “missing” data back into existence. The ghost of the data protects the integrity of the system.
Event sourcing takes it further. The entire state of a system is derived from a sequence of events that can never be modified. Nothing is updated. Nothing is deleted. The current state is just the sum of everything that ever happened, stretching back to the first transaction.
These aren’t niche techniques. They’re the dominant patterns in serious systems engineering. And they all share the same assumption: a record of what went wrong is more valuable than a clean record of what’s right.
Organizations are the one system that still believes in erasure. They restructure and call it “alignment.” They lay people off and call it “optimization.” They abandon a strategy and call it “pivoting.” Each time, the institutional memory of what was tried and why it failed walks out the door. Arnold Kransdorff calls institutional forgetting “the single biggest constraint to decision-making excellence.” One writer discovered his organization had attempted to solve the same problem five times over a decade, each attempt failing because no team ever reviewed why the previous ones didn’t work. Five teams, five failures, zero learning — because each reorg erased the evidence.
Not everyone gets this wrong. Japanese companies like Ricoh have maintained corporate memory across 40+ years using a system that looks a lot like a human version of event sourcing. Senior engineers mentor juniors not just on technique but on why decisions were made. Employees rotate through departments so knowledge isn’t siloed in one head. Documentation isn’t a box-checking exercise — it’s a living system maintained by communities of practice who treat institutional knowledge the way a database treats its records: as infrastructure that the whole system depends on, not overhead that gets cut when budgets tighten. The result is an organization that can tell you not just what it does, but why it stopped doing the thing it did before — and what happened when it tried the thing you’re about to suggest.
So the case for retention seems airtight. Keep everything. Never delete. Build the append-only organization.
Except Nietzsche would tell you that’s a recipe for paralysis.
In On the Genealogy of Morals, Nietzsche argues that forgetting is not a defect — it’s an “active and in the strictest sense positive faculty of repression,” a mental gatekeeper that blocks unnecessary impressions so consciousness can function. Without it, the mind is overwhelmed. He goes further: “there can be no happiness, cheerfulness, hope, pride, immediacy, without forgetfulness.” Psychological health depends on the capacity to let things go.
In On the Use and Abuse of History for Life, he makes the organizational version of this argument. A person — or by extension, an institution — that cannot forget the past is paralyzed by constant awareness of everything that has ever happened. The ability to stand “on the crest of the moment” by deliberately setting aside what lies behind is required for joy, creativity, and decisive action. An organization drowning in its own decision logs can’t make new decisions. A team that reviews every post-mortem before every sprint eventually stops sprinting.
This isn’t a contradiction. It’s a design problem.
The append-only ledger and Nietzsche’s active forgetting are both right, and the tension between them is where the real work happens. The question isn’t whether to remember or forget. It’s who decides what to keep and when to let go. Banking makes the ledger mandatory and the forgetting impossible. Git makes history automatic and deletion deliberate. These are systems that have chosen a default — remember everything — and then made the exception (forgetting) require explicit justification.
Organizations do it backwards. They make forgetting automatic (people leave, reorgs happen, Slack channels get archived) and remembering optional (post-mortems when there’s time, decision logs when someone’s motivated). The defaults are wrong. Not because everything should be kept — Nietzsche is right that an organization crushed under the weight of its own history can’t move — but because the decision about what to forget should be deliberate, visible, and justified. The same way a database administrator decides which tombstones to finally garbage-collect, not by accident, but by policy.
The real skill, as Nietzsche puts it, is knowing “when to forget at the right time just as well as we remember at the right time.” Wisdom isn’t total retention or total forgetting. It’s the judgment to know which memories are still load-bearing and which ones are just weight.
The engineers who named the database deletion marker a “tombstone” understood something the rest of us are still working out. A tombstone isn’t the thing itself. It’s proof that the thing once lived — placed deliberately so anyone passing through later knows: this absence is not an accident. Something was here. Someone decided it shouldn’t be anymore. And they left a marker so you’d know to ask why.
Every organization is full of unmarked graves. The systems we build for machines solved this problem decades ago. The systems we build for people still pretend that forgetting is free — and that the only cost worth tracking is the cost of remembering.
The agent-shaped org chart
Every real org has the same topology: principal, role-holder, specialists. Staff AI maps onto it, node for node, and the cost collapse shows up in the deliverables that were always just human-handoff overhead.
AI as staff, not software
Two frames for what AI is doing to work. The tool frame makes tools smarter. The staff frame makes roles unnecessary. Those aren't the same product, the same company, or the same industry.
Knowledge work was never work
Knowledge work was always coordination between humans who couldn't share state directly. The artifacts were never the work. They were the overhead — and AI just made the overhead optional.
The work of being available now
A book on AI, judgment, and staying human at work.
The practice of work in progress
Practical essays on how work actually gets done.
How to manage content for multiple clients without flattening their voices
How to manage content for multiple clients without their voices blurring into one house style: a workspace and a voice profile per client, batchable stages, and approval buffers.
Why does AI writing sound generic? It has nothing to work with
Why does AI writing sound generic? Because the model has none of your perspective, examples, constraints, or stakes to work with. The fix is interview-first, not better adjectives.
How to train AI to write in your voice, not your vibe
How to train AI to write in your voice isn't a prompt trick. It's a system: writing samples, interview answers, keep/avoid lists, revision loops, and approval gates.
The chain was never a chain
On roles, fleets, and the Hegelian reversal waiting at the end of the AI transition. The sequel to Knowledge Work Was Never Work and Apps Are Irrelevant.
The first real user breaks everything
Your product works until someone actually uses it. The gap between 'works in dev' and 'works for a person' is where most systems fail — and most organizations avoid looking.
The loop nobody bothers to close
Most systems observe. Almost none learn. The difference is a feedback loop — and the boring cleanup work that makes it possible.