Capability, system, or mindset: diagnose before you fix

A few years ago, I had an engineering manager leading the rebuild of a sign-up flow. Weeks went by and there was still no plan. Every time I asked, he needed more discovery, more requirements, more confirmation.

My first conclusion was that he didn’t know what he was doing. He wasn’t technical, I thought, so he didn’t really understand the technical implications of the project. So I did what many managers do when they think someone lacks the skills: I started micromanaging him.

It didn’t take long to see I was wrong. He had been a tech lead before, and he had years of experience as a technical project manager in consultancy. He knew every small detail, every edge case, and what was potentially missing. He knew the project better than I did.

I had misdiagnosed him. If I had kept going, I would have spent weeks helping someone with a problem he didn’t have.

Same behavior, three different causes

When someone keeps repeating the same behavior, like missing deadlines, delaying decisions or avoiding ownership, it usually comes from one of three causes:

• System. The environment blocks the behavior: no authority, no clarity, imposed deadlines, constant interruptions.

• Capability. The person doesn’t know how to do it yet.

• Mindset. The person can do it and is allowed to, but a belief makes it feel unsafe.

Each cause needs a different fix: change the environment, build the skill, or remove the fear. Apply the wrong one and you either blame people for something the organization causes, or you train someone who already knows more than you.

So I check them in order: system first, capability second, mindset last.

Step 1: Check the system

I start with the system because it’s the easiest to rule out, and it’s probably the most common cause in many companies.

I ask questions like:

• Do you feel supported?

• Is it clear what you need to achieve?

• Can you make the decisions you need to make?

Two situations I’ve seen many times.

A team misses a deadline by a lot. From the outside, it looks like they don’t know what they’re doing. Then you ask, and you find out the deadline was imposed top-down. The team said from the start it wasn’t possible, the manager said it was non-negotiable, and they obeyed and did their best.

Another team keeps slipping because priorities change all the time, or because people get pulled into meetings and discoveries for unrelated projects. Every interruption delays the work a bit more.

In both cases, coaching the people changes nothing. The fix is the environment.

Step 2: Check capability

If the system supports the person, I look at skills:

• Do you know how to do this?

• Do you need someone to help you?

• Do you feel equipped to move forward?

When I took over one team, a very senior engineer had just asked to move to another team because he couldn’t work with his product manager. He was key: he had a lot of knowledge, and the team was only four people. Losing him meant 25% less capacity and a delayed roadmap. But he had said that if he didn’t change teams, he would leave the company, so everyone agreed.

His version was that the product manager micromanaged him and wasn’t open to discussion. I talked to both of them, and it wasn’t that black and white. When I went back to the engineer, the conclusion was clear: he didn’t know how to give feedback to his product manager. He had never given him a specific example or anything he could act on. He was avoiding the conflict, and that made him part of it.

I told him that directly. He said I was making him feel incompetent. I explained that he was missing one specific skill: resolving a conflict like this one.

He decided to come back to the team. He didn’t need a mindset change. He needed awareness and a structured way to drive the conversation. I gave both of them that, and I talked to each of them separately so they could understand how the other side felt.

They sorted it out, and both said the relationship got better. He left the company one or two months later for a better offer, probably something he had started looking for during the conflict. But the team finished what it needed, and his last weeks with us were much calmer.

Step 3: Look for the belief

If the system supports the person and they have the skills, then I look for fears that come from past experiences.

Back to my engineering manager. He had the authority and the knowledge, and the system supported him. Still, he needed more and more time for every decision. So I asked him what was stopping him. He told me he knew about 70% of the requirements, and he couldn’t build the full timeline until he understood the last 30%.

Me: Why do you need the details of work we won’t touch for at least two months? The team can start now on what we know. If that 70% takes around two months, assume one more month for the rest, commit to three, and say we’re still defining some parts.

Engineering manager: I’m very uncomfortable committing without knowing that last 30%.

As I spent more time with him, I found out why. In his previous environment, he had been heavily punished for missing deadlines. The team around him wasn’t great, and every time it missed something, he took the hit. So committing without certainty felt dangerous.

A past system had created a belief that stayed after the system changed. That’s why I check the current system first: if it supports the person and the behavior is still there, they may be carrying something from before.

More pressure would have made it worse. Instead, I told him I would take the blame. I explained how I work: I value speed over certainty, I’m comfortable making calls without knowing everything, and if we fail, we learn and move on. I will never blame someone for taking a risk because they had to decide with incomplete information. What I don’t accept is hiding information, lying, or skipping company processes.

I also made one thing clear. He was responsible for the project and for the technology in the area. If he didn’t make the call, nobody would. Meanwhile, the project wasn’t starting, and stakeholders and senior management were getting anxious.

We closed the plan. The initial estimate was 16 weeks. I sat with the teams and with him and asked them to treat it like a hackathon: permission to fail, permission to take risks, and a target of 6 weeks. They started two or three days later, still without knowing the last 30%, and delivered in 7 weeks.

The hackathon framing did a lot of that work. But none of it was possible until the fear of committing was out of the way.

When you can’t change the system

Sometimes the system is the problem and you can’t fix it, because the deadline or the shifting priorities come from your own boss.

Then my job is to raise the risks with their consequences: we will miss the deadline, we are burning people out, we will see resignations. Then I disagree and commit. In the end, it’s my boss’s call. How to manage up in that situation is a topic for another post.

The takeaway

When you see the same behavior again and again, don’t jump to “attitude problem”. Check the system first, then the skills, and only then look for the belief behind it. Each cause has its own fix.