Organizational design · Work dependencies · Operating models
Design the work and its coordination before drawing the new organization chart.
Arcus helps leaders compare structural options against how work is delivered, where decisions stall and which capabilities must be shared or kept close to customers. A redesign should make an operating problem easier to solve.
Work → Dependencies → Design → Transition
01 / Which work genuinely needs to be grouped together?
02 / Where would the new model move coordination effort?
03 / Can the organization afford and deliver the transition?
Should you restructure—or change how teams work together?
A growing organization misses service targets despite adding managers. Leaders propose combining departments under one executive. This could help if conflicting priorities and unresolved handoffs are the main constraint. It could also leave the problem intact if specialist capacity is scarce, customer demand has changed or the approval process remains unchanged.
Arcus’s central thesis is that an organization design should make the most important work dependencies manageable. Moving reporting lines can relocate a coordination problem without resolving it. Compare the existing model, a process-level intervention and credible structural alternatives before committing to a new chart.
This page addresses the choice and implementation of an operating design. A broader organizational review establishes which problems require attention; design work turns that diagnosis into alternatives for grouping work, assigning authority, allocating capacity and coordinating delivery.
Four diagnoses that can produce the same missed target
Use operational evidence and interviews across handoffs to distinguish these causes. They can coexist.
01 / Work crosses incompatible boundaries
Teams optimize their own queues while the end-to-end service stalls. Trace a sample of work from request to outcome: record handoffs, waiting, rework and changes of priority. A common supervisor may help, but so might a shared scheduling rule or an accountable process owner.
02 / Capacity or expertise is the constraint
Delays cluster around a scarce skill or an overloaded role even when decisions are clear. Examine workload, variation, coverage and the time required for the work. A reporting-line change does not create capability or remove demand.
03 / Decision authority is misplaced
Routine work waits for decisions that could be made closer to delivery, or local choices create enterprise consequences without review. Compare the authority actually used with the formal delegation. Separate a decision-rights correction from a wholesale restructure.
04 / Measures and incentives conflict
A function meets its own cost or activity target by transferring work or risk elsewhere. Examine whole-service results alongside local measures. Co-location and new titles alone will not reconcile competing objectives.
What organization research contributes
The abstract of the 2012 Academy of Management Review article Organization Design: The Epistemic Interdependence Perspective describes an analytical framework connecting interdependence, the knowledge needed to anticipate others’ actions and organizational information-processing requirements. It provides a useful theoretical lens for asking what teams need to know about one another to coordinate work.
This is conceptual research, not an empirical estimate of restructuring success. The bibliographic record and publisher abstract were reviewed; the full article was not accessible. Arcus does not infer a prescribed structure, savings estimate or validated diagnostic from it. The framework on this page is our management synthesis and should be tested against the organization’s own evidence.
A documented warning about the redesign business case
The UK National Audit Office’s Reorganising central government report, published March 18, 2010 examined historical government reorganizations. It found weak definition and tracking of benefits, and reported that three-fifths of the arm’s-length bodies had not appraised alternative options before deciding to reorganize. Its cost estimate was explicitly incomplete and did not deduct benefits.
These are findings about UK government changes in a specific historical period. They are not a current Canadian failure rate and do not show that restructuring never works. They support a narrower management requirement: define the intended benefit, compare alternatives and establish cost and outcome tracking before implementation.
An attractive target structure is therefore not a complete business case. Leaders need to explain the mechanism of improvement: which dependency, decision or capacity problem changes, how it changes and what new coordination work the alternative creates.
The Arcus work-dependency design test
Apply this original diagnostic to one important service or value stream. Use evidence and explicit judgments rather than a generic numerical score.
01 / Define the work and outcome
Identify the customer or service recipient, the intended outcome and major work steps. Separate demand, activity and results. Record where variation matters: some requests may be standardized, while others need local judgment.
02 / Map dependencies and authority
For each critical handoff, identify what must be exchanged, who controls timing and resources, and who resolves exceptions. Distinguish predictable transfers from work requiring frequent joint adjustment. Record where information arrives too late to be useful.
03 / Compare whole operating models
Specify grouping, decision rights, specialist access, common standards, coordination routines and measures for each alternative. Explain which dependency becomes easier and which becomes harder. Do not assess a chart independently of its operating rules.
04 / Test transition and viability
Identify one-time change work, ongoing coordination needs, capacity coverage and service risks. Define an observable test and review gate before wider rollout. Escalate unresolved dependencies rather than treating the announcement date as proof of readiness.
Compare realistic operating-model choices
These are conditional design hypotheses, not a universal ranking of structures. A hybrid must explain its boundaries and exception rules.
Functional teams with stronger integration
Consider when specialist depth and common standards matter and most cross-team work can be coordinated through clear routines. Add an end-to-end owner, shared priorities and escalation where needed. Trade-off: specialist pools can remain distant from customer context; integration work needs real authority and time.
Customer, service or product-aligned teams
Consider when outcomes require frequent joint adjustment and teams can hold the necessary capabilities. Trade-off: expertise or systems may be duplicated, and scarce specialists can be spread too thin. Specify common standards and access to capabilities that remain shared.
Shared specialist services with local delivery
Consider when repeatable specialist work can be pooled while local relationships or judgment remain important. Trade-off: central queues can weaken responsiveness. Define service expectations, demand priorities, escalation and how local exceptions are handled.
Matrix or dual-accountability arrangements
Consider when two dimensions genuinely require sustained influence, such as professional standards and service delivery. Trade-off: competing priorities can create negotiation overhead. State who decides resources, performance expectations and unresolved conflicts; two reporting lines are not a substitute for those rules.
Worked illustration: centralize specialists or create service teams?
A fictional organization has regional service teams supported by a central specialist group. Delays are attributed to the central pool. Leaders consider assigning specialists permanently to each region. No client outcome or numerical performance claim is implied by this illustration.
A dependency review finds two distinct types of work: routine requests with stable information requirements, and complex cases that require repeated discussion with local teams. Full decentralization might shorten complex-case communication but leave some regions without enough specialist work to maintain coverage. Full centralization might preserve expertise while continuing to separate specialists from context.
One testable option is to keep a pooled route for routine work and create named specialist partnerships for complex cases, with an agreed prioritization process. Compare this with permanent regional teams using evidence on demand mix, waiting, rework, coverage and coordination time. If complex work dominates and each region can sustain capability, a more decentralized model becomes more plausible. If scarcity is the real problem, allocation or capability development may be necessary under either structure.
The decision is conditional. Leaders should identify what evidence would reverse their preferred option, how a pilot protects service continuity and who can resolve cross-region priority conflicts. A hybrid without these rules can reproduce both models’ disadvantages.
Build the economics around work, not assumed headcount savings
Compare each option over the same planning period and demand assumptions. Start with recurring staffing and operating requirements; add management and coordination time, systems support and specialist coverage. Then identify one-time design, consultation, recruitment, training, data migration, temporary duplication and handover requirements. Do not treat all of that work as free because current staff perform it.
A useful comparison separates four quantities: ongoing resources in the current model; ongoing resources in the proposed model; one-time transition resources; and the capacity required to sustain service during change. Keep released capacity separate from cash savings. A lower workload creates a cash benefit only if spending can actually be reduced or avoided; redeployed time should be described as redeployed capacity.
Include a sensitivity assessment for demand, recruitment delays, learning time and dependencies on technology or partners. If an option appears affordable only when implementation is immediate and disruption is negligible, the business case is fragile. No standard savings percentage or optimal span of control is assumed here.
Sequence implementation around service readiness
The executive sponsor should confirm the outcomes, constraints and decision authority. Design leads should work with service owners, HR, finance, technology and affected teams to develop alternatives and document trade-offs. The first gate is an agreed diagnosis and a feasible model—not approval of a diagram alone.
Before implementation, settle critical role accountabilities, capacity allocation, handoff standards and escalation. Identify required approvals and appropriate specialist advice on people, contractual or regulatory matters. The second gate is readiness to maintain the service while responsibilities change. Communicating a new structure does not establish that readiness.
Pilot where a bounded test is feasible. Monitor end-to-end completion, waiting, rework, service quality, unresolved decisions and workforce coverage against a suitable baseline. Review changes in demand and other initiatives before attributing results to the redesign. Where a pilot is impractical, use structured scenario walkthroughs and explicit continuity arrangements, recognizing their limits.
The final gate is a review of adoption, operating outcomes and recurring resource requirements. If local performance improves while the wider service deteriorates, revisit the boundaries and measures. Organization development—including capability, management routines and collaboration—must continue after reporting lines change.
What Arcus can help leadership deliver
An engagement can range from a focused operating-model comparison to a broader design and implementation program.
01 / Diagnose
A work and dependency map, stakeholder evidence summary and decision brief distinguish structural constraints from capacity, workflow and incentive issues.
02 / Evaluate and decide
Alternative operating models, role and decision-rights maps, resource comparisons and risk assessments make the case for change—and the case for retaining elements of the current model—reviewable.
03 / Design and implement
A target operating model, draft accountabilities, coordination standards, implementation roadmap and readiness gates connect design choices with service continuity.
04 / Measure and improve
A baseline and review framework, outcome indicators and implementation review help leaders test whether the intended mechanism worked and what requires adjustment.
Discuss the organizational choice you need to make
Tell Arcus which service or strategic priority is difficult to deliver, the models under consideration and the timing constraints. We can help define an evidence-based design scope and practical deliverables. Begin with a general description rather than identifiable employee records.
For the broader diagnosis, see organizational review and design. For authority and escalation arrangements, see governance consulting services.
Selected historical Arcus work
These retained examples and testimonial describe broader Arcus work. They are not measured results of the design diagnostic above.
Below is a sample of the range of services that Arcus has provided to clients.
- A survey of 2,350 consumers and 1,320 business leaders for feedback on sustainability trends
- Architecting a multi-year change strategy for a Fortune 500 company
- Mentoring a CEO on organizational change
- Excellence transformation of a leading B2B services company
- Creating a new sales deployment model for a healthcare company
- Developing a position evaluation and compensation model for a professional medical association
- Improving services to customer segments by deepening their understanding of customer attitudes
“Arcus manages to consistently deliver tangible results on market research and strategy projects. They combine deep business expertise, powerful research capabilities, and innovative thinking to deliver substantial value.”
– Vice President, Nikon