Diagnosing difficult behaviour

When the same conversation keeps repeating with different people, the problem is usually structural - and this guide will help you tell when it isn’t.

May 12, 2026

👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.

To accelerate your growth see:

Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.

Someone on your team keeps complaing, nitpicks every code review, or stays quiet in meetings but then complains to you in 1:1s.

Maybe they’re being “difficult”.. There is a chance though that it’s the environment around them.

Most advice on how to deal with “difficult” engineers revolves around having hard conversations with them. These conversations help for sure, but if you have to be having them often, you might be treating the symptom instead of the cause.

A lot of “difficult” behaviour comes from how the team is set up, what gets rewarded, and what gets tolerated.

This article covers three team conditions that often create these behaviours, how to spot them, and how to separate a system problem from a people problem.

The “difficult person”

There’s a well-known psychology concept called the fundamental attribution error. It basically means this:

When other people behave badly, we blame their personality.
When we behave badly, we blame the situation.

For example:

You were late because traffic was terrible.
They were late because they’re unreliable.

Managers do this all the time (either knowingly or not).

The engineer asking difficult questions becomes “negative” instead of confused by unclear goals.
The engineer checking on deadlines becomes “controlling” instead of worried that the project is slipping.
The quiet engineer becomes “disengaged” instead of someone who feels ignored whenever they speak.

Amy Edmondson’s famous research on psychological safety showed something important: teams in the same company could behave completely differently depending on the local environment. High-performing teams actually reported more mistakes because people felt safe speaking up.

Same kinds of people. Different systems. Different behaviour.

A lot of what managers call “difficult behaviour” is actually a system problem.

1. Ambiguous ownership

The behaviour

Someone keeps stepping into areas that don’t seem like their responsibility.

They reopen made decisions.
They review and nitpick other teams’ PRs.
They sound territorial in Slack.

What’s usually happening

Nobody actually knows who owns what.

One document says Team A owns it.
Another implies Team B owns it.
And actual decisions happen based on whoever argues hardest in meetings.

In his article about engineering reorgs, Will Larson argues that many poor working relationships come from information gaps. When ownership becomes clear, a lot of conflict disappears naturally.

Write down ownership clearly.

Not following vague org-chart ownership.

Who owns the service?
Who makes the final call?
Who handles incidents?
Who owns its planning?

Team Topologies gives useful language for this. I also wrote about common Team Topologies mistakes, and most of them come down to the same issue: teams adopt the labels but never define how they actually work together.

2. Decisions that never really close

The behaviour

An engineer keeps reopening old discussions.

They escalate disagreements.
They challenge decisions that already seemed made.
You start dreading seeing their name in Slack.

What’s usually happening

In your organisation, decisions don’t actually close.

People agree in meetings.
Then decisions get reversed later by whoever pushes hardest afterward.

The engineer has learned that escalation works.

That behaviour is annoying, but it’s also rational inside that system.

This is closely related to why managers end up chasing teams for updates. When ownership and decision-making are unclear, every conversation turns into lobbying.

Record decisions somewhere.

What was decided?
Who decided it?
Who was consulted?
When can it be revisited?

Then reinforce “disagree and commit”.

Amazon explains this really well in its shareholder letter. People can disagree during discussion, but once the decision is made, the team moves forward together.

Without that norm, the loudest (or most annoying) person wins in the end.

Eventually quieter engineers stop engaging altogether.

3. Behaviour the system rewards

The behaviour

There’s someone everybody complains about in DMs.

Maybe they’re rude in PR reviews.
Maybe they miss commitments.
Maybe they don’t like helping juniors.

You’ve had conversations with them already, but nothing changes.

What’s usually happening

The system is still rewarding them.

Maybe they’re the fastest engineer.
Maybe they know critical systems nobody else understands.
Maybe leadership keeps praising them anyway.

“The behaviour is acceptable because the output is valuable.”

That’s why the behaviour continues.

Netflix’s culture memo makes this point clearly: company values are revealed by who gets rewarded, promoted, or tolerated.

Brendan Gregg’s article on brilliant jerks explains this well too. The problem persists because leadership allows it to persist.

I’ve written before about how senior engineers lose trust, but the harder question is this:

Are you still rewarding the behaviour anyway?

You need to think about:

What gets rewarded?
What gets tolerated?
What gets called out?

The DORA research on generative culture references a great John Shook quote:

You don’t change culture by changing how people think. You change culture by changing how they behave.

Behaviour follows incentives.

A better way to diagnose the problem

When you catch yourself using a personality label, replace it with a structural question.

Look at your last few difficult conversations.

If the people were different but the complaints were similar, the problem is probably structural.

I built a free 1:1 questions generator partly because the questions managers ask shape the answers they get. If your questions only focus on individuals, you’ll miss the system entirely.

For a deeper version of this, I also wrote the EM Field Guide. It’s the playbook I wish someone had handed me when I first became an Engineering Manager almost a decade ago with my learnings since then.

Sometimes the person really is the problem though

Not everything is structural.

Susan Fowler’s story about Uber is an example of that. The structure protected terrible behaviour from a harasser. Treating it as purely structural though would have been an insult to her experience.

A useful diagnostic question is this:

If the structure changed tomorrow, would this person adapt?

Most people would. Some won’t.

That’s usually the signal you’re dealing with an individual issue rather than a system issue.

What you can do tomorrow

Think about the engineer you currently consider “difficult”.

Before preparing for another difficult conversation, ask:

Is ownership around this issue actually clear?
Are decisions documented and closed?
Is the system rewarding the behaviour somehow?

Fix those first.

A surprising number of difficult conversations disappear once the system improves.

And if the behaviour still continues afterward, you’ll at least know you’re dealing with the real issue instead of the symptom.

If you enjoyed this article, consider subscribing to get:

✉️ Free: 1 original post every Tuesday, my favourite posts of the week every Sunday + 10 Notion Templates for Engineering Managers
🔒 Paid: Full archive + 50+ EM templates & playbooks + The EM Field Guide