Organisational Design Basics for HR Professionals

Organisational design aligns work, decision authority, roles and coordination with strategy. Moving boxes on an organisation chart is one output, not the design process.

Start with work and customers

Define the outcomes, customers, capabilities and constraints. Identify work that must be close to a market, standardised centrally or integrated across functions. Do not begin with the names of current leaders.

Choose grouping logic

Functions group expertise; business units group products or markets; geography supports local responsiveness; process structures follow an end-to-end flow; matrices combine dimensions but increase coordination cost. Select the dominant logic and make trade-offs explicit.

Clarify decision rights

For important recurring decisions, name who decides, provides input, executes and can escalate. A matrix fails when two leaders can block but nobody can decide.

Design roles and layers

Define accountabilities, not only reporting lines. Review spans based on work complexity, manager capability, employee experience and geographic spread. Removing layers can speed decisions, but overly broad spans reduce coaching and control.

Map interfaces

Most failures occur between teams. Define hand-offs, service expectations, shared data and issue resolution. Centralising payroll administration, for example, still requires local attendance ownership and a clear exception route.

Test scenarios

Walk through a customer issue, new hire, budget decision, product launch and crisis. Note where information stops or approvals duplicate. Test normal and exceptional work before finalising roles.

People implications

Assess role changes, skills, workload, location, selection, consultation and employment terms. Use fair criteria and current legal advice where roles may be displaced. Do not announce a chart before leaders can explain how work will operate.

Implementation

Sequence decisions, role appointments, process changes, system access and communication. Track decision time, hand-off errors, workload and customer outcomes. Adjust design based on evidence rather than reversing it after the first complaint.

Establish design principles

Before comparing structures, agree a short set of choices such as customer proximity, consistent control, speed, specialist depth or cost discipline. Principles must resolve tensions. “Be agile and efficient” is too vague; “routine transactions are standardised centrally while market pricing decisions remain local” guides an actual design decision.

Size work before naming jobs

Estimate demand, volumes, service levels, skill requirements and peaks. Distinguish permanent work from projects and exceptions. Then build roles with coherent outcomes and feasible workload. Designing positions around incumbents can preserve fragmented responsibilities, while using benchmark ratios without understanding work can remove capacity that the process still needs.

Govern the design process

A small design team should maintain assumptions, options and decision logs. Leaders need defined approval rights, and HR should challenge duplication, unclear accountability and people risk. Sensitive employee data and premature role conclusions require controlled access. Where consultation or employee-representation obligations apply, incorporate them into the sequence using current local advice.

Consider enabling systems and controls

A reporting-line change does not automatically change workflow, data access, financial authority or system roles. Map these dependencies for each proposed unit. Check segregation of duties, privacy, record ownership and continuity during transition. If systems cannot support the target design immediately, specify a safe interim process and an owner for closing the gap.

Know when the design is working

Use measures tied to the reason for change: decision cycle time, customer resolution, duplicated work, control failures, management load, skill coverage and employee clarity. Establish a baseline before implementation. Early confusion may reflect transition rather than a flawed model, so combine data with structured feedback and review at agreed intervals.

Good design makes important work and accountability easier to see. It does not eliminate coordination; it decides where coordination is worth its cost.