# How do you talk to someone who puts themselves first?

**Someone who puts themselves first** needs feedback about choices, not a verdict about character. Name the visible work they selected, the shared work they left behind, and the credit they claimed. Explain the cost to delivery and trust, then request one specific contribution with a check date. The conversation is about fair participation in engineering work, not a demand that ambition disappear.

        
## What pattern should you bring to the 1 on 1?

        
Collect choices that show the pattern across comparable opportunities. The engineer volunteered to present the architecture, declined the on call rotation, left release verification to two teammates, and later described the launch as their design. One glamorous task alone proves little. The combination of visible ownership, avoided maintenance, and expanded personal credit shows the work problem you need to discuss.

        
Separate this concern from a generic workload dispute. The issue is not simply that one person completed fewer tickets. Glue work may be hidden, and some design work legitimately carries broad responsibility. Trace who handled alerts, documentation, testing, handoffs, and cleanup around the visible result. Fair feedback starts with a complete account of contribution.

        
## How should you open without calling them selfish?

        
Say: “I want to discuss how work and credit were divided in the payments launch. You chose the design presentation and asked to be removed from two on call shifts. Maya and Theo completed the release checks and handled the weekend issue. In Monday's update, you presented the launch as work you led without naming their contributions.” Then pause for their account.

        
Selfish is an interpretation of identity. The examples are choices with consequences. The engineer may say they believed the manager had approved every trade. Check that claim. If unclear staffing created part of the problem, own it. You can correct the system and still ask the engineer to represent contribution accurately and carry an agreed share of less visible work.

        
## What team cost should you name?

        
Explain that selective participation changes what teammates are willing to share. People stop offering ideas when someone else takes the stage and leaves them the operational burden. They become cautious about pairing because contribution may disappear from the story. The result is slower collaboration, brittle ownership, and resentment around assignments that the manager then has to mediate.

        
Connect the pattern to engineering risk. When one person owns design status but avoids on call learning, their future decisions miss production detail. When release cleanup always moves to quieter engineers, the system rewards presentation over reliability. This is not a complaint that everybody must enjoy every task. It is a requirement that ownership includes the unglamorous consequences of a choice.

        
## What contribution should you request now?

        
Choose a concrete responsibility that matters to the current work. Ask the engineer to take the next primary on call week, pair with the release owner on verification, and write the next project update with contributors named beside their work. Do not assign a random punishment. The action should reconnect visible ownership with operational responsibility and honest credit.

        
Keep the ask short enough to remember: “For this release, ownership includes on call coverage, verification, and naming other contributors. I need you to complete those three parts.” Ask what support or scheduling constraint matters. Then set a review for the Monday after the rotation, when you can examine actual handoffs and the written update.

        
## How can credit be corrected without public humiliation?

        
Ask the engineer to update the project note and recognize the missing contributors in the next normal team forum. The correction should be factual, not a forced confession. A useful sentence names who built the test harness, who ran verification, and who handled the incident. It does not need to announce that the manager ordered the change.

        
Correct your own recognition practices too. If managers praise whoever presents without asking how the work happened, self promotion becomes rational. Project reviews should identify design, implementation, operation, coordination, and learning. Better visibility does not excuse the engineer's choice, but it reduces the incentive and opportunity to repeat it.

        
## Which evidence keeps this conversation fair?

        
| Area | Evidence | Question |
| --- | --- | --- |
| Visible work | Design and presentation | Who chose it? |
| Shared duty | On call and checks | Who carried it? |
| Credit | Updates and reviews | Who was named? |
| Learning | Production follow through | Who gained context? |

        
Artifacts prevent the discussion from becoming a popularity contest. Review the rotation, task history, project notes, and incident record. Also ask whether the engineer performed invisible work you missed. A fair manager is willing to discover that the pattern is weaker than expected. Precision makes any remaining concern stronger.

        
## What sequence should the conversation follow?

        
- Name the project and the choices you observed.
- Describe who carried the work left behind.
- Explain the delivery and trust cost.
- Ask for the engineer's account.
- Correct any incomplete facts.
- Request one complete ownership cycle.
- Set the evidence and follow up date.

        
Do not negotiate the basic principle that credit follows contribution and visible ownership carries operational duties. You can negotiate which rotation or release is practical. If the engineer argues that their architecture work is more valuable, acknowledge its value and return to the missing obligations. Strong design is not a coupon that removes team responsibility.

        
## How do you respond to common objections?

        
If they say nobody else wanted to present, distinguish presentation from claiming sole credit. If they say on call interrupts important work, ask why that cost should always move to peers. If they say the release tasks are below their level, explain that seniority increases responsibility for complete outcomes. Use the same calm facts rather than debating whether they are a good person.

        
An objection may reveal a real career or role issue. Perhaps incentives reward only visible design, or the engineer was explicitly hired for research with no operations duty. Resolve mismatched expectations honestly. Do not use a moral conversation to hide an unclear role. Once the role is clear, the participation standard should be clear too.

        
## What should you inspect at the follow up?

        
On the agreed date, look at whether the engineer completed the duty, shared context, and represented credit accurately. Ask teammates about the handoff rather than whether they like the person. Did the next owner receive usable information? Did the project note reflect real contribution? Did the engineer remain engaged when the work became less visible?

        
Recognize a complete ownership cycle specifically. If they took on call, improved the runbook, and thanked the release owner, name those changes. If they complied publicly while privately pushing duties back to others, address that behavior with new facts. The goal is a durable contribution pattern, not one theatrical act of helpfulness.

        
## How can a release reveal whether ownership changed?

        
Use the next release as a complete test rather than watching isolated acts of helpfulness. Before work begins, list design, implementation, verification, communication, support, and cleanup. Ask the engineer which parts they will own and which parts need named partners. The list prevents the visible design from becoming the whole story again. It also lets the manager see whether they choose a fair share before praise or pressure enters the picture.

        
During the release, notice how the engineer responds when an unattractive task appears. A failed migration check may require careful log review while a leadership update is due. Do they stay with the failure, arrange a responsible handoff, or disappear into the more visible update? Do not manufacture a test. Ordinary delivery will create enough moments where complete ownership becomes visible.

        
Ask how they describe the work to people outside the team. A useful account says that one person designed the approach, another built the test harness, and the on call pair diagnosed the rollout issue. Accurate credit is not a ceremonial thank you added after private pressure. It is part of how the engineer understands the system of work that produced the result.

        
Also inspect who receives growth opportunities. Someone who repeatedly selects architecture while peers inherit cleanup gains stronger promotion evidence from an unfair division. Rotate meaningful design ownership and expect senior engineers to make less visible work teachable. Fairness is not achieved by giving everybody identical tasks. It is achieved when status does not let one person keep the benefits and export the costs.

        
At the release review, ask the engineer what they would claim as their contribution and what they would credit to others. Compare that account with the record. If it is accurate and they carried the duties they accepted, name the improvement. If important labor disappears again, show the specific omission and explain that the original concern remains open. The follow up should make contribution visible, not ask whether the engineer now feels more team oriented.

        
## How do you avoid turning fairness into scorekeeping?

        
Do not assign points to every support task or demand equal visibility after each sprint. Engineering contribution varies with skill, urgency, and role. Instead, inspect whether the same person repeatedly gains status while others repeatedly absorb cost. Ask whether work allocation produces learning and recognition for several people over time. A senior engineer may reasonably lead a difficult design, but complete leadership includes making operational work visible, sharing context, and taking responsibility when the design meets production. When discussing fairness, invite the engineer to propose a division that protects the outcome and gives peers credible ownership. Review that proposal against capacity and growth, not against a rigid quota. Also ask quieter contributors what work is missing from the plan, without framing them as complainants. The manager should own the final allocation and recognition system. At the follow up, look for a changed pattern across assignment, execution, and storytelling. One extra cleanup task does not repair a habit of taking the best work, just as one prominent presentation does not prove selfishness. The relevant evidence is whether benefits and burdens can move, whether credit tracks reality, and whether teammates can trust that collaboration will not make their work disappear.

## What are common questions?

### Should you tell the engineer they are selfish?

No. Describe the visible work chosen, shared work avoided, credit claimed, and effect on delivery and trust.

### Is assigning on call a punishment?

It should not be. Use a normal, fair duty that reconnects project ownership with production responsibility.

### How should missing credit be repaired?

Ask for a factual update in the normal project forum that names each person's actual contribution.

### What if the engineer did invisible work too?

Add that work to the record and revise your conclusion before deciding whether a concerning pattern remains.

### When should you follow up?

Choose the date immediately after the next complete ownership cycle so you can review real evidence.

Related: [having a difficult conversation with an engineer](https://isilta.com/blog/how-to-have-a-difficult-conversation-with-an-engineer/), [talk to a strong engineer who hurts the team](https://isilta.com/blog/how-to-talk-to-a-high-performer-who-hurts-the-team/), [talk to someone who overrates their work](https://isilta.com/blog/how-to-talk-to-someone-who-overrates-their-work/).