How do you have a difficult conversation with an engineer?

A difficult conversation with an engineer works best when you prepare two or three observable facts, describe the work cost, make one short request, and set a date to check what changed. Hold it in private, stay with one topic, and listen for information that could alter your view. The goal is not a dramatic confrontation. It is a clear working agreement that both people can test.

What should you prepare before the 1 on 1?

Write down what you directly observed, where it happened, and what changed in the work. Replace conclusions such as selfish, arrogant, or negative with events another person could recognize. A design owner took the visible architecture task, declined two on call shifts, and left the release checklist to others. A reviewer wrote three insulting comments on a junior engineer's change. Facts let you be direct without pretending you know motive.

Choose one subject for the conversation. A manager who arrives with six months of accumulated irritation often lists every disappointment, while the engineer cannot tell which change matters now. Select the behavior with the clearest current cost. Keep other issues for their own conversations if they remain relevant. Prepare a sentence that connects the behavior to an engineering result, such as slower review, hidden risk, repeated rework, or lost trust between teams.

According to iSilta's 2026 survey of 146 organizations, 78% report weak 1 on 1s when managers are trained late. A difficult conversation cannot wait for a later training program. You can prepare carefully, ask a trusted manager to test your evidence, and speak now while the engineer still has a fair chance to change the next piece of work.

How should you open the conversation?

Start without a long warning or false praise. Say that you want to discuss one pattern, then name a recent example and its cost. For example: “I want to discuss what happened after Tuesday's architecture decision. You agreed in the review, then told the mobile team to ignore it. They stopped implementation because they did not know which direction was real.” The opening gives the engineer something concrete to answer.

Do not spend five minutes saying how difficult this is for you. That asks the listener to comfort the manager before hearing the concern. A calm opening is enough. Your tone should communicate that the issue matters and that you expect a workable discussion. If there may be serious formal consequences, follow the correct company process and do not disguise that process as an ordinary chat.

How do you describe behavior without assigning a motive?

Use actions, artifacts, dates, and recipients. Pull request comments, incident notes, planning decisions, and work assignments are stronger than a general report that somebody is hard to work with. Explain what you saw and ask what was happening from their perspective. They may provide missing context, but context does not automatically remove the impact. Both can be true.

Avoid mind reading. “You wanted the project to fail” invites an argument about intention. “After agreeing to the rollout, you reopened the rejected option in two channels and asked another team to pause” keeps the discussion on choices. If the engineer says they were raising a new risk, ask when the risk appeared and which agreed route they used. The distinction can change your response.

What short ask should you make?

Ask for one behavior that can be observed in the next relevant situation. You might require the engineer to take disagreement back to the decision owner before advising another team, pair with a named colleague on the next service change, or bring a recommendation when escalating a decision. Do not ask them to be less difficult, improve attitude, or become more collaborative. Those phrases provide no reliable test.

Make the boundary clear enough that support does not erase responsibility. You can offer a review template, a pairing block, or help clarifying authority. The engineer still owns the requested action. Ask them to restate the agreement in their own words and correct any mismatch before the meeting ends. Shared wording now prevents a later argument about what you meant.

Which conversations are in this series?

1. Someone who puts themselves first
2. Someone who overrates their work
3. Someone who dislikes the job
4. Someone who agrees then undermines
5. Someone who will not share knowledge
6. Someone who treats junior engineers poorly
7. Someone who never owns a miss
8. Someone who sends every hard call up
9. A strong engineer who hurts the team
10. A former peer you now manage

Choose the guide that matches the behavior you need to address, not a permanent label for the person. The same engineer can hoard knowledge in one quarter and respond generously after direct feedback. A guide is a way to prepare one conversation. It is not permission to reduce someone to a type.

Each guide uses the same management spine: facts, work cost, a short ask, and a dated check. The examples differ because the listener's likely concern differs. Someone who believes their work is excellent needs artifacts. A former peer may need authority made explicit. Someone who dislikes the job needs an honest decision about whether the role can change.

How do you listen without losing the point?

After the opening, ask a real question and stop talking. “How did you see that decision?” is better than a question that contains the desired answer. Listen for facts you missed, a conflicting instruction, a skill gap, or a different account of ownership. Take brief notes if the subject is complex, but keep attention on the person rather than building a case while they speak.

Listening is not agreement. If the engineer explains that pressure caused them to skip review, you can acknowledge the pressure and still require review next time. If they show that another leader told them to bypass the process, pause before assigning individual blame and resolve the authority conflict. Good listening can change the diagnosis while preserving a clear expectation.

What record should you keep?

Send a brief written follow up that reflects the conversation rather than a secret verdict. Include any important context the engineer added, the action each person owns, and the date you will review evidence. Follow your organization's rules for sensitive notes. The purpose is a reliable agreement and fair continuity, not a dramatic document.

When should you check again?

Choose a date connected to real work. If the concern is review tone, inspect the next two reviews and meet the following Friday. If the concern is decision ownership, check after the next planning cycle. A date many months away leaves the engineer guessing and lets the manager reinterpret scattered events. A check tomorrow may provide no meaningful chance to practice.

At the check, discuss evidence rather than asking whether things feel better. Name what changed, what did not, and what the next expectation is. Recognize a real improvement without declaring the whole issue solved from one event. If the behavior continues, say so directly and use the appropriate performance process. Repeated ambiguity is not kindness.

How do you keep the conversation professional?

Pick a private setting with enough time and no audience. Avoid delivering important correction in a hallway, a crowded video call, or the final minute of a routine meeting. Privacy protects dignity and makes disagreement safer. Do not create mystery days in advance with a message that says only “we need to talk.” Give a simple topic when practical.

Professional does not mean emotionless. The engineer may be surprised, embarrassed, angry, or relieved that an unspoken tension is finally named. Allow a pause. Restate facts if the conversation drifts into identity. If either person cannot continue productively, schedule a prompt continuation and record what remains open. Do not let a pause become indefinite avoidance.

What can you say when the conversation starts to drift?

Return to the single example and the next action. You can say, “I hear that you disagree with how planning was run, and we should discuss that separately. In this conversation, I need us to resolve what you will do when you disagree with a recorded decision.” This is not refusing context. It is preventing every organizational frustration from becoming a reason that no current behavior can be addressed.

If the engineer turns the discussion into a comparison with peers, note any credible inconsistency and keep the request intact. “I will review whether I have applied this standard evenly. Your review comment still needs to name the technical risk without attacking competence.” Fairness questions deserve an answer, but another person's behavior does not remove this person's responsibility. Put a date beside your review of the comparison so the promise is real.

How can you prepare the exact first minute?

Write four short lines before the meeting: the topic, the observed example, the work cost, and the question. For instance: “I want to discuss how the payments decision was handled after planning. You agreed to the recorded choice, then asked the mobile team to pause it. They lost two days because they did not know which direction was active. What changed after the meeting?” Read the lines aloud once so you can hear any accusation or hidden assumption. Then put the note aside and speak naturally. The preparation is a guardrail, not a performance. It keeps nervous managers from circling the subject, adding irrelevant praise, or turning one event into a claim about character. It also creates room for listening because you no longer need to invent the opening under pressure. If the engineer supplies important new context, update your account. If they answer a different question, return to the four lines and ask again. Before ending, write the short ask and follow up date together. The first minute should make the topic unmistakable. The remaining time should test the facts, define the change, and preserve the listener's ability to respond with dignity.

What are common questions?

Related: talk to someone who puts themselves first, talk to someone who overrates their work, talk to someone who dislikes the job.

Prefer prepared conversations over memory alone? Explore iSilta features or try the product demo.