Design the Work System Before Redrawing the Org Chart
Organizational design turns fragmented handoffs into clear, accountable work.
An organization chart can be accurate—and the organization can still be hard to run. The chart identifies reporting lines; it rarely reveals how work moves, where decisions stall, or why capable people must rely on workarounds to deliver a result.
Sometimes those changes are necessary. But the chart is only a partial map. Before leaders rearrange boxes, they need to see the work system underneath them: the tasks required to produce an outcome, the handoffs between teams, the information people need, the decisions they can make, and the exception paths that take over when normal work breaks down.
Consider a customer exception that passes from sales to operations to finance and then to a senior leader. The visible problem may look like slow execution. The design problem may be more specific: no one owns the end-to-end outcome, the approval threshold is unclear, or the information needed to resolve the issue is trapped in separate systems. Adding another meeting will not fix that. A usable work system might.
That is organizational design. It is the deliberate arrangement of work, authority, coordination, and feedback so people can deliver results without relying on heroics.
Start with one outcome, not a future-state chart
Organizational design is often mistaken for a restructuring exercise. It is better understood as a leadership discipline: making the work of the organization easier to see, easier to coordinate, and easier to improve.
Start with one outcome that matters—a customer onboarding, a service recovery, a proposal-to-cash process, a project handoff, or a recurring operational decision. Then ask:
- What work must happen for this outcome to be delivered well?
- Where does work change hands?
- Which decisions affect speed, quality, cost, risk, or the customer experience?
- What information must travel with the work?
- What happens when the normal process cannot handle the case?
This approach gives leaders something more useful than an abstract debate about “flat” versus “hierarchical” organizations. It gives them observable work, visible dependencies, and a concrete starting point for redesign.
The four design lenses
A practical review of any work system can begin with four questions.
1. Task: What work is actually required?
Jobs should be designed around the real work required to deliver an outcome—not merely around legacy titles or inherited responsibilities. Leaders need to distinguish between work that requires judgment, relationship management, technical expertise, routine execution, review, and escalation.
When that distinction is weak, people either duplicate effort or leave critical work unowned. The remedy is not always a new position. It may be a clearer role, a simplified handoff, better information, or a deliberate decision to remove low-value work.
2. Authority: Who can decide, and within what threshold?
A role without usable authority creates delay. A role with broad authority but no boundaries creates risk. Sound design makes the threshold visible: who decides, what evidence is required, what amount of risk or expense is acceptable, and when an issue moves upward or across the organization.
This is more precise than telling people to “take ownership.” Ownership becomes credible when people know the outcome they own, the decision they may make, and the point at which they must involve others.
3. Coordination: How do dependencies get managed?
Specialization builds capability. It also creates interfaces. A sales team, an operations team, and a finance team can each perform well independently while the customer experience fails between them.
The coordination mechanism should match the interdependence of the work. Some work is pooled: teams share standards or resources but operate largely independently. Some is sequential: a delay or defect upstream directly affects the next step. Some is reciprocal: people must continually adjust to one another, as in complex delivery, product development, or incident response.
The answer may be a shared queue, a standard, a liaison role, a recurring decision forum, a common measure, or an explicit exception process. It is not automatically a reorganization—and it is not automatically more meetings.
4. Feedback: How does the organization know whether the design is working?
A design is not complete when the chart is announced. Leaders need feedback that shows whether the system is producing the intended result: quality, cycle time, rework, customer outcome, workload, risk, and the volume of exceptions.
A team that reports only activity can look busy while the work system deteriorates. Useful feedback lets leaders see where decisions slow down, where handoffs fail, and where people are compensating for a design problem with personal effort.
Design around outcomes without weakening functional expertise
Many organizations get stuck between two unhelpful extremes: functional silos with weak customer integration, or cross-functional teams with no durable technical standards. A stronger pattern is often to preserve both.
Functional leaders can protect professional standards, capability development, capacity, and technical quality. At the same time, named owners can integrate the work required to deliver a customer or operating outcome across functions. A light enterprise layer can establish shared policy, data, financial, and risk guardrails.
This is not a universal template. The right design depends on size, industry, regulatory exposure, capability, and the nature of the work. The principle is simpler: organize expertise where it must deepen, and integrate the work where the outcome depends on multiple specialties.
The key is to make the interface usable. If a value-stream owner is accountable for a result but cannot resolve routine trade-offs, the role is ceremonial. If a functional leader owns standards but has no visibility into customer consequences, the function becomes isolated. Effective design gives both roles a clear contribution and a workable way to coordinate.
AI is a design stress test—not an organizational shortcut
Artificial intelligence belongs in this discussion because it changes task bundles. It can accelerate drafting, retrieval, analysis, routing, and some forms of routine execution. It does not automatically decide who is accountable, resolve conflicting priorities, repair a broken handoff, or determine when a customer exception requires human judgment.
In that sense, AI is a stress test for organizational design. It exposes questions leaders may have been able to ignore when work moved more slowly:
- Which tasks can be automated, augmented, reviewed, or redesigned?
- Where must human judgment remain visible?
- What information may be used, and who owns its quality?
- When should a decision be escalated rather than accepted automatically?
- Which role owns the customer or operating outcome after the tool is introduced?
The objective is not to build an “AI organization” around a tool. It is to redesign the work deliberately so technology strengthens a coherent operating model. Leaders looking for the detailed discipline of a governed pilot should begin with ARCH’s guide, Responsible AI Implementation Starts with a Workflow, Not a Tool.
Run a 60-day design test
Leaders do not need to redesign the entire organization to begin learning. A short, bounded design test can produce real evidence.
- Choose one visible bottleneck. Select a customer-critical or operational outcome where delay, rework, escalation, or confusion is observable.
- Map the work system. Identify the task flow, handoffs, decisions, information, measures, and exception path.
- Make one design change. Clarify a threshold, simplify a handoff, establish a shared queue, name an end-to-end owner, or create a feedback routine.
- Measure the result. Compare quality, cycle time, rework, customer outcome, workload, and risk—not speed alone.
- Decide what the evidence supports. Scale the change, revise it, or stop it. A disciplined stop is learning, not failure.
This kind of test makes organizational design concrete. It also prevents a familiar mistake: launching a broad transformation before leaders have demonstrated which design choices improve the work.
Design is visible where work happens
Organizations do not become effective merely because their charts are elegant. They become effective when authority is usable, handoffs are deliberate, information reaches the people who need it, and feedback makes breakdowns visible before they become chronic.
The next time a team says, “This process is broken,” do not begin with the question, “Which box should move?” Begin with a better question: What must change in the work system for this outcome to be delivered well?
That is where organizational design begins.
ARCH helps leadership teams diagnose handoffs, decision rights, and operating-model friction during organizational transition.
For leaders who need to diagnose broader transition readiness before redesigning a work system, ARCH’s Organizational Health During Transition guide offers a complementary diagnostic. For a context-specific redesign effort, explore Organizational Transition Consulting & Operating Model Redesign.
The Dr. Claude Kershner Show
See Organizational Design in Practice
Watch the full video for a practical walkthrough of how work, authority, and coordination shape the way an organization performs.
Sources and evidence notes
This article draws on established organizational-design scholarship on structure, information processing, and coordination. Foundational references include Organizations: Structures, Processes, and Outcomes (Donaldson), Designing Organizations (Galbraith), and Organization Design (Burton, Obel, and Håkonsson). The AI section is intentionally limited to organizational-design implications. Recommendations are context-dependent and should be adapted to an organization’s industry, risk, legal obligations, and operating reality.
