You already know how this goes.
New tool shows up. Everyone gets excited. Teams adopt it. Projects fail. The tool gets blamed. Someone writes the “Why We Abandoned X” post. A newer tool shows up. Back to the top of the script.
Microservices were going to fix the monolith. Then microservices became the problem. Kubernetes was going to fix the infrastructure. Then Kubernetes became the infrastructure. AI is going to fix the productivity problem. And three years from now, someone will write a blog post titled “Why We Abandoned AI” that describes the exact same failure pattern: good tools, applied without understanding, to problems they were never designed to solve.
The tool is not the problem. It never was. The problem is that the knowledge of how to use a tool well, when to apply it, when to walk away, what trade-offs you’re signing up for, what mistakes the last ten teams already made, lives in the wrong places. In the heads of senior engineers who leave. In Slack threads that expire. In post-mortems nobody reads. In consultancy reports that cost six figures and gather dust.
We need knowledge management that works like code. Versioned. Reviewed. Executable. Open. Alive.
01. Problems
The analysis
The blame cycle
The pattern is so consistent you could script it.
Phase one: a technology gains momentum. Conference talks. Vendors. Job postings. Phase two: teams adopt it without understanding the preconditions for success. Phase three: projects struggle, not because the technology is bad, but because it got applied to the wrong problem, at the wrong scale, by people who didn’t have the context to use it right. Phase four: blame the tool. Phase five: a new tool shows up. Restart.
Docker did not fail anyone. Teams that containerised stateful applications without thinking about data persistence failed themselves. Kubernetes did not make operations harder. Teams that reached for it to orchestrate three services, when a systemd unit file would have done the job, made operations harder. Microservices did not create distributed system nightmares. Teams that split a monolith into two hundred services without understanding what a microservice actually is, where its boundaries belong, what it costs to run, what distributed systems demand in return, made those nightmares themselves.
The tool is seldom the root cause. The absence of knowledge about how to use the tool is the root cause. And that knowledge exists. It’s just not in the room when the decision gets made.
Knowledge trapped in heads
The most valuable technical knowledge in any organisation lives in the heads of maybe five to ten people.
They know which architectural decisions were made, and why. They know which vendor promises turned out to be lies. They know the three things you must never do with the payment system on a Friday. They know that the auth service works because of a bug that everyone has agreed to pretend is a feature.
Then they leave. They always leave.
When they go, the knowledge walks out with them. The organisation keeps the code. Loses the reasoning. Inherits the system. Does not inherit the judgement that built it.
The documentation graveyard
Most organisations have documentation.
It is out of date. Scattered across four platforms. Written in a style that assumes context the reader does not have. Maintained by no one. Wikis rot. Confluence pages become archaeology. READMEs describe systems that have not existed in years.
The problem is not that people don’t write documentation. The problem is that documentation is treated as a one-time artefact instead of a living system. Nobody reviews it. Nobody revises it. Nobody owns it. It is the first thing written and the first thing forgotten.
Best practices without context
The internet is full of best practices. Most of them are harmful.
“Always use microservices.” A best practice. “Always write unit tests.” A best practice. “Always use a message queue.” A best practice. None of them are true. Not without context. What is your scale? Your team size? Your deployment cadence? The cost of failure? A best practice with no stated context is just a popular opinion with better marketing.
And yet teams keep citing them, in design docs, in architecture reviews, in interviews, as if the label alone carried authority. It doesn’t. A best practice that worked at Netflix in 2018 is not a best practice for your three-engineer team in 2026. It is a historical note.
We do not have a tooling problem. We have a memory problem. The industry keeps learning the same lessons and forgetting them on a three-year cycle.
What policy-makers must do
Stop funding technology adoption. Start funding technology understanding. Every public sector digital programme should allocate a minimum percentage of its budget to knowledge capture: architectural decision records, post-mortems, pattern libraries, context-rich documentation. If the knowledge cannot survive the team that made it, the investment is temporary.
Require decision records on public projects. Every significant technology choice on a publicly funded project should be documented. What was decided. What alternatives were considered. Why this option was chosen. What would trigger a reversal. This is not bureaucracy. It is institutional learning. The thing every public institution claims to want and almost none of them fund.
Fund open knowledge commons for the public sector. A shared, searchable, version-controlled record of technical decisions, patterns, and anti-patterns from government IT projects. Across municipalities. Across agencies. Across nations. The same mistake made in Stockholm and in Rotterdam is a mistake that should have been made only once.
Speaking partners
Government digital service agencies (GDS, 18F, DIGG in Sweden). ThoughtWorks and similar practice-led consultancies willing to open-source their methodology. The InnerSource Commons. Maintainers of open documentation frameworks (Docusaurus, MkDocs, Backstage). And, most of all, the senior engineers and architects already inside government who maintain informal knowledge networks despite every incentive to keep their heads down.
What individuals & companies can do
Write decision records. Not just documentation. Every time your team makes a significant technical choice, write an ADR: the context, the decision, the consequences. Fifteen minutes. In two years, when someone asks “why did we use Kafka here?”, the answer exists. And it is not “because Dave thought it was cool, and Dave left.”
Stop blaming the last tool. Before your team walks away from a technology, ask the three questions. Did we understand the preconditions for its success? Did we have the skills to use it correctly? Did we apply it to the right problem? If the answer to any of those is no, the next tool will fail for the exact same reason. You will just get to rename the failure.
Build a failure library. Document not just what worked but what didn’t, and why. Make it searchable. Make it part of onboarding. The most valuable knowledge in any organisation is the list of things that have already been tried and have already failed.
02. Solutions
The analysis
Knowledge as code
The software industry solved the problem of collaborative, versioned, reviewable work product decades ago. It is called version control.
Code is written. Reviewed by peers. Merged. Versioned. Tested. Deployed. If it breaks, you revert. If it is wrong, someone submits a correction. If it is outdated, the diff shows when it changed and who changed it.
Knowledge about technology decisions should work the same way. Not wiki pages anyone can edit and no one reviews. Not PDFs that are correct the day they ship and wrong the day after. Living documents in version-controlled repositories. Subject to pull requests. Subject to peer review. Subject to continuous integration. When a best practice changes, the change is tracked. When a pattern is deprecated, it is marked, not deleted, so the reasoning survives.
Contextual pattern libraries
A pattern library is not a list of best practices.
It is a collection of solutions, each annotated with the problem it solves, the context in which it works, the context in which it fails, the trade-offs it introduces, and real examples of both success and failure.
“Use event sourcing” is not a pattern. “Use event sourcing when you need a complete audit trail, when your team has distributed systems experience, and when you can tolerate eventual consistency. Avoid it when your domain is simple, your team is small, or you need strong consistency.” That is a pattern.
These libraries should be open, collaborative, and opinionated. Not neutral surveys of every possible option. That is what Google is for. Opinionated guides that say: in this context, do this. In that context, do not. Here is why. Here is what happened when someone ignored the advice.
Open KMS: knowledge management that ships
Most knowledge management systems are built for managers who want to organise information. They need to be built for practitioners who want to find answers.
The difference is fundamental. Managers want taxonomy, hierarchy, dashboards. Practitioners want search, context, and examples. One group wants to see the whole map at once. The other just wants to find the right road.
An open KMS for technical leaders should be: version-controlled (Git-based), searchable (full-text and semantic), contextual (tagged with team size, domain, scale, technology), peer-reviewed (pull request workflow), executable (runnable examples, not just descriptions), and federated (organisations contribute to a shared commons while keeping private extensions).
The tools exist. Git. Markdown. Static site generators. Semantic search. The stack is mature and free. What is missing is the curation. Someone has to decide what goes in, what the quality bar is, how to keep it alive. That is a community problem, not a technology problem. And community problems are harder than technology problems, which is why the industry keeps trying to solve this with another product.
The anti-pattern catalogue
Best practices get all the attention. Anti-patterns are more valuable.
Knowing what not to do, and why, prevents more damage than knowing what to do. An open, community-maintained catalogue of technology anti-patterns, each documented with the pattern, why it seems like a good idea at the time, why it fails, what to do instead, and examples of the failure. This would save the industry billions in repeated mistakes.
This catalogue already exists informally. Scattered across blog posts. Conference talks. Twitter threads. Slack DMs. It needs to be consolidated, structured, and maintained. Not by a vendor with a product to sell, but by practitioners with scars to share.
The best code is reviewed before it ships. The best decisions should be reviewed before they are made, against a record of every time the same decision was made before.
What policy-makers must do
Fund an open-source KMS for the public sector. Not a SaaS product from a vendor. A Git-based, community-maintained, nationally hosted knowledge base of technology patterns, anti-patterns, and decision records from public sector projects. Seed it with retrospectives from completed projects. Make contribution a condition of future funding.
Mandate post-mortems as deliverables. Every publicly funded IT project should produce a structured post-mortem on completion. What worked. What did not. What would be done differently. Publish it. Index it. An organisation that funds ten projects and captures ten post-mortems is building institutional intelligence. One that funds ten projects and captures none is buying the same lesson ten times and calling it variety.
Create cross-agency knowledge exchanges. Secondments. Shared retrospectives. Joint architecture reviews. The municipality that solved the identity verification problem last year should be in the room when the next municipality starts. This costs almost nothing. The savings are enormous. The only reason it does not happen is that nobody is paid to make it happen.
Speaking partners
InnerSource Commons. The Architectural Decision Records community. Backstage adopters and contributors. Open-source documentation communities. DevOps and platform engineering networks. The growing community of practice around engineering effectiveness, particularly the leads at companies like Spotify, Zalando, and Klarna who have already built internal knowledge systems at scale.
What individuals & companies can do
Adopt ADRs tomorrow. Architectural Decision Records take fifteen minutes to write and save weeks of re-litigation. Use the format: Title, Status, Context, Decision, Consequences. Store them in the repository next to the code they describe. If your team does nothing else from this article, do this.
Build your team’s pattern library. Start small. Five patterns your team uses often. Five anti-patterns you have learned the hard way. Put them in a Git repo. Review them every quarter. Share them with new hires on day one. This is your most valuable onboarding document. It will also be the one document everyone actually reads.
Contribute to open knowledge projects. If you have learned an expensive lesson, write it up. Not as a blog post that will be buried in a month. As a structured contribution to a shared knowledge base. Projects like the Technology Radar, the DORA reports, and the C4 model all started as one practitioner’s hard-won knowledge, shared openly.
Review decisions, not just code. Add a decision review step to your development process. Before committing to a significant technical choice, check: has this been tried? What happened? What were the preconditions for success? If your team cannot answer these questions, you are making the decision blind. And you will get the result that blindness usually gets.
03. Opportunities
The analysis
Breaking the cycle
The three-year blame cycle is not inevitable. It persists because the industry has no institutional memory.
Each team, each company, each new generation of developers starts from scratch. Makes the same mistakes. Different brand names. The team that adopted SOA badly in 2008 is the team that adopted microservices badly in 2018 and will adopt AI agents badly in 2028. The technology changes. The failure mode does not.
Breaking the cycle does not require better tools. It requires better knowledge infrastructure. If every significant technical decision were recorded, reviewed, and searchable, if every failure were documented with the same rigour as every success, the industry would learn at the rate it invents, instead of limping three years behind its own experience.
AI-augmented knowledge systems
Here is the irony.
AI is exceptionally good at the exact problem the industry refuses to solve manually. Semantic search across decision records. Pattern matching across post-mortems. Surfacing relevant precedent the moment a team proposes a decision.
An AI-augmented KMS could, when someone says “let’s use event sourcing for the billing system,” immediately surface: three previous projects that tried this, two that succeeded with these preconditions, one that failed for this reason, and the resulting recommendation. Not because the AI is clever. Because the record exists, and the AI can read it.
This is not speculative. The components exist. The thing that is missing is the structured knowledge to feed them. AI cannot learn from lessons that were never recorded.
Competitive advantage through institutional memory
The company that remembers is faster than the company that rediscovers.
Every decision that does not need to be re-debated. Every mistake that does not need to be re-made. Every pattern that does not need to be re-learned. Compound that over years and the difference is staggering. Two companies. Identical talent. Identical budgets. Identical technology stack. One has a living knowledge base. The other does not. They will diverge in delivery speed within six months.
This is the least glamorous competitive advantage in technology. It is also one of the most durable. You cannot poach an organisation’s institutional memory. You cannot acquire it in a fundraising round. You can only build it. Deliberately, consistently, openly.
The open knowledge economy
When organisations share knowledge openly (patterns, anti-patterns, decision records, post-mortems) they do not lose competitive advantage. They gain ecosystem leverage.
The company that publishes its engineering practices attracts engineers who want to work that way. The municipality that shares its project retrospectives helps the next municipality avoid the same pitfalls, and in return benefits from theirs. Open knowledge is not zero-sum. It is compounding. Every contribution raises the floor for everyone, including the contributor, and the floor is where most of the industry currently lives.
The industry does not have a tooling problem. It has an amnesia problem. And the cure is not a better tool. It is a better memory.
What policy-makers must do
Treat knowledge infrastructure as critical infrastructure. A national open knowledge base of technology decisions, patterns, and failures has the same strategic value as a national compute cluster. It costs a fraction as much. Fund it. Staff it. Maintain it. The return is not measured in one project. It is measured in every project that comes after.
Incentivise open knowledge sharing. Offer procurement advantages to companies that contribute to open knowledge commons. Make post-mortem publication a condition of government contract completion. Create awards for the most valuable public contribution to shared technical knowledge. Shift the incentive from hoarding to sharing, because right now the incentive runs the wrong way.
Embed knowledge practices in education. Teaching developers to write code without teaching them to record decisions, document trade-offs, and learn from failures is like teaching doctors to prescribe without teaching them to take a patient history. Decision records, post-mortems, and pattern thinking should be part of every computer science curriculum. Not as a seminar. As a habit.
Speaking partners
University computer science departments. National digital skills agencies. The Software Engineering Institute. IEEE and ACM working groups on software engineering practice. Companies with mature engineering effectiveness programmes (Spotify, Google, Etsy, Netflix) whose published engineering practices have already quietly shaped the industry. And the open-source communities maintaining the tools that make knowledge-as-code possible in the first place.
What individuals & companies can do
Stop starting from scratch. Before your team kicks off a new project, spend one day, just one, looking for precedent. Who has built something similar? What did they learn? What would they do differently? This one habit, applied consistently, eliminates more waste than any process improvement framework ever will.
Build the KMS you wish you had. Start with a Git repo. A folder of Markdown files. A search tool. Add your team’s top ten decisions, top five failures, top five patterns. Share it with the next team. Improve it every quarter. In a year, it will be the most valuable asset your engineering organisation owns. And it will have cost almost nothing to build.
Name the cycle when you see it. When someone in your organisation says “microservices were the wrong choice, let’s rewrite everything as a monolith”, or “the data lake was a mistake, let’s move to a data mesh”, ask the question: was the tool wrong, or was our understanding of how to use the tool wrong? If it’s the latter, the rewrite will fail for the same reason. Fix the knowledge gap before you fix the architecture.
Make knowledge a first-class engineering output. Code ships. Tests ship. Documentation should ship. Decisions should ship. Retrospectives should ship. If your team’s only deliverable is working software, you are producing a product but not building an organisation. The organisation is the thing that remembers.
Conclusion
The technology industry is extraordinarily good at building new things. It is extraordinarily bad at remembering what it learned while it was building the last thing. This is not a character flaw. It is a systems failure. Knowledge lives in the wrong places, in the wrong formats, maintained by the wrong incentives.
The fix is not another tool. It is a practice. Treat knowledge with the same rigour you treat code. Version it. Review it. Test it against reality. Maintain it. Share it. When someone proposes a decision, check it against the record. Not because you distrust their judgement, but because you respect the judgement of everyone who came before.
The tools are blamed because the patterns are forgotten. The patterns are forgotten because they were never written down. And they were never written down because the industry decided, somewhere along the way, that only code is worth saving.
It is time to save the rest.
Kubernetes is not your problem. Microservices are not your problem. AI will not be your problem. Your problem is that you keep making decisions in a room with no memory. Build the memory. The decisions will follow.