MENU

When Shared Ownership = Zero Ownership

Why shared project responsibility fails - and how to avoid it without the theatre

At Nolo we work on *a lot* of projects. Client projects, our own projects, our own projects as part of client projects. Large projects, small projects. You get it. As a team we see many different project management approaches. But across all those differences there is one issue that we see time and again - the problem of “shared ownership”.

You’ve been in the meeting.

It’s the one where a room full of super-smart, fully engaged people agree the project is “looking a bit tight”, make another couple of additions to the risk register - just to be safe - then after the idle closing chat everyone disappears. Back to the day job.

Cut to two weeks later. The project team is still talking about the same rocks in the river. The same decision is still ‘with someone’. The same dependency is ‘yeah that’s happening’. The project hasn’t blown up spectacularly. Nobody’s turned up wearing a sandwich board with ‘The End is Nigh’ written on it in Sharpie. At least not yet.

It’s just developed that special kind of quietly creeping anaemia where everything technically has an owner, but nothing quite gets done, nobody’s fully sure why, and half the people in the room couldn’t confidently explain what’s happening - or what the real issue is. But the one definite is that fatigue is creeping in and engagement is draining away.

But here’s the good bit - it’s not just you. It’s not even just your team, or your organisation. This is all well studied, well known human group behaviour dynamics. We’ve seen it in retail, ops, creative teams, product, finance - basically anywhere a project cuts across functions and the default is “the group will manage it”.

The short version: when ownership is shared in theory but not owned in practice, responsibility diffuses. It turns into a fog. People default to what they can see, control, and be judged on - their own output, their own workstream, the stuff that lands in front of the important folks - and the project becomes a stray cat everyone feeds but no-one takes home because it looks like more effort. And nobody has the energy for that.

Project work is uniquely adept at creating this confusion because it sits across:

  • reporting lines
  • incentives
  • the gravity of real work
  • and the perceived fiction that a group will somehow manage itself

That’s not collaborating. That’s anarchy with calendar invites.

And the cost isn’t just in delivery. It’s human too:

  • Trust drops because follow-through starts to feel like a dice roll
  • Motivation slides because effort doesn’t produce meaningful progress
  • Frustration spikes because people start filling gaps they don’t own (but other people do)
  • Safety erodes because accountability gets confused with blame, so everyone gets careful

None of that sounds like good, healthy, productive fun. So why does it happen - and how do you avoid it so running projects results in gain not drain?

When ownership is shared in theory but not owned in practice, responsibility diffuses.

Gavin Fudge, Nolo Apps

The psychology of ‘someone will handle it’

This isn’t a mysterious cultural failing. It’s a predictable set of behaviours that show up when responsibility is unclear, contribution is hard to see, and the group is large enough for everyone to plausibly assume “that’s not on me”.

1. Diffusion of responsibility: the bystander effect, but with decisions

The classic finding: when people believe others are also present, they feel less personal responsibility to act.

Darley and Latané showed this in foundational experiments on bystander intervention - as the number of perceived bystanders increased, people were slower and less likely to intervene.

Translation (project edition): if the project ‘team’ owns the decision, the risk, or the dependency, then everyone can reasonably assume someone else is on it. Not because they’re selfish or ducking responsibility. Because the system makes that assumption feel rational.

At Nolo, this is one of the first things we listen for - not because we’re trying to catch people out, but because it tells you immediately whether the project has real ownership or just shared intent.

Telltale signs you’ve got ownership diffusion:

  • actions phrased as “we should…” or “someone needs to…”
  • decisions that are “with the business” (which business, exactly?)
  • risks that are “owned by the group”
  • blockers that live in meetings but not in anyone’s diary


2. Social loafing: effort drops when contribution isn’t identifiable

When individual effort can’t be clearly seen or attributed, people tend to exert less effort on collective tasks - a behaviour named ‘social loafing’.

