How do you talk to someone who dislikes the job?

Find whether the work can change before the team pays

Someone who dislikes the job may still ship good code while making it clear that this work is not what they want. Ask what part of the role has become unacceptable, whether a realistic change exists, and how long you will test it. Do not demand enthusiasm. Protect the team from endless contempt, and be honest when the available job cannot become the job the engineer wants.

How do you know this is about the job?

Look for specific statements and choices rather than a temporary low mood. The engineer says they no longer want product support, avoids customer context, and asks repeatedly for research work that the team does not have. They still deliver assigned changes, but every planning discussion returns to how pointless the domain feels. That is different from one difficult sprint or ordinary fatigue.

Do not diagnose disengagement from quietness. Ask directly: “You have said several times that you do not want the kind of work this team owns. I want to understand whether this is a difficult period, a part of the role we can change, or a role you no longer want.” The options make room for a real answer without demanding a cheerful performance.

What should you listen for?

Listen for the object of dislike. It may be the domain, the support burden, the amount of coordination, a stalled technical path, a broken relationship, or engineering work itself. Ask which parts give energy and which parts feel unacceptable. A broad statement such as “I hate this job” often contains several problems with different possible responses.

Also ask what changed and when. A new on call load may be fixable. A promised platform project may have vanished. The engineer may have learned that they want a different craft. Do not rush to persuade them that the current job is secretly good. Your task is to understand the choice both sides actually face.

What can realistically change?

List changes within your authority: a different project mix, a rotation away from a draining duty, a transfer conversation, clearer product context, or a time limited learning assignment. Then state constraints. If the team exists to maintain a customer facing service, you cannot promise a pure research role. A fantasy adjustment delays the decision and spreads the cost to peers.

Test one meaningful change rather than ten comforts. For example, shift the engineer from repeated feature work to a six week reliability project while they retain a fair on call share. Define the work, duration, and result. The test should answer whether a different shape of the real role improves the fit, not whether temporary special treatment feels pleasant.

What behavior still has to stop?

Disliking the job does not permit contempt toward teammates or customers. Name any observable behavior separately: dismissing product questions, mocking roadmap work, or telling new hires that their work is pointless. Explain the team cost and require professional participation while the role decision is open. You are not asking for false excitement.

A useful request is: “You may disagree with this roadmap. In planning, I need you to state the technical concern without calling the work stupid or implying that colleagues lack judgment.” Check that behavior at the next planning session. Role fit and conduct can be discussed together without pretending they are the same issue.

Which options should you put on the table?

SignalPossible actionDecision date
One duty is the issueChange the work mixAfter one cycle
Team domain is the issueExplore a transferBy a named date
Role itself is wrongPlan an honest exitAfter process review
Cause is unclearRun a bounded testWithin six weeks

Do not present an exit as a threat for speaking honestly. It is one possible conclusion when no available work matches what the person wants. Follow company policy and involve the proper people for any employment action. The manager can be humane without promising indefinite customization.

How do you design a fair trial?

  1. Name the part of the role being tested.
  2. Choose one change within real constraints.
  3. Protect duties that remain shared.
  4. Define work and conduct evidence.
  5. Set a midpoint conversation.
  6. Set the final decision date.
  7. Choose continue, transfer, or exit honestly.

Write the trial in ordinary language. For six weeks, the engineer leads service reliability work, remains in the rotation, and attends product planning without dismissive comments. At week three, discuss energy and delivery. At week six, decide whether this shape is sustainable or whether to pursue another path.

How do you protect the rest of the team?

Do not quietly redistribute every unwanted task to people who still care about the domain. Explain work changes in terms of project needs and maintain a fair duty system. Respect the engineer's privacy, but do not make peers absorb an open ended accommodation whose boundaries only the manager understands.

Watch the story the engineer tells in shared spaces. Honest disagreement can improve a roadmap. Repeated contempt can make colleagues question the value of their work and burden them with defending ordinary choices. Address each event close to the moment, then use the private follow up to examine the pattern.

What if the role cannot change?

