· Valenx Press · 13 min read
managing-former-peers-as-new-amazon-sde1-manager
Managing Former Peers: A New Amazon SDE1 Manager’s Guide to Authority
TL;DR
The fastest way to lose authority with former peers is to pretend nothing changed. Your authority at Amazon comes from calibrated decision-making, not friendship or technical superiority. New managers who survive the first 90 days establish one non-negotiable behavior change and communicate it explicitly; those who fail leave their team guessing what changed.
Who This Is For
This is for the SDE who just got promoted to SDE1 Manager (or equivalent L5 to L6-ish transition) and now leads people who sat next to them at team lunch three weeks ago. You probably make between $170,000 and $220,000 total comp now, up from roughly $140,000-$180,000 as an individual contributor, and the raise feels hollow because you’re terrified of the first one-on-one with someone who knows exactly how you got here.
You have probably already made one awkward comment about how you are “still one of the team” and immediately regretted it. You are not looking for leadership philosophy. You are looking for what to do Monday morning so nobody tests you and finds you soft.
How Do I Handle the First Team Meeting After My Promotion?
The first team meeting is not about vision. It is about territory marking, and every former peer is watching to see if you understand this.
In a Q2 debrief I sat in on, a new Amazon manager named his promotion in the first thirty seconds, then spent twelve minutes explaining how he wanted to keep things “exactly the same” and how everyone should feel comfortable coming to him about anything. The senior engineer in the room later told his skip-level, “He just told us he has no plan and he’s scared.” That manager was gone within eighteen months, not fired, but reorganized into a staff role with no reports.
The counter-intuitive truth: your former peers do not want you to be the same person. They want evidence that the promotion changed you in a specific, useful way.
Walk in with one calibrated change. Not ten. One. “Starting this sprint, I will be the person who reads every operational review before it goes to senior leadership. I need them twenty-four hours before deadline. This is non-negotiable because I have seen us get burned twice.” Then sit in the silence. The silence is where authority lives. The manager who fills it with reassurance talks himself out of his own authority.
The first counter-intuitive truth is this: authority at Amazon is signaled by what you stop doing, not what you start. You stop attending one recurring meeting that wastes time. You stop reviewing code in areas where you have no expertise. You stop answering Slack within thirty seconds because you are doing actual manager work.
Each absence must be announced, or it reads as neglect. “I am no longer attending the daily standup. Sarah is the source of truth. I will read the async update at 10 AM.” This is not delegation. This is demonstrating that your time has been revalued.
📖 Related: H1B vs L1 Visa for Amazon Internal Transfer: Pros and Cons
What Should My First One-on-Ones with Former Peers Cover?
Your first one-on-ones should kill the fantasy that your relationship is unchanged, and they should do it fast. The problem is not finding common ground; it is establishing that the ground itself has shifted.
I watched a hiring manager in AWS debrief a new manager who spent his first one-on-one with a former peer discussing their shared frustration with another team’s API. Forty minutes of commiseration. In the same conversation, he failed to mention that this engineer’s promotion document was due in six weeks and that he, as manager, would be calibrating it against the L6 bar. The engineer left thinking they were allies. When the manager later gave constructive feedback on the promotion doc, the engineer felt betrayed. The relationship never recovered.
The script for your first one-on-one: “Three things are different now. One, I write your performance narrative, which means I cannot be your venting partner about work. Two, I need to understand your career goals in the next two weeks because they will shape what projects I assign. Three, I will make decisions you disagree with, and when I do, I need you to disagree and commit in the room, then tell me privately if it is still eating at you.” Then stop talking. Let them sit with it.
The second counter-intuitive truth: the faster you introduce friction into former peer relationships, the faster you build real trust. The manager who delays the hard conversation because they want to “earn trust first” is actually hoarding relational credit they will spend catastrophically later. Spend it immediately on honesty. The engineer who hears the truth in week one knows you will not surprise them in week twelve.
How Do I Stop Doing Their Former Work Without Seeming Useless?
You were probably promoted because you were good at something technical. Now that skill is a trap. The moment you touch code that a former peer could handle, you signal that your promotion was administrative, not functional.
In a debrief for a retail team, the hiring manager defended a new SDE1 Manager who kept fixing bugs in his old component. “He is the fastest at it,” the manager argued.
The senior engineer in the loop pushed back: “Then he is also the reason three other engineers have not grown into that ownership. He is optimizing for his own hero narrative at the cost of their development.” The hiring manager changed his vote from “inclined to hire” to “no hire” for the promotion case. The lesson transferred to how he evaluated current managers.
The transition script for code ownership: “I am the last person who will fix a bug in this component. Starting next sprint, I will review architecture decisions only, and only when they cross into other systems. By Q3, I will not even do that.” Then make it true. The team watches your calendar more carefully than your words. If you are still in the on-call rotation three months post-promotion, you have failed a test you did not know you were taking.
The third counter-intuitive truth: your technical credibility at Amazon is maintained by strategic absence, not presence. The manager who shows up in a code review to demonstrate they still know the system is the manager who reveals they do not understand their new job. Your credibility comes from knowing which decisions matter and being invisible in the ones that do not.
📖 Related: Promotion Packet Cost vs Benefit for Amazon IC6 PMs
How Do I Handle a Former Peer Who Challenges Me Publicly?
The public challenge is inevitable. How you respond in the first ten seconds determines whether you will ever have authority with that person or anyone who witnessed it.
I sat in a debrief where a new manager described being challenged in a sprint planning meeting: “That timeline is impossible, and you would know that if you were still writing code.” The manager paused, then said, “Let’s take this offline.” In the debrief, every senior leader in the room leaned forward. “Why did you not handle it in the moment?” The manager said he did not want to embarrass the engineer.
The senior director responded: “You did not protect the engineer. You protected yourself. And every person in that room now knows that public challenge works on you.”
The correct response, practiced and delivered without rising intonation: “I am going to pause on that. You are right that my coding volume has dropped. That is intentional, because my job now is to see patterns across six teams, not to hold the deepest context on one. The timeline stands because of [specific dependency or risk], not because I am guessing.
If you have data I do not, I want it in the next hour. Otherwise, we are moving on.” Then move on. The challenge is not about your technical knowledge. It is about whether you will defend your decision-making process under pressure. The problem is not your answer; it is your judgment signal.
If the same person challenges you again in the next thirty days, the conversation is no longer about the technical issue. It is about behavior. “This is the second time you have questioned my judgment in a group setting. I need to understand whether you disagree with the decision or with my role in making it. Those require different conversations.” This is not aggressive. This is structural maintenance. Teams without this maintenance devolve into seniority-by-tenure, which is lethal to Amazon’s promotion and retention culture.
How Do I Calibrate My Relationship with My Own Manager Now?
Your relationship with your skip-level or direct manager has also changed, and you are probably underutilizing it because you are still performing the role of competent IC.
The new SDE1 Manager who waits for their manager to set the agenda is the manager who gets managed by default.
In my first month as a new manager at Amazon, I brought a list of three decisions I had made without waiting for approval, one I was unsure about, and one I was actively avoiding. My manager’s response: “This is the first time someone at your level has ever brought me the thing they are avoiding.” That single conversation established a pattern that accelerated my calibration reviews for two years.
The script: “I have made three decisions since we last spoke that I want to calibrate with you. Two I am confident in, one I want your pattern-matching on, and one I am avoiding because I do not yet have the stomach for the tradeoff.” This is not vulnerability theater. This is demonstrating that you know what managerial courage looks like and that you are building it systematically.
The fourth counter-intuitive truth: your manager does not want you to succeed. Your manager wants to not be surprised by your failures. The manager who reports only good news is the manager who gets less support, not more.
Bring the operational review that went badly before it becomes a narrative. Bring the team tension before it becomes a departure. Your authority with your own manager comes from being the person who surfaces problems at the right granularity: not so early that you are asking permission to breathe, not so late that the damage is done.
Preparation Checklist
-
Write the exact sentence you will say when a former peer treats you like a peer in a decision-making moment. Practice it until it feels mechanical, not emotional. The specific wording matters more than you think; “I need to be the manager in this conversation” lands differently than “we need to remember I am the manager now.”
-
Identify one meeting, one code review habit, and one Slack channel you will exit in the next fourteen days. Announce each exit with a two-sentence rationale and a named replacement. No ghosting. The absence without explanation is what reads as incompetence or indifference.
-
Schedule a thirty-minute calibration conversation with your manager for the end of your third week, not your first. Week one is too early for real pattern data; week six is too late to correct course. The specific timing signals that you are gathering information before demanding attention.
-
Work through a structured preparation system. The PM Interview Playbook covers leadership transition scenarios with real Amazon debrief examples, including the specific behavioral questions new managers fail most often and the exact rubric senior leaders use to evaluate “earn trust” and “hire and develop the best” during promotion reviews.
-
Draft your first performance feedback for each direct report before they expect it, even if delivery is months away. The act of writing it will reveal where your observation is thin and where you are still relying on old impressions. Thin observation is the first sign that you are managing the role, not the people.
-
Establish your “no” pattern within the first thirty days. Every new manager says yes too often. Document three things you said no to, with the explicit tradeoff you named. “No, we are not taking on that dependency because it would require Sarah to context-switch off her promotion project.” This creates a trail of decision logic that protects you when priorities are questioned.
Mistakes to Avoid
BAD: Keeping the same lunch schedule with your former peer group and using it to discuss work frustrations.
GOOD: Consciously creating one professional boundary that redefines the relationship. “I am still having lunch with you, but I am no longer the person who processes your frustration about this team. That needs to go to [peer manager] or to me in a one-on-one with a specific ask.”
BAD: Waiting for your former peers to adjust to your new role before you fully inhabit it.
GOOD: Announcing one behavior change in the first forty-eight hours that only a manager would do. “I am keeping a running document of operational patterns I see across sprint retros. I will synthesize and share monthly.” This is not a big change. It is an unmistakable signal.
BAD: Addressing a public challenge by proving your technical correctness.
GOOD: Addressing a public challenge by defending your decision-making process and redirecting to the appropriate forum. The goal is not to win the technical argument. The goal is to demonstrate that you have a decision-making process that does not depend on being the smartest engineer in the room.
FAQ
How quickly should I stop coding in my old component?
Immediately for operational work, within six weeks for feature work, and never entirely for architectural guidance until you have developed replacement technical judgment on your team. The problem is not that you code; it is that you code when others could, which signals that your promotion added no value. The specific timeline depends on whether you have promoted or hired someone with credible ownership. Without that person, your withdrawal creates a vacuum, not a development opportunity.
What if my closest former peer now reports to me and we have real friendship history?
The friendship does not end, but its expression at work must change explicitly. The script: “Our friendship lives in a different container than this working relationship. I will not let either of us pretend they are the same, because that is how both get damaged.” Then live it.
The friend who gets favorable project assignment, who hears about decisions early, or whose feedback you handle more delicately than others, is the friend you are sacrificing for temporary comfort. The managers who survive at Amazon are not the ones who were never friends with reports. They are the ones who made the boundary visible and consistent.
How do I know if I am getting this right in the first ninety days?
You will not get direct feedback. The signal is inverse: absence of tests. Former peers stop probing. Your manager stops attending your meetings “just to observe.” Operational reviews stop generating surprises that require your intervention.
The engineering teams adjacent to yours start routing decisions through your team rather than around it. These are lagging indicators. The leading indicator is simpler: in your first thirty days, you should feel uncomfortable in at least three specific conversations where your old self would have been comfortable. If you are not actively trading comfort for clarity, you are not managing. You are waiting to be found out.amazon.com/dp/B0GWWJQ2S3).