Latané, Williams, and Harkins demonstrated this experimentally - famously with clapping and shouting. As group size increased, individual effort decreased.

Karau and Williams pulled the evidence together in a meta-analysis and proposed the Collective Effort Model - noting that people work better when they believe their effort is instrumental and will be recognised.

Translation: the least-owned work is often the most valuable work - the glue. Sequencing. Chasing the decision. Surfacing the trade-off. Aligning the handover. It’s not ‘anyone’s deliverable’, so it quietly becomes no-one’s priority.

If you’ve ever wondered why projects can be “busy” and still go nowhere, it’s usually because the glue work has become invisible - and invisible work doesn’t get protected.

One important nuance: people don’t always loaf. Sometimes they compensate - working harder when they think others might underperform on something meaningful.

That’s exactly why a few heroic individuals can keep a project moving - right up until they burn out or check out.


3. Role ambiguity: when “who does what” is fuzzy, performance suffers

Projects are basically role ambiguity factories. Everyone has a day-job role, then a project role draped over the top, and the seams don’t always line up.

Meta-analytic evidence shows role ambiguity is associated with poorer performance outcomes.

Translation: if decision rights, escalation routes, and ownership boundaries aren’t explicit, you get:

  • hesitation (“is this mine to decide?”)
  • duplication (“I did it because I thought no-one else would”)
  • gaps (“I thought you had it”)
  • over-step (“it needed doing”)


4. Accountability effects: behaviour changes when people expect to explain themselves

Accountability has a bad reputation because organisations often use it like a stick. The research is more interesting than that.

Lerner and Tetlock reviewed a large body of evidence showing that when people expect their judgments and choices to be evaluated, it changes how they process information and how they follow through.

Translation: when “I’ll own this and report back” is a normal, low-drama expectation, projects move. When it’s optional, everything drifts.

At Nolo, we’re not chasing “accountability culture”. We’re trying to build systems where follow-through is the default because the work is clear, visible, and owned - not because of fear of negative repercussions.


5. Intention isn’t a plan: vague goals create vague action

Two bits of research matter here:

Goal-setting theory shows specific and challenging goals (with feedback) reliably improve performance compared with vague “do your best” intentions.

Implementation intentions (“if X happens, I will do Y”) improve follow-through by linking action to a trigger and a concrete response.

Translation: “we need to sort the migration” is a sentiment. “If the supplier file arrives by Tuesday 12:00, then Sam validates columns A–F against spec v3 and posts pass/fail by 17:00” is a mechanism.

And if you’ve sat through enough project stand-ups and retros, you’ll know: most projects fail in the gap between sentiment and mechanism.

So, what can we do about it?

If you want shared goals without foggy ownership, design the project so responsibility can’t evaporate.

At Nolo Apps, this is the part we care about most - not theory, but what you can do as an intention that changes the shape of the work.

Here are three practical design requirements:

  • Clear ownership - who is on the hook for what
  • Visible contribution - helps effort stay high
  • Fast feedback loops - so reality corrects the plan

1. Make single-thread ownership the default

For anything that spans multiple teams, assign one accountable owner. Not a status-chaser. An integrator - the person responsible for making the whole thing move.

This counters diffusion of responsibility by removing ambiguity about who acts first.

A simple rule that saves projects:

If it needs more than one team to complete it, it needs exactly one named owner to drive it.

This is where a lot of projects get weirdly emotional, because people confuse ownership with control. It’s not control - It’s stewardship.

2. Clarify decision rights where it matters

You don’t need a 40-row RACI spreadsheet. You need simple clarity on the decisions that shape delivery.

Make sure to clarify who makes the decisions on:

  • the big scope trade-offs
  • the risky dependencies
  • the “go/no-go” moments (testing, cutover, launch readiness)
  • anything that keeps coming back as “with someone”

Role ambiguity predicts worse performance, so this is not bureaucracy - it’s friction removal.

Include minimum viable decision clarity:

  • Who decides?
  • Who executes?
  • Who must be consulted?
  • Where is this written down?

