Fixing the "I Thought You Owned That"

Fixing the "I Thought You Owned That"

The most reliable signal that a team has an ownership problem, and how to remove it

Nobody says "I thought you owned that" in anger.

That is what makes it so dangerous. It is said in surprise, usually quite politely, often with a small nervous laugh, almost always by someone who is not to blame and is about to spend the next four hours fixing something that should never have broken.

I have heard that sentence in every company I have worked in, on both sides of the industry. It is the single most reliable signal that a team has an ownership problem and it almost never arrives at a convenient moment. It arrives at the exact point where the cost of the gap is highest.

And here is the part people get wrong when they respond to it. The instinct is to look for the person who dropped it. Who missed this. Who was supposed to be watching. That instinct feels like accountability and it is almost always the wrong diagnosis, because the honest answer in most of these situations is that nobody dropped anything.

Nobody dropped it because nobody was holding it.

Key Takeaways

• Nobody dropped it because nobody held it. The failure is unassigned work, not a careless person.
• Responsibility divides, it does not multiply. The more people who could act, the less likely any one of them does.
• Failures cluster at the handoff. Work rarely breaks inside a department; it breaks where ownership changes hands.
• One name in the Accountable column, always. Two names is the original problem, now written down.
• RACI is a role, not a document. A matrix nobody owns is worse than none, because it looks solved.

What the Chaos Actually Looks Like

Let me describe the scene properly, because the abstract version of this problem is useless.

• Picture a busy period. In our world that usually means a bull market, when everything moves at once. Several client campaigns running in parallel. Multiple departments involved in each one. Requests arriving through five different channels at all hours, most of them urgent, many of them small.
• Here is what happens to work allocation under that kind of pressure. It stops being assigned and starts being absorbed. Something comes in and it goes to whoever has five minutes free. That feels efficient. It is the opposite.
• Because when work is distributed by spare capacity rather than by ownership, nobody holds the thread. Every individual task gets done. The person with five minutes does the thing and does it well. But no single person is tracking the shape of the whole, so the gaps between the tasks are invisible until something falls into one.
• Meanwhile, the communication gets strange in a very specific way. You end up with overcommunication and miscommunication at the same time, which sounds like a contradiction and is not. There are hundreds of messages a day. Nobody is under-informed in terms of volume. And still, the one thing that actually mattered was said in a thread that the relevant person was not in, at 2am their time, by someone who assumed it had already been handled elsewhere.
• More messages, less clarity. That combination is the classic sign of a missing system, not a communication problem. You cannot fix it by talking more. Talking more is what is causing it.
• At some point in this, an approvals line breaks. It is always something like approvals. A piece of work goes out that should have had a final check, or a piece of work sits for two days waiting for a check that nobody knew they were supposed to give. Someone asks what happened. And the answer, from three different people, is a version of the same sentence.
• “I thought you owned that”.

Why Good People Let Things Fall

Here is the uncomfortable thing. In almost every case I have seen, the people involved were good, senior, conscientious people who cared about the outcome. That is not a coincidence. It is a well-documented feature of how humans behave in groups.

A famous psychology experiment illustrates it precisely. In Darley and Latane's 1968 study, bystanders heard someone apparently having a seizure over an intercom. When a listener believed they were the only person who could hear it, about 85% acted. When they believed several others were listening too, that share fell to roughly 31 percent, and the people who did act took far longer to move. Not because they cared less, but because they assumed someone else would.

The people in the second group were not crueller. They were not less capable. They were doing something entirely rational from the inside: assuming that with several people present, someone else was already acting.

The researchers found that people go through several mental steps before deciding to act. The biggest obstacle is not noticing the problem. It is not deciding whether it is serious. It is deciding whether it is their responsibility to do something about it.

Is it my job?

Read that back and think about your last operational failure. Not the person who made a mistake, but the thing that simply did not get done. There is a very good chance that four people noticed it, all four assumed it belonged to someone else, and all four were behaving reasonably given what they knew.

Responsibility spread across a group does not multiply. It divides. The more people who think someone else owns it, the less likely anyone is to act. Which gives us the sentence I keep coming back to: everyone was responsible, which meant no one actually was.

The Single-Owner Standard: one owner, real authority, a maintained map

The Failure Almost Always Happens at the Handoff

There is a second piece of the puzzle, and it is one of the most useful ideas I have found for operations work. Organisations are usually very good at the first half of solving a complex problem and very bad at the second.

The first half is dividing the work. Splitting the project into parts, assigning specialists, building clean components. Humans love this. It feels like progress, it produces org charts and project plans, and it is easy to measure.

The second half is bringing all those pieces back together. That is where most organisations struggle. They spend a lot of time deciding who does what and much less time thinking about how everyone's work connects. When something goes wrong, the instinct is to fix individual tasks instead of the way those tasks fit together.

The data backs this up. PMI's research found ineffective communication is the primary contributor to project failure one third of the time, and hurts project outcomes more than half the time. Put plainly, organisations spend far more time managing individual tasks than managing how those tasks connect, and that connective tissue is where projects quietly succeed or fail.