Say so without pretending patience will create a different company. “The role will continue to include customer support and product delivery. I do not have a research position to offer. I want us to decide by November 20 whether you can choose this role as it is or whether we should discuss a transition.” Clarity gives the engineer agency.

Do not advise resignation casually or use a transition conversation to avoid formal obligations. Consult the correct internal process. Continue normal management, fair assignments, and recognition while the decision is open. An engineer who may leave still deserves a professional workplace, and the team still needs reliable ownership.

How should the final follow up work?

Review the trial against what both sides agreed. Did the changed work improve fit? Did professional conduct hold? Did the team pay an unreasonable cost? Ask the engineer what they learned before giving your view. Then choose a real next step rather than extending uncertainty because the conversation feels uncomfortable.

If the engineer stays, document the role they are choosing and any durable work agreement. If they seek transfer, name owners and dates without promising a destination. If an exit path is appropriate, follow policy and preserve dignity. The success of this conversation is an honest decision, not necessarily retention.

How can you discuss motivation without asking for personal disclosure?

Keep questions connected to work. Ask which responsibilities they want more or less of, what kind of problem they hope to solve, and which conditions make the current role hard to choose. They do not owe you a diagnosis, family history, or private explanation for every change in energy. If they volunteer sensitive context, follow policy and focus only on what the workplace needs to address.

Avoid turning the 1 on 1 into a sales pitch for the company. Listing benefits, mission statements, and other people's enthusiasm can make honest dislike feel like disloyalty. Reflect what you heard, test what can change, and say what cannot. The engineer is more likely to make a responsible choice when the manager does not require a performance of gratitude before discussing options.

Ask what a good week in the actual role would contain. Their answer may reveal a feasible shift, such as more debugging and less roadmap presentation. It may reveal an impossible role, such as no customer work on a customer product team. Translate the answer into a small trial or a clear constraint. Do not leave it as an inspiring description with no relation to available work.

During the trial, do not ask for a daily happiness score. Observe whether the engineer engages with the chosen work, meets duties, and uses professional language about the rest of the role. At the midpoint, ask what the new arrangement changed and what remained wrong. A disappointing answer is useful evidence. The purpose is a decision, not proof that the manager's adjustment succeeded.

Be alert to indefinite waiting. An engineer may say they need another quarter after every date because choosing feels risky. The manager may accept because replacing a capable person feels hard. Restate the options and the decision date. Compassion allows enough time for evidence and process. It does not require the team to carry permanent uncertainty about whether a core owner wants the work.

How can you keep an honest exit path from sounding punitive?

Introduce it only after you understand the mismatch and the available changes. Say that leaving or transferring can be a responsible choice when the real role does not fit, not a punishment for naming dissatisfaction. Avoid phrases that imply immediate resignation or question loyalty. Explain which options you can explore, which decisions belong to other people, and what work expectations remain during the process. If company policy requires a people partner or another owner, involve them before making promises. The engineer may choose to stay after seeing the role clearly. Ask for that choice in terms of responsibilities, not enthusiasm: can they perform customer support, participate professionally in planning, and own the agreed service? If they cannot, extending the arrangement may harm them and the team. Set a date that allows useful investigation without months of drift. Continue to recognize good work and address conduct normally during that period. Do not withdraw opportunities as a way to push them out, and do not assign critical long term ownership without a transition plan. A humane exit path gives both sides accurate information, time to act, and respect. It does not guarantee the engineer's preferred destination or ask colleagues to carry indefinite uncertainty.

What are common questions?

Should a manager try to make the engineer like the job?

No. Understand the mismatch, test a realistic change, and make an honest decision about the available role.

Can the engineer still perform well?

Yes. Good delivery can continue even when the person no longer wants the work, which is why direct discussion matters.

What conduct can you require?

Require professional disagreement and reliable ownership, without demanding excitement or gratitude.

How long should a role trial last?

Use enough real work to test the change, often one cycle or several weeks, with a midpoint and final date.

What if no suitable role exists?

State the constraint honestly and use the proper process to explore transfer or a respectful exit path.

Related: having a difficult conversation with an engineer, talk to someone who sends every hard call up, talk to a former peer you now manage.

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