The real reason your team keeps pushing problems back to you
“Lack of accountability. That’s the problem we have.” It’s one of the first lines I hear from most founders in the first conversation of a fractional COO engagement. The language varies – “they don’t take ownership”, “they don’t step up”, “they need to think like an owner” – but the frustration underneath is identical. Problems keep landing on the founder’s desk. The team keeps bringing them things they should be handling themselves. And the founder is left wondering why the smart, expensive, experienced people they hired can’t seem to solve problems without them.
Here’s the uncomfortable reframe I’ve come to after running this conversation hundreds of times: your team almost certainly doesn’t have an accountability problem. What they have is a competence-and-systems problem wearing an accountability problem’s clothes. This article explains the reframe, why it matters, and what to actually do about it.
The conversation that keeps repeating
I want to tell you about a founder I worked with – let’s call him Jonny, which isn’t his real name. I still remember the first call I had with him. “Lack of accountability. That’s the problem we have” was the first sentence. He talked about feeling overwhelmed with too many problems bubbling up to his level. He wanted his team to “step up” and “own” the problems that came their way.
I asked Jonny to explain how all those problems were ending up with him. “It’s pretty simple” he said. “The team find too many problems they can’t solve, so they bring it to me and expect me to fix it. I end up owning the problem. I need that to change.”
In my slightly annoying coach-like way I pushed him a bit further. “What’s going on for them when they do that?” I won’t share exactly what he said next – it would get my emails quarantined for excessive use of expletives. A fair summary is that he had concluded his team members lacked the competence to do the jobs he’d given them, and that’s why they kept pushing problems back to him. Before you judge him too harshly, most of us have had that exact thought at 11pm on a Tuesday when yet another problem has landed in our DMs.
Then I asked him to think about the relationship between competency and ownership. He went quiet. You could almost see him processing it. Because what Jonny was really asking for – and what most founders ask for when they talk about accountability – is for their team to behave like he would behave. To make the decisions he would make. To solve problems the way he would solve them. But here’s the thing. He could solve those problems because he’s competent to solve them. He’s done it before. He knows what good looks like. He’s built the pattern recognition through his journey as a founder. His team members don’t have that. And they never will to the extent he does.
What “accountability” usually means (and what it should mean)
When a founder says their business has an accountability problem, they usually mean one of three things:
“People aren’t owning problems the way I would.” This is really a statement about competence. The person doesn’t have the pattern recognition to solve this class of problem, so they escalate. Solving it requires either building the competence (training, coaching, exposure) or reducing the class of problem they’re facing (simpler systems, clearer inputs, tighter guardrails).
“People aren’t delivering on what they said they’d deliver.” This is really a statement about goals and measurement. The person committed to something, and there’s no structural mechanism to check whether it’s happened. Solving it requires a goals framework the whole business shares – quarterly priorities, a cadence of check-ins, visible progress – so commitment becomes observable and correctable in-flight, not just reviewable in the post-mortem.
“People aren’t taking decisions they’re empowered to take.” This is really a statement about permission and safety. The person doesn’t believe they have the authority to decide, or they believe the cost of getting it wrong is higher than the cost of escalating it. Solving it requires the founder to be clear about where decision rights actually sit – and then to resist the temptation to overturn decisions the team makes inside those rights.
None of these three problems are really about “accountability” in the motivational sense. All three are structural. And that’s the first piece of good news: structural problems are fixable. Motivational problems – “my team just isn’t trying hard enough” – tend to be unfixable, which is why that framing traps founders in endless cycles of the same frustration.
The competence lens
After my conversation with Jonny, he went quiet for a while and then suggested something different. He suggested he might need to think more about how to increase the competence of his team. Not so they could think like a carbon copy of him – that was never going to happen – but so they could develop the skills to solve the kind of problems that kept landing on his desk.
This is the reframe I take into almost every fractional COO engagement. If problems are escalating to the founder, the real question is: what do the people those problems belong to need in order to solve them without the founder? And the answer is almost always some combination of:
Exposure to the pattern. Pattern recognition comes from having seen the situation before. If you want your team to solve a class of problem, they have to see the problem, try to solve it, and get feedback – ideally when the stakes are low enough that getting it wrong doesn’t break the business.
A decision-making framework. Not a process flowchart. A simple shared way of thinking about the problem class. When I installed one of these with a product scale-up client, problems that used to escalate to the founder started getting solved two layers below, because the framework gave the team a shared language for thinking it through.
Permission to be wrong. Teams that can’t be wrong don’t make decisions. They escalate. The founder who escalates problems up because “I just wanted them to check with me” is the same founder who then complains those people don’t take ownership. The permission has to be explicit, repeated, and defended when somebody uses it and gets it wrong.
Somebody visible doing it well. Accountability is a learned behaviour, and people learn it by watching somebody further along the path. In a small scale-up that person is usually the founder. In a slightly bigger one, it’s the first senior hire who sets the tone for everybody beneath them. Protect that person fiercely.
The systems lens
The competence reframe goes a long way, but it doesn’t go all the way. There’s a second lens that matters just as much, and it’s the systems lens. Accountability without systems is a series of hopeful promises. Accountability with systems is an operating reality.
If your business has accountability problems that the competence lens doesn’t fully explain, look for these structural patterns:
No visible goals framework. People can’t be held to account for delivering on commitments they never made visibly. If your goals live in the founder’s head and nobody writes them down, measures them, or reviews them on a defined cadence, the problem isn’t the team.
No operating cadence. Without a rhythm – weekly leadership meeting, monthly review, quarterly planning – there’s no structural moment at which commitments get examined and adjusted. Accountability leaks out of businesses that don’t have the cadence to hold it.
Unclear role boundaries. When two people share an accountability, neither owns it. When no-one is named, no-one is responsible. Role clarity is the condition under which accountability becomes possible.
Founder involvement at every level. If the founder is still the one deciding which projects ship, which hires to make, which clients to take on, the team can’t be accountable for those outcomes. The decision sits in the founder’s chair. The ownership has to move with it.
These are the components of a business operating system, which is the structural answer to most of what scaling founders call an accountability problem. Install the system, and a lot of the “accountability” problems stop being problems.
“Simon worked with us at ThinkTribe during a pivotal time for the business. He helped us rethink our structure, sharpen our strategy, and confidently navigate the transition from founder-led to a more scalable, leadership-driven model. His calm, insightful approach brought clarity where there was complexity and left us better equipped for the next phase of growth.”
Deri Jones, Founder and CEO, ThinkTribe
What changed for Jonny
Back to Jonny. Once he’d accepted that the problem wasn’t accountability – that it was a competence gap and a systems gap wearing an accountability costume – the work got more useful. We spent less time on language like “step up” and “own it” and more time on what his team actually needed in order to solve the problems they were facing. We built a decision-making framework for the recurring class of problems that kept escalating. We put a proper operating cadence around the leadership team. We tightened role definitions so that every significant decision had one owner. We made it explicit what the team were empowered to decide, and we defended them when they used that permission and occasionally got things wrong.
None of this was about accountability as a character trait. All of it was structural. And the effect on Jonny’s week was visible within a couple of months – fewer problems landing on his desk, more decisions happening without him, a leadership team that was starting to feel like a leadership team rather than a list of people with titles.
Next step. If the founder experience in this article feels familiar – the problems landing on your desk, the frustration about your team not “stepping up” – the most useful thing you can do next is to stop looking at the team’s character and start looking at the systems and competences around them. That’s usually where the actual fix lives.
