7 Reasons Why Feedback Matters More Than Practice in Interview Prep
Stop believing the myth that practice makes perfect—it doesn’t. Practice without feedback makes permanent mistakes. If you’re endlessly rehearsing without knowing what you’re doing wrong, you’re setting yourself up for failure. The truth? Feedback, not practice, is the real key to interview success.
Practice doesn’t make perfect—it makes permanent.
If you’re practicing the wrong way, every repetition only solidifies your mistakes.
The key to interview success isn’t just more practice—it’s the right feedback.
I would know because as a senior Engineering Leader at Amazon, I have coached and mentored 1000+ people in the last decade at Amazon and beyond.
1. Is Practice Making Your Mistakes Permanent?
Repetition without reflection can solidify errors. Are you practicing, or just perfecting bad habits?
Imagine you’re rehearsing for an interview, answering common questions repeatedly. You feel prepared because you’ve memorized your responses. But in reality, no one has told you that your answers lack depth, fail to showcase your achievements, or meander off-topic.
Practice alone reinforces bad habits: If you consistently structure your answers poorly, repetition will only make those mistakes permanent.
Blind spots remain hidden: Without a fresh perspective, you won’t know if your tone sounds arrogant, your examples lack relevance, or your storytelling fails to connect with the interviewer.
A case in point: A candidate once spent hours rehearsing responses for behavioral questions. They practiced alone, confident in their ability to explain past successes. But in the actual interview, they realized too late that their responses came across as rehearsed and insincere. Practice had ingrained, not improved, their approach.
2. Why Feedback is Your Secret Weapon
Feedback uncovers blind spots and shows you where to focus. Are you practicing with a purpose or in the dark?
Now picture a different scenario. After your first mock interview, a coach points out that your responses are vague. They suggest specific examples, help you structure answers using the STAR method, and advise you to focus on impact rather than process. You rework your answers, practice again, and this time, they shine.
Feedback identifies blind spots: A mentor or peer can tell you where your responses lack clarity or confidence.
It sharpens focus: Constructive criticism helps you prioritize what matters most to interviewers—outcomes and ownership.
Consider this: Feedback from a single mock interview helped one candidate pivot from general anecdotes to targeted stories showcasing leadership. The difference? They landed the job, and their interviewer later cited their clarity and confidence as standout traits.
3. Mock Interviews: Your Best Training Ground
Want to prepare for the real thing? Mock interviews expose weaknesses and build resilience under pressure.
Think about the nerves that creep up before an interview. Mock interviews are the rehearsal space where those jitters are tamed, and mistakes are caught before they matter most.
Simulate real pressure: A mock interview replicates the actual setting, preparing you for the stress of the moment.
Reveal weaknesses: In one session, you might realize you freeze on technical questions or struggle with behavioral ones. Better here than in the real deal.
Consider this: A student once practiced solo for weeks but couldn’t handle live follow-ups in their first mock session. With feedback, they adapted, building the composure to think on their feet—a skill that clinched their next interview.
4. Always Ask: What Did I Do Wrong?
Don’t leave an interview without learning something. Feedback after failure is the fastest path to success.
Interviews aren’t a one-and-done event. Each one is an opportunity to grow, but only if you’re open to learning from it.
Post-interview feedback matters: Even if you don’t get the job, ask for feedback. What went well? What didn’t?
Create a feedback loop: Continuously improve with every attempt.
Consider this: A candidate who consistently requested feedback after interviews improved their STAR responses over time. What began as rambling answers transformed into concise narratives, each iteration inching closer to perfection.
5. Practice Without Feedback? Stop Wasting Your Time
Practice only works when paired with direction. Are you improving—or just spinning your wheels?
Repetition is only valuable if it’s paired with reflection. Feedback doesn’t just tweak your approach—it overhauls it when necessary.
Practice without direction is wasted effort: Spending hours on ineffective answers just reinforces bad habits.
Feedback accelerates improvement: A 10-minute critique can highlight what hours of practice miss.
Consider this: One engineering candidate discovered through feedback that their technical explanations were overly detailed. After adjusting, their responses became precise, impressing the panel with clarity rather than complexity.
6. Learn from the Best: Feedback is Essential
The world’s top performers, from Bill Gates to Elon Musk, credit feedback as their key to growth. Are you taking their advice?
Bill Gates said it best: "We all need people who will give us feedback. That’s how we improve." Leaders across industries agree that feedback is the foundation of success.
Ken Blanchard calls feedback 'the breakfast of champions.'
Elon Musk emphasizes its necessity for innovation: "A feedback loop is critical to think about how you can improve."
If the world’s most successful people rely on feedback to refine their approaches, why would interviews be any different?
7. Combine Feedback with Practice for Results
It’s not one or the other. Feedback shapes your practice; practice locks in your improvements. Are you balancing both?
It’s not an either-or scenario. The real magic happens when feedback and practice work together.
Feedback refines your approach: It tells you what to focus on.
Practice solidifies improvements: It ensures you’re ready when it matters.
Consider this: A software engineer preparing for a big tech interview used feedback from mock sessions to tailor their preparation. They practiced hard, but only on the areas identified as weaknesses. The result? They breezed through technical and behavioral rounds, securing a dream offer.
Always Remember: Feedback transforms practice from a shot in the dark to a targeted journey toward excellence. It sharpens, directs, and accelerates growth, making it the single most critical factor in interview preparation success.
What are you waiting for? Take action. Now.
Schedule a FREE 30-minute consultation. To unlock the full potential of your career, signup for monthly mentorship at 40% discount.
Why Your Mentor Isn’t Helping: 5 Coaching Frameworks Every Mentee Should Demand
Most mentors suck. Not because they don’t care, but because they lack structure. If your mentor isn’t using these 5 coaching frameworks, they’re winging it—and so are you.
Don’t settle for generic advice—demand a mentor who transforms potential into results.
Top 5 Coaching Frameworks Every Mentor Should Master
Great mentorship isn’t about giving answers—it’s about asking the right questions and guiding others to find their own solutions. Over the years, I’ve found that successful coaching relies on frameworks that provide structure while leaving room for flexibility. Let me share the top five coaching frameworks I believe every mentor should master, along with real stories that demonstrate their impact.
GROW Model
The GROW model—Goal, Reality, Options, and Way forward—is a classic for a reason. I remember coaching Sarah, a young professional overwhelmed by too many career options. She wanted to switch industries but didn’t know where to start. We began by defining her goal: to transition into tech within six months. Then, we explored her reality—her current skills and experience weren’t aligned with the roles she wanted. Next, we brainstormed options, from taking online courses to leveraging her network. Finally, we set actionable steps. By breaking the process into these clear phases, Sarah gained focus and confidence. Six months later, she landed a role in her dream industry.
Situational Leadership
One size does not fit all in coaching. The Situational Leadership framework emphasizes adapting your approach based on the individual’s development level. Take Raj, for example, a mentee who was new to management. At first, he needed clear direction and hands-on guidance. But as he grew more comfortable, my role shifted to providing support and encouragement. Eventually, he became highly competent and needed little intervention. Understanding when to lead, coach, or delegate is crucial to empowering mentees at every stage of their growth.
Solution-Focused Coaching
Sometimes, people get stuck focusing on problems instead of possibilities. I remember working with Elena, who was frustrated by a difficult boss. Instead of dwelling on what wasn’t working, I used solution-focused coaching to shift her perspective. I asked, “What would a successful relationship with your boss look like?” That simple question opened a floodgate of ideas. She identified actions she could take to improve communication and align on expectations. Within weeks, her relationship with her boss improved, and her overall performance soared. Focusing on solutions unlocks progress.
Feedback Framework
Constructive feedback can make or break a coaching relationship. I use a simple framework: Start with strengths, address areas for improvement, and end with encouragement. One mentee, James, struggled with public speaking. After a presentation, I told him, “You explained the concepts clearly, which shows your strong understanding. One area to improve is maintaining eye contact—it will make you more engaging. I know you have what it takes to captivate an audience with a little practice.” This balanced feedback motivated James to work on his weaknesses without feeling discouraged. He later gave a stellar presentation that earned praise from his team.
Growth Mindset Coaching
Carol Dweck’s growth mindset principles have profoundly shaped how I mentor. I worked with Maria, a mentee who believed she wasn’t good at coding. She often said, “I’m just not cut out for this.” I reframed her thinking by emphasizing progress over perfection. “You’re not there yet,” I told her, “but every mistake you make is teaching you something new.” Over time, Maria started to embrace challenges as opportunities to grow. She persisted, practiced, and eventually excelled. Encouraging a growth mindset helps people see failure as a stepping stone to success.
Each of these frameworks has its strengths, but what they all share is a focus on guiding people to their own insights and solutions. Mentorship isn’t about being the hero of someone’s story—it’s about helping them become the hero of their own.
Mastering these coaching frameworks doesn’t just make you a better mentor. It transforms the people you mentor, helping them achieve results they never thought possible. The real measure of success in mentorship is the impact you leave on others, and these frameworks provide the foundation for that impact. Start mastering them today and watch the ripple effect unfold.
What are you waiting for? Take action. Now.
Schedule a FREE 30-minute consultation. To unlock the full potential of your career, signup for monthly mentorship at 40% discount.
Lessons from 100+ mentorings: Stop blaming the system, and start achieving your goals
Landing your dream job isn’t about luck—it’s about clarity, preparation, and ownership. Discover how 100+ professionals transformed their careers with LeaderHub through mentorship and practical steps that you can start applying today.
Stop blaming the system. I mentored 100+ people landing dream jobs and leapfrogging their career in the last decade because they took action—what’s your excuse?
When I began mentoring, I thought it was about sharing knowledge. What I discovered was far deeper. It wasn’t about just teaching skills; it was about helping people uncover their potential. That’s the heart of transformation—unlocking what’s already within someone. Along the way, I’ve helped over 300 professionals land their dream jobs. Here’s what I’ve learned, and the stories that have stayed with me.
1: Confidence begins with clarity. I once mentored a software engineer, Amelia, who felt stuck in her role. She had the technical skills but couldn’t figure out why she wasn’t moving forward. In our first session, I asked her, “What’s your dream job, and why does it excite you?” She couldn’t answer. Most people think they lack skills, but what they really lack is direction. We spent weeks narrowing down her goals and finding the “why” behind her aspirations. Once she had clarity, it was like flipping a switch—her confidence soared, and she began taking deliberate steps toward roles that aligned with her passion. Clarity transforms uncertainty into purpose.
2: Success loves preparation. I remember working with Vipul, who kept getting rejected after final-round interviews. Frustrated, he said, “I don’t know what I’m doing wrong.” Together, we dissected his interview technique. He was winging it, hoping his charm and technical knowledge would carry him. I told him, “You don’t rise to the occasion; you fall to the level of your preparation.” We practiced every possible question, breaking it down to ensure he delivered concise, confident answers. The next time he interviewed, he landed the job. Rehearsing like it’s game day isn’t optional—it’s essential.
3: Growth thrives on feedback. Feedback can be tough to hear. Tatiyana, a marketing professional I mentored, struggled with taking critique. She’d bristle at suggestions, believing they undermined her abilities. During a review session, I pointed out a critical flaw in her presentation and noticed her defensive body language. I paused and said, “Feedback isn’t criticism—it’s an investment in your growth.” That moment shifted her mindset. Over time, she became eager for constructive input and used it to refine her work. Eventually, she landed her dream role leading a team of her own. When you embrace feedback, you unlock your potential.
4: Relationships open doors skills can’t. Early in my career, I mentored Sanjeev, who was brilliant but shy. He thought networking was about attending events and collecting business cards. I challenged him to build genuine connections instead. I told him, “Your skills will get you noticed, but relationships will get you hired.” We role-played networking conversations, and I encouraged him to reach out on LinkedIn with personalized messages. One meaningful connection led to a conversation, which led to a referral, which led to the job he’d been chasing for years. Networking isn’t about quantity—it’s about quality.
5: Ownership is everything. One of the most inspiring mentees I’ve worked with was Maya. She was stuck in a role she didn’t enjoy and blamed the job market for her lack of progress. I told her, “Your career isn’t a lottery ticket—it’s a choice.” That conversation marked a turning point. Maya began taking ownership of her learning, upskilling herself in areas that aligned with her dream job. She rewrote her resume to tell a compelling story of her achievements and practiced pitching her value in interviews. Within months, she secured her dream role, not because of luck, but because she took charge.
Helping people transform their careers isn’t about handing them answers—it’s about helping them uncover their strengths, build their confidence, and take ownership of their paths. Each of these stories reminds me that mentorship isn’t just about jobs—it’s about changing lives.
If over 100 people can achieve their dreams by unlocking their potential, imagine what’s possible for you. Take action today, and you’ll look back knowing you didn’t just land a job—you transformed your future. The next success story could be yours.
What are you waiting for? Take action. Now.
Schedule a FREE 30-minute consultation. To unlock the full potential of your career, signup for monthly mentorship at 40% discount.
Stop Being a Yes-Man: The Truth About Why Trust Builds Fortunes
Yes-men don’t build trust, they build mediocrity. If you’re too scared to speak up, too soft to challenge bad ideas, or too flaky to deliver on your promises, don’t expect anyone to rely on you when it matters. At Amazon—and in life—trust isn’t given, it’s earned. And being blunt, honest, and reliable is how you rise to the top.
Let’s be real: trust is one of those things everyone says they want, but few people actually know how to build. It’s like the gym membership of leadership principles—great in theory, ignored in practice.
Yet at Amazon, Earn Trust isn’t just some corporate buzzword plastered on a wall. It’s a daily, often awkward, sometimes humbling commitment that separates great teams from dysfunctional ones.
Here’s the kicker: trust isn’t about being everyone’s best friend or playing nice at meetings. It’s about saying, “Yeah, I screwed up,” when you did. It’s about calling out a bad idea, even if it makes things uncomfortable. And it’s about doing what you said you would, every damn time, no matter how inconvenient it gets.
At Amazon, “Earn Trust” shows up in unexpected ways. It’s the VP who admits in front of their team that their strategy bombed and needs rethinking. It’s the junior engineer who challenges a flawed plan in a room full of senior leaders, backed by solid data. It’s not always pretty, but it works. And if you can master this, you’ll not only thrive at Amazon—you’ll thrive anywhere.
In this post, we’re going to break down Earn Trust—what it really means, why it matters, and how you can start practicing it in your own life. No fluff, no corporate jargon. Just practical lessons, a few battle-tested tips, and one or two cringe-worthy mistakes to learn from. Let’s dive in.
Do they ask this in the interviews?
Yes. Amazon-wide for all L4+ and roles.
Question:
“Tell me about a time when you disagreed with a team member or leader’s opinion. How did you handle it, and what was the result?”
Reasonable Answer:
“In one project, a colleague suggested a solution that I believed wasn’t scalable. I shared my concerns in a team meeting and explained why I thought we should explore alternatives. The team considered my input, but we ultimately went with the original plan. While I disagreed, I respected the decision and supported the implementation.”
Let’s analyze this response:
✅ Shows willingness to voice concerns.
❌ Lacks details on how the disagreement was handled.
❌ Doesn’t show how trust was maintained or built during the process.
❌ Misses the impact of the actions on the team or the project outcome.
Better Answer:
“During a system redesign project, a senior team member proposed an approach to improve performance. While their idea was interesting, I noticed it didn’t address potential scalability issues, especially for future customer growth. I scheduled a one-on-one discussion with them first to avoid calling them out in front of the team. I explained my perspective with data from previous projects, highlighting where similar approaches had failed under high traffic. I asked thoughtful questions to better understand their rationale and shared alternative solutions that could meet both short- and long-term goals.”
“In the next team meeting, I respectfully raised my concerns and shared the data I’d gathered. To my surprise, other team members also voiced similar doubts, leading to a collaborative discussion. Together, we refined the proposal, ultimately integrating parts of both approaches into a scalable solution. By addressing the issue respectfully and with evidence, I not only helped the team avoid potential pitfalls but also strengthened trust with the senior team member. They later thanked me for challenging their idea in a constructive way.”
Why This Works:
✅ Demonstrates respectful and thoughtful communication.
✅ Uses data to back up concerns and drive the discussion.
✅ Maintains trust through one-on-one conversations and a collaborative approach.
✅ Highlights a positive outcome and improved team dynamics.
What does it mean in practice?
Here’s the deal: trust isn’t about handshakes, smiles, or playing office politics. It’s about showing up, owning your crap, and delivering results. At Amazon, it’s the glue that keeps teams running at a thousand miles an hour without falling apart.
“Earn Trust” means:
- Listen like you give a damn. Don’t just wait for your turn to talk—actually hear people out.
- Speak the truth. Even when it’s awkward. Even when it sucks. Say it straight, but with respect.
- Own your mistakes. Seriously, stop the blame game. If something’s broken, call it out and fix it.
- Do the thing you promised. No excuses, no drama—just get it done.
And here’s the kicker: it’s not about agreeing on everything. Disagreeing respectfully? That’s trust in action. Because when people know you’re honest, reliable, and self-critical, they’ll trust you—even when you challenge them.
Social cohesion
Let’s talk about a dirty little secret of teamwork: social cohesion isn’t always your friend. Yeah, you heard that right.
Jeff Bezos himself has said it—too much “getting along” can kill a team’s ability to solve real problems. Why? Because when everyone’s too afraid to rock the boat, bad ideas sail straight to failure.
Here’s the deal: a team that prioritizes harmony over honesty becomes a yes machine. Nobody speaks up. Nobody questions the obvious flaws. Everyone nods along to avoid the awkwardness of disagreement. And then what? You build the wrong product. You chase the wrong metrics. You solve the wrong problem.
At Amazon, challenging opinions isn’t just encouraged—it’s essential. When done respectfully, pushing back sharpens ideas, uncovers blind spots, and forces everyone to think deeper. The best teams thrive on friction, not fake smiles.
So, let me ask you this: would you rather hurt someone’s feelings for five minutes or let your entire team waste months solving the wrong problem? Tough love might sting, but it saves lives—okay, maybe just careers—but you get the point. Challenge the idea. Fix the problem. Move forward.
How to Apply This in Your Team (Without Causing a Riot)
Alright, you’re sold on the idea of challenging opinions. But how do you do it without turning your team into a battlefield? Here’s your playbook:
- Start with respect. Challenge the idea, not the person. It’s not about proving someone wrong—it’s about finding the best solution.
- Ask the hard questions. Don’t just nod along. Dig deeper. “Why do we think this will work?” “What’s the data to back it up?” Make questioning a habit.
- Create a safe space. Let your team know it’s okay to disagree. Reward people who speak up, even if their ideas don’t always land.
- Model it yourself. Admit when you’re wrong. Show that being challenged doesn’t threaten you—it helps you grow.
- Focus on the outcome. Keep the end goal in sight. This isn’t about who’s right—it’s about what’s right for the team and the customer.
Want a high-performing team? Teach them that challenging ideas is a sign of respect, not rebellion. That’s how you turn social cohesion into productive collaboration.
Why “Earn Trust” Is the Secret Sauce for Success
Here’s the harsh truth: nobody trusts a yes-man. You know the type—the person who nods at everything, avoids conflict like it’s the plague, and sugarcoats feedback to the point of uselessness. Sure, they’re easy to work with, but when it really matters—when the stakes are high, and you’re staring down a tough decision—do you turn to them for advice? Hell no.
At Amazon, and honestly, in real life, trust is built on two things: truth and guts. People trust you when you’re honest, even when it’s uncomfortable. They trust you when you have the courage to say, “This won’t work,” or, “Here’s where we’re failing.” Because when the stakes are high, nobody wants someone who says what they think you want to hear. They want someone who tells it like it is, no matter how much it stings.
Think about it: When you need real feedback, do you go to the person who sugarcoats everything? Or do you go to the blunt friend, the one who calls out your BS and tells you exactly what needs to change? Exactly. That’s why “Earn Trust” isn’t just crucial for Amazon—it’s a life skill. Being honest and reliable earns you a reputation as the person who gets sh*t done and makes others better.
The bottom line? Yes-men fade into the background. Truth-tellers rise to the top. If you want people to trust you—not just agree with you—get real, speak up, and start delivering. Trust isn’t given. It’s earned.
Conclusion
At Amazon—and in life—trust isn’t handed out like candy. It’s earned through your actions, your honesty, and your ability to show up when it matters most. Leaders who listen intently, speak candidly, and deliver consistently are the ones who build lasting relationships and drive meaningful results.
If you want to succeed, stop aiming to please and start aiming to be trusted. Be the person who challenges bad ideas with respect, admits mistakes without excuses, and backs every claim with action. That’s how you earn trust.
And here’s the real kicker: once people trust you, they’ll follow you. They’ll rely on you. They’ll come to you when things are falling apart because they know you’ll be honest, reliable, and real. That’s not just a leadership principle—it’s a superpower. Earn trust, and you’ll do more than succeed. You’ll lead.
- If you want to know more about this topic, signup for Office Hours
- If you have an interview lined up, schedule a mock interview
- If you need guidance to succeed in your current role and get promoted, or prepare to switch, signup for monthly mentorship
Nail Your Amazon Interview by Mastering the Art of Ownership
You want to ace your Amazon interview? Then stop acting like an employee and start thinking like an owner. Ownership isn’t just a buzzword—it’s the mindset that separates “meh” candidates from unforgettable ones. In this post, we’re breaking down what it takes to prove you’ve got what it takes to lead, not just follow.
Imagine you’re in the middle of a high-stakes project, and suddenly, a critical component fails.
All eyes turn to you.
In that moment, true ownership emerges taking full responsibility to drive solutions.
Cultivating this mindset within your organization transforms challenges into opportunities and propels both individual and collective success.
Here’s how to embed a culture of ownership in your team.
This post is for you—anyone looking to not just survive Amazon’s behavioral interviews but to crush them.
We’ll unpack what ownership actually looks like, break down a sample question with real-world examples, and teach you how to dig into your experience to craft a bar-raising answer.
By the end, you won’t just understand what ownership means—you’ll live and breathe it. Let’s get started.
A brief summary of Ownership at Amazon
In the previous post, we explained Ownership. Here's a quick summary:
Ownership is about taking full responsibility for outcomes, not just tasks, and thinking beyond your immediate role to drive meaningful results. It’s a mindset that prioritizes long-term impact, accountability, and a relentless focus on making things better for the organization as a whole.
Ownership means responsibility: You don’t wait for someone to hand you a solution—you find the problem, own it, and solve it.
Think long-term: Owners don’t chase short-term wins at the cost of lasting impact. They invest in sustainable outcomes.
Act on behalf of the whole: Ownership isn’t confined to your team or role. It’s about doing what’s best for the organization as a whole.
Drive results, not excuses: Owners take accountability for outcomes, whether they succeed or fail. They don’t pass the buck.
Empower others: True ownership inspires collaboration and creates momentum that extends beyond individual contributions.
Amazon is always looking for leaders like you
Think about it: companies like Amazon are looking for leaders, not task-doers.
When you demonstrate ownership, you show that you don’t just follow orders; you take initiative, solve problems, and create value. It’s the difference between saying, “I did what was asked,” and saying, “Here’s how I made a lasting impact.”
Ownership tells the interviewer that you think like a founder, not just an employee—that you’re someone who doesn’t wait to be told what to do but steps up to lead. And leaders, whether they’re engineers or managers, are exactly who Amazon is looking for.
What does it look like during an interview?
The interviewer leans forward, pen ready, and asks, “Tell me about a time when you were responsible for delivering a project, and things didn’t go as planned. What did you do to ensure success?”
Now, this isn’t just a question—it’s a mirror. They want to see how you own your responsibilities, especially when the stakes are high.
Did you step up, adapt, and drive the project to completion, or did you let obstacles define the outcome?
Ownership here isn’t about playing the hero; it’s about showing resilience, accountability, and the ability to lead through challenges.
This is your chance to prove that you don’t just handle tasks—you see them through, no matter what.
Scenario 1
The candidate sits back, thinking for a moment before responding, “Well, there was a time when I was managing a system migration project. Things didn’t go as planned because some dependencies weren’t ready on time. I escalated the issue to my manager and waited for them to address it. Eventually, the dependencies were resolved, and we completed the migration, but it took longer than expected.”
The interviewer nods but doesn’t write much.
The candidate’s answer feels safe, uninspired.
They acknowledged the problem but offered no evidence of initiative, no spark of ownership. It’s a flat response because it leaves the story incomplete—what could they have done differently? How did their actions influence the outcome?
Ownership isn’t just identifying a problem; it’s actively driving the solution.
This answer simply shows someone following the script, not owning the story.
❌ No Initiative: The candidate identified the problem but stopped at escalation, showing no effort to address or resolve the issue independently.
❌ Lack of Ownership: They deferred responsibility to their manager, missing an opportunity to demonstrate accountability and leadership.
❌ No Impact or Results: The answer provides no evidence of meaningful action or outcomes, leaving the impression of passivity rather than proactivity.
Scenario 2
The candidate straightens up, nodding as they recall the scenario.
“During a system migration project, some dependencies weren’t ready on time, which delayed our timeline. I flagged the issue to my manager and also reached out to the team responsible for the dependencies to understand the roadblocks. I offered some suggestions to help them prioritize our requirements and coordinated daily check-ins to track progress. Eventually, we got the dependencies ready and completed the migration a few weeks behind schedule, but I made sure to minimize the delays as much as possible.”
The interviewer jots down a few notes, acknowledging the effort. It’s a decent answer—the candidate showed awareness of the issue, took some initiative by communicating with other teams, and helped keep things moving.
However, it stops short of being memorable.
The candidate acted within the expected boundaries of their role, but there’s no indication of going above and beyond to truly own the outcome.
It’s a story of responsibility, not leadership.
✅ Some Initiative: The candidate communicated with the dependency team and provided suggestions, showing an effort to address the issue.
✅ Collaboration: Demonstrated teamwork by coordinating with others to minimize delays.
❌ Limited Ownership: Relied on established processes without fully taking responsibility for the outcome.
❌ No Long-Term Solution: Focused only on immediate fixes without addressing the root cause of the delay.
❌ Minimal Impact: The answer lacks significant results or measurable improvements, making it less memorable.
Scenario 3
The candidate leans forward and begins confidently:
“During a critical system migration project, we encountered a significant roadblock when key dependencies from another team weren’t delivered on time. This delay jeopardized not just our timeline but also the success of downstream systems reliant on the migration. I knew this wasn’t just a problem to report—it was one to own.”
[Situation] The migration project had multiple interconnected dependencies. One of the key teams responsible for delivering crucial components missed their deadlines, putting the entire project at risk. Without immediate action, the delay would cascade, impacting other teams and systems.
[Task] As the lead for the migration, it was my responsibility to ensure the project’s successful delivery. This meant finding a way to manage the immediate impact of the delay while addressing the systemic issues causing it, all without compromising quality or creating additional risks.
[Action] First, I met with the dependency team to diagnose the root cause of the delay. It turned out that misaligned priorities and unclear communication between teams had caused the issue. I worked with them to reprioritize their deliverables and identify quick wins to unblock our work.
Next, I reorganized our team’s timeline to focus on tasks that didn’t rely on the delayed dependencies. Simultaneously, I developed a temporary workaround, enabling us to test and progress other aspects of the migration without waiting for the missing components.
Finally, I proposed and implemented a long-term fix. I introduced a dependency-tracking system in our project management tool, ensuring that all teams could flag risks earlier. I also initiated bi-weekly cross-team syncs to maintain better alignment and transparency on future projects.
[Result] The project was delivered just one week behind schedule, avoiding major disruptions to downstream systems. More importantly, the new tracking system and communication processes became organizational standards, reducing dependency-related delays by 40% in subsequent projects. These changes set up the entire organization for smoother, more efficient project execution in the future.
“By taking ownership of the problem, I ensured the project’s success while driving systemic improvements that benefited the entire organization.”
Now, what do you think of this response?
Why this answer works?
✅ Proactive Problem-Solving: The candidate takes initiative to address the issue at both the immediate and systemic levels.
✅ Balanced Approach: Tackles the current problem while implementing changes that prevent similar issues in the future.
✅ Clear Use of STAR: The response is structured and concise, making it easy for the interviewer to follow.
✅ Quantifiable Results: Demonstrates measurable success with reduced delays and increased organizational efficiency.
✅ Leadership and Ownership: Reflects taking full accountability, acting beyond the role’s basic requirements, and influencing the broader organization.
✅ Alignment with Amazon’s Principles: Embodies the ownership mindset Amazon values, showing the ability to think long-term and act on behalf of the entire company.
The takeaway
Here’s the deal: If you want to stand out, if you want that job, you’ve got to show up like you’re already part of the team.
Take responsibility.
Drive results.
Solve problems like it’s your company on the line—because that’s the mentality they’re looking for.
But here’s the kicker: This isn’t just about landing a job at Amazon. It’s about how you approach your entire career.
Ownership is what separates the good from the great. It’s how you create opportunities, build influence, and make an impact.
So stop playing small. Take this mindset, own it, and start making moves—whether it’s for your dream job or your dream life. Let’s go! 🔥
Before you go…
Don’t forget to signup for my newsletter below to stay in touch.
Don’t forget to signup for LeaderHub weekly Office Hours if you want to know more about Engineering Leadership.
You can also book a FREE 30-minute consultation to ask any question you may have about a career at Amazon, Meta, or Google.
Why ‘That’s Not My Job’ Is Killing Your Career
What if the key to unlocking your career potential was a simple shift in mindset? At Amazon, leaders don’t wait to be told what to do—they take ownership, solve problems, and drive results. Whether you’re an executive or an engineer, learning to think like an owner can redefine your impact and set you apart. Ready to ditch the “that’s not my job” attitude? Let’s dive into what ownership really means—and why it’s the secret weapon you’ve been missing.
In the wild, a wolf pack thrives not because of the strength of its leader, but because each member takes responsibility for the survival of the group.
The scout ventures ahead to find prey, the sentry watches for danger, and the rest align to ensure the pack moves as one. This natural instinct to “own the mission” is what keeps the pack alive. In business, it’s no different.
Companies like Amazon succeed because they’ve embedded this principle of ownership into their culture—encouraging every individual, regardless of rank, to think not as employees but as stewards of the entire organization.
Ownership is the glue that turns individuals into teams and teams into movements.
My Story Behind Building Momentum from the Ground Up
Ownership is an attitude.
It is a relentless commitment to making something better.
It’s stepping into a situation, no matter how chaotic or uncertain, and saying, “This is mine to fix.”
When I joined one of Amazon’s core data teams in the summer of 2021, that’s exactly what I decided to do. The team, contributing to open source, was struggling for relevance in a sea of priorities. We were adrift, lacking direction and clarity. So, I took ownership.
The first step was asking the uncomfortable but necessary questions: Why does this team exist? What value do we provide?
Together, we crafted a team charter that defined our mission, tenets, and purpose—a compass for everything we’d do moving forward. Ownership, at its core, is about creating clarity where there is none.
With this foundation, we tackled the next challenge: operations. It wasn’t glamorous work. Defining release and support policies and streamlining workflows isn’t the stuff that makes headlines, but it’s what allowed us to move faster, innovate independently, and stay ahead. We stopped waiting for the rest of the organization to dictate our pace. Ownership means not just solving problems but anticipating them and building systems that eliminate them entirely.
Once the basics were in place, it was time to think bigger.
In sales, they call it lead generation; for us, it was socializing our purpose across Amazon. We didn’t wait for recognition—we earned it. We doubled our open-source contributions year-over-year and shared our innovations with anyone who would listen. Month by month, we built momentum. And as that momentum grew, so did the attention from executive leadership.
Suddenly, our team wasn’t just relevant—it was indispensable.
The projects we tackled were no longer minor contributions but groundbreaking solutions to problems a Distinguished Engineer once described as “unsolved for the last 40 years.” We didn’t achieve this by staying in our lane. I took on roles far outside my job description: program manager, product manager, technical evangelist, even a sales and marketing rep. Ownership isn’t about doing what’s expected; it’s about doing what’s needed.
This is the essence of Amazon’s ownership principle.
It’s not about perfection or even control—it’s about responsibility.
When leaders take ownership, they empower their teams to expand their scope and influence, not just within the organization but in the broader world. Ownership doesn’t just build better teams or better products. It builds momentum—and momentum changes everything.
Leaders are owners, they aren't told what to do
At Amazon, the idea that “leaders are owners, they aren’t told what to do” is a powerful declaration of autonomy and accountability.
It flips the traditional command-and-control model on its head, placing the responsibility for initiative squarely in the hands of individuals.
Ownership means that leaders don’t wait for direction; they assess the landscape, identify opportunities, and act decisively.
This mindset fosters a culture where every leader feels empowered to make decisions as if they owned the company themselves.
In practice, it’s what allows Amazon to scale innovation—because when leaders take responsibility without needing explicit instructions, they create a ripple effect of accountability and forward motion across teams.
It’s the difference between a stagnant organization waiting for top-down directives and a dynamic one that thrives on bottom-up innovation.
What does it mean for Amazon?
Amazon’s “Ownership” principle isn’t just corporate jargon—it’s a fundamental ethos that permeates the company’s operations. Leaders at Amazon are expected to act on behalf of the entire company, think long-term, and never say, “that’s not my job.” 
This mindset has tangible impacts. For instance, when Amazon decided to enter the cloud computing market, it wasn’t a direct extension of their retail business. However, employees took ownership of the initiative, leading to the creation of Amazon Web Services (AWS), which now contributes significantly to Amazon’s revenue.
Moreover, the “Ownership” principle fosters a culture where employees proactively address issues beyond their immediate responsibilities. This approach not only accelerates problem-solving but also drives innovation, as individuals feel empowered to implement solutions without waiting for directives.
However, this high level of ownership can have downsides. It may lead to burnout, as employees might overextend themselves trying to manage multiple responsibilities. Additionally, without clear boundaries, there’s potential for role confusion and inefficiencies.
In essence, Amazon’s emphasis on ownership cultivates a proactive and innovative workforce, but it’s crucial to balance this with support systems to mitigate potential drawbacks.
What Does Ownership Mean for Engineers and Individual Contributors
At Amazon, all employees, including people managers are LEADERS.
For engineers and individual contributors, ownership is about how they approach their work and the problems they solve.
It’s stepping beyond the boundaries of “what’s in my job description” and thinking, “What can I do to make this better?”
Let me share a story to illustrate.
Imagine a developer tasked with maintaining an internal tool that automates reporting. The tool works, but it’s slow and clunky, and no one loves using it. Instead of just patching bugs and moving on, they dig deeper.
They rewrite the codebase for efficiency, optimize the database queries, and even add a dashboard to make the tool more user-friendly.
Then they go a step further: they reach out to the teams using the tool, gathering feedback and iterating based on what they learn.
Months later, that once-overlooked tool becomes a critical part of the workflow, saving hours for dozens of teams. That’s ownership.
Here’s another example.
A junior engineer notices that their team’s deployments frequently fail due to inconsistent configurations.
While it’s not technically their responsibility, they take the initiative to automate configuration validation as part of the CI/CD pipeline.
The result?
Fewer failed deployments, less downtime, and more confidence across the team. Ownership here looks like fixing systemic issues, not just treating symptoms.
For individual contributors, ownership often means being proactive about identifying problems and opportunities.
It’s about not waiting for permission to improve things that matter. It means thinking like a stakeholder—anticipating needs, understanding the bigger picture, and delivering work that aligns with the organization’s goals.
Ownership doesn’t just make engineers better at their jobs; it amplifies their impact, turning small actions into long-lasting contributions.
Does it mean I do everything myself?
No. It does not.
Ownership is not micromanagement, martyrdom, or an excuse to hoard responsibilities.
It doesn’t mean doing everything yourself, refusing help, or burning out in the name of accountability.
True ownership is about driving outcomes, not controlling every input. It’s not about ignoring boundaries or taking on tasks outside your expertise to prove a point; it’s about ensuring those tasks are completed effectively, even if that means delegating or collaborating.
Ownership isn’t a license to override processes or act unilaterally—it thrives within a framework of trust, transparency, and teamwork.
Simply put, ownership is about responsibility, not ego. It’s not about saying, “I did it all,” but rather, “I ensured it got done, and done well.”
Before you leave
Ownership is a mindset that can transform teams, drive innovation, and create lasting impact.
Whether you’re an executive, a manager, or an individual contributor, adopting an ownership mentality empowers you to take control, think long-term, and deliver results that matter.
It’s about stepping up, not because someone asked you to, but because you see an opportunity to make things better.
Now it’s your turn.
Reflect on your work—are you approaching it as a task to complete, or as something you own? Start by identifying one area where you can take more responsibility, fix a recurring problem, or drive a meaningful change.
Share this post with your team and challenge them to do the same. Ownership isn’t just about what you do—it’s about the culture you create. Take action today, and watch how it inspires those around you.
Don’t forget to signup for my newsletter below to stay in touch. Why? Because, I have a passion of writing posts like this that will culminate in a polished giveaway — just as a token of appreciation for your time and most importantly to help advance your career. You, my reader, are the reason we exist.
Don’t forget to signup for LeaderHub weekly Office Hours if you want to know more about Engineering Leadership.
You can also book a FREE 30-minute consultation to ask any question you may have about a career at Amazon, Meta, or Google.
Adopt a Customer-Obsessed Mindset in 7 Bold Steps
“Why does your engineering team exist? It’s not to write code or hit deadlines—those are outcomes, not purpose. Your team exists to solve problems for the customer, to make their lives easier, better, or more enjoyable. Yet too many teams lose sight of this. They focus on the What—shipping features, closing tickets—without asking Why. The truth is, if you don’t know your team’s purpose, how can you expect them to deliver meaningful work?
Customer-first thinking isn’t just a nice-to-have; it’s the foundation for innovation. When you shift your focus to the people using your product, everything changes. Decisions become clearer, priorities align, and your team works not just with skill, but with intent. That’s how you build trust. That’s how you deliver value. And that’s where real success begins.”
If your engineering team isn’t obsessed with the customer, you’re not innovating—you’re just keeping busy.
If you’re an Engineering Manager or Director, this might sting a little. You pride yourself on your team’s technical prowess and ability to deliver, but here’s the hard truth: Without a relentless focus on the customer, all that effort risks being wasted. The best teams—the ones that innovate, adapt, and consistently exceed expectations—don’t just ship code. They solve real problems for real people. So, how can you guide your team to think and act with the customer at the center? Let’s break it down.
In my previous posts, I emphasized the need for customer obsession and how Amazon models this mindset on a daily basis.
Too many teams measure success by how much they build or how fast they deliver. But the truth is, none of that matters if your work doesn’t make a meaningful difference to the people using it. The best teams don’t start with features or deadlines; they start with the customer. And if that’s not how your team operates, it’s time to rethink everything.
1. Start with Why
Every successful product, feature, or service begins with a fundamental question: Why are we doing this? It’s easy to get caught up in the What—the technical requirements, the deadlines, the KPIs—but the most impactful work is always anchored in a clear purpose. For engineering teams, that purpose is the customer.
A Compelling Story to Frame the Problem
Consider the story of a team that launched a revolutionary product but failed to connect with users. Despite cutting-edge technology and flawless execution, the product floundered. Why? They built something for themselves, not for their customers. Contrast this with teams that obsess over understanding their users: They create solutions that resonate, delight, and endure.
The difference between these outcomes lies in starting with Why. Teams driven by a customer-first approach consistently outperform those that focus only on execution.
Why It Matters
At its core, putting the customer first ensures that:
The team’s work is meaningful and impactful.
Priorities align with real-world needs, not internal assumptions.
Every decision contributes to building trust and loyalty with users.
Without this focus, even the best-engineered solutions risk irrelevance. Engineers are problem solvers by nature, but the problems worth solving are the ones that matter to the people you serve.
Reflection for Leaders
As an engineering manager, your role is to help your team connect their day-to-day work to the larger purpose. Ask them:
Who benefits from what we’re building?
How will our work make a difference in their lives?
If we weren’t here, what would our customers lose?
By starting with Why, you inspire your team to think beyond tasks and deliverables. You help them see their work through the eyes of the customer—fostering a deeper sense of ownership, pride, and innovation.
Understanding the Why sets the foundation for everything else. It’s the first step in creating a culture where the customer isn’t just a stakeholder but the driving force behind every line of code, every sprint, and every decision.
2. The Golden Circle Applied to Engineering Teams
When we think about our work as engineers and managers, it’s easy to get caught up in the What—the code, the tools, the features. We obsess over deadlines, performance benchmarks, and how efficiently we’re shipping updates. But none of that truly matters if we lose sight of Why we’re doing it in the first place.
Simon Sinek’s Golden Circle challenges us to flip the script. Instead of starting with What we do or even How we do it, we begin with Why. For engineering teams, that means grounding everything we build in the value it creates for the customer.
Start with Why
The Why for engineering teams is simple but profound: to solve meaningful problems for our customers.
This is more than delivering functional software—it’s about understanding the human at the other end of the process. What challenges do they face? How can we make their lives better, easier, or more rewarding?
Ask your team: “If we disappeared tomorrow, what difference would it make to the people who use our products?”
How We Deliver on the Why
The How is the bridge between the purpose and the execution. Engineering teams can deliver on their Why through:
Customer Empathy: Involve team members in customer interviews or user-testing sessions to connect them directly to real-world pain points.
Iterative Problem-Solving: Use Agile practices not just to iterate on features, but to iterate on value—adapting and refining based on customer feedback.
Aligned Prioritization: Make decisions about what to build based on what has the most impact on the customer, not just what’s technically interesting or quickest to deliver.
The What Becomes Clear
When teams are aligned on their Why and their How, the What becomes a natural extension. Instead of scrambling to meet arbitrary goals, the team creates products and features that reflect a clear purpose.
Features stop being a checkbox for internal roadmaps and start being solutions to real problems.
Performance metrics shift from vanity stats (lines of code, tickets closed) to measurable outcomes like user satisfaction and task success rates.
Does Your Work Reflect the Golden Circle?
When reviewing your team’s current projects, ask:
Can we articulate the Why for this project in one sentence?
Do we know How this work connects to solving a customer problem?
Does the What deliver measurable value for the customer?
The best engineering teams aren’t the ones with the flashiest tech stacks or the quickest deployments. They’re the ones who consistently ask, “Who are we building this for?” and align every line of code, every decision, with their answer.
So, before you dive into the next sprint, take a moment to recalibrate. Start with Why. Everything else will follow.
3. From Vision to Action
Adopting a customer-first mindset isn’t just a policy change—it’s a cultural shift. It starts with a clear vision and flows into everyday actions. As an engineering manager, your role is to guide your team from simply knowing about the customer to truly understanding and prioritizing them.
Paint a Clear Vision
Great leaders inspire by making the future feel tangible. What does success look like when your team puts the customer first? It’s not about shipping faster or implementing trendier technologies; it’s about outcomes that directly improve the customer’s life.
Instead of “We’ll reduce query latency by 30%,” say, “Customers will no longer have to wait when they’re in a hurry to find information.”
Frame technical work as a means to an end—where the end is always the customer.
A vivid vision bridges the gap between technical ambition and customer value. It gives your team a purpose that resonates beyond code.
Reinforce Through Stories
Nothing builds understanding like stories. Share examples where putting the customer first led to exceptional outcomes:
Did a quick pivot based on user feedback save a struggling product?
Was there a feature that initially seemed unnecessary but became a game-changer for users?
Stories humanize the customer and connect your team’s work to real people. Use them often—in meetings, retrospectives, and 1:1s—to ground technical discussions in customer impact.
Model the Behavior
Culture starts at the top. If you want your team to embrace a customer-first approach, you need to demonstrate it yourself:
Take the time to review customer feedback regularly and share insights with the team.
Show curiosity about the customer’s world by attending support calls or sitting in on user testing sessions.
When prioritizing work, openly weigh decisions based on customer impact, even if it means deferring internal goals.
When your actions reflect a commitment to the customer, your team will follow suit.
Make It Real
A vision without action is just wishful thinking. Help your team translate the customer-first mindset into their daily work:
During sprint planning, challenge the team to articulate the customer value of each task.
Celebrate wins that demonstrate customer empathy, like well-received feature updates or bug fixes that solved a major pain point.
Encourage team members to think beyond functional requirements—ask, “What would delight the customer here?”
A customer-first culture doesn’t happen overnight. It’s built through intentional actions, modeled behaviors, and a shared commitment to making the customer the centerpiece of everything you do.
When your team starts seeing their work through the customer’s eyes, it transforms not just what they build, but how they feel about building it. They’ll find purpose in their work—and that’s where innovation thrives.
4. Fostering Customer-First Thinking
Creating a customer-first culture isn’t just about inspiring words—it’s about embedding practices into your team’s workflow that consistently prioritize the customer. Here’s a step-by-step framework you can use to guide your team toward customer-first thinking.
Step 1: Walk in Their Shoes
Empathy is the foundation of a customer-first mindset. To build it, your team needs to step out of the engineering bubble and directly engage with customers.
Conduct Customer Interviews: Invite engineers to join user research sessions or customer calls. Hearing firsthand about customer struggles creates a deep emotional connection to their pain points.
Experience the Product: Encourage your team to use the product as if they were customers. What feels frustrating or unintuitive? What works well?
Shadow Support Teams: Assign engineers to spend a day observing how customer support handles queries. It’s an eye-opening way to understand recurring issues and the stakes of solving them.
Step 2: Align Metrics with Impact
Too often, engineering teams focus on metrics that measure output (e.g., tickets closed) rather than outcomes (e.g., customer satisfaction). Realign team goals to reflect the value delivered to customers.
Replace technical KPIs with customer-centric metrics:
Instead of “Reduce load times by X%,” use “Increase customer retention on feature Y by Z%.”
Track Net Promoter Scores (NPS) or customer feedback ratings as a measure of success.
Use customer impact as the ultimate filter for prioritization. Ask, “Will this work make a noticeable difference to the customer?”
Step 3: Reward Customer-Centric Wins
Behavior that gets recognized gets repeated. Create a culture where actions that prioritize the customer are celebrated.
Call Out Customer Wins: Highlight moments in retrospectives or team meetings when a feature or fix had a big impact on the customer.
Create Recognition Systems: Introduce awards like a “Customer Hero of the Sprint” to recognize team members who go above and beyond to serve customer needs.
Share Feedback: Loop customer success stories or positive feedback directly back to the team. Knowing their work made a difference fuels motivation and purpose.
Step 4: Create a Feedback Loop
A customer-first culture requires constant learning. Build mechanisms to bring the customer’s voice into your team’s daily operations.
Embed Feedback in Processes: Regularly review customer feedback during standups or sprint planning sessions.
Use Customer Data to Drive Decisions: Collect and analyze user behavior data to uncover patterns and areas for improvement. Share these insights widely with the team.
Iterate Together: Establish a rhythm of building, testing, and refining based on customer input. Show the team how feedback shapes decisions.
Make It Part of Your DNA
The best frameworks are sustainable because they integrate seamlessly into existing workflows. Build customer-first practices into the rituals your team already follows:
Add a “Customer Check” to every code review: Does this change improve the user experience?
Start retrospectives with a reflection on customer impact: What did we do last sprint that helped our users the most?
By following this framework, you can transform customer-first thinking from a philosophy into a way of working. Over time, it becomes second nature for your team to prioritize the customer in every decision—and that’s where the magic happens.
Your team won’t just build products; they’ll build solutions that matter. And in doing so, they’ll create something far greater than features or functionality—they’ll create trust.
5. Breaking Old Habits
Shifting to a customer-first culture can encounter resistance. It’s natural—teams are accustomed to established workflows, priorities, and metrics. Addressing these objections head-on can pave the way for meaningful change.
Common Objections and How to Address Them
“We don’t have time for this.”
Reality Check: Explain how investing time in understanding the customer reduces wasted effort on features that miss the mark.
Practical Solution: Incorporate small changes, like dedicating one sprint planning session a month to reviewing customer feedback, rather than overhauling the entire workflow.
“We already know what the customer needs.”
Reality Check: Acknowledge the team’s expertise but emphasize that customer needs evolve and assumptions must be validated regularly.
Practical Solution: Use data and anecdotes from recent user interactions to challenge these assumptions.
“Our metrics are already strong.”
Reality Check: Strong metrics are important, but highlight how customer-first thinking can provide additional insights into long-term satisfaction and loyalty.
Practical Solution: Encourage experimenting with customer-focused metrics alongside traditional ones to demonstrate their value.
Breaking Habits That Hinder Progress
Defaulting to Internal Priorities
Encourage the team to reframe priorities by asking, “How does this benefit the customer?”
Adjust sprint goals to explicitly include customer-impact deliverables.
Relying Solely on Past Practices
Share stories or data showing how other teams benefited from prioritizing customer input.
Pilot new practices, like customer journey mapping, to demonstrate their value incrementally.
Focusing Only on Short-Term Results
Highlight how long-term customer trust can improve retention and advocacy.
Use case studies or feedback loops to connect present efforts to future gains.
Building Consensus
Bringing a team on board requires collective alignment:
Hold workshops to identify gaps between current practices and customer expectations.
Create shared goals that balance technical objectives with measurable customer outcomes.
Use retrospectives to reflect on how recent work has impacted the customer.
Resistance to change is inevitable, but it can be addressed by clarifying benefits, demonstrating success incrementally, and fostering an environment where the customer is seen as a vital part of every decision. Teams often resist what they don’t fully understand, so transparency and engagement are key to driving adoption.
6. Impact on Team Culture and Performance
A customer-first culture does more than improve the products or services your team delivers—it reshapes how your team works, collaborates, and thrives. The effects ripple across your organization, transforming both performance and morale.
Empowered Teams with Clear Purpose
When engineers see the direct connection between their work and customer outcomes, their sense of purpose grows stronger. They’re no longer writing code in isolation—they’re solving tangible problems for real people.
Purpose-driven teams are more motivated and resilient, even during challenging projects.
Engineers become more proactive, seeking ways to deliver additional value rather than merely meeting requirements.
Boosted Innovation
Focusing on the customer unlocks creativity. When the team deeply understands customer needs, they can challenge assumptions and identify opportunities to solve problems in unique ways.
Teams start thinking beyond traditional feature sets, exploring innovative approaches that differentiate your product in the market.
Iteration becomes natural as customer feedback guides refinements and inspires new ideas.
Stronger Collaboration Across Functions
A customer-first culture aligns everyone—from engineering to product management, design, and support—around a shared goal. This alignment fosters better communication and smoother collaboration.
Cross-functional teams are more likely to make decisions that balance technical feasibility, customer needs, and business goals.
Silos dissolve as everyone speaks the same language: the voice of the customer.
Improved Performance Metrics
When customer impact is prioritized, the metrics that matter—retention, satisfaction, and engagement—naturally improve. Teams that focus on delivering meaningful results see:
Fewer wasted resources on features that don’t resonate with users.
Increased loyalty from customers who feel understood and valued.
A Positive Feedback Loop
Success breeds more success. When the team sees how their work has positively impacted the customer, it reinforces the value of their efforts and strengthens the commitment to the customer-first mindset.
Positive feedback from customers energizes the team and builds momentum.
Stories of impact become part of the team’s identity, creating pride in the work they do.
By adopting a customer-first approach, engineering teams don’t just achieve better results—they redefine how they measure success. It’s no longer about lines of code or sprint velocity; it’s about the difference they make for the people they serve. This cultural shift creates a more engaged, innovative, and collaborative team ready to tackle any challenge.
7. Lead with the Customer at the Center
Adopting a customer-first culture isn’t a one-time initiative—it’s a continuous commitment that starts with you as a leader. By prioritizing the customer, you shape not just the products your team creates, but the mindset with which they approach every challenge.
Challenge the Status Quo
Ask yourself and your team:
Are we designing solutions based on customer needs or internal assumptions?
Do our metrics reflect customer success, or are they focused only on operational efficiency?
How often do we engage directly with the people who use what we build?
Challenging these habits is the first step toward building a culture that keeps the customer front and center.
Take Immediate Steps
To begin embedding this mindset:
1: Host a Workshop: Dedicate a session to exploring your team’s “Why.” Clarify how your work impacts the customer and identify areas where alignment could improve.
2: Set Up a Feedback Loop: Create a system for collecting and regularly sharing customer insights with the team. This can include surveys, interviews, or user testing sessions.
3: Redefine Success: Work with your team to adjust goals and KPIs to focus on customer outcomes.
Inspire Through Action
Leadership is about more than words—it’s about setting the example. Show your team what it means to prioritize the customer by:
Sharing customer stories in team meetings and retrospectives.
Celebrating wins that demonstrate customer impact, no matter how small.
Regularly involving yourself in customer-facing activities, like shadowing support teams or sitting in on usability sessions.
Build a Legacy
Teams that adopt a customer-first culture deliver more than great products—they build trust, loyalty, and long-lasting relationships with the people they serve. But it all begins with leadership. By taking the first step, you’re not only improving the work your team does today—you’re creating a foundation for sustained success and innovation.
The question is: Will you start now?
Take one action today to align your team’s work with the people who rely on it. Every change, no matter how small, moves you closer to building a team that doesn’t just solve problems but understands and champions the people behind them. That’s the real measure of success.
Don’t forget to signup for my newsletter below to stay in touch. Why? Because, I have a passion of writing posts like this that will culminate in a polished giveaway — just as a token of appreciation for your time and most importantly to help advance your career. You, my reader, are the reason we exist.
Don’t forget to signup for LeaderHub weekly Office Hours if you want to know more about Engineering Leadership.
You can also book a FREE 30-minute consultation to ask any question you may have about a career at Amazon, Meta, or Google.
How to Embrace Amazon’s Customer Obsession and Land the Job
Imagine you’re in an interview at Amazon, and the hiring manager asks, “Tell me about a time you solved a customer problem.” How you answer this question could determine whether you get the job. At Amazon, Customer Obsession isn’t just a nice-to-have skill—it’s a core expectation, and understanding how to embody it can be the key to landing and thriving in a role at the company.
Imagine you’re in an interview at Amazon, and the hiring manager asks, “Tell me about a time you solved a customer problem.” How you answer this question could determine whether you get the job. At Amazon, Customer Obsession isn’t just a nice-to-have skill—it’s a core expectation, and understanding how to embody it can be the key to landing and thriving in a role at the company.
Interview at Amazon coming up? Sign up for a mock interview session with Sanjeet.
Here’s what Customer Obsession means for everyone else, why it matters, and how one can adapt their mindset to align with Amazon’s most celebrated Leadership Principle.
What Does Customer Obsession Really Mean at Amazon?
At its core, Customer Obsession means putting the customer at the center of everything you do. It’s not just about responding to customer needs—it’s about anticipating them, finding creative solutions, and going above and beyond to deliver value.
A good question to ask at this point is: Who is the customer?
Jeff Bezos explained it best: “We’re not competitor-obsessed; we’re customer-obsessed. We start with what the customer needs and we work backwards.”
At Amazon, this principle drives decisions at all levels:
Engineers design features by imagining the ideal customer experience, not by focusing on technical limitations.
Operations teams optimize delivery routes to ensure packages arrive faster than promised.
Customer service representatives are empowered to resolve issues quickly, without bureaucracy.
For an employee, Customer Obsession isn’t a task; it’s a mindset. Every role—whether it’s writing code, managing a supply chain, or designing marketing campaigns—is tied to serving the customer.
Why Does It Matter to Amazon?
Customer Obsession is one of the reasons Amazon has consistently ranked high in customer satisfaction surveys. In 2024, the American Customer Satisfaction Index (ACSI) gave Amazon a score of 83 out of 100, making it one of the top-rated companies in retail. For job seekers, this focus means Amazon hires people who can contribute to this level of excellence.
But there’s more to it. Customer Obsession isn’t just about external results. It shapes Amazon’s internal culture. Employees are encouraged to “work backward,” starting from the customer’s needs and crafting solutions that meet those needs, even if it challenges conventional processes.
What Does This Mean for You as a Candidate?
If you want to work at Amazon, you need to show that you can think like they do—always keeping the customer in focus. Here’s how this translates into specific qualities Amazon looks for during interviews:
Empathy: Can you understand the customer’s perspective, even when it’s not explicitly stated?
Example Question: “Describe a time when you identified a problem before a customer noticed it.”
Problem-Solving: Are you resourceful and creative in solving customer issues? Amazon loves candidates who can think critically and propose innovative solutions.
Example Question: “Tell me about a time you improved a process that impacted the customer experience.”
Ownership: Amazon expects employees to take responsibility for customer outcomes, even if it’s outside their direct role.
Example Question: “Describe a situation where you took ownership of a problem and drove it to resolution.”
Data-Driven Thinking: Amazon thrives on metrics. Can you back up your decisions with data that ties back to the customer
Example Question: “How have you used data to identify and address a customer need?”
How to Adapt to Amazon’s Customer Obsession Mindset
To stand out in the hiring process and excel once you join, you need to do more than just understand Customer Obsession—you need to live it. Here’s how:
1. Reframe Your Work Around the Customer
Think about your current or past roles. How did your work directly or indirectly serve a customer? If you’re in a back-end role like software development, consider how your work enabled a better user experience.
Example: “I built a tool that reduced processing time for customer orders by 30%, enabling faster delivery and higher customer satisfaction.”
2. Practice “Working Backwards”
Amazon’s famous “working backward” approach starts with the ideal customer experience and builds the solution to meet that vision. You can demonstrate this mindset in your answers.
Example: “When I noticed recurring customer complaints about late deliveries, I spearheaded a project to identify bottlenecks in our logistics chain and reduced delays by 40%.”
3. Use Data to Tell Your Story
Be prepared to quantify your impact. At Amazon, numbers matter.
Example: “By introducing an automated follow-up system, I improved customer retention rates by 15% in six months.”
4. Show Proactive Ownership
Amazon values employees who don’t pass the buck. Show that you’ve taken initiative to fix problems—even if they weren’t in your job description.
Example: “When a critical customer-facing system crashed, I coordinated with multiple teams to restore service in two hours, minimizing downtime and customer complaints.”
5. Learn From Amazon’s Examples
Research how Amazon embodies Customer Obsession. Study stories like the development of AWS or the creation of Prime. Use these examples to inspire your answers and demonstrate that you understand the company’s ethos.
How to Prepare for Interviews
Understand the Leadership Principle: Read Amazon’s definition of Customer Obsession and think about how it applies to your experience.
Practice Behavioral Questions: Amazon uses the STAR (Situation, Task, Action, Result) format. Prepare stories that highlight empathy, problem-solving, and ownership.
Ask Yourself “Why?”: For every action you describe, tie it back to the customer.
Example: “Why did I optimize that process? To ensure customers received accurate billing information on time.”
What Happens Once You’re Hired?
If you join Amazon, Customer Obsession will be part of your daily work. Here’s what you can expect:
Regular Metrics Reviews: Teams constantly evaluate performance against customer-focused metrics like delivery times, error rates, or NPS (Net Promoter Score).
Customer-Focused Meetings: In product or project meetings, someone will always ask, “How does this help the customer?”
Encouragement to Innovate: Employees are empowered to propose new ideas that improve the customer experience, even if they challenge the status quo.
Advice from Amazon Employees
Former Amazon manager John Rossman, author of The Amazon Way, advises candidates to show they can think like an owner. “Don’t wait to be told what to do. At Amazon, you’re expected to proactively find ways to make things better for the customer.”
A recent hire shared their experience: “During my interview, I emphasized how I identified a flaw in our team’s process and fixed it to save customers hours of troubleshooting. They loved that I could see the problem from the customer’s side.”
Final Thoughts: Are You Ready for Amazon?
At Amazon, Customer Obsession shapes every decision. To thrive, you must make it a core part of how you work, solve problems, and engage with others.
As you prepare for your interview or your first day, ask yourself this: If the customer were in the room, would they be proud of the decision I’m making? If you can honestly answer “yes,” you’re already on your way to thriving at Amazon.
Don’t forget to signup for my newsletter below to stay in touch. Why? Because, I have an assembly line of posts like this that will culminate in a polished giveaway — just as a token of appreciation for your time and most importantly to help advance your career. You, my reader, are the reason we exist.
Don’t forget to signup for LeaderHub weekly Office Hours if you want to know more about Engineering Leadership at AWS.
You can also book a FREE 30-minute consultation to ask any question you may have about a career at Amazon, Meta, or Google.
‘Tis the season of AWS re:Invent! I had a front-row seat to this incredible event for five unforgettable years.
Picture this: a room full of builders, laptops humming, sleeves rolled up, and ideas taking shape. As a Solution Architect, I wasn’t just teaching—I was in the thick of it, helping attendees solve real problems with hands-on demos and code I’d spent months perfecting. Watching someone’s face light up as they nailed a solution they didn’t think was possible? That’s the kind of electricity that makes re:Invent more than a conference—it’s a catalyst for innovation.
AWS re:Invent 2024 is in progress.
When you think of re:Invent, the first images that come to mind might be the Venetian, larger-than-life keynotes, and the frenzy of new service announcements. But for those of us in the trenches—Solution Architects (SAs)—re:Invent is much more than an annual conference. It’s a culmination of hard work, collaboration, and moments that redefine cloud computing.
Between 2014 and 2019, I had the privilege of attending five re:Invents, witnessing firsthand the exponential growth of AWS services (from 30 to over 175 in that short span!) and the evolution of the event itself. Here’s what it’s like to be an SA at re:Invent, from the breakneck pace to the after-parties—and everything in between.
The following is my personal account of re:Invent.
CEO Keynotes
Let’s start with the keynote. Andy Jassy’s addresses were the crown jewel—hours packed with groundbreaking announcements. Each year, you’d feel the pulse of AWS innovation speeding up.
Then came Werner Vogels, Amazon’s CTO, with his engineering deep dives. Whether it was discussing distributed systems or real-world customer use cases, he painted a vivid picture of how AWS was transforming industries. Occasionally, James Hamilton joined the stage, giving us goosebumps as he unraveled the enormity of AWS infrastructure.
One year, Jassy unveiled a suite of services that sent shockwaves through the industry. As SAs, we were tasked with quickly understanding these tools and preparing to support customers in deploying them—sometimes within hours of the announcements.
Breakout and Builder Sessions
Hundreds of breakout sessions spread across venues like Venetian, Mirage, and Aria turned the Strip into a tech mecca. These sessions ranged from beginner walkthroughs of new services to advanced deep dives for hardcore builders.
I proctored and led dozens of builder sessions where we helped attendees create real-world solutions. It wasn’t just about showcasing AWS’s power; it was about empowering attendees to take that power home. Many of these sessions were driven by the code samples and demos I built throughout the year, tailored for specific customer needs.
The Booth Marathon
If you’ve ever visited the AWS service booths, you know the energy is electric. For SAs, booth duty was an endurance sport. One minute you’d explain Lambda to a startup founder, and the next, you’d discuss compliance frameworks with an enterprise CTO.
Visiting partner booths was equally enlightening. AWS partners, from ISVs to consulting firms, showcased innovations built on AWS. These interactions weren’t just about learning—they were opportunities to forge connections that would drive business for years to come.
Networking at Its Best
For SAs, re:Invent was a golden opportunity to network—not just with customers and partners but with AWS service and engineering teams.
During one memorable session, a customer voiced a critical feature request for a new service. I connected them directly with the service team, and that feedback eventually made its way into the product roadmap. That’s the kind of impact SAs could have at re:Invent: turning customer needs into real solutions.
Private Previews and Product Insights
At AWS, information is distributed on a need-to-know basis. That means re:Invent was often the first time we’d get a hands-on preview of upcoming services. Private preview sessions gave us the chance to provide input on features and even shape the roadmap based on customer demand.
I’ll never forget a private preview where the team unveiled a machine learning service. We provided feedback from customers who’d been asking for exactly that capability—and within a few months, it launched with those features included.
Finding water on Mars
Finding water on Mars? Well, almost. That’s me holding a bottle of water near the red hills of Las Vegas, not far from the Hoover Dam. The terrain was so strikingly crimson, it felt like we had landed on the Red Planet itself. This photo is from one of our offsite adventures during re:Invent, probably around 2016. These offsites were more than just a break—they were a rare opportunity to meet and bond with our global team, scattered across continents. Sneaking in a few hours to explore and connect was something we wouldn’t trade for the world (or Mars, for that matter). 🌎🚀
Big Deals, Bigger Parties
Re:Invent wasn’t just about learning and networking—it was about action. VP- and executive-level meetings set the stage for major deals, from massive data center migrations to cutting-edge analytics implementations.
And when the work was done? We celebrated. AWS’s “Work hard, play hard” ethos came alive with frugal-yet-lavish parties at some of the Strip’s finest venues. One night, after an intense day of meetings, I found myself at a table with industry leaders, sharing stories over Michelin-starred dishes.
Learning, Growing, and Gifting
Re:Invent wasn’t just an opportunity for customers—it was a chance for SAs to grow. From pop quizzes and trivia with peers to earning certifications and rocking gold jackets, the week was a celebration of knowledge.
And of course, the swag. On the last day, it was a race to collect goodies from partner booths. I didn’t buy T-shirts or hoodies for months after returning home!
The Spirit of re:Invent
At its core, re:Invent is more than a sales and marketing event. It’s where ideas are born, partnerships are forged, and careers are transformed. As a Solution Architect, it was a privilege to be at the center of it all, answering questions, easing concerns, and helping customers and partners achieve what seemed impossible.
The spirit of re:Invent isn’t just about celebrating innovation—it’s about living it. You work hard, you achieve something bigger than yourself, and then you party like there’s no tomorrow.
And that’s what makes re:Invent unforgettable.
Ready to dive deeper into AWS innovation and the life of a Solution Architect? Let’s connect. Share your thoughts below or drop by my newsletter for more 🚀
Want more insights? Subscribe to my newsletter below. I share weekly lessons from my journey at Amazon, designed to help you elevate your career and lead with impact.
Don’t forget to signup for LeaderHub weekly Office Hours if you want to know more about Solution Architecture at AWS.
You can also book a FREE 30-minute consultation to ask any question you may have about a career at Amazon, Meta, or Google.
What Software Development Managers at Amazon Really Do
Listen up! Being an SDM at Amazon isn’t just managing code—it’s about hustling on all fronts. You’re leading teams, innovating like crazy, and wearing so many hats your head spins. It’s like running a startup inside a titan. If you’re not ready to grind, don’t bother showing up.
The Software Development Manager (SDM) role at Amazon is a masterclass in balancing tactical execution with strategic vision. It’s not just a job—it’s a mission. From defining team culture to innovating on behalf of customers, every decision carries weight, and every action sets a precedent.
When I joined Amazon as an SDM in 2021, I quickly learned this was more than managing timelines or wrangling engineers. It was about creating impact—on the team, the customer, and the business. Here’s a deep dive into what this role entails, with real anecdotes to show you the human side of leading at Amazon.
1. Defining Team Identity: Tenets and Charters
When I joined my first team, the first challenge wasn’t technical—it was cultural. We were a group of talented individuals but lacked a shared understanding of what we stood for. So, I gathered the team to define our tenets and charter, the core principles guiding our decision-making.
One tenet we agreed on was: “We value correctness over speed when it matters.”
It wasn’t just lip service. During a critical release, this tenet became our North Star. A partner team requested a faster turnaround on a new feature, but we held firm, ensuring the output met our high standards. This clarity avoided chaos, built trust with our stakeholders, and solidified our team’s reputation.
Defining tenets isn’t just an exercise in alignment—it’s an investment in decision-making for when things get messy.
2. Balancing the Tactical and Strategic
Imagine you’re managing two timelines simultaneously. One is the here-and-now—your operational plans, release schedules, and on-call rotations. The other is the long game—a three-year strategy that maps out not just where your team will be but what kind of impact it will create.
I set up an internal wiki for our team at w.amazon.com. This wasn’t just documentation—it was our contract with the rest of Amazon. It outlined our release schedules, support protocols, and engagement rules.
One time, a VP reached out after reviewing our wiki and said, “Your documentation saved me two hours of back-and-forth.” That’s the kind of efficiency Amazon thrives on.
On the strategic side, I broke down our three-year vision into roadmaps spanning 12–24 months. One of the most rewarding projects was an innovative analytics pipeline that improved query response times by 50%. Getting there required meticulous resource planning and aligning with multiple teams.
3. Working Backwards from the Customer
At Amazon, the customer isn’t just king—they’re the only priority. One of my favorite examples was leading the development of PartiQL-Scribe, an open-source application layer transpiler.
The idea stemmed from a customer pain point: managing fine-grained access controls across disparate data sources. After months of planning, prototyping, and navigating organizational red tape, we delivered a solution that unified multiple SQL dialects into one cohesive framework.
I remember spending late nights refining our PRFAQ document, preparing for reviews with Distinguished Engineers. The feedback was brutal but invaluable. When the feature launched, a customer’s feedback summed it up perfectly: “This just saved us weeks of work.”
4. Leading Operations Like a Pro
Operations aren’t just about keeping the lights on—they’re about building trust. I defined our on-call rotation policy to ensure every team member was supported, not overwhelmed.
One memorable moment was during a high-severity outage. Our system went down during peak traffic, and I had to step in to coordinate the response. Thanks to our well-documented support protocols, we restored service in record time. The postmortem revealed areas for improvement, but also underscored how preparation turns crises into learning opportunities.
5. Growing and Empowering the Team
Growing a team isn’t just about headcount—it’s about capability. Over two years, I hired new engineers, mentored interns, and championed promotions for three team members.
One intern, in particular, stood out. They built a prototype for a real-time data visualization tool that surpassed everyone’s expectations. Watching them grow from a nervous college student to a confident professional was incredibly rewarding.
Empowerment wasn’t just a buzzword—it was a philosophy. Weekly 1:1s became a space for candid conversations about career goals and challenges. One of my engineers told me, “I’ve never felt this supported in my career.” That’s the power of intentional leadership.
6. Building Consensus and Resolving Conflicts
Consensus-building at Amazon can feel like navigating a labyrinth. As an SDM, I facilitated discussions to align our roadmap with broader organizational goals, often acting as the mediator between competing priorities.
One such instance involved negotiating service ownership boundaries with a partner team. It wasn’t easy—hours of debate and dozens of revisions later, we reached an agreement that allowed both teams to thrive. The key? Staying solution-oriented and inviting diverse perspectives.
7. Ruthless Prioritization and Focus
Here’s a hard truth: You can’t do it all. I had to make tough calls, shelving projects that didn’t align with our core objectives.
One time, I had to convince my team to drop a promising initiative to focus on a higher-impact project. It wasn’t easy—people were emotionally invested. But by showing the bigger picture and ensuring transparency, we rallied around the new priority.
8. Operational and Strategic Reviews
Amazon runs on reviews. Weekly and monthly reviews weren’t just checkpoints—they were opportunities to pivot, refine, and adapt.
During one monthly review, we identified a bottleneck in our deployment pipeline. Within weeks, we implemented a fix that reduced deployment times by 40%. These reviews weren’t about finding faults—they were about driving improvement.
9. Mentorship and Team Cohesion
One of my proudest moments as an SDM was organizing a team offsite where we played a live-action VR game. It wasn’t just fun—it was team-building disguised as entertainment.
I also encouraged every team member to find a mentor, creating a culture of continuous growth. One of my engineers said, “This mentorship program transformed how I approach problem-solving.” That’s the ripple effect of investing in people.
10. Expanding Influence Beyond the Team
An SDM’s impact doesn’t end with their team. By collaborating with Principal and Senior Engineers, I influenced technical decisions that shaped roadmaps across multiple teams.
One example? Proposing a shared library for analytics that became a standard across five teams. It wasn’t just a technical win—it was a testament to the power of collaboration.
The Bottom Line
The SDM role at Amazon is about more than hitting targets—it’s about leaving a legacy. It’s about balancing the tactical with the strategic, empowering your team, and always putting the customer first.
If you’re aspiring to lead at this level—or simply want to refine your leadership skills—remember this: Great leadership is about building others up, making bold decisions, and staying true to your principles.
Want more insights? Subscribe to my newsletter below. I share weekly lessons from my journey at Amazon, designed to help you elevate your career and lead with impact.
Don’t forget to signup for LeaderHub weekly Office Hours if you want to know more about Engineering Leadership at AWS.
You can also book a FREE 30-minute consultation to ask any question you may have about a career at Amazon, Meta, or Google.
Why Your Software Isn’t as Great as You Think (And How to Fix It)
Think your software’s the next big thing? Your users might disagree. Discover why obsessing over your customers—not your competitors—is the key to building products that actually matter.
Let’s cut to the chase. You’ve spent months crafting this new feature. The code is clean, the interface is slick, and you’re convinced it’s going to disrupt the industry. But when you launch, users treat it like a pop-up ad on a dial-up connection. What happened?
Before Amazon, I remember leading a development team where we built this state-of-the-art scheduling tool. We were so focused on outdoing our competitors—adding more features, integrating the latest tech—that we forgot to ask our users what they actually needed. The result? A bloated product that nobody wanted to use.
Customer vs. Competitor Obsession
In the tech industry, it’s tempting to fixate on what your competitors are doing. They’ve implemented a new AI algorithm? We need a better one. They’ve launched a mobile app? Ours has to have more features.
But here’s a radical idea: instead of obsessing over your competitors, why not obsess over your customers?
Amazon excels at this. Trust me, I would know because I worked with them for 10+ years. They’re not trying to mimic or outdo other retailers. They’re laser-focused on providing the best possible experience for their customers. They’re constantly asking, “What does the customer want?” rather than “What are our competitors doing?”
Who Is Your Real Customer?
This might sound basic, but it’s crucial: who is your customer? For software engineers and managers, your customers could be end-users navigating your application, other developers using your APIs, or businesses relying on your platform to operate smoothly.
Understanding who you’re building for is the first step. If you don’t know who your customer is, how can you possibly meet their needs?
Work Backwards from the Customer
Before writing a single line of code, start with the customer’s needs. At Amazon, they don’t begin projects without a Press Release and FAQ (PRFAQ) written from the customer’s perspective. It’s like writing the end-user documentation before the product exists.
This approach forces you to think about the problem you’re solving, how it benefits the customer, and what the user experience should be—all before getting lost in the technical details.
Trust Is Everything
In software, trust is earned through reliability, transparency, and delivering on promises. If your application crashes frequently or your updates introduce more bugs than features, users will lose faith in your product.
Amazon maintains trust by being transparent and customer-centric. For example, they allow honest customer reviews on product pages, even if they’re negative. This openness builds credibility and keeps customers coming back.
Invent on Behalf of the Customer
Customers may not always know what they want until they see it. They didn’t ask for one-click shopping or cloud computing services, but now they can’t imagine life without them.
As engineers and managers, we should strive to anticipate our customers’ needs. This means being willing to innovate and take risks to create solutions that genuinely make their lives easier.
Long-Term Thinking: Beyond the Next Release
In a world obsessed with rapid development cycles and quarterly results, it’s easy to lose sight of the bigger picture. Amazon thinks in terms of years, not weeks. That successful feature launched today was likely planned out three years ago.
Adopting a long-term orientation means investing in scalable architectures, maintainable codebases, and technologies that will serve your customers well into the future.
Looking Around Corners
Anticipating what’s next in technology and customer needs isn’t about having a crystal ball. It’s about staying curious, keeping an eye on industry trends, and listening to your customers’ feedback.
Developing this foresight is a discipline. It requires you to be proactive rather than reactive, to explore possibilities before they become mainstream, and to be ready to pivot when necessary.
It’s Not Easy, But It’s Worth It
Putting the customer first is challenging. It may mean discarding pet projects, rethinking your approach, or admitting that your initial idea wasn’t the best solution.
But consider the alternative: building products that don’t resonate with users, wasting resources on features no one uses, and ultimately losing market share to someone who got it right.
So, What’s the Next Step?
Stop fixating on your competitors’ feature sets and start engaging with your customers. Gather feedback, conduct user testing, and immerse yourself in their experience.
Remember, there are many paths to success in software development. You can chase trends, mimic competitors, or cut corners to ship faster. But if you want to build something meaningful and lasting, customer obsession isn’t just a strategy—it’s a necessity.
So go ahead, be obsessed with your customers. They might not send you thank-you emails, but they’ll keep using your products. And in today’s age and world of flickering attention span, that’s the biggest compliment you can get. Or, survey. And we all know how fun surveys are. More on that awkwardness later.
Don’t forget to signup for my newsletter below to stay in touch. Why? Because, I have an assembly line of posts like this that will culminate in a polished giveaway — just as a token of appreciation for your time and most importantly to help advance your career. You, my reader, are the reason we exist.
Don’t forget to signup for LeaderHub weekly Office Hours if you want to know more about Engineering Leadership at AWS.
You can also book a FREE 30-minute consultation to ask any question you may have about a career at Amazon, Meta, or Google.
Why some First-Time Managers Fail (And How You Can Succeed)
Becoming a manager isn’t a promotion; it’s a shift. It’s not about control, but trust. Not about doing, but enabling. Most fail because they cling to the old rules of individual success. Great managers? They rewrite the rules—empowering teams, celebrating others, and leading with empathy. It’s a leap worth taking.
How hard can it be to lead a team?
That was the question I asked myself the first time I got promoted. My boss congratulated me, handed me the reins of a small but ambitious team, and said, “You’ll do great.” At that moment, I felt proud, capable, and slightly terrified. The title change seemed simple—just one word added to my email signature. But little did I know, it was the beginning of the steepest learning curve of my career.
What followed were months of missteps, overthinking, and occasional breakthroughs. Leading wasn’t about technical proficiency anymore; it was about people. And people, I quickly realized, don’t come with instruction manuals.
If you’re stepping into management for the first time, you’re not just taking on a new role. You’re stepping into a completely different game. This is my story of learning to lead, and the lessons I wish someone had shared with me.
Lesson 1: The Hero Complex Will Break You
In my first week as a manager, I made it my mission to fix everything. A team member struggled to complete a project? I stepped in. Another couldn’t solve a technical issue? I solved it. It felt good—like I was proving I deserved the promotion.
Then, it happened.
I stayed late every night. I was drained from juggling my own work and everyone else’s. The team had become passive, waiting for me to provide answers. My “helpfulness” had quietly turned into micromanagement, and morale was plummeting.
The turning point came when one of my team members pulled me aside and said, “I want to learn, but I don’t feel like I have space to try.”
That’s when it hit me: My job wasn’t to be the hero. It was to help others become heroes of their own work.
Key Insight:
The best leaders don’t solve every problem—they empower their teams to solve problems themselves. Leadership isn’t about doing; it’s about enabling.
Lesson 2: Feedback Isn’t a Criticism Sandwich
Early on, I followed a common piece of advice: Always sandwich criticism between two compliments. It seemed logical—people would leave the conversation feeling good while still getting the message.
But one day, I gave feedback to a team member about missed deadlines. I wrapped it between praise for their “great effort” and how “they’re so valued on the team.” The result? They walked away feeling confused and unsure what to change.
It turns out that “constructive feedback” wrapped in too much fluff is like giving someone a map without marking the destination. Clarity, not sugar-coating, builds trust.
What worked better was saying something like, “I noticed you missed the last two deadlines. Let’s figure out what’s blocking you and how I can support you in meeting them next time.” The directness was hard at first, but my team appreciated knowing exactly where they stood.
Key Insight:
Feedback isn’t about being nice or harsh—it’s about being clear. When you care about someone’s growth, you owe them the truth, delivered with kindness.
Lesson 3: Listening Is a Superpower
A few months into my role, I started every meeting with an agenda and ended it with action items. Efficient? Sure. Effective? Not always.
One day, I noticed my team seemed disengaged during our one-on-ones. Meetings felt transactional, not relational. Then a colleague asked me, “When’s the last time you listened without thinking of what to say next?”
It was a gut punch. I had been listening to respond, not to understand.
So, I tried a new approach. During one-on-ones, I asked open-ended questions like, “What’s been on your mind?” and “What can I do to help you thrive here?” Then, I let the silence sit. I listened. I didn’t rush to fill the gaps or offer solutions.
The results were profound. I learned about challenges my team was hesitant to share before. Trust deepened, and our conversations became richer.
Key Insight:
Listening is leadership. People don’t just want to be managed—they want to be heard.
Lesson 4: Your Team’s Success Is Your Success
Before becoming a manager, I took pride in my individual achievements—delivering stellar code, solving complex problems, and meeting tight deadlines. But as a manager, those victories no longer mattered.
I learned this the hard way during a quarterly review when my boss asked, “What has your team achieved?” I froze. My individual wins had blinded me to the bigger picture: A manager’s success is measured by the team’s success.
So, I shifted my mindset. I started celebrating my team’s milestones, even if I hadn’t directly contributed. I made space in meetings to highlight their achievements. Over time, the team became more collaborative and motivated, knowing their work was recognized.
Key Insight:
Your job as a manager is to build an environment where your team can excel—and then celebrate their wins like they’re your own.
Conclusion: The Shift from Me to We
Becoming a first-time manager is like learning to drive on a winding road. The rules are unfamiliar, the stakes are higher, and mistakes feel magnified. But the destination—helping others succeed—is worth every wrong turn.
To all the first-time managers out there, remember this: Leadership isn’t about having all the answers. It’s about asking better questions, fostering trust, and creating a space where people can do their best work.
You don’t need to be perfect. You just need to be present, intentional, and willing to grow alongside your team.
So, go ahead. Lead boldly. Listen deeply. And never stop learning.
Want more insights? Subscribe to my newsletter below. I share weekly lessons from my journey at Amazon, designed to help you elevate your career and lead with impact.
Don’t forget to signup for LeaderHub weekly Office Hours if you want to know more about Engineering Leadership at AWS.
You can also book a FREE 30-minute consultation to ask any question you may have about a career at Amazon, Meta, or Google.