Engineering Leadership Principles

I believe an engineering manager’s most important responsibility is creating an environment where engineers can do the best work of their careers. A big part of that is being a shield for the team: removing organizational friction, managing competing priorities, and taking on the distractions that pull engineers away from meaningful technical work. When engineers have the space to focus on building great products and solving hard problems, they’re more engaged, more creative, and better able to deliver for customers. I don’t see my role as standing in front of the team. I stand behind them, making sure they have the clarity, support, and resources they need to succeed.

Strong engineering organizations are built by investing in their people. I want every engineer to have opportunities to step outside their comfort zone, whether that means leading a design review, owning a critical project or component, mentoring a teammate, or learning a new technology. People grow when they’re trusted with real responsibility and supported along the way. My job is to find the right opportunities to stretch engineers, then provide the coaching, feedback, and space they need to build confidence and develop their own technical judgment.

The best teams are built on trust. Every engineer should have a voice, and the people closest to a problem should play a meaningful role in deciding how we solve it. I value open discussion, different perspectives, and decisions grounded in data, but once we make a decision, we commit to it together. That also means being willing to take risks and accepting that sometimes we’ll get things wrong. We celebrate our wins, learn from our failures, and use both to make the team and the product better. Most importantly, ownership doesn’t end when the code ships. We own the outcome and the customer experience that comes with it. That sense of ownership gives engineers a real stake in what they build and pride in what we deliver as a team.

Hiring is one of the most important responsibilities I have as an engineering leader. Every person you bring onto a team changes it in some way: its culture, its capabilities, and what it can accomplish. As a Bar Raiser at Amazon, I’ve helped guide more than 750 hiring decisions, and one thing I’ve learned is that the goal isn’t simply to find someone who can do the job. I’m looking for people who will thrive on the team and make the people around them better. Technical skills can be developed, but qualities like ownership, curiosity, and the ability to earn trust are much harder to teach. If those qualities aren’t there, I’m willing to keep looking. A bad hire can set a team back far more than an open role.

When I interview someone, I’m often more interested in how they arrive at an answer than whether they get to the “right” one. Real engineering problems rarely have clean answers. They require navigating ambiguity, making tradeoffs, challenging assumptions, and adjusting when new information comes to light. I look for candidates who ask good questions, explain their thinking, and stay curious throughout the conversation. The strongest engineers I’ve worked with tend to be lifelong learners. They want to understand why something works, not simply know that it does. That curiosity gives them the ability to keep growing long after the skills they were hired for have changed.

I also hire for potential, not just the experience someone already has. No candidate is perfect, and even exceptional engineers will have areas where they need to grow. If someone has strong fundamentals, good judgment, and a genuine desire to learn, I’m comfortable leaning in and giving them the opportunity to stretch into responsibilities they haven’t held before. I’d rather invest in someone who is still pushing the boundaries of what they can do than hire someone who has stopped growing. Building a great team means recognizing that potential, creating opportunities for people to realize it, and maintaining a high bar along the way. I’m comfortable waiting for the right person. My job as a hiring manager isn’t to put butts in seats; it’s to make the team stronger with every person we add and make sure each new hire has the opportunity to succeed.

Career growth is about more than rewarding hard work or time in a role. The engineers who make the biggest impact are the ones who continually expand their sphere of influence—moving from delivering individual features to shaping technical direction, mentoring others, improving how the team works, and eventually influencing decisions beyond their own team. As a manager, part of my job is to make that path clear. Every engineer should understand what success looks like at their current level, what’s expected at the next, and where they have opportunities to grow. When those expectations are clear, career progression becomes less of a guessing game and more about demonstrating impact.

Growth also doesn’t happen by accident. I work with engineers to identify the skills, experiences, and behaviors they need to reach the next stage of their careers, then turn those into a plan we can work toward together. We revisit that plan regularly in one-on-ones to talk about progress, expectations, timelines, and where the next opportunity might be. That could mean owning a high-impact project, driving an architectural decision, mentoring another engineer, or representing the team with stakeholders. I look for opportunities that push people outside their comfort zones without leaving them on their own once they get there. Ultimately, I want engineers to leave my team with a broader sphere of influence, greater confidence in their own judgment, and the experience to take on challenges they weren’t ready for when they joined.

