“Everyone is responsible for the customer” sounds constructive until a customer requires a decision. Sales wants a concession, operations needs a stable plan and finance questions the exposure. Nobody knows who can decide.
Accountability becomes useful when a role has a clear outcome, enough authority to influence it and a defined way to resolve dependencies. A job title alone establishes none of these.
Define roles around outcomes
A role describes a recurring contribution to the organization. One person may hold several roles, and several people may perform the same role in different contexts.
For each important role, define its purpose, expected outputs, scope, authority and interfaces. Include the resources it can commit and the decisions that remain outside its mandate.
Avoid writing long activity inventories. “Attend project meetings” describes participation. “Resolve cross-functional readiness gaps before release” describes a contribution that can be evaluated.
Separate different kinds of authority
People management, technical authority, process ownership and commercial approval are distinct. They may sit with one person or be deliberately separated.
A project leader can own delivery coordination without being qualified to approve a safety-critical technical change. A functional manager can develop specialists without having unilateral authority to reprioritize every committed project.
The organization must explain how these forms of authority interact. Otherwise, employees receive competing instructions and are left to negotiate the hierarchy themselves.
Design the decision before assigning initials
Tools such as a responsibility matrix can help identify who performs, approves, advises or receives information. Their value depends on the underlying decision being specific.
“Responsible for quality” is too broad. “Approve release when verification evidence meets the agreed criteria” is actionable.
For a significant decision, record:
- the decision owner
- the required input
- any bounded approval rights
- the time limit
- the escalation route
A single accountable owner is often useful, but some decisions legitimately require separate approvals for different obligations. Name those boundaries explicitly.
Test the rules against a real exception
Consider a hypothetical customer requesting an accelerated commissioning date. Sales can discuss the request but cannot commit additional delivery capacity. The project leader develops options; operations confirms capacity; the authorized commercial owner approves the tradeoff within defined limits.
If the request breaches those limits, the escalation should include options, consequences and a recommendation. It should not simply transfer an unresolved problem upward.
Test what happens when an adviser does not respond or two approval rights conflict. An arrangement that works only when everybody agrees is incomplete.
Match accountability with control
Do not hold a role solely accountable for an outcome it cannot materially influence. A process owner needs access to evidence and a mechanism for improving cross-functional performance.
Equally, authority should not become unlimited discretion. Define budget, risk and policy boundaries. Explain which decisions can be made locally and which require additional review.
Keep the definitions visible where work occurs: in project briefs, workflow rules and onboarding. A document stored far from daily decisions has limited practical value.
Review the highest-friction decisions
Select ten decisions that repeatedly wait, escalate or get reversed. Ask the people involved to describe who currently decides. Differences in their answers reveal ambiguity.
Clarify the most consequential decisions first, then observe actual cases. Track response time, reversals and the quality of outcomes. Update the rules when new evidence shows that a boundary is wrong.
The aim is fewer avoidable negotiations and clearer responsibility for the decisions that shape performance.