Why Software Engineers Are So Hard to Lead (And What to Do About It)

Quick Bridge: Engineering managers rarely talk about this out loud. The overconfidence that derails code reviews, the semantic precision that stalls every planning meeting, the principled refusal to do the things that would actually get someone promoted. This post names all three patterns, explains what is driving each one, and gives you specific language for the conversation that starts to change things.

There is a conversation I have had more times than I can count.

An engineer on my team is doing genuinely good work. By any technical measure, they are one of the stronger contributors. Their promotion has been stalled for two years. When I ask them what they think is getting in the way, they describe the features they built, the problems they solved, the systems they improved.

They do not mention that the people who make promotion decisions have almost no visibility into any of it.

That gap, between what an engineer knows about their own work and what the organization can actually see, is one of the most consistent problems in engineering management. And it is only one of three.

The Engineering Manager Communication Gap That's Stalling Your Team's Careers

Most management advice about engineers focuses on process: how to run better sprint reviews, how to set clearer expectations, how to structure 1-on-1s. That advice is useful. What it does not cover is the set of behavioral patterns that engineers bring to the table before any of those structures are in place.

These are not failure modes. They are default behaviors that engineering training and culture produce. Understanding where they come from is the first step to doing something useful about them.

After more than twenty years managing software engineers, I have narrowed the hardest ones down to three.

Three Engineering Management Challenges You Have Probably Stopped Naming Out Loud

Overconfidence about their own work. Skepticism about everyone else's.

The engineer who dismisses a colleague's design as poorly thought through is often the same engineer who is completely confident their own estimate will hold. Both positions are usually wrong by a similar margin.

This pattern shows up in code reviews that turn into status contests. In estimates that get defended rather than questioned. In planning meetings where every engineer is convinced the other engineers are the problem.

I have watched this long enough to recognize it as a pattern, not a personality flaw. It turns out there is actually a name for it: Dunning-Kruger.

Engineers overestimate their own work while underestimating the people around them. Even the genuinely skilled ones. You cannot accurately evaluate someone else's problem from the outside.

Precision at the wrong moment.

Engineering culture selects for precision. That is not a weakness. The ability to think in exact terms, to notice when two people are using the same word to mean different things, to catch definitional errors before they become bugs. This is real and valuable.

The problem is when that same precision instinct shows up in a planning meeting where the goal is a decision. I have sat in rooms where the first thirty minutes went to debating what "done" means for a feature no one has started building yet. The instinct is right. The context is the problem.

Principled resistance to visibility work.

This is the one that costs people careers most directly.

Engineers take an idealistic stance against the behaviors that would actually help them advance. Not ethical objections. Principled resistance to things like talking in cross-functional meetings, building relationships outside their immediate team, or framing their work in language their senior leaders can understand.

"I should not have to talk in meetings. They should pay attention to me and know what I am doing."

"I should not need to work with that other team to get the right result."

I watched an engineer spend three years doing excellent work that almost no one outside their immediate team could see. When the promotion stalled, they were genuinely confused. They had built things that worked. They had not made those things visible to the people making career decisions about them.

According to research from PostHog, searches for "product engineer" grew 89% between 2021 and 2024. These are engineers who actively engage with customers and understand what the product does for real people. The market is recognizing what engineering managers have known for years: customer and organizational awareness is not a default engineering skill. It has to be developed. (PostHog: Product Engineer vs. Software Engineer)

Why Engineers Are Trained to Struggle With This

Here is the root cause that took me years to see clearly.

These patterns are not personality defects. They are the predictable output of how engineers are trained, hired, and rewarded.

Engineers spend their entire education focused on one thing: find the best solution. The person who does that fastest and cleanest wins. You build confidence by being right. You advance by knowing more than the people around you.

The overconfidence pattern and the semantic precision instinct are not accidents. They are what the system selected for.

The visibility problem has the same root. Engineers are also taught, early in their career and mostly by example, that if you build good things, people will notice. That was true when the team was small enough for everyone to see the work directly. It stops being true somewhere around the time the organization grows past twenty or thirty people, and nobody tells the engineer that the rules have changed.

This is not an engineering problem. It is an information problem. The behaviors make complete sense given what engineers have been taught about how success works.

The Pragmatic Engineer's research on software engineering promotions confirms what I have seen: the engineers who advance are not just technically stronger than their peers. They are also visible to the people making career decisions. That is a skill most engineers have never been coached on. (Pragmatic Engineer: Software Developer Promotions)

Three Conversations That Actually Change Things

Here is what to actually say.

For the overconfidence pattern:

Do not challenge the engineer's technical assessment directly. That triggers defensiveness. Try this instead:

"I want to talk through how your read on [colleague's work / this estimate] is landing in the team. Can we spend ten minutes on it?"

You are making it a conversation about perception, not a debate about facts. The engineer can engage with "how it is landing" without having to defend their position.

For the semantics pattern:

When a meeting goes into definitional territory, name it without judgment:

"I want to make sure we get a decision out of this meeting. Can we agree on a working definition for today, even if it is imperfect, and revisit the language after we have tested it?"

You are not telling them precision is wrong. You are giving the instinct a better outlet: define it, test it, refine it. Engineers can work with that.

For the visibility pattern:

This is the conversation most managers skip entirely because it feels uncomfortable to say.

"I want to talk about something that is affecting your career. The work you are doing is strong. The problem is that the people who influence your next move cannot see it."

"That is not about your work quality. It is about the gap between what you know you are doing and what is visible outside this team. I want to help you close that gap."

Then ask: "Who in senior leadership do you think has a clear picture of what you have built in the last year?"

The answer to that question usually opens the conversation on its own.

What Changes When Engineers Get This Information

I have managed engineers who were all three of these things. Skeptical of everyone's work but their own. Precise to a fault in planning meetings. Principled in ways that were quietly limiting their career.

Some of them are now directors and senior managers.

What changed was not their technical skill. What changed was that someone told them the truth about how their behavior was landing. Not as a performance issue. As information they did not have about how the organization actually worked.

When engineers understand what is actually required at the level they want to reach, most of them adjust. They are problem-solvers by nature. Give them an accurate problem and they will work on it.

This week: Choose the one conversation from the three above that fits the engineer on your team who needs it most. Not all three conversations at once. One engineer. One conversation.

Frame it as information, not feedback. See what opens up.

What is the one engineer behavior that frustrates you most as a manager? Have you ever had the conversation that actually changed it?

You're great at the work. Let's make you impossible to ignore.

If you are looking for help having the conversations with your engineers that shift how they see the path ahead, consider reaching out. https://www.jessestaffordcoaching.com

Search This Blog