Capability, system, or mindset: diagnose before you fix

Imagine an engineering manager on your team leading the rebuild of a key product flow. Weeks go by and there’s still no plan. Every time you ask, they need more discovery, more requirements, more confirmation.

The easy conclusion is that they don’t know what they’re doing. Maybe they’re not technical enough, you think, so they don’t really understand the technical implications of the project. So you do what many managers do when they think someone lacks the skills: you start micromanaging.

Then you look closer. They’ve been a tech lead before and have years of experience running technical projects. They know every small detail, every edge case, and what’s potentially missing. They know the project better than you do.

You’ve misdiagnosed them. Keep going, and you’ll spend weeks helping someone with a problem they don’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?

Take a very senior engineer who asks to move to another team because they can’t work with their product manager, and says they’ll leave the company otherwise. On a small team, losing that knowledge means a real hit to capacity and the roadmap, so everyone is tempted to just agree.

Their version is that the product manager micromanages them and isn’t open to discussion. Talk to both sides, and it’s rarely that black and white. Often the real issue is that the engineer doesn’t know how to give feedback to the product manager. They’ve never given a specific example or anything the product manager could act on. They’re avoiding the conflict, and that makes them part of it.

Telling them this directly can sting. They may feel you’re calling them incompetent. The point to make is that they’re missing one specific skill: resolving a conflict like this one.

That’s not a mindset problem. What they need is awareness and a structured way to drive the conversation. Give them that, talk to each side separately so they can understand how the other feels, and the relationship can recover without anyone changing teams.

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 the engineering manager with no plan. They have the authority and the knowledge, and the system supports them. Still, every decision takes more and more time. So you ask what’s stopping them. Say they tell you they know about 70% of the requirements, and they can’t build the full timeline until they understand the last 30%.

You: 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%.

Dig deeper and you often find the reason in a previous environment: they were heavily punished for missing deadlines, the team around them wasn’t strong, and every miss landed on them. So committing without certainty feels dangerous.

A past system 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 makes it worse. What works for me is taking the blame myself and explaining 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 make one thing clear. They are responsible for the project and for the technology in their area. If they don’t make the call, nobody will. Meanwhile, the project isn’t starting, and stakeholders are getting anxious.

Once the fear is out of the way, you can go further. Treat the project like a hackathon: permission to fail, permission to take risks, and an ambitious target well below the original estimate. The team can start right away, without knowing the last 30%.

The hackathon framing does a lot of the work. But none of it is possible until the fear of committing is gone.

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.