Linum Blog

Accountability Without Blame: Restoring Ownership When Work Crosses Teams

Jay Steyn
March 6, 2026
Most organisations reach a point where work no longer fits neatly inside one team. Product teams need engineering and risk. Sales needs marketing and operations. Delivery needs legal and compliance. So the business builds a structure where people work across teams and sometimes answer to more than one leader. That is what people usually mean when they say "matrix organisations."

Most organizations reach a point where work no longer fits neatly inside one team. Product teams need engineering and risk. Sales needs marketing and operations. Delivery needs legal and compliance. So the business builds a structure where people work across teams and sometimes answer to more than one leader. That is what people usually mean when they say "matrix organizations."

It is a sensible structure. It lets specialists be shared and prevents every unit from rebuilding the same capabilities. The downside is predictable. Ownership becomes unclear because many people can say they were involved, but nobody feels ultimately responsible.

When accountability is unclear, the conversation after an incident is often a chain of reasonable explanations. "We were waiting on another team." "They changed the requirement." "We did our part." "We assumed someone else owned it." "Legacy code did it." The explanations may be accurate. The outcome is still failure. Harvard Business Review describes this criticism directly. In their words, critics claim that a matrix structure “slows decision making and obfuscates accountability” (Vantrappen & Wirtz, 2016).

This matters because unclear expectations lead to poor execution and morale. Research on matrixed environments often highlights role conflict and role ambiguity when people receive competing expectations from multiple leaders. It also highlights that strong accountability and role clarity correlate with healthier organisational performance (Bazigos & Harter, 2016).

So what does leadership look like if you want ownership without creating fear?

Start with a hard truth. If the system makes it easy to deflect, deflection will become normal. W. Edwards Deming captured the point:

"A bad system will beat a good person every time."  (The W. Edwards Deming Institute, 1993).

Below are three leadership moves that remove the space for excuses.

1) Put one name next to each important outcome

Choose outcomes where failure is visible and costly. Releases. Incidents. Regulatory deliverables. Key customer commitments. For each one, name a single person who owns the outcome end to end. This person does not have to do all the work. They do have to make sure it gets done. That includes pushing for decisions, escalating conflicts, and closing the loop.

A simple standard helps:

If you own the outcome, you do not say "we did not have time for blue/green deployments." You say "we set an aggressive timeframe and we are now proposing a full outage to change the database architecture. That does not meet the acceptance criteria we agreed. Here are the risks, here is the decision I need today, and here is the revised plan to deliver the change safely."

2) Decide who decides

Many accountability arguments are priority arguments in disguise. One team believes a task is urgent. Another team believes it is optional. Work stalls. Later, both teams can explain why they behaved rationally. Leadership has to make "who decides" explicit, especially for recurring decisions like scope trade-offs, incident severity, and release go or no-go.

One question changes the tone fast:

Who makes the call here, and by when?

3) Make trade-offs visible and owned

A CTO asks a team lead to produce a plan to address critical severity items. The expectation is clear: stabilise the system first, then return to feature delivery. Two weeks later, the critical items are largely untouched and the team has shipped feature work. When questioned, the explanation is familiar. Product pressure. A stakeholder escalated. The team thought the critical items could wait.

The accountability issue is not that priorities changed. Priorities always change. The issue is that the trade-off happened quietly, without an explicit decision, and without a named owner taking responsibility for the risk.

In a matrix, this is where accountability often fails. Work gets reprioritised in side conversations. Everyone can point to a reason. Nobody owns the decision or the consequences.

The leadership move is to make trade-offs visible and owned. If critical severity work slips, the team lead must surface it immediately, state what will move as a result, and request a decision. If leadership accepts the risk, it is documented. If leadership does not accept the risk, feature work stops until the critical items meet the agreed bar.

Handling excuses without humiliation

When a lead starts explaining, do not argue with the explanation. Accept it. Then redirect to ownership with three questions:

  1. What outcome were you accountable for?
  2. When did you first see risk building, and what did you do next?
  3. What are the next actions, who owns each, and when are they due?

This keeps the culture safe while still forcing responsibility. It builds the habits that matter most in organisations. Early escalation. Clear ownership. Closure.

A short checklist you can use tomorrow

  1. For this outcome, who is the single owner?
  2. Who makes the call on key decisions, and by when?
  3. What will we stop doing to make room for this work?
  4. What does "done" look like in one sentence?
  5. What can we show in 7 to 14 days?
  6. What dependency could stall us, and what is the escalation path?
  7. If this fails again, what system change prevents repeat failure?
References

More articles from Linum Labs