This is not a morale conversation; it is a performance control conversation. The right 1on1 template makes the gap visible, names the standard, and forces a dated decision. At Amazon, vague support reads as managerial avoidance, not empathy.
TL;DR
This is not a morale conversation; it is a performance control conversation. The right 1on1 template makes the gap visible, names the standard, and forces a dated decision. At Amazon, vague support reads as managerial avoidance, not empathy.
Not sure what to bring up in your next 1:1? The SRE Interview Playbook has 30+ high-signal questions organized by goal.
Who This Is For
This is for a new manager in the first 90 days who inherited an engineer missing deadlines, producing unstable code, or repeatedly failing design review. It is also for a manager who suspects the problem is not raw ability, but inconsistent ownership, weak judgment, or defensive behavior. If you are trying to rescue a possible fit issue without turning the relationship adversarial, this is the right frame.
What should the first 1on1 say?
The first 1on1 should be explicit, brief, and anchored in observable misses. In a Q4 manager calibration I sat through, the strongest engineering manager did not open with reassurance. He named the late deliverable, the rework, and the downstream cost in one minute, then asked for the engineer’s read. The room trusted him because he was specific, not because he was gentle.
The problem is not your honesty, but your ambiguity. If you say, “I want to help you grow,” the engineer hears drift. If you say, “Your last two commits missed the agreed design, your status updates arrived after the team had already moved, and this has to change by next Friday,” the engineer hears a standard.
A clean opening has four parts. State the gap. State the standard. State the impact. State the next check-in date. That is the template. Anything longer usually becomes self-protection, and anything softer usually becomes a delay tactic.
Not a pep talk, but a performance contract. Not a vague concern, but a concrete mismatch. Not a personality critique, but an output diagnosis. Those distinctions matter because underperformers often weaponize vagueness; they agree with the mood and ignore the obligation.
A useful first sentence is: “I am concerned because your current output is not meeting the bar for this role, and I want us to be precise about what changes in the next 30 days.” That sentence is cold on purpose. Cold is better than confusing.
How do I tell whether this is a skill gap or an ownership gap?
If the engineer improves when the work is broken into smaller slices, it is usually a skill gap. If the engineer improves only when watched closely, it is usually an ownership gap. Amazon managers confuse those two all the time, and the mistake costs months.
In one manager sync, a new manager kept calling the problem “context switching.” The skip manager cut through it: the engineer was not overloaded, they were buffering hard problems, waiting for someone else to define the work, then surfacing late. That is not a workload problem. That is an ownership problem wearing workload language.
Look for the pattern, not the excuse. A skill gap shows up as slow but honest progress, better output after clearer scoping, and fewer repeat mistakes once the missing knowledge is named. An ownership gap shows up as partial updates, evasive language, recurring surprises, and a habit of treating every question as if it were someone else’s job.
The problem is not that the engineer needs encouragement, but that the failure mode has not been named. Managers waste time trying to motivate what is actually a judgment defect. They also make the reverse mistake: they treat every weak performer as unmotivated when the real issue is a narrow technical blind spot.
Not “they do not care,” but “they do not yet own the full problem.” Not “they need more confidence,” but “they need a clearer contract.” Not “they are toxic,” but “their execution pattern is predictable and broken.” That distinction prevents emotional drift and keeps the conversation tied to evidence.
A manager at Amazon should listen for three signals. First, does the engineer restate the issue accurately without being prompted? Second, do they propose a real change, not a cosmetic one? Third, do they follow through without another reminder? If those three do not improve, the issue is not misunderstanding. It is reliability.
What should the 30/60/90-day 1on1 template contain?
The template should be simple enough to repeat and strict enough to measure. A credible reset at Amazon is usually a 30-day proof window, a 60-day accountability checkpoint, and a 90-day decision point. Anything looser turns into theater.
The template should fit on one page. It should contain five things: current standard, specific misses, expected behavior, support you will provide, and the date of review. If you need more than one page to explain the gap, you are probably mixing diagnosis with autobiography.
Use this structure in every weekly 1on1:
- Current standard: what “good” looks like in this role right now.
- Current gap: the exact work product, date, and impact where the engineer missed.
- Next action: one deliverable that proves change before the next meeting.
- Support: one thing you will unblock, and one thing the engineer owns alone.
- Review date: the day you will judge whether the pattern changed.
A serious reset works like a five-round interview loop, not like one loose conversation. Each meeting should produce a distinct signal: clarity, commitment, execution, follow-through, or escalation. If all five meetings say the same thing, the meetings are decoration.
In practice, the 30-day window is about proof of comprehension, not perfection. By day 7, the engineer should be able to describe the problem without defensiveness. By day 14, you should see a visible change in status quality or task ownership. By day 30, there should be evidence that the pattern is different. If not, the template is not the issue.
Not “improvement over time,” but “evidence by date.” Not “better vibes,” but “observable output.” Not “we had a good talk,” but “the next artifact was materially better.” That is how Amazon managers separate intent from execution.
The best managers also document the template in a way that would survive a skip-level review. Not because they expect conflict, but because ambiguity later becomes political. If a senior manager asks what changed between week one and week four, you want the answer to be legible in writing, not trapped in memory.
How do I keep this from turning into a PIP by another name?
You keep it from becoming a disguised PIP by being honest about the stakes and clean about the boundaries. If the engineer is already on a formal correction path, pretending this is casual support is dishonest. If they are not, collapsing every hard conversation into process language is equally weak.
In Amazon culture, managers often hide behind “coaching” when they are actually evaluating risk. That is a mistake. An underperforming engineer does not need a manager who sounds kind. They need a manager whose expectations are legible enough that the outcome is not surprising.
The psychology here is simple. Once a manager starts documenting a decline, people become sensitive to every word and every delay. If the manager remains vague, the engineer feels ambushed later. If the manager is clear from day one, the engineer may be uncomfortable, but they are not confused. Confusion is worse than discomfort.
The problem is not documentation itself, but the lie that documentation can be neutral. It cannot. The moment you write down the gap, you are signaling that the pattern matters. That is not cruelty. That is management.
A credible manager separates support from judgment. Support means unblocker time, clearer requirements, or paired review on a specific task. Judgment means a dated assessment of whether the engineer changed the pattern. Blurring those two creates false hope and weak accountability.
In a leadership discussion, I once heard a manager say, “I do not want them to feel managed.” That sentence is usually a tell. If the person is underperforming, they should feel managed. Not humiliated. Managed. The distinction is the difference between professional pressure and managerial negligence.
Preparation Checklist
Use this checklist before the first conversation, not after you have already drifted into frustration.
- Write one sentence that states the standard for the role in plain English.
- List three concrete misses with dates, artifacts, and downstream impact.
- Decide what change would count as real progress in 30 days, not just better tone.
- Set a weekly 1on1 cadence for four weeks and hold the same day each time.
- Separate what you will support from what the engineer owns alone.
- Prepare one escalation point if the pattern does not change by the 30-day review.
- Work through a structured preparation system (the PM Interview Playbook covers Amazon-style debrief calibration and Leadership Principles with real debrief examples) so the judgment call is grounded in cases, not slogans.
Mistakes to Avoid
The worst mistakes are predictable because they are emotionally convenient. Managers talk around the issue, overpromise support, or treat improvement as a vibe instead of a deadline.
- Speaking in abstractions
BAD: “You need to be more proactive and improve your communication.”
GOOD: “Your last two status updates arrived after the team had already made decisions, and that creates rework.”
The problem is not that abstract language is polite. The problem is that it gives the engineer too much room to reinterpret the issue. Amazon does not reward reinterpretation.
- Turning support into indefinite patience
BAD: “Let’s keep an eye on it for a while and see if it gets better.”
GOOD: “We will review this again on June 14, and we will decide whether the pattern changed.”
Indefinite patience is not support. It is managerial avoidance dressed as empathy. A serious manager sets a review date because dates force reality.
- Using empathy to soften the standard
BAD: “I know this is hard, so I am not going to press the deadline.”
GOOD: “I understand this is hard, and the deadline still stands.”
Empathy without standards is just sentiment. Engineers do not need a manager who excuses the miss. They need one who can hold the line without becoming punitive.
FAQ
- Should I tell the engineer this could lead to a PIP?
Yes, if the risk is real and the performance gap is not changing. The point is not to threaten; the point is to remove ambiguity. If you hide the consequence, you are not protecting the relationship. You are delaying the truth.
- How direct should the first 1on1 be?
Direct enough that the engineer can repeat the issue back to you in one sentence. If they cannot do that, your message was too soft or too broad. The goal is not emotional agreement. The goal is shared reality.
- What if the engineer is strong technically but still underperforming?
Then the issue is probably not technical depth. It is execution reliability, ownership, or judgment under pressure. Amazon has little tolerance for “brilliant but unstable” as a long-term excuse. Strong code does not cancel weak follow-through.
Ready to build a real interview prep system?
Get the full PM Interview Prep System →
The book is also available on Amazon Kindle.