This information needs to be visible where people actually work - not in a forgotten folder or doc no-one looks at, or done as a meeting discussion. And it needs to be explicit, not implicit.

3. Make contribution identifiable - name the work

Social loafing is heavily influenced by whether individual effort is visible and attributable.

Make the work visible at the level that matters:

  • every action has an owner (a person, not “the Ops Team”)
  • every action has a due date
  • every action has a definition of done - one sentence, no more, no less
  • every action has a next step - what happens immediately after this is done

If your tracker can tell you status but can’t tell you ownership, it’s not a project system. It’s a mood board.

(We’re good with mood boards. Just not as a delivery mechanic.)

4. Build accountability without blame

Accountability changes how people think and act when it’s expected and real.

The trick is to make it normal, lightweight, and forward-looking. Not a threat of ego attack based on things that can’t be changed (spoiler alert: none of us can change the past).

A pattern that works:

  • Start meetings with “actions closed” before “new actions”
  • Overdue actions get neutral prompts: “What changed? What do you need? What’s the new date?”
  • Never “Why didn’t you do that?”
  • Keep it factual. No drama. Progress over performance is the focus.

This keeps accountability from turning into theatre - or worse, silence.

5. Turn intentions into if-then plans

Implementation intentions work because they remove ambiguity at the moment action needs to happen.

Upgrade your action language from “Review vendor feed” to “If vendor feed arrives by Tuesday 12:00, then Alex validates columns A–F against spec v3 and posts pass/fail by 17:00.”

This is one of those changes that feels almost too simple until you realise how many projects are run entirely on vibes rather than reality.

6. Set goals that have edges, and give feedback that’s real

Specific and challenging goals with useful feedback drive performance better than ambiguity.

So instead of “Complete UAT” try “By Friday 17:00, close 30 priority test cases, with zero P1 defects open, and owners assigned for any remaining P2s with fix dates.”

Edges create traction → Traction creates progress → Progress creates engagement.

7. Shrink the execution group at delivery point

Big groups are good for alignment. Small groups are good for delivery.

As delivery group size grows, diffusion and loafing risks increase - especially when contribution is hard to see.

Keep the wide stakeholder circle, but create small delivery cells for outcomes:

  • 2–4 people
  • one accountable owner
  • clear deliverables
  • short-cycle check-ins where progress is evidenced, not narrated

8. Watch for hero compensation and fix the system, not the person

Sometimes the project works because one or two people compensate for the fog - they chase, patch, decide, and rescue. Social psychology shows this can happen when people expect others to underperform on meaningful tasks.

If you spot it, don’t praise it and move on. That’s how you bake burnout into your model.

Instead:

  • make the glue work explicit
  • redistribute ownership
  • make escalation safe and normal
  • stop relying on informal heroics as the real project plan - this is short term gain for long term pain when the heroic performers check out without warning.

The Kick

You don’t fix project issues by asking engaged teams to “take more ownership” or do more work. You fix it by designing an environment where ownership is clear, contribution is visible, and follow-through is normal.

  • Diffusion of responsibility is real - remove ambiguity.
  • Social loafing is real - make contributions identifiable and acknowledged.
  • Role ambiguity is real - clarify decision rights and boundaries, and make sure they are explicitly known.
  • Accountability effects are real - build calm report-back loops that focus on progress, not past activity.
  • Intention is not execution - use specific goals and if-then planning.

Projects rarely fail because people don’t care. They fail because the system quietly makes it reasonable for everyone to care about the cost, but still assumes someone else will pick up the tab.

And that stray cat stays outside. In the cold.

References and models cited:

If you takeaway nothing else...

1
Shared ownership is no ownership. When responsibility belongs to everyone, accountability belongs to no one.
2
Make every action visible, named, and defined.
3
Design for follow-through, and the project moves. Leave it to goodwill, and the stray cat stays outside.