Is it a skills problem or is it (lack of) trust and accountability?

When a team is slow, the instinct is to train them, tool them up, or reorganize them. All three are usually wrong.

I have worked with enough product organizations in the last year to notice a pattern that holds almost every time. A director or VP comes in frustrated. Delivery is slow. Requirements are fuzzy. Escalations keep landing on their desk when they should not. Engineering is complaining. And leadership is starting to ask questions.

The reflex answer is usually one of three things: send the team to a workshop, introduce a new process framework, or restructure reporting lines. Sometimes all three happen in sequence. And almost always, six months later, the same problems are back in a different configuration.

Here is what I have come to believe: in most of these situations, the skill gap is real but secondary. The primary problem is a trust and accountability gap that runs across the organization. And no amount of training or tooling fixes that until you name it.

The reorg fallacy

Reorganizing is seductive because it looks like a decision. It feels like action. You move boxes on a chart, change reporting lines, maybe rename a team or two, and something visibly changes. Leaders feel like they have addressed the problem.

But reorgs almost never fix the underlying issue because they address structure, not behavior. If engineers and product managers do not have a shared understanding of what good looks like, changing who reports to whom does not create that understanding. If a team has learned to absorb ambiguity silently rather than escalate early, a new org chart does not change that habit. If the product org has lost the confidence to push back on engineering, flipping the reporting structure does not restore that confidence.

What I saw in one organization was instructive. The team had recently moved from a flexible model to a more structured planning framework in hopes it would create discipline and predictability. It created neither. What it created was more overhead, more frustration, and a growing sense that the process was the point rather than the outcome. The plan was not the problem. The trust between product and engineering was the problem. No planning model survives a broken working relationship.

What accountability actually looks like when it is missing

Accountability gaps have a specific texture. A leader is spending too much of their time (let’s say 20%+)  on coordination work that should be two levels below them. The same escalations recur because no one owns the systemic fix. Decisions that could be made at the team level are floating up because people are not sure what they are authorized to decide.

This is not a motivation problem and it is usually not a capability problem either. It is a clarity problem that has calcified into a behavior pattern. People have learned that the safest thing to do is wait, ask up, and let leadership absorb the uncertainty. That pattern is rational given the environment they are operating in. It just does not scale.

The common response from leadership is to push back the other way: bring me solutions, not problems. And I understand the impulse. You want a team that thinks independently, owns outcomes, and does not need hand-holding through every decision. That is the right aspiration.

But taken too far, "bring me solutions not problems" becomes its own failure mode. It puts enormous pressure on people to resolve ambiguity before they surface it, which means the obvious problems get solved and the gnarly ones get buried until they explode. Leaders end up with a team that looks proactive on the surface but is quietly sitting on the things that are hardest to bring up. You have not built independence. You have built a culture of invisible risk.

The line worth finding is more nuanced than either extreme. You want your team to be independent and proactive. You also want to be equipped to actually help them, not just receive polished summaries of things that have already been decided. The goal is not to remove leadership from hard problems. It is to make sure leadership is in the loop early enough to add real value, rather than late enough to only absorb blame.

In one situation I observed closely, the bottleneck was not confined to the product team. It extended all the way to the COO, who was being pulled into individual coaching conversations and direct execution work that had no business reaching her level. The product team was not the only actor in the system. The leaders above them had, over time, made it safer to escalate than to decide. Until that changes, coaching the team to be more independent is working against the grain of everything else. But the answer was not to cut off the escalation path. It was to redesign it so that the right problems were surfaced at the right level, with enough context to actually move them forward.

It takes two to tango

This is the part that is hardest to say out loud in a consulting or coaching engagement: if your team is slow and dependent, the system produced that team. The habits they have are the habits that were rewarded, or at least tolerated, for long enough to become the default. You cannot fix the team in isolation without also examining what the leadership layer above them has been modeling and incentivizing.

One of the most useful reframes I have found is this: the escalation problem is not a team problem. It is a working relationship problem. If product and engineering do not have enough shared language, mutual trust, and clarity about ownership boundaries to work through ambiguity together, escalations are the logical outcome. Coaching product to write better requirements only goes so far if engineering culture is not moving in parallel. Both sides have to change for the system to change.

In another organization I worked with, the leader was carrying enormous load managing up, managing across, and managing down simultaneously while also trying to grow her own strategic thinking. The burnout was not about effort or capability. It was about a system that had placed her at the center of every decision because no one around her had been empowered to own anything fully. The fix was not a new prioritization framework. It was a deliberate redistribution of decision authority, paired with enough safety for people to make calls and occasionally be wrong.

Where AI fits and where it does not

AI tools will not fix a trust and accountability problem. I want to be direct about this because there is a lot of noise right now about using AI to accelerate teams, and most of it assumes the team's underlying operating system is sound.

What AI does is amplify the existing undercurrent. If your team has strong judgment, clear ownership, and healthy working relationships, AI can make them significantly faster. Requirements get drafted and refined more quickly. Research gets synthesized faster. Cross-functional communication gets smoother. The team's real output, which is decisions and shipped product, accelerates because the execution overhead drops.

But if the undercurrent is fuzzy accountability and learned dependence, AI makes that worse. It gives people more ways to produce output without building judgment. It generates requirements that no one owns. It creates the appearance of productivity without the substance of it. A team that is already good at avoiding hard conversations will find new ways to avoid them with AI-assisted scaffolding.

The sequence matters. Clarity of ownership and accountability comes first. Once that is in place, AI is a genuine accelerant. Before it is in place, it is a distraction that makes the underlying problem harder to see.

What actually works

The organizations I have seen make real progress share a few things in common. They name the trust and accountability gap explicitly rather than letting it sit under the surface as a vague performance problem. They look at the full system, not just the team, and ask what the leadership layer has to change alongside the team. They build a shared understanding of what problems belong at which level, and they create enough psychological safety for hard things to surface early rather than late.

None of this requires a reorg. Some of it requires a framework. Most of it requires honest conversation about what is actually happening and who owns what part of fixing it.

If your team is slower than it should be, the skill question is worth asking. But ask the trust and accountability question first. The answer is usually hiding there.