Short answer
Organizational design defines roles, responsibilities, and reporting relationships that support the intended work. It rates whether people know who owns what, not how neat the chart looks.
About Organizational design
Defines roles, responsibilities, and reporting relationships that support the intended work. Strong design makes decision rights, interfaces, and workload visible enough to test before a reorg is treated as done.
Use this competency for
- People roles that change team structures, role charters, or reporting lines with Function owners.
- Functions accountable for clarifying ownership when work stalls at team boundaries.
Do not use this competency for
- Do not use it to rate taste in titles, or to score how often someone proposes a reorg.
Important distinctions
Workforce planning
Workforce planning sizes capacity. Organizational design decides how work and authority are grouped.
Expectations by level
IC1
Documents defined structures with guidance
Updates well-defined role and reporting records with guidance and flags missing owners on work that already has a named team.
Observable behaviors
- Keeps the live org record aligned with announced reporting.
- Writes a role purpose in outcome language, not a task dump.
- Names the decision owner for a recurring handoff.
Examples
- Corrected a reporting line after a manager change was announced but not reflected in the system.
- Added a missing owner to a handoff that had two teams and no decision right.
IC2
Designs a Function structure independently
Independently proposes a Function structure for a known workload, tests it with the people who do the work, and records what will stop if the design is wrong.
Observable behaviors
- Separates a reporting change from a title change.
- Maps interfaces between teams before moving people.
- States the decision rights the new design is meant to fix.
Examples
- Stopped a title inflation request and instead clarified who owned a delayed launch decision.
- Drafted a two-team split with a shared intake owner after work queued in one inbox.
IC3
Sets structure practice across Functions
Guides multi-Function design and changes shared practice when reorgs repeatedly recreate the same ownership gaps.
Observable behaviors
- Defines a design brief that includes work, not only boxes.
- Reviews post-change evidence and adjusts interfaces.
- Blocks a structure change that has no named decision rights.
Examples
- Introduced a design brief after two reorgs left the same cross-team decision ownerless.
- Merged overlapping manager layers after work still needed the same person to unblock.