Kill the Org Chart, Keep the Capability
Why departments are political boundaries and skills are units of value
Deep Dive #1 in the “The Agentic Enterprise Series”
A department is a political boundary. A skill is a unit of value.
These are not the same thing, and confusing them is one of the most expensive mistakes an organisation can make. Departments exist because of org charts, power dynamics, and historical accident. Skills exist because work needs to be done. When you organise around departments, you optimise for the org chart. When you organise around skills, you optimise for outcomes.
This distinction sounds simple. The implications are radical.
The Problem with Functional Decomposition
The standard model of organisational design is functional decomposition. You identify the major categories of work: marketing, sales, finance, engineering, operations, HR — and you create departments for each. You hire specialists, install managers, build processes, and connect the departments through coordination mechanisms: committees, approval chains, project managers, integration meetings. In a desparate attempt to sound more modern, these departments are now sometimes named “domains”, but the principle stays the same.
The logic is intuitive. Group similar work together. Build deep expertise in each function. Achieve economies of scale through specialisation. It made sense for the industrial economy that invented it.
The problem is that functional decomposition organises around inputs, not outputs. A marketing department is defined by what it does (marketing activities), not by the value it creates (customers who buy). An engineering department is defined by its discipline (software engineering), not by the capabilities it provides (reliable software features delivered to customers). Finance is defined by its function (financial management), not by the decisions it informs (better capital allocation).
When you organise around inputs, you create two persistent dysfunctions.
First, you create handover friction. Any outcome that requires multiple functions, which is nearly every outcome that matters, requires coordination between departments. That coordination is expensive. Context is lost at every handover. Accountability diffuses across department boundaries. Nobody owns the outcome end-to-end because the outcome does not live inside any single department. The product launch that requires marketing, sales, engineering, and operations to align is an organisational obstacle course, not a coordinated effort.
Second, you create artificial scarcity. The procurement department does not just process procurement — it controls access to procurement capability. If marketing needs a vendor contract and the procurement team is at capacity, marketing waits. The capability exists in the organisation; it is just trapped behind a departmental gate. The department creates a bottleneck out of a capability that could, in principle, be available to anyone who needs it.
This is not an accident. Departments have a survival instinct. They protect their scope, guard their resources, and resist having their capabilities made accessible to others. Because accessible capabilities do not require a department to gatekeep them. And without gatekeeping, the political justification for the department dissolves.
Conway’s Law and Its Uncomfortable Implications
In 1967, computer scientist Melvin Conway published an observation that became one of the most cited laws in software engineering: “Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.”
This is Conway’s Law. It was written about software, but it applies to any complex product of human collaboration.
If your organisation has four departments working on a product, the product will have four components — one for each department. Not because that is the best architecture for the product. But because the departments cannot easily communicate across their boundaries, so they design components that minimise cross-boundary dependencies. The org chart becomes the architecture.
Conway’s Law has a corollary that software engineers call the Inverse Conway Manoeuvre: if you want a particular system architecture, design your organisation to match that architecture. Structure your teams the way you want your software structured, and the software will emerge to match.
The same logic applies to capabilities. If you want cross-functional capabilities — capabilities that serve anyone who needs them, regardless of which department they sit in — you cannot organise purely by function. The functional organisation will produce functional capabilities, siloed by department. To produce cross-functional capabilities, you need cross-functional teams.
This is the insight behind the shift from functional departments to capability-oriented cells. Stop organising around “who does this type of work” and start organising around “what outcome does this capability produce?” The team owns the capability end-to-end: the knowledge, the process, the tools, and the quality of the outcome.
What a Skill Actually Is
The word “skill” is overloaded. I use it in a specific technical sense here.
A skill is a self-contained, invokable capability. It has inputs (what it needs to start), a process (how it executes), and outputs (what it produces, including a definition of “done”). It is self-contained in that everything needed to execute the skill lives within the skill — the knowledge, the tooling, the decision logic. It is invokable in that it can be activated by anyone with a legitimate need, without requiring them to understand the internals.
This maps precisely to the service concept in software architecture. A service has an interface: you call it with specific inputs and receive specific outputs. You do not need to know how the service works internally. You do not need to configure it before use. You do not need permission from the service’s internal team to call it — you just need to satisfy the interface contract.
Think about procurement as a skill rather than a department.
As a department, procurement is a team of people who process purchasing requests. To engage them, you submit a request, wait for acknowledgment, answer clarifying questions, get approval, and eventually receive a purchase order. The department controls access. They have a queue. They have internal priorities. You wait.
As a skill, procurement is an invokable capability. It accepts a request (vendor type, scope, budget, timeline, compliance requirements). It executes the necessary steps — vendor assessment, contract review, approval routing, PO generation. It produces a result: a signed contract, a configured vendor relationship, documentation of the decision. Any team in the organisation can invoke it. The procurement knowledge is embedded in the skill. You do not need to know how procurement works to use procurement capability.
The difference is not just efficiency. It is structural. The skill version removes the department’s control over access to the capability. Which is why this transition is politically difficult — the department loses its gatekeeping power, and gatekeeping power is often the main source of a department’s political weight.
How Service-Oriented Architecture Solved This in IT
Software engineers spent two decades learning how to decompose complex systems into independently deployable services. The evolution went through recognisable stages that map to organisational evolution.
The monolith: everything in one codebase, one deployment, one team (conceptually). Fast to build initially. Increasingly painful as it grows. Every change risks breaking everything else. Scaling requires scaling the whole system, even if only one part is under load. This is the functional organisation: one integrated system where everything touches everything.
Service-oriented architecture (SOA): decompose the monolith into services, each with a defined API. Services communicate over the network. Each service can be deployed independently. Teams can own services without coordinating every change with every other team. The coupling moves from internal (shared code, shared database) to external (API contracts).
Microservices: take SOA further. Services are small, focused on a single capability. Deployment is automated. Services can be written in different languages, use different databases, scale independently. The principle of single responsibility, applied at the system level: each service does one thing well.
The lesson from this evolution is not that microservices are always the answer. (They introduce their own complexity — distributed systems failures, network latency, observability challenges.) The lesson is that capability decomposition — organising around what a component provides rather than what type of code it contains — produces systems that are more independently evolvable, more resilient, and more composable.
The same decomposition applied to organisations: stop organising around what type of work a team does (functional decomposition) and start organising around what capability a team provides (capability decomposition). What can this team deliver? Who can invoke it? What are the interface contracts — the inputs it needs, the outputs it produces, the standards it adheres to?
Capability Mapping: Seeing What You Actually Have
Most organisations have no clear map of their capabilities. They have org charts, which map teams. They have process documentation, which maps activities. They do not have a capability register — a clear inventory of what the organisation can do, who provides it, and how it can be accessed.
Start with your value streams — the end-to-end processes that produce value for customers. For each value stream, identify the capabilities required at each stage. Then ask: where does this capability live? Is it accessible to everyone who needs it, or locked inside a department?
Three patterns emerge. Some capabilities are genuinely scarce — only two people understand a compliance domain, both on the same team. Some are abundant but inaccessible — many people could do the work, but the formal process requires routing through a specific department. Some are duplicated — three teams built the same analysis tool because they could not access each other’s.
Each pattern has a different fix. Scarce capabilities need investment — documentation and training to distribute the knowledge. Inaccessible capabilities need restructuring — remove the gatekeeping, publish the interface. Duplicated capabilities need consolidation — pick one canonical implementation and retire the others.
The map also reveals what is missing: gaps in the value chain that nobody owns, work happening informally through heroic individuals with no institutional support.
Tribal Knowledge and the Packaging Problem
One of the deepest problems in organisational capability is tribal knowledge — expertise that lives in specific people’s heads and is not captured anywhere. The senior engineer who knows why the system was architected a particular way. The account manager who understands the client’s unstated preferences. The finance analyst who knows which numbers in the monthly report are reliable and which are artefacts of how the data is collected.
This knowledge is immensely valuable, fragile, non-transferable, and a single point of failure. When the person leaves, it leaves with them.
Skills solve this through packaging. A skill is not just a process — it is a knowledge artefact. It encodes the heuristics, the edge cases, the “this looks right but it isn’t” patterns that take years to develop. A recipe tells you the steps. A good recipe also tells you what to look for, what can go wrong, how to adjust when the context differs from the expected.
The critical difference between a document and a skill is activation. A document is passive — someone must find it, open it, read it, and decide to follow it. A skill is active — it surfaces when needed, provides only the information relevant to the current context, and is designed to be executed, not read.
AI changes this calculus significantly. Natural language processing can extract knowledge from existing documentation. Embedding models can match that knowledge to the context in which it is needed. Retrieval-augmented generation can surface the relevant heuristic at the moment of decision. The technology for skill packaging now exists. But the organisational design must support it: skills need owners accountable for their quality, feedback loops that route performance signals back to those owners, and governance standards that ensure interoperability.
Real-World Examples
W.L. Gore, the materials science company, has operated without traditional management hierarchy since its founding in 1958. What holds the organisation together is not reporting lines but expertise networks. People are known for their skills, and skills are how work gets done. When a project needs a specific capability — adhesives chemistry, regulatory compliance, manufacturing process — it finds the person or people who have that skill. There is no department to route through. There is a skill to invoke.
The result, after sixty-plus years: Gore consistently ranks among the most innovative companies in its industry, with a patent portfolio and product range that belies its relatively modest size. The organisational model is not a charity project. It is a competitive strategy.
Amazon’s “two-pizza team” principle — teams small enough to be fed with two pizzas — was an attempt to enforce capability decomposition. Teams own a specific service, end-to-end. They are accountable for its availability, its performance, its evolution. Jeff Bezos’s memo mandating that all service teams expose their capabilities through APIs — or be fired — is the clearest executive statement of capability thinking I know of in a major organisation. “Expose your capability as a service. Enable others to use it. Or you are not doing your job.”
Haier, the Chinese appliance manufacturer, reorganised around what they call micro-enterprises — thousands of small, semi-autonomous units each owning a specific capability or customer relationship. The management overhead is minimal. Coordination happens through market mechanisms: micro-enterprises buy and sell services from each other. Capability is the currency, not hierarchical position.
Implementation Patterns
The transition from department thinking to skill thinking does not require a complete organisational redesign. It requires a change of lens applied consistently over time.
Start with capability mapping as described above. Build the inventory. Identify the highest-value capabilities — those where inaccessibility is causing the most visible pain.
Pick one capability to restructure as a shared skill. Define its interface: inputs, outputs, standards, SLAs. Document the knowledge it requires, including the heuristics and edge cases. Build or configure the tooling that supports execution. Identify an owner — a person or team accountable for the skill’s quality. Publish it: make it known, make it accessible, make it easy to invoke.
Measure its performance in production. How often is it invoked? By whom? What is the quality of the outputs? What feedback do users provide? Use this to improve the skill. The skill should evolve faster than documentation ever did — because it has a feedback loop, an owner, and real usage data.
Repeat. Over time, the org chart becomes less relevant. What matters is the capability register: what skills exist, who provides them, what standards they meet. Teams form around capabilities, not around departments. Hierarchical reporting becomes a light administrative structure, not the primary coordination mechanism.
The transition is political as much as organisational. Departments will resist losing their gatekeeping power. The framing that works is not “we are eliminating your department” but “we are making your capability available to everyone who needs it.” The department’s value is its expertise, not its control over access to that expertise. Packaging the expertise as a skill does not destroy the department — it transforms it from a bottleneck into a service provider.
The Agentic Enterprise View
In an agentic enterprise, the skill register is the operating system. AI agents and human workers invoke the same catalogue of capabilities. The question “is this done by a human or an AI?” is secondary to “which skill handles this, and did it perform to standard?”
The capability decomposition required for this is the same capability decomposition that makes organisations function better with humans alone. The difference is that AI makes the gap between good and bad organisational design more visible, faster. An AI agent cannot navigate a poorly packaged capability the way a human can — through informal knowledge, relationship networks, institutional memory. It needs a clean interface. It needs documented logic. It needs real feedback.
Design your capabilities for AI, and you will have designed them for humans too.
Start here: build a capability register for one value stream. Map every capability required, who provides it, and how accessible it is. The gaps and the bottlenecks will be immediately visible.
Next in the series: Fire the Traffic Cop — How intent-based routing makes managers obsolete as dispatchers, and essential as capability builders