What Headquarters Can't See
What Headquarters Can’t See
One Takeaway: All the knowledge needed to run your business doesn’t exist in any one place. And it can’t be centralized without destroying its value. Understanding the knowledge problem explains when to centralize decisions, when to decentralize authority, and why the answer changes as you scale.
In Growth Isn’t One Sided, we saw that operators, refiners, and creators need different systems to function effectively. In The Cost of Working Together we explored why transaction costs make internal coordination difficult. But there’s a deeper challenge underneath underlying these points: the knowledge problem.
As companies grow from 10 to 100 to 1,000 people, total knowledge in the organization increases dramatically. But the ability of any central decision-maker to access and use that knowledge decreases. Small companies tend to be able to run on founder instincts. Founders try to know everything happening in the business. When it’s smaller it’s much easier to get a full picture of the business. But, this changes with large companies. Large companies need to embrace decentralized decision-making. No executive can possibly know all the information needed for good decisions.
But decentralization creates its own problems. Coordination failures. Inconsistent choices. Local (i.e. close-to-the-problem) optimization that can hurt the whole. How do you balance centralized strategy with distributed knowledge? The answers come from Nobel-prize winning economist Friedrich A. Hayek’s insights on the role and types of knowledge in our world.
Two Product Teams, Same Company, Different Decisions
A fast-growing SaaS company had two product teams. Both reported to the same Chief Product Officer. Both followed the same development process. Both served enterprise customers. They faced similar decisions about feature prioritization.
The Marketing Automation Team (centralized decision-making). Every feature request went through a central prioritization committee. Product managers gathered customer feedback, analyzed usage data, and submitted business cases. The CPO, VP of Product, and Head of Engineering met bi-weekly to review submissions and set priorities.
The process was rigorous. Standardized ROI frameworks. Data-driven impact analysis. Strategic alignment scoring. Time and budget allocation optimization.
When customers in the healthcare vertical requested HIPAA compliance features, the local PM documented the requirements. Development cost: 3 engineering-quarters. Projected revenue: $2M from healthcare customers.
The committee reviewed it against other requests. The ROI looked marginal. Three quarters of development for $2M didn’t clear their hurdle rate. Healthcare was only 15% of the market.
The features got deprioritized. The local PM told frustrated customers it wasn’t on the roadmap.
Six months later, three major healthcare customers churned to a competitor who had built HIPAA compliance. The lost revenue: $8M annually. The centralized committee hadn’t known that healthcare customers chose specifically based on compliance. The ROI analysis wasn’t right to factor this in. It also didn’t factor in the cost of losing these reference customers. Or that losing them could damage future healthcare sales. It also wasn’t helpful in figuring out if a competitor was actively targeting this vertical.
The Sales Enablement Team (decentralized decision-making). The local PM had authority to make most feature decisions without central approval. They were simply held to a quarterly development budget. She sat in with the sales team. She heard customer conversations daily, and understood competitive dynamics in real-time.
When enterprise customers started asking about Salesforce integration, she didn’t need to write a business case. She heard the pattern directly from customers. “We love your product, but we can’t buy without Salesforce integration.” She was already aware of the competitive landscape because it came up in client conversations. Two competitors had basic integration, one was building deep integration.
She allocated 1.5 engineering-quarters from her team’s budget. The business case wasn’t obvious from central metrics. Integration would impact maybe 30% of prospects. But she knew from her front-line context that the 30% asking represented 70% of potential revenue. She knew that lack of integration was a deal-killer, not a nice-to-have. She knew that the competitor’s deep integration was 6 months out, so they had a window to act.
The integration shipped. Enterprise sales increased 40% quarter-over-quarter. She made a better decision than any central committee could have because she had access to knowledge that didn’t exist in centralized data systems.
The difference. Both teams had smart PMs, good processes, and access to the same company resources. The difference was in who had authority to make decisions and whether they could access the knowledge that mattered.
This is Hayek’s knowledge problem. The knowledge needed for good decisions is spread throughout the organization in forms that can’t be fully combined. Solve it well and you make better decisions faster. Solve it poorly and growth itself can undermine your decision quality.
Knowledge Exists in Two Different Forms
Hayek won the Nobel Prize in Economics partly for explaining a problem that most management theory ignores.
Hayek recognized that the knowledge needed to run a complex system (like an economy) doesn’t exist in any centralized location and can’t be effectively centralized. The Soviet Union’s central planners failed not because they were stupid. They failed because the knowledge needed to run an economy doesn’t exist in a form that central planners can access and use.
The same problem affects every organization that grows beyond the point where one person can know everything.
Local knowledge is specific to context. In this case local means “close-to-the-problem.” This can mean close in proximity (if your business operates across many geographic markets). This can also simply mean closest to the opportunity or breakdown point. The sales rep knows the customer in front of them is evaluating competitors right now. The operator knows this specific machine makes a noise before it fails. The customer success manager knows an account’s satisfaction is down without looking at a dashboard. This knowledge is tacit, time-sensitive, and held by people close to the situation. It gets lost when transmitted through formal reporting systems.
Systematic knowledge is general across contexts. Optimization algorithms. Strategic frameworks. Process improvements that work in many locations. Performance patterns that reveal themselves in aggregated data. This knowledge is explicit, relatively stable over time, and can be enhanced by central analysis.
Decisions that depend on systematic knowledge benefit from centralization. Resource allocation across regions. Process standardization. Strategic positioning. Capital investment. Centralizing these enables optimization based on existing historical patterns.
Decisions that depend on local knowledge benefit from decentralization. Feature prioritization. Sales approach adaptation. Operational problem-solving. Customer relationship management. Decentralizing these enables speed, context, and adaptation.
Your company needs both. Centralize too much and you make decisions without the knowledge that makes them good. Decentralize too much and you lose coordination.
Why Centralization Destroys Local Knowledge
The temptation to centralize is strong. Centralization promises consistency, optimization, reduced duplication, and clear accountability. But the process of centralizing information destroys much of its value.
Reporting filters out context. When the healthcare PM submitted her business case, here’s what happened to her knowledge. She knew healthcare customers were strategically important despite being only 15% of the market. She knew they were price-insensitive if you solved compliance. She knew the competitive window was closing. She knew the technical risk was lower than it appeared.
What made it into the ROI analysis: $2M projected revenue. 3 engineering-quarters. 15% market segment. Comparison to features with “better” ROI. Everything that couldn’t be quantified, everything about timing and competitive dynamics, everything she understood tacitly got filtered out. Not because the committee was incompetent. Because her knowledge didn’t survive the reporting process’ standard format.
Information arrives too late. Local knowledge is often time-sensitive. The value of knowing a customer is evaluating competitors right now is high. The value of knowing they were evaluating competitors last quarter is near zero. Central decision-making has latency. It requires time to gather, format, queue, deliberate, and communicate back.
Aggregation loses what matters. Your customer satisfaction score across all customers might be 4.2 out of 5. That’s fine for a board presentation. But the customer success manager knows Enterprise Customer A is at 3.5 and dropping, while Healthcare Customer C is at 2.5 and likely to churn. The aggregate says everything is fine. The granular knowledge reveals problems that need immediate action.
When Decentralization Creates Problems
Hayek explains why centralization fails. But total decentralization doesn’t always work in a business context either.
Local teams optimizing for their own metrics without coordination can destroy business value. Sales might promise custom features product hasn’t committed to. Product ships capabilities sales hasn’t been trained to sell. Customer success gives discounts that wreck unit economics. Each team is locally rational. Together they lose money.
Multiple teams can end up solving the same problem independently without knowing it. Engineering builds redundant capabilities. Operations reinvents processes that exist elsewhere. Customers get inconsistent experiences across regions. Pricing varies without strategic reason.
The question isn’t centralize or decentralize. It’s systematically matching decision authority to where the relevant knowledge actually lives.
One quick note, decentralization has more practical limits in a business than in an economy. This is due to the fact that individuals within businesses are focused around a single common end/goal. This is not true for an economy where many people are focused on their own, varying ends/goals.
The Knowledge Version of Coase’s Question
In “The Cost of Working Together” we discussed Coase’s insight: firms exist because internal coordination is sometimes cheaper than market coordination. The same logic applies to knowledge and decisions.
Some good rules of thumb for businesses on when to centralize decisions are:
When the knowledge it requires is systematic.
When consistency across the organization creates more value than local adaptation.
When the delay of central decision-making won’t destroy time-sensitive value.
Generally speaking, capital allocation (with exceptions), broad strategy, brand standards, and core process design fit the bill. These benefit from central analysis.
Some good rules of thumb for businesses on when to decentralize decision are:
When the knowledge it requires is primarily local.
When adaptation to context creates more value than consistency.
When time-sensitivity makes central approval too slow.
Operational problem-solving, customer relationships, local market tactics, and feature prioritization for specific segments are good examples of things that benefit from, or absolutely need, decentralization. These need authority close to the knowledge.
For any major decision, the practical test is three questions.
What knowledge does this decision actually need?
Where does that knowledge live?
What gets lost if you force that knowledge through a central reporting process before it can influence the decision?
This isn’t a one-time design choice. As companies grow, the answers change. Decisions that should be centralized at 50 people might need decentralization at 500. Decisions that should be centralized in stable markets might need decentralization during times of rapid market change. The knowledge problem is a moving target in your organization.
Different Functions Need Different Knowledge Access
The operators, refiners, and creators framework maps directly onto different knowledge requirements.
Operators need local knowledge access. Operator work depends on knowledge of particular circumstances, times, and places. This customer has this problem right now. This process is breaking down in this specific way. Centralizing operator decisions can destroy effectiveness. The knowledge that makes operators valuable doesn’t often survive centralization. By the time central decision-makers review operational issues, circumstances may have changed. To deal with this, it’s best to decentralize operational decisions while centralizing strategic direction and process standards.
Refiners need systematic knowledge access. Refiner work depends on systematic knowledge that benefits from centralization. Process improvements that apply across contexts. Data patterns that only appear in aggregated analysis. Optimization opportunities that compare performance across the organization. A single location’s data might not reveal patterns that appear across all locations. The best way to deal with this is to centralize refiner analysis and system-wide improvement while maintaining connections to local operational knowledge. Usually it’s best to have refiners both at the HQ and local level. This allows both deep (vertical, in market) focus as well as broad (horizontal, across market) focus.
Creators need hybrid knowledge access. Creator work depends on both. They need local, external knowledge about emerging opportunities and customer needs. They have to have access to internal knowledge about strategic positioning and constraints. Pure centralization is too slow to capture opportunities. Pure decentralization can waste resources on uncoordinated experiments. The goal here is to decentralize identifying opportunities and initial experiments while centralizing strategic direction and resource allocation.
Harmonizers as Knowledge Brokers
In “The Cost of Working Together” we explained how Harmonizers solve transaction cost problems by building new internal rules and structures. We described them as internal entrepreneurs who redesign the rules of the game. Now we can see another dimension of their value. Harmonizers attempt to solve the knowledge problem by brokering between centralized and decentralized knowledge.
This is a different kind of work than what we discussed in the previous article. There, Harmonizers built structures. For example they can create shared budgets, joint metrics, and reputation systems. For those situations it’s about coordinating people, abilities, and incentives. Here, they’re doing something more fluid. They’re moving knowledge between people who have it and people who need it. They translate between different functional languages along the way.
They translate local knowledge for central decision-makers. The customer success manager knows an account is at risk, but that knowledge lives in support conversations. These in-person conversations reveal things like tone shifts, response delays, and questions that signal the customer is evaluating alternatives. In contrast, a dashboard just shows a satisfaction score. The Harmonizer converts the tacit, local understanding into something central leadership can act on. The challenge is doing this without flattening it into a number that strips out the context.
They translate systematic knowledge for local decision-makers. Strategy documents and company-wide priorities exist. But, local teams often don’t know how those priorities apply to their specific context. The Harmonizer connects strategic direction to local decisions. They explain not just what the company is trying to do but why it matters for this particular team’s work. They help the frontline workers see how their local knowledge can serve the broader goal.
They identify which decisions are better centralized versus decentralized. This might be the most valuable function. Most organizations default to one approach based on culture rather than the knowledge needs of specific decisions. Harmonizers recognize when local knowledge is essential versus when systematic analysis should be the standard. They know when time-sensitivity requires local authority versus when coordination creates more value. They make the organizational design adaptive rather than fixed. In short, they know when to calculate and when to judge.
Why Harmonizers Can’t Be Replaced by Information Systems
This might cause you to pause and ask an important question. If the problem is knowledge distribution, can’t we just build systems to capture local knowledge?
Not quite. Here’s why.
Much local knowledge is tacit. It can’t be fully explained to someone else. We may not know that we know certain things. The customer success manager’s sense that a customer is about to churn, based on changes in communication patterns, doesn’t fit in a CRM field.
Local knowledge is often too context-specific to generalize. You can’t aggregate insights like “this customer needs this feature because of their specific business model.” This is especially true across hundreds of customers.
Time-sensitive knowledge can become obsolete before reporting systems process it. The competitive intelligence that “this customer is talking to our competitor now” has immediate value. It’s worthless in next weeks quarterly review.
The valuable context gets filtered out in standardized reporting. Everything that makes local knowledge useful for decisions can’t be captured in the forms and templates that information systems need.
Harmonizers solve this not by capturing all local knowledge centrally. Instead they ensure decisions get made at the level where the relevant knowledge exists. They broker between centralized and decentralized decision-making. Their goal is to allow each type of decision to be made where the knowledge needed for good decisions is actually available.
This is especially relevant right now. Many scale-ups are trying to solve coordination problems by buying software. They’re focused on better dashboards, more sophisticated analytics, AI-powered insights. These tools are valuable for systematic knowledge. They are, at their core, incapable of replacing local, tacit knowledge that Harmonizers broker. Investing in information systems without investing in knowledge brokers solves half the problem. But, it ignores the harder half.
Warning Signs You’ve Got the Balance Wrong
Signs you’ve over-centralized.
Decisions take weeks when they should take days. Good opportunities die waiting for approval.
Local teams work around formal processes to get things done.
Central decision-makers don’t have context for good decisions.
Innovation slows because everything needs central approval.
Signs you’ve over-decentralized.
Different parts of the organization make contradictory decisions or resources get wasted on duplicate efforts.
Customers get inconsistent experiences.
Local teams optimize for their own metrics at the company’s expense.
Strategic initiatives fail because local teams don’t align.
The Knowledge Problem Changes With Scale
What works at 50 people often fails at 500. The knowledge problem evolves as your company does.
Startup phase (10-50ish people). Founders have access to most if not all relevant knowledge. Small enough that everyone knows what’s happening. Informal communication keeps everyone aligned. Centralized decision-making works because knowledge is naturally concentrated. But there’s a clear transition signal that pops up. This happens when founders can’t keep up with all decisions. Important information stops reaching decision-makers on it’s own.
Scale-up phase (50-500 people). Knowledge becomes distributed. There’s too many people, too many processes, or too many customers for founders to know everything. Specialization concentrates expertise in teams. Informal communication breaks down. This is where most coordination failures first appear. This isn’t because people stop caring or the culture is lost. It happens because the knowledge needed for good decisions no longer reaches the people making them. Channels need to be more formalized.
Mixed centralization and decentralization becomes necessary. Some decisions must decentralize. Operators need authority to respond to local conditions. Some must stay central. Things like strategy and resource allocation need systematic analysis.
Harmonizers emerge as knowledge brokers here. They translate between local and central knowledge in both directions. Their role is to build systems that enable centralized strategy and decentralized execution. The goal is to do this without creating either bureaucratic friction or uncoordinated chaos.
Enterprise phase (500+ people). Knowledge is highly distributed and specialized. No executive can know even a fraction of what the organization knows. Most operational decisions must be local. Central planning focuses on resource allocation and strategic boundaries. Harmonizers become necessary and essential here. Culture and principles guide decentralized decisions where direct oversight can’t reach. The primary challenge becomes maintaining strategic coherence across decentralized decision-making while preserving and highlighting the local (close-to-the-problem) knowledge that makes decisions good.
Looking Ahead: When Measurement Becomes the Problem
Understanding the knowledge problem helps provide an answer on when to centralize versus decentralize. But there’s a related challenge that affects both. We often try to measure what we can quantify. We are told to manage to metrics. But what happens when the most important knowledge can’t be measured and management prioritizes only what’s measurable?
Operators facing pressure to hit metrics might ignore unmeasurable local knowledge that would improve outcomes. Refiners optimizing for efficiency might destroy unmeasured effectiveness. Creators pursuing innovation might abandon valuable uncertainty because it doesn’t produce results on the timeline that performance evaluation systems demand.
Next, we’ll explore why metrics can kill innovation. How measurement systems create bias toward the quantifiable rather than the important. And how to design measurement systems that support the three functions rather than undermining them.
The Bottom Line
Hayek’s knowledge problem explains why organizational design gets harder as you scale. The knowledge needed for good decisions becomes increasingly distributed in forms that resist centralization.
Small companies can centralize because founders access most knowledge through direct experience. Growing companies must decentralize because the knowledge needed for good decisions exists in specialized teams. This tacit understanding can’t be centralized without destroying it.
But decentralization can create internal coordination problems. The challenge isn’t choosing between centralization and decentralization. It’s matching decision authority to knowledge and problem location. Operators need local authority because operational knowledge is local and time-sensitive. Refiners need systematic knowledge access because optimization requires aggregated data. Creators need hybrid authority because opportunity identification is local but resource allocation should be systematic.
The competitive advantage goes to organizations that solve the knowledge problem well. It goes to organizations that make decisions based on the knowledge that actually matters. They use it where it exists without creating either centralized friction or decentralized chaos.