Engineering excellence starts long before a service reaches production. It begins with thoughtful, resilient system design and engineers who are always looking around corners—thinking about how a system might fail, where it will struggle as it scales, and what tradeoffs we’re making along the way. My teams look for potential bottlenecks early and instrument our services so we can measure capacity and performance rather than guess at them. We stress test to understand how our systems behave under load, identify their tipping points, and continually re-baseline as the software and its usage evolve.

That same discipline carries into production. We set aggressive performance SLAs, establish clear on-call handoffs, and regularly review our metrics for the slow degradation that can otherwise go unnoticed. Every service has an incident response plan with runbooks, clear points of contact, escalation paths, and a process for learning from failures. When an incident happens, the priority is simple: mitigate the impact, communicate clearly, and restore service. Once the immediate problem is behind us, we dig into the root cause and make the changes necessary to keep it from happening again. The goal isn’t to build systems that never fail; it’s to build systems and teams that are prepared for failure, recover quickly, and come out stronger on the other side.

Curiosity is one of the traits I value most in an engineer. The best engineers aren’t satisfied with knowing that something works—they want to understand why it works. They’re willing to dig into an unfamiliar codebase, peel back the layers of a service, or challenge their own assumptions when something doesn’t quite add up. Just as importantly, that curiosity extends to the customer. They want to understand the problem behind the request, not just the feature they’ve been asked to build. Great engineering isn’t about shipping more features; it’s about solving meaningful problems. Engineers who keep asking questions tend to make better decisions because they understand both the technology and the people it serves.

That curiosity should also extend to the tools we use. Modern cloud platforms give us an incredible toolbox, but having a service available doesn’t automatically make it the right solution. I encourage engineers to look beyond the obvious choice: understand the tradeoffs, explore open-source alternatives, see how others have approached the same problem, and be willing to consider ideas that come from outside our usual ecosystem. Every technology choice has consequences for cost, scalability, maintainability, and operational complexity. Engineers who keep exploring and learning build a broader technical toolkit, but more importantly, they develop the judgment to know which tool fits the problem in front of them.

I believe engineering leaders earn credibility by staying connected to both the technology and the realities of building and operating software. For me, that means sharing in the operational responsibilities of the team—participating in on-call rotations, working the ticket queue, and digging into production issues alongside engineers. I stay involved in design reviews, not to dictate the solution, but to ask questions, challenge assumptions, and make sure we’ve thought through the tradeoffs. I also participate in code reviews when I can, both to stay connected to the implementation and as an opportunity to mentor and reinforce the engineering practices we care about.

Staying technical also means accepting that there’s always more to learn. Technology moves too quickly to rely on what worked five or ten years ago, so I make a point of exploring new technologies, architectural patterns, open-source projects, and capabilities from cloud providers. I still enjoy writing code and contributing directly when there’s an opportunity to add value, but I’ve also learned that another commit from me isn’t always what the team needs. Sometimes my highest-impact contribution is asking the right question, providing context, removing an obstacle, or simply getting out of the way and giving an engineer the space to solve the problem themselves.

Customer impact starts with understanding the customer before writing a single line of code. I believe in working backwards from the problems customers are trying to solve, the friction they encounter, and the outcomes that matter most to them. But that understanding can’t come from feature requests or assumptions alone. It comes from building relationships, talking directly with customers, and creating channels where feedback can flow openly in both directions.

My teams don’t just deliver software and move on. We walk alongside our customers, learning how they actually use what we build, where their workflows break down, and where we can make their lives easier. Those conversations become an ongoing feedback loop: they shape product direction, challenge our assumptions, and help us understand whether our engineering decisions are producing the outcomes we intended. Staying close to the customer keeps us focused on the problem rather than the feature. Ultimately, success isn’t measured by how much software we ship, but by whether what we build makes a meaningful and lasting difference for the people using it.

Coming soon - there are lessons learned :)