Operating Models · 9 minutes · Organizational design · Decision-rights architecture · Workflow design
When organizations redesign themselves, the first artifact is often an organizational chart.
Boxes move. Reporting lines change. Functions are renamed. New executive roles appear. Old departments are combined or divided.
The chart may be necessary. It can clarify hierarchy, formal accountability, and managerial relationships. But it does not explain how the organization will work.
It does not show how a client, resident, applicant, customer, or partner moves through the organization; where decisions are made; how information travels; where work is handed from one team to another; which capabilities are required; what systems support delivery; how competing priorities are resolved; or how performance problems are corrected.
An organizational chart describes formal structure. An operating model describes coordinated action. Confusing the two creates organizations that look different but continue to operate in the same way.
A reorganization may be expected to solve slow decision-making; duplicated work; unclear responsibilities; poor service delivery; weak accountability; inconsistent performance; or difficulty implementing strategy.
Changing reporting lines may help. But these problems rarely exist only because a team reports to the wrong executive.
They may be caused by conflicting decision rights; fragmented data; poorly designed workflows; weak handoffs; missing capabilities; unclear service standards; overloaded approval structures; incompatible technology; or incentives that reward local performance over organizational outcomes.
A new chart does not automatically resolve those conditions. The organization may adopt a new structure while preserving the same approval bottlenecks; the same informal workarounds; the same duplicated systems; the same unclear handoffs; and the same dependence on a small number of people who know how things really work.
The structure changes. The operating logic does not.
A complete operating model should answer six questions.
The operating model begins with purpose. What must the organization deliver? For whom? Through which services, programs, products, investments, or functions? What outcomes is it accountable for?
Without clarity on value, structure becomes an internal exercise. Teams are organized around professional disciplines or historical arrangements rather than the work the organization must perform.
Capabilities describe what the organization must be able to do consistently. Examples include research; financial analysis; service delivery; program management; stakeholder engagement; data governance; procurement; evaluation; product development; compliance; and implementation.
Capabilities are not the same as job titles. A capability may be delivered through an internal team; a shared service; an external partner; technology; training; a contractor; or a redesigned process.
This is why capability planning should come before headcount planning. The first question is not how many people do we need? It is what must the organization be able to do?
The operating model must show how work flows across the organization: entry points; process stages; handoffs; information requirements; review points; approvals; exceptions; and completion conditions.
Consider a grant-making organization. The chart may show programs, finance, legal, evaluation, and executive leadership. The operating model must explain how an opportunity enters the pipeline; who assesses strategic fit; who conducts due diligence; how financial and program risk are reviewed; who recommends funding; who approves; how agreements are issued; how performance is monitored; and what happens when a grantee cannot meet the original conditions.
The chart shows the teams. The operating model shows the work.
Decision rights are one of the most important and least visible parts of an operating model. For each consequential decision, the organization should know who recommends; who approves; who must be consulted; who can change the decision; who can pause implementation; who can override a standard rule; and who is accountable for the result.
Organizations frequently confuse involvement with authority. Many people attend the meeting. Few know who can decide.
This produces repeated review; delayed approvals; informal escalation; executive bottlenecks; and decisions that are revisited because authority was never explicit.
Decision rights are not a governance detail. They are operating infrastructure.
Organizations cannot operate effectively when information is fragmented across spreadsheets; email; individual drives; disconnected platforms; informal conversations; and undocumented institutional memory.
The operating model must identify what information is required; where it originates; who owns it; who can access it; how it is validated; how it moves; and how it supports decisions.
Technology should then be selected or designed around the operating requirements. When technology leads before the operating model is clear, organizations often automate confusion.
Performance is not only a dashboard. The operating model must establish what is measured; why it matters; who reviews it; what authority they hold; what happens when performance declines; and how learning changes operations.
A metric without an owner is information. A metric connected to a review process, decision right, and corrective action becomes management infrastructure.
Many organizational failures occur between teams rather than within them. A team may complete its work correctly, but the process still fails because the handoff is weak.
A handoff should define what must be completed before responsibility transfers; what information must accompany the work; who accepts responsibility; how quickly the next stage must begin; what happens when information is missing; and how exceptions are escalated.
Without these rules, teams create informal workarounds. They rely on personal relationships, memory, and repeated clarification. This may function while experienced staff remain in place. It becomes fragile when people leave; volume increases; partners change; work becomes more complex; or the organization introduces automation.
A resilient operating model makes handoffs explicit.
Every organization already has an operating model. The question is whether it is deliberate.
The actual operating model may be found in who people call when formal processes fail; which spreadsheet is trusted more than the official system; who can get a decision made quickly; which team absorbs work that belongs elsewhere; what staff do to manage exceptions; and which senior person is required to unblock routine activity.
These behaviours reveal how the organization truly works. A formal redesign that ignores the hidden operating model is unlikely to succeed.
The work must examine formal structure; actual behaviour; incentives; workarounds; dependencies; and institutional knowledge. Otherwise, the organization may design an idealized model that has little relationship to operating reality.
Before approving a structural redesign, leaders should ask:
If the answer focuses mainly on titles and reporting relationships, the organization has probably designed a chart rather than an operating model.
Organizational structure matters. It affects authority, identity, accountability, and leadership. But structure must be connected to the way work is actually performed.
A functioning operating model explains what value the organization creates; what capabilities it requires; how work moves; who decides; how information supports action; how partners connect; and how performance improves.
The question is not whether the new chart looks clearer. It is whether the new model makes the organization more capable of delivering its mandate.
Common Practice designs the operating structures, decision rights, workflows, governance systems, and implementation pathways behind organizational strategy. We build how the organization must work—not only how it appears on paper.
The Ten-Component Operating Model — One page: all ten components, the handoff rules, and the ten questions to test before approving a redesign.