Institutional Knowledge and Why We Continue to Work Together
One Takeaway: Working with other people isn’t always easy. It can be costly. This entire series has been about some of those costs. Coordination failures. Knowledge that doesn’t flow. Metrics that can destroy valuable work. Rules that make cooperation irrational. But working together also generates something important that working apart cannot: knowledge that accumulates across people and time. Building an organization that protects and compounds that knowledge may be the most important thing a manager can do.
Why Bother?
This series has spent a lot of time on what can go wrong inside organizations. Coordination becomes expensive as you grow. The knowledge your leaders need doesn’t reach them. Measurement systems destroy your most valuable work. The rules of the organization make cooperation irrational. The capabilities that made you successful fight against the innovation you need next. I’ve come to call these people problems. These are the costs and failures that arise whenever people try to coordinate work toward a shared goal.
After all of that, a reasonable person might ask: why bother? Working together sounds exhausting. If working together inside a company creates this many problems, why not just work apart? Why not hire contractors for everything through the market, where prices coordinate millions of strangers without anyone needing to be in charge?
It’s not a hypothetical question. It’s a question economists have taken seriously. Ronald Coase won the Nobel Prize in part for answering it. His answer was that firms exist when internal coordination costs less than the transaction costs of using markets. Sometimes it’s cheaper to bring people inside an organization than to buy their work on the open market. That’s true, and it explains why firms emerge in the first place.
But it doesn’t explain what firms actually do that makes them worth continuing. It doesn’t explain:
Why firms can get better at what they do over time.
Why they sometimes endure even when market alternatives get cheaper.
Why organizational knowledge matters so much that companies talk about “institutional knowledge” as one of their most valuable assets.
Why new employees take months to become effective, and what they’re learning during that time.
Why the most valuable work inside a firm is often the work that most resists being moved outside it.
Coase answered why firms emerge. The more useful question, especially for anyone actually running one, is what firms do that nothing else can? What makes the costs of coordination worth bearing? What are you building by keeping people together year after year focused on your products and customers?
The answer is about knowledge. But not the kind most people mean when they use that word.
Why Some Problems Resist Standardization
Throughout this series we’ve seen the same pattern from different angles. Organizations build systems that work well for some kinds of work and systematically threaten, or destroy, others. These systems include metrics, processes, incentive structures, and evaluation frameworks. In many cases, the traditional roles of managers. These systems aren’t broken. They’re just designed for a very specific kind of problem and fail when used to address a second kind of problem.
Some problems are complicated. They have many steps and many parts, but the relationships between them are knowable and the outcomes are predictable. These problems can be addressed through analysis, measurement, and optimization. They respond well to the systems most organizations build as they scale.
Other problems are complex. They’re organic, dynamic, and relational. The parts interact in ways that change depending on context. Outcomes come from the interactions rather than being calculated in advance. These problems can’t be addressed through standardization. Not because they’re harder. Because they’re a fundamentally different kind of thing.
I’ve come to call the mismatch “robot thinking.” Not as a criticism. As a description. Robot thinking treats every problem as if it were complicated. Standardize it. Measure it. Optimize it.
For genuinely complicated work, this is excellent. For complex work, it creates the very people problems this series has been diagnosing.
But what exactly makes complex problems resist standardization at a basic level? The answer is about the kind of knowledge each type of problem involves.
Two Kinds of Knowledge
Most discussions of knowledge in business treat it as a thing that exists somewhere and can, in principle, be moved around. You learn something. You write it down. Someone else reads it and learns it too. Knowledge is information and information is transferable. The question becomes how efficiently the transfer happens.
The economist Richard Langlois (Scope, Scale, and the Reuse of Knowledge) pointed out that this picture is partially right, but it misses something important. Some knowledge isn’t a separable artifact at all. It’s generated in the process of producing other things. It is embedded in that production, and because of this, exists nowhere else.
This is the difference between knowledge that can be templated and knowledge that can only be embedded in the doing. You can capture templated knowledge can in a procedure, a standard, a piece of code, a manual, or a model.
Template knowledge is what makes scale possible. Once you’ve figured out how to make a good widget, you can write down the steps, build a jig, train someone to follow the procedure, and reproduce the result. The cost of creating the template gets spread across every unit you produce afterward. This is why standardization works. This is why some kinds of expertise can be packaged into software, sold as consulting frameworks, or contracted out to specialists. Template knowledge is, by its nature, separable from any particular producer. It can be moved.
Embedded knowledge can’t. It develops through repeated experience in a specific context. It accumulates across people who work together over time addressing genuine customer demands. It comes together across functions through sustained collaboration. And it persists in routines, judgments, and relationships that nobody can fully document. You can’t separate it from the people and the work that produced it because it doesn’t really exist apart from them. Even when you try to write it down, what you capture is the surface, the visible procedure. You do not capture the contextual judgment that knew when to follow the procedure and when to deviate from it.
This is what makes complicated problems complicated and complex problems complex.
Complicated problems are problems where template knowledge can do most of the work. Robot thinking works for them because the knowledge they require is templatable.
Complex problems are problems where embedded knowledge is appropriate. Robot thinking fails because the knowledge they require can’t be templated.
The complicated/complex distinction tells you the domains are different. The template/embedded distinction tells you why.
And it tells you what your firm actually does that nothing else can.
What This Looks Like in Practice
Let’s say you have a startup and two employees are working together. One has been around for five years and the other is one year in. The newer employee has an idea for a new product. He runs it by the senior employee. It just so happens that the senior employee had that same idea three years ago. She’s sympathetic to it, but she remembers why it didn’t get built in the first place.
Maybe there were product limitations that made it impractical. Maybe a senior executive killed a similar proposal. Maybe they ran a pilot and it was expensive and inconclusive. The thing is, without the institutional knowledge, the new employee is stuck at square one. With it, he either knows quickly this is a dead end, or he becomes aware of specific nuances that need to be thought through before trying again. Either way, the knowledge share saves time, money, and effort by avoiding redundant work.
Now here’s the part that matters for this article. Some of what the senior employee knows can be documented — the fact that the idea was tried, that it failed, what the outcome was. That’s the templatable surface of institutional knowledge, and good documentation practices preserve it. A future employee could find the post-mortem and learn the basic history.
But the most valuable part of what the senior employee knows can’t be documented. It’s the judgment about why it failed in this specific context. Whether a different version might work now that the product has changed. How this idea connects to three other things she’s learned since then. What the new employee’s version would need to address that the original didn’t. That knowledge is embedded in her accumulated experience. It’s what made the hallway conversation more valuable than reading a deck. And it only exists so long as she works for the firm.
If she leaves, the post-mortem stays. The judgment leaves. The firm retains the template. It loses the embedded knowledge that made the template useful.
This is what a firm does that a collection of market relationships can’t quite replicate. The newer employee didn’t hire the senior employee as a consultant. He didn’t contract for her institutional memory. He accessed it because they both work inside the same organization. Because the firm created the conditions where that knowledge could be passed on through a conversation that neither of them planned. The firm does this by keeping people together long enough for knowledge to accumulate and transfer in ways that nobody can fully design or predict.
What matters isn’t whether people are technically employees or contractors. What matters is whether the conditions exist for embedded knowledge to accumulate and transfer. These conditions include:
Sustained relationships
Shared context
Continuity of work and
A kind of proximity that lets someone access knowledge they didn’t generate through a conversation they didn’t plan.
A firm, in the sense that matters here, is any arrangement that creates those conditions (See Klein What is a Firm, Anyway? for a brief discussion).
The Asset You Don’t Own
Think about what your firm actually controls. It owns its equipment. It owns its real estate, or at least holds the lease. It owns its intellectual property, its codebase, its documented processes, its brand. These assets stay when people leave. They can be inventoried, valued, transferred, and protected. If someone walks out the door tomorrow, the building is still there. The code is still there. The patents are still there.
Now think about the embedded knowledge we just described. The senior employee’s judgment about why that product idea failed and what a new version would need. The engineer’s intuition about which architectural decisions will hold up under scaling. The account manager’s feel for when a client relationship is at risk before any metric shows it. The operations lead who knows which processes can absorb a disruption and which ones will cascade.
Your firm doesn’t own any of that. Not the way it owns a server or a trademark. It accesses it through people. And its access is contingent on something it can’t fully control: that those people continue to show up.
This makes embedded knowledge unlike every other resource a firm manages. Every other asset responds to conventional management logic. Acquire it. Protect it. Optimize its use. Measure its return. Embedded knowledge doesn’t respond to any of these in the way you’d expect.
You can’t get embedded knowledge the way you get equipment. You can’t buy it on the market. You can’t hire someone and have them bring it with them from a previous employer. These employees will bring their own embedded knowledge from a different context, which is valuable but not the same thing.
Embedded knowledge specific to your firm can only be generated inside your firm. It’s gained through sustained experience in your specific context. The only way to “get” it is to create the conditions where it develops over time.
You can’t protect embedded knowledge the way you protect intellectual property. You can’t patent a senior employee’s contextual judgment. You can’t copyright the cross-functional teamwork that lives in the relationships between your teams. Non-compete agreements don’t preserve knowledge. They just prevent the person who carries it from using it somewhere else for a while (maybe). The only way to protect embedded knowledge is to maintain the relationships and conditions that keep it accessible and transferring to others. If it lives in one person and that person leaves, no legal mechanism can recover it.
You can’t optimize the deployment of embedded knowledge the way you optimize a supply chain. You can’t route it efficiently to where it’s needed. You often don’t know where it’s needed until the moment arrives (like the hallway conversation between the senior and junior employee that neither of them planned). The only way to “optimize” embedded knowledge is to create enough proximity and continuity that these unplanned transfers happen naturally and frequently.
And you can’t measure embedded knowledge the way you measure other assets. Its value is often invisible until the moment it prevents a costly mistake, unlocks a cross-functional insight, or enables a judgment call that no template could have produced. You only notice its absence after it’s gone. When the person who carried it has left and the new hire makes the same mistake the organization already paid to learn from three years ago.
This is the paradox at the heart of managing a firm. The asset that makes your organization most valuable is the asset you have the least control over. And the management approaches designed for the assets you do control (standardize, measure, optimize) are precisely the approaches that can destroy the asset you don’t.
Robot thinking works for owned assets. Standardize the process. Measure the output. Optimize the deployment. These assets respond to control because they’re fully within the firm’s possession.
Embedded knowledge doesn’t respond to control. It responds to conditions. It accumulates when people work together long enough in a shared context. It transfers when there’s enough proximity and trust for unplanned conversations to happen. It compounds when the organizational environment treats it as valuable even when it can’t be measured. And it disappears, sometimes overnight, when any of those conditions break down.
Every system your firm builds is a choice about which kind of asset to focus on.
Metrics that reward only measurable output focus on owned assets and neglect embedded knowledge.
Incentive structures that punish cross-functional collaboration focus on efficient use of controllable resources and destroy the conditions for knowledge transfer.
High turnover in the name of cost optimization treats people as interchangeable inputs and resets the embedded knowledge that was the actual competitive advantage.
What Makes It Worth Continuing
The costs of coordination that this series has diagnosed aren’t just friction to be minimized. They’re the price of maintaining the conditions under which embedded knowledge compounds. Some of those costs are genuinely wasteful and should be reduced — that’s what good institutional design does. But some of them are the cost of keeping people together long enough, in close enough proximity, with enough shared context, for the kind of knowledge to develop that no market relationship and no AI tool can replicate.
The question isn’t how to eliminate coordination costs. It’s how to make sure what you’re getting in return — in embedded knowledge, in cross-functional judgment, in accumulated contextual understanding — is worth more than what you’re paying. That’s the trade-off at the center of every firm. And managing that trade-off is what management is actually for.
But managing it well requires seeing a distinction that most organizations miss.
Efficiency vs. Effectiveness
Efficiency means doing work cheaper, faster, with fewer resources. Effectiveness means doing work in a way that produces the right outcome in a specific context. These are not the same thing, and optimizing for one can destroy the other.
Robot thinking optimizes for efficiency. Standardize the process. Reduce the cost per unit. Measure output per hour. For templatable work, efficiency and effectiveness align. The standardized process is the most effective process because the right answer is known and the job is to execute it at the lowest cost. But for embedded work, the two come apart. The cheapest way to do the work is not always the most effective way. Effectiveness depends on contextual judgment that doesn’t show up on a cost-per-hour comparison.
Outsourcing a function, either to a contractor or now even to an AI agent, might be more efficient on paper. Lower hourly rate. No overhead. But if the work has an embedded component, the outsourced version is less effective. It gets done without the contextual judgment that would have made it actually useful. And then you spend more fixing, redoing, or compensating for the gap than you saved on the hourly rate. You maximized efficiency and destroyed effectiveness, and ended up with neither.
This is what every coordination failure in this series has been about.
Metrics that optimize for measurable efficiency while destroying unmeasurable effectiveness.
Incentive structures that reward efficient compliance while punishing effective cooperation.
Reporting structures that surface cost data while stripping out the context that makes the data meaningful.
The cost of working together inside a firm is real. But the return on that cost isn’t efficiency. It’s effectiveness found in the accumulated ability to do the right thing in context, not just the cheap thing on paper.
What This Means for AI
AI is, at it’s core, a templating technology. It lowers the cost of creating templates. It turns previously embedded craft into code, models, and standardized workflows. It excels at complicated problems.
Some economists have predicted that AI will shrink firms by lowering transaction costs. That may well be true for work where template knowledge dominates. Work that was traditionally held inside firms because of the cost of bundling complementary template-based capabilities will, in many cases, move out.
But that only describes part of what firms do. As AI expands what can be templated, the question for any leader becomes: which of the work I’m keeping inside my firm is genuinely embedded, and which am I keeping inside out of habit? The work that AI can template isn’t your competitive advantage. The work it can’t is.
Getting this wrong creates problems in both directions.
Keep templatable work inside when it could be moved out and you waste resources. Your best people spend their time on work a tool could handle, while the complex cross-functional work that only they can do goes unattended.
Push embedded work out, or treat it like template work internally, and you get the failures this series has been diagnosing. You standardize work that depends on contextual judgment and the judgment disappears. You measure it on the wrong metrics and the measurement destroys what made it valuable. You centralize decisions that depend on local knowledge and the knowledge gets stripped out.
AI makes this second mistake harder to see. AI’s success at complicated work creates pressure to template everything. If AI can write the report, surely it can handle the client relationship. If AI can analyze the data, surely it can make the strategic judgment. If AI can standardize the process, surely the process should be standardized.
The question isn’t “will my company survive AI.” It’s “do I know which work in my company is genuinely embedded, and am I building around that distinction or ignoring it?”
What This Means for Managers Like You
This article has been about what firms do that nothing else can. But firms don’t do anything on their own. People do. And the question of what firms do eventually becomes a question about what the people running them should be doing.
If your organization has two kinds of work, it has two kinds of management challenges. And they require fundamentally different things from you.
For the templatable work, your job is relatively clear. Build good systems. Set clear metrics. Standardize processes. Optimize for efficiency. This is important work and the series has never said otherwise. Robot thinking is excellent here.
For the embedded work — the complex, cross-functional, judgment-dependent work that this series has been about — your job is something else entirely. It’s stewarding the asset your firm doesn’t own.
That means making structure decisions based on what kind of knowledge you need to accumulate, not just what looks clean on an org chart.
It means treating hiring in embedded roles as a knowledge investment that compounds over years, not a cost to be minimized per hour.
It means understanding that turnover in these roles doesn’t just create replacement costs. It resets the compounding that was your actual competitive advantage.
It means recognizing that documentation preserves the templatable surface of your institutions knowledge, but not the embedded depth. Pretending otherwise creates a dangerous illusion.
Most fundamentally, it means creating and protecting the conditions under which embedded knowledge accumulates, transfers, and compounds. Designing rules where cooperation is rational. Connecting knowledge between people who have it and people who need it. Protecting valuable work from measurement systems that would destroy it. Recognizing which work is genuinely embedded and making sure your systems treat it accordingly.
This is harmonizer thinking. And it’s not a nice-to-have. It’s the economic justification for your role as a manager.
The manager who only does robot thinking and only standardizes, measures, and optimizes is managing the part of the organization that could increasingly be managed by software or by well-designed processes that don’t need much human judgment. That work matters, but it’s not what makes the firm worth continuing.
The manager who also does harmonizer thinking — who stewards the asset the firm doesn’t own, who creates the conditions for embedded knowledge to compound, who protects complex work from systems designed for complicated work — is doing the work that justifies the costs of coordination. They’re the reason the firm produces something that a collection of independent contractors with AI tools cannot.
Every article in this series has been building toward this point. The coordination failures aren’t bugs in the system. They’re the cost of doing something that only firms can do. Your job isn’t to eliminate those costs. It’s to make sure what your firm produces is worth more than what those costs consume.
The Bottom Line
Working together is costly. This series has shown exactly how and why.
But firms do something that working apart cannot. Working together creates the conditions for knowledge that only exists in the doing. Knowledge accumulated across people working together over time, brought together across functions through repeated collaboration. This is the asset you don’t own but can’t succeed without.
Your products can be copied. Your processes can be studied. Your templatable work can, and increasingly will, be moved to the market and to an AI system. But the embedded knowledge building up in your organization — the pattern recognition, the cross-functional judgment, the contextual understanding built through years of shared experience — is the advantage that persists.
Complicated problems have complicated solutions. Complex problems need something different. Robot thinking handles the first. Your firm exists for the second. And your most important job is making sure it does.