The RACI Is Clear. So Why Are We Still Acting Like Separate Teams?

During a transformation effort, we introduced a RACI to create clarity. It was meant to help people understand who was responsible, who was accountable, and where others needed to be consulted or informed.

Instead, something unexpected started happening in the conversations around it.

The language shifted from “we” to “they.” Product owns this. UX owns that. Engineering is responsible for this part. That’s not my decision. That’s not my job.

The framework intended to create clarity was also making our silos easier to see.

That experience changed how I think about accountability frameworks. I still believe clarity matters. Teams need to understand decision rights, responsibilities, and expectations. But a RACI—or any framework—can’t substitute for the behaviors of a high-performing team.

Clarity about responsibility should never become permission to stop acting like a team.

Accountability isn’t a boundary

When I tell someone they’re accountable for something, I don’t mean collaboration becomes optional. I don’t mean everyone else gets to step away. And I definitely don’t mean that producing the artifact assigned to your role matters more than the outcome the team is trying to achieve.

That distinction matters because frameworks can unintentionally turn responsibility into boundaries.

When that happens, people start waiting for permission. They hold back expertise because they aren’t the decision maker. They see a risk but assume it belongs to another function. When something goes wrong, it becomes easy to explain which part of the RACI failed rather than asking why the team failed to achieve the outcome.

We win and lose as a team.

Your seat at the table comes with a responsibility

If you have expertise that can make the decision better, speak up.

Your job on the team and your seat at the table exist because you bring knowledge, experience, and perspective that the team needs. Being consulted rather than accountable doesn’t make that expertise less important.

Advocate for what you know. Explain the risks. Challenge assumptions. Bring the customer perspective, the technical constraint, the business context, the research, or the data.

Then, when the decision is made, disagree and commit.

You don’t have to be the decision maker to have a responsibility to make the decision better.

Why I’m leaning more toward decision frameworks

This is one reason I find myself increasingly drawn to frameworks such as DACI and other approaches that make decision-making explicit.

There’s still value in understanding responsibility. But I’m often more interested in a few practical questions: Who is driving this forward? Who ultimately makes the decision? Whose expertise must inform it? And once we decide, how do we move together?

Even then, the framework is only half of the equation. It needs an equally loud counter-message about the behaviors we expect from the team.

Speak up. Collaborate. Challenge respectfully. Share what you know. Don’t hide behind your role. Don’t blame another function. Optimize for the outcome rather than your individual deliverable.

What it looks like when it works

I’ve also seen the opposite—and it’s noticeably different.

One team started by getting aligned on the outcome the customer and the business needed to achieve. Before dividing the work, they shared ideas and brainstormed together. There were no sacred cows and very little “my lane” versus “your lane.”

Only after they understood the problem and the outcome did they divide the work.

And then they continued working together to deliver it.

That sequence matters.

They didn’t begin with, “Who owns this?” They began with, “What are we trying to achieve?”

Outcomes win

Frameworks are useful. Roles matter. Decision rights matter. Accountability matters.

But none of them are the goal.

A perfectly completed RACI doesn’t create customer value. An artifact delivered on time doesn’t automatically mean the problem was solved. And being technically correct about whose responsibility something was doesn’t make a missed outcome a success.

The framework should give the team clarity so people can move faster together—not create lines that give them permission to move apart.

At the end of the day, outcomes win.