Once you see this, you cannot stop seeing it. Look at where things actually go wrong in an agency. It is almost never inside a department. Marketing is good at marketing. Development ships. Growth runs the campaign. Failures happen where ownership changes hands: the handoff between design and development, the moment a client request enters the system, the approval that has to pass through several people.

Nobody is assigned to the gaps. Everybody is assigned to the boxes.

And the more specialised your team is, the worse this gets, because specialisation is exactly what creates the gaps in the first place. We are over 60 people across seven departments, fully remote, spread across most of the world's time zones. That structure gives us real depth in each area. It also means there are far more gaps, and they cannot all be resolved through quick conversations.

Structure does not remove coordination work. It relocates it and makes it invisible.

The handoff gap: work breaks between departments, not inside them

The Word "Stop"

So what do you actually do when you find yourself in the middle of it?

The instinct is to push through. You are mid-campaign, there are deliverables due, and stopping to fix the process feels like a luxury you cannot afford. So you patch. You add a message. You tag one more person. You take on the coordination personally, in your head, because you are the only one who can see the whole picture right now.

That works for about a week and then you are the bottleneck as well as the fix.

The thing I have learned to do instead is unglamorous. You take a breath, you say stop, and you rewrite the whole flow. Not adjust it. Rewrite it. Sit down with the actual sequence of the work, from request to delivery, and define who owns each step. Even if that means one very long night. I have done exactly that more than once and I will do it again, because the maths is not close.

One night of rebuilding the flow, against an entire campaign run in a state of low-grade panic. There is no version of that trade that loses.

The hard part is not fixing the process. The hard part is finding the time to do it. There is always another client request, another meeting, another deadline that feels more urgent. Improving the way work gets done rarely feels like today's priority, so it keeps getting pushed aside.

The signal I have learned to trust is the sentence at the top of this article. When "I thought you owned that" appears twice in the same week, it is not a run of bad luck. It is the system telling you it does not exist. This is the same failure we write about in why launch campaigns fail: the work was never unowned on purpose; it was unowned by default.

What RACI Is, and the One Rule That Matters

RACI is a way of writing down who does what on a piece of work. Four labels:

• Responsible: the people doing the work
• Accountable: the one person who owns the outcome
• Consulted: people whose input is needed before a decision
• Informed: people who need to know afterwards

The single rule that carries almost all the value is this. There is exactly one Accountable per item. Never two.

Responsible can be five people. Consulted can be a list. Informed can be the whole company. But Accountable is one name, always, and the moment you have two names in that column you have rebuilt the exact problem you were trying to solve, only now it is documented.

This is why the broken approvals line is such a common story. Approvals are almost always where two people quietly believe they are both Accountable, or where both quietly believe the other one is. It is the highest-traffic gap in most agencies and it is the one people define last. The lesson from that kind of failure is never that a person failed. It is that ownership was never defined, and an undefined thing cannot be dropped, because it was never picked up.

RACI made simple: one Accountable name per item, never two

The Part Nobody Tells You: RACI Needs an Owner

RACI is not a document. It is a role.

The way it usually goes wrong is not that the matrix is badly built. It is that someone builds a good one, presents it, everyone agrees it makes sense, and then it is handed over to "the team" to follow. Three weeks later the work has drifted, two rows are out of date, a new client request has arrived that fits nowhere on the board, and everyone has quietly gone back to whoever has five minutes free.

The matrix did not fail. It was abandoned.

RACI works when one person sets it up and then keeps standing on top of it. Someone who notices when reality has drifted from the grid and pulls it back. Someone who, when a request comes in that does not fit, assigns an owner immediately rather than letting it float. Someone who updates it when scope changes, which in client work is constant.

Without that person, you have a nice document, and a nice document is genuinely worse than nothing, because it creates the feeling that ownership has been handled. People stop asking who owns this, because there is a file somewhere that answers the question. The file is eight weeks old.

There is a pattern here I find quite funny. The framework whose entire purpose is defining accountability will fail if nobody is accountable for it. So the question to ask of any matrix is short: who is the A on the RACI? If you cannot name that person in one second, your matrix is a decoration.

Diffusion of responsibility: helping falls as group size rises, from 85% to 31%

The Single-Owner Standard

Everything above collapses into one test we apply to any recurring flow. Call it the Single-Owner Standard. A piece of work passes only when three things are true.

1. One name owns the outcome. Exactly one Accountable, written down, never two. If two people can each believe it is theirs, or each believe it is the other's, it fails.
2. That name can actually decide. A person can only own something they have the authority to decide. If you make someone Accountable but every real decision routes through you, you have not delegated ownership, you have delegated blame, and people work that out fast.
3. Someone owns the map itself. The RACI has an A of its own, a person who keeps it current as scope changes. An unmaintained matrix is a decoration.

Miss any one of the three and the gap comes back, usually as a polite message at the worst possible moment. The Single-Owner Standard is not more paperwork. It is the smallest set of conditions under which a busy team stops losing work in the space between its people.

