In this week’s Build I’m sharing a bit about some work I did with a founder last year. I’m very grateful to him for giving me permission to share a bit about his story here.

I still remember very well the first call I had with Jonny.

“Lack of accountability. That’s the problem we have” was the first sentence of that first call.

He talked about how he felt 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.

Sounds familiar? I hear some version of this from nearly every founder I work with.

The language might change slightly. I hear a lot about “taking initiative”, “being more proactive” and “thinking like an owner”. In fact back when I was a managing director I remember using most of these myself.

But regardless of the words, the frustration underneath is identical.

Problems keep landing on the founder’s desk. The team keeps bringing you things they should be handling themselves.

And you’re left wondering why the brilliant people you hired can’t seem to solve problems without you.

Let’s get back to Jonny.

In our first session together I asked him 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 that they do that?”

I’m not going to share exactly what he said next as it’ll get my emails quarantined for excessive use of expletives. It wasn’t quite the deeply self-reflective response that deep down I was hoping for.

A fair summary would be that Jonny had concluded his team members lacked the competence to do the jobs he’d given them.

That was why they couldn’t solve the problems and pushed them back to him to fix.

Now before you judge him too harshly, I reckon most of us have had that exact thought at 11pm on a Tuesday night when yet another problem has found its way into our DMs.

Those people we hired – those smart, experienced and expensive people – seem unable to make a decent decision without our input.

But here’s where it gets interesting.

I asked Jonny to think about the relationship between competency and ownership of problems.

He went quiet. You could almost see him processing that thought. (I love being a coach and watching people work through things with the gentlest of steers.)

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 they would behave.

They want their people to make the decisions they would make. To solve problems the way they would solve them.

But here’s the thing: you can solve those problems because you’re competent to solve them. You’ve done it before. You know what good looks like to you. You’ve built the pattern recognition through your journey as a founder.

Your team members don’t have that. And they never will to the extent you do.

Our conversation continued and we got onto talking about whether Jonny would continue to focus on ownership. After some more exploration he suggested something different.

He suggested he might need to think more about how to increase their competence.

Not so they could think like a carbon copy of him. But so they could develop the skills to solve the kind of problems that happened in his business.

Because the truth I see in almost every business I work in is this: if team members feel competent to solve the problem, there’s no accountability issue.

Let’s just pause to think about that for a moment.

Have you ever been truly competent at something and yet reluctant to own it?

Probably not.

When you know you can handle something, you just get on and do it.

When you hesitate, procrastinate or deflect – it’s not a character flaw. It’s more often than not an indicator of a competency gap.

And this is where most founders get it backwards.

They try to solve an accountability problem when they actually have a competence problem.

They get frustrated (or maybe more than a bit frustrated) about why people won’t just step up.

But people can’t take accountability without competence.

You can only delegate tasks to people who are competent to complete them.

This distinction matters enormously.

If you’re focused on more accountability, you’re essentially asking people to behave differently whilst keeping everything else the same. You’re hoping for a mindset shift without changing the underlying conditions that created the lack of accountability in the first place.

But if you focus on competence, you’re gradually increasing your team’s capability to handle the problems that come their way. And then more accountability follows naturally.

People who can solve problems do solve problems. They don’t need motivational speeches about ownership or a fancy bonus scheme. They just need the skills, knowledge and experience to be effective.

So what does focusing on competence actually look like?

It means asking different questions when problems land with you:

• Not “Why didn’t you fix this?” but “What would you need to know to fix this next time?”
• Not “Why are you bringing this to me?” but “What part of this problem can you solve and what part do you need help with?”
• Not “When will you start taking more accountability?” but “What skills or experience do you feel you’re missing to tackle this confidently?”

It means building capability systematically:

• Creating opportunities for your team to solve problems just beyond their current competence (with support).
• Debriefing decisions and problems together so they can see your thinking process – working out loud and “showing your workings” like you did in your maths exams at school
• Being explicit about the frameworks and heuristics you use to make decisions.
• Accepting that people will make different decisions than you would. And that more often than not that’s going to be OK.

It means being honest about the competence gaps in your organisation:

• Where have you hired for potential rather than proven capability?
• Where have people grown into roles without the development they needed?
• Where are you expecting people to operate at a level they’ve never operated at before?
• Where have you given someone a promotion or a fancy job title to stop them leaving?

I’m not suggesting this is easy.

Building competence takes time. It’s slower than just solving the problem yourself (at least in the short term). It requires you to be more thoughtful about how you develop your team not just what tasks you assign them.

But here’s what I’ve noticed: founders who focus on building competence create teams that genuinely take ownership. Not because they’ve been told to. But because they can.

The ownership isn’t forced or performative. It’s natural.

And that’s how Jonny decided to work differently. He didn’t tell his team to stop bringing him problems. He committed to helping them become competent enough to handle them.

We then worked together mapping out where his team had competence gaps. It wasn’t a comfortable conversation. It needed him to admit that some of the perceived incompetence he was seeing was actually a failure of his own leadership.

But as we reflected on that moment later in our work together, he found it was also liberating. Instead of having an intractable accountability problem, he realised he had a people development problem he could actually work on. The accountability would follow.

And over time it did.

So here’s what I’m wondering: when you look at the problems that keep landing with you, are you seeing an accountability problem or a competence problem?

And if it’s competence, what would it take to genuinely close those gaps?

best regards,
sw

From the Build archive

Build #8 –
Building businesses with accountability

What does accountability really mean?

> Read the article

Build #24 –
Holding to account

Accountability drives performance in rapid growth businesses. Discover what it really means to hold people to account firmly but fairly using the 3Hs model.

> Read the article