How a RACI decays without an owner: current at week one, abandoned by week eight

How We Actually Run It

The Single-Owner Standard is a test. This is the practice that keeps a team passing it.

1. Define it at kickoff, not mid-crisis. The worst time to design ownership is when the thing is already on fire, because in a crisis every decision gets made in favour of whoever is loudest or fastest, and that is not the same as whoever should own it.
2. One A per row, enforced aggressively. Most arguments about a RACI are actually arguments about who the A is, and those arguments are useful. Have them early, in daylight, before the work starts.
3. Put it where the work lives. Not in a folder. Not in a deck. In the same place people are already looking every day, or it does not exist.
4. Assign ad-hoc requests immediately. This is the discipline that matters most in a busy period. When something new arrives, the first response is not "who is free." It is "who owns this." Those two questions produce very different results.
5. Do the correction in public, not in private. If someone has taken ownership of something they should not have, or a task is starting to drift, fix it in the channel where the work is happening. Publicly reassigning something is not a telling-off; it is teaching everyone else how the system works. Done in a direct message, it teaches one person and nobody else.
6. Revisit when the shape of the work changes. A new scope, a new client, a new team member, or a changed deadline all break yesterday's map.

*This is the same operating discipline behind how we deliver client work and how we scale delivery without losing quality. Ownership is the load-bearing wall under both.

Where RACI Breaks

Fair balance, because the framework has real limits.

1. It is a diagnostic more than an operating system. RACI is very good at showing you where ambiguity lives. It is not good at making decisions faster, resolving conflicts, or telling you what to do when two departments genuinely disagree. Treating it as the answer to all coordination problems is how it turns into paperwork.
2. It can be over-applied. Not every task needs a matrix. If you RACI everything, you will spend more time maintaining the map than walking the ground, and the team will start treating the whole thing as bureaucracy, which it will have become. Use it for recurring flows and complex multi-department work. Do not use it for a task with two people in it.
3. The C column is where projects go to die. Consulted is the most misused label in the framework. People add themselves because being consulted feels like influence, and a long C list turns every decision into a negotiation. Consulted means your input is required before the decision. It does not mean you have a veto, and if it quietly becomes one, you have built a committee with extra steps.
4. It can be used defensively. This is the real risk and it is cultural, not structural. The moment someone says "that is not my row," you have a problem no framework will fix. The point of defining ownership is to make sure things get caught, not to give people a document that proves it was not their fault.

The way we hold both is that the RACI defines who is accountable and the culture defines that everybody still speaks up. Seeing a problem and saying nothing because your name is not on the row is not doing your job. It is a failure of a different kind, and a much harder one to fix.

Ambiguity Is a Tax and You Are Already Paying It

Decades of workplace research point to the same conclusion. Gallup finds only about half of employees strongly agree they know what is expected of them at work, and that share has fallen from 61 percent in 2015 to 49 percent in 2026. Half. In an area everyone assumes is already handled.

When people clearly understand what is expected of them, organisations see lower turnover, higher productivity, and better performance. Anyone who has managed a team has seen it firsthand. Role clarity is not administration. It is one of the highest-leverage things you can give a person.

If I could leave founders with one idea, it would be this: giving people more autonomy starts with giving them more clarity. Nobody takes initiative into a fog. The most self-directed person you will ever hire cannot own something that was never assigned to anyone, because from the inside it does not look unowned. It looks like it belongs to someone else.

You want people who run at problems. Then be precise about which problems are theirs, and watch how much faster they move.

Frequently Asked Questions (FAQs)

Final Word

Ambiguity does not stay ambiguous. It resolves itself eventually, usually at the worst possible moment, in the form of a polite message that could have been avoided.

I thought you owned that.

Somebody should have. Make sure somebody does.

About the Author: Lui is an operations leader with 8+ years across Picsart, DISQO, and blockchain-native companies. At AP Collective, Lui has scaled and shaped the 60+ person team, driving client delivery across hundreds of campaigns.

Written by Lui, Chief Operating Officer at AP Collective.

Disclaimer: This article reflects operating experience at AP Collective and is offered as general management guidance, not a guarantee of results. Cited studies are attributed to their original researchers and publishers; figures were accurate as of the last-reviewed date.

Related Reading

• How Crypto Marketing Agencies Deliver. The delivery system that ownership sits underneath, from intake to reporting.
• Scaling Marketing Delivery Without Losing Quality. What has to hold when a team grows past the point of quick conversations.
• Why Launch Campaigns Fail. The operational gaps that turn a good plan into a missed launch.

Sources

• Darley and Latané, bystander intervention and diffusion of responsibility, 1968 link: simplypsychology.org/bystander-effect.html
• Project Management Institute, the essential role of communications (2013 Pulse of the Profession) link: pmi.org/learning/thought-leadership/pulse/essential-role-communications
• Gallup, many employees do not know what is expected of them at work link: news.gallup.com/businessjournal/186164/employees-don-know-expected-work.aspx