Building High-Performance Engineering Culture: Mission, Vision, and Tenets

Every high-performance engineering team needs a foundation. Not the technical stack-that’s the easy part. The foundation that matters is shared understanding of mission, vision, and how the team works together. Without this, you get talented engineers pulling in different directions, making inconsistent decisions, and creating friction where there should be alignment.

I’ve built teams at AWS, Cisco, and startups. The pattern that works consistently comes from Amazon’s approach: define your mission (why you exist), your vision (where you’re going), and your tenets (how you work). This isn’t corporate theater. It’s the operating system for high-performance teams.

This post explains the framework, how to apply it when forming new teams, and why three specific tenets-Customer Obsession, Earn Trust, and Have Backbone; Disagree and Commit-form the foundation of engineering excellence.

The Amazon Framework: Mission, Vision, Tenets

Amazon’s approach to team culture is deceptively simple. Every team defines three things:

Mission: Why does this team exist? What problem are we solving?

Vision: Where are we going? What does success look like in 3-5 years?

Tenets: How do we work? What behaviors and principles guide our decisions?

The mission and vision provide direction. The tenets provide the operating principles that guide daily decisions when leadership isn’t in the room.

Why This Works

Most companies have mission and vision statements. Few have tenets. That’s the mistake.

Mission and vision tell you where to go. Tenets tell you how to get there. When an engineer faces a decision-ship now or wait for more testing, build the simple solution or the scalable one, escalate an issue or handle it locally-tenets provide the framework for making that decision consistently with team values.

The key insight: tenets are decision-making heuristics that scale culture. You can’t be in every meeting, review every decision, or guide every choice. Tenets encode your values into principles that engineers internalize and apply independently.

Amazon’s Leadership Principles: The Gold Standard

Before defining your team’s tenets, it’s worth understanding Amazon’s Leadership Principles. They’re the gold standard for engineering culture, refined over 30 years of building one of the world’s most successful technology companies.

Amazon has 16 Leadership Principles. Every Amazonian knows them. They’re used in hiring (behavioral interviews probe for evidence of each principle), performance reviews (you’re evaluated against them), and daily decisions (meetings reference them explicitly).

A critical point about priority: At Amazon, Customer Obsession is the number one priority. The other 15 principles matter, but when they conflict with Customer Obsession, Customer Obsession wins. There is no priority ordering among the other 15-they’re all important, but Customer Obsession is first.

Here are the principles most relevant to engineering teams:

Customer Obsession

Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

This isn’t “customer focus” or “customer-centric.” It’s obsession. The difference matters. Customer focus means you consider customers. Customer obsession means you start with the customer and work backwards. Every decision begins with “what does the customer need?” not “what’s technically interesting?” or “what’s easiest to build?”

Ownership

Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job.”

Ownership means you’re responsible for outcomes, not just outputs. You don’t throw code over the wall and move on. You own it in production. You respond to pages. You fix bugs. You improve performance. The code is yours, and you’re accountable for its success.

Invent and Simplify

Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here.” As we do new things, we accept that we may be misunderstood for long periods of time.

Engineering teams naturally gravitate toward complexity. Invent and Simplify pushes back. The best solution is often the simplest one. Innovation isn’t adding features-it’s solving problems in ways that make the complex simple.

Are Right, A Lot

Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.

This principle is often misunderstood. It’s not about being right in arguments. It’s about making good decisions consistently. The key phrase is “seek diverse perspectives and work to disconfirm their beliefs.” Being right a lot requires intellectual humility-actively seeking evidence that you’re wrong.

Learn and Be Curious

Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.

Technology changes constantly. What you knew five years ago is obsolete. High-performance engineers are learning machines. They read papers, experiment with new tools, and stay current. Curiosity isn’t optional-it’s survival.

Hire and Develop the Best

Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others.

Every hire either raises or lowers the bar. There’s no neutral. High-performance teams are relentless about hiring people better than themselves and developing them into leaders.

Insist on the Highest Standards

Leaders have relentlessly high standards - many people may think these standards are unreasonably high. Leaders are continually raising the bar and drive their teams to deliver high quality products, services, and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.

This is the principle that separates good teams from great ones. High standards aren’t about perfection-they’re about not accepting mediocrity. Code reviews matter. Tests matter. Documentation matters. Operational excellence matters. You don’t ship broken code because you’re behind schedule.

Think Big

Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

Small thinking produces small results. High-performance teams think big-not recklessly, but ambitiously. What would 10x better look like? What would delight customers? What would change the game?

Bias for Action

Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

Analysis paralysis kills momentum. Bias for Action means you make decisions with incomplete information, knowing you can course-correct. The key phrase is “many decisions are reversible.” Don’t treat every decision like it’s permanent.

Frugality

Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense.

Frugality isn’t about being cheap. It’s about being resourceful. Can you solve this with existing tools instead of buying new ones? Can you build this with three engineers instead of ten? Constraints force creativity.

Earn Trust

Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.

Trust is earned through consistency, honesty, and humility. You admit mistakes. You give credit to others. You’re candid about problems. You don’t spin or hide bad news. Trust is the foundation of high-performance teams.

Dive Deep

Leaders operate at all levels, stay connected to the details, and audit frequently. No task is beneath them.

You can’t lead effectively from 30,000 feet. Dive Deep means you understand the details. You read the code. You look at the metrics. You understand the customer pain points. You don’t delegate understanding.

Have Backbone; Disagree and Commit

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

This is the principle that enables high-velocity decision-making. You argue your position vigorously. You bring data. You challenge assumptions. But once the decision is made, you commit completely-even if you disagreed. No “I told you so.” No undermining. Full commitment.

Deliver Results

Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

Results matter. Not activity, not effort, not intentions. Results. High-performance teams ship. They deliver. They hit commitments. When things go wrong, they adapt and deliver anyway.

Strive to be Earth’s Best Employer

Leaders work every day to create a safer, more productive, higher performing, more diverse, and more just work environment. They lead with empathy, have fun at work, and make it easy for others to have fun. Leaders ask themselves: Are my fellow employees growing? Are they empowered? Are they ready for what’s next? Leaders have a vision for and commitment to their employees’ personal success, whether that be at Amazon or elsewhere.

Great teams take care of their people. You create an environment where people grow, feel valued, and do their best work. This isn’t soft-it’s strategic. The best people have options. They stay where they’re growing and valued.

Success and Scale Bring Broad Responsibility

We started in a garage, but we’re not there anymore. We are big, we impact the world, and we are far from perfect. We must be humble and thoughtful about even the secondary effects of our actions. Our local communities, planet, and future generations need us to be better every day. We must begin each day with a determination to make better, do better, and be better for our customers, our employees, our partners, and the world at large. And we must end every day knowing we can do even more tomorrow.

With success comes responsibility. The systems you build affect people’s lives. The decisions you make have consequences. High-performance teams think about impact, not just features.

Defining Your Team’s Tenets

Amazon’s Leadership Principles are comprehensive, but your team doesn’t need 16 tenets. You need 3-5 that address your specific context.

The key insight: tenets should emphasize behaviors that aren’t obvious or aren’t prevalent in your team. Don’t state the obvious. Don’t emphasize what’s already strong. Focus on the behaviors you need to cultivate.

The “Unless You Know Better” Principle

Most tenets should end with an implicit “unless you know better.” This phrase is critical to understanding how tenets work.

Tenets are heuristics, not laws. They guide decisions in the absence of better information. When you have specific knowledge that contradicts a tenet, you’re empowered to make the right decision.

Example: Your tenet is “Bias for Action-ship fast and iterate.” But you’re building a payment processing system where bugs mean financial loss. You know better. You slow down, add extensive testing, and ship carefully.

Example: Your tenet is “Invent and Simplify-choose the simplest solution.” But you’re building a system that will scale to millions of users, and the simple solution won’t scale. You know better. You build the more complex, scalable solution.

The phrase “unless you know better” prevents tenets from becoming dogma. It empowers engineers to use judgment. It acknowledges that context matters.

When to invoke “unless you know better”:

• You have specific domain knowledge that contradicts the tenet
• The situation is exceptional and the tenet doesn’t apply
• Following the tenet would produce a clearly worse outcome

When NOT to invoke it:

• You’re uncomfortable with the tenet (that’s not knowing better, that’s avoiding it)
• You prefer a different approach without clear reasoning (that’s preference, not knowledge)
• You haven’t thought through why the tenet exists (understand it first, then decide if you know better)

The “unless you know better” principle requires two things:

1. Judgment: You must actually know better, not just think you do
2. Accountability: If you invoke “unless you know better,” you own the outcome

This is what separates high-performance teams from rule-following teams. High-performance teams internalize principles, apply judgment, and take ownership. Rule-following teams apply principles blindly and blame the rules when things go wrong.

Tenets with “unless you know better” create a culture of empowered decision-making within a framework of shared values.

The Selection Process

When forming a new team, ask:

What behaviors will make this team successful? Think about your mission and the challenges ahead. What ways of working will be critical?

What behaviors are missing or weak? Look at your team composition. What gaps exist? What behaviors need reinforcement?

What decisions will this team face repeatedly? Tenets should guide common decisions. If your team rarely faces a particular tradeoff, don’t make it a tenet.

What behaviors differentiate high performers? Think about the best engineers you’ve worked with. What did they do differently?

The Three Essential Tenets

In my experience building engineering teams, three tenets consistently matter most:

1. Customer Obsession

Every engineering team should start with Customer Obsession. It’s the foundation that prevents the most common failure mode: building technically impressive systems that don’t solve customer problems.

Why it matters: Engineers naturally optimize for technical elegance, performance, or architectural purity. These matter, but they’re means to an end. The end is customer value. Customer Obsession keeps you focused on outcomes, not outputs.

What it looks like in practice:

• Design reviews start with “what customer problem does this solve?”
• Technical decisions reference customer impact: “this reduces latency by 50ms, which improves checkout conversion”
• Engineers talk to customers, read support tickets, and understand pain points
• Features are prioritized by customer value, not technical interest
• “This is technically cool” isn’t sufficient justification

When to emphasize it: Always. Every team needs Customer Obsession. It’s never obvious enough, never strong enough. Even teams that think they’re customer-focused usually aren’t customer-obsessed.

2. Earn Trust

Trust is the foundation of high-performance teams. Without trust, you get politics, CYA behavior, and information hoarding. With trust, you get candor, collaboration, and speed.

Why it matters: Engineering is collaborative. Code reviews, design discussions, incident response, on-call rotations-all require trust. When trust is high, teams move fast because they don’t waste energy on politics. When trust is low, everything takes longer.

What it looks like in practice:

• Engineers admit mistakes openly: “I broke production, here’s what happened”
• Code reviews are candid but respectful: “This approach has a race condition”
• People give credit generously: “Sarah’s design made this possible”
• Bad news travels fast: “We’re going to miss the deadline” surfaces early
• Leaders are vocally self-critical: “I made the wrong call on the architecture”
• Commitments are kept: if you say you’ll deliver Friday, you deliver Friday

When to emphasize it: When forming new teams, when trust has been damaged, or when you’re seeing political behavior. If people are hedging, spinning, or covering their tracks, Earn Trust needs emphasis.

3. Have Backbone; Disagree and Commit

This is the tenet that enables high-velocity decision-making without descending into either groupthink or endless debate.

Why it matters: Engineering teams face constant decisions: architecture choices, technology selection, feature prioritization, quality tradeoffs. Without Disagree and Commit, you get two failure modes:

• False consensus: People don’t voice disagreement, decisions are made without full information, and problems surface later
• Analysis paralysis: People voice disagreement but never commit, decisions drag on, and momentum dies

Have Backbone; Disagree and Commit solves both. You’re obligated to voice disagreement. You’re also obligated to commit once the decision is made.

What it looks like in practice:

• Engineers challenge decisions respectfully: “I disagree with using microservices here, and here’s why”
• Disagreement is expected and valued: “Good, let’s hear the counterargument”
• Decisions have clear owners: “I’ve heard everyone, I’m deciding we’ll use Postgres”
• Once decided, everyone commits: no “I told you so,” no undermining, no passive resistance
• If new information emerges, you can revisit: “We decided X, but this changes things”

When to emphasize it: When you’re seeing either false consensus (people agreeing in meetings but complaining afterward) or endless debate (decisions never stick). Also critical for teams with strong personalities who might dominate discussions.

Additional Tenets to Consider

Beyond the essential three, consider these based on your team’s context:

Insist on the Highest Standards: When quality is slipping, when technical debt is accumulating, or when you’re seeing shortcuts that will hurt you later.

Bias for Action: When the team is over-analyzing, when decisions are slow, or when you need to increase velocity.

Dive Deep: When the team is too high-level, when details are being missed, or when you need more technical rigor.

Ownership: When people are throwing code over the wall, when operational excellence is weak, or when you need more accountability.

Invent and Simplify: When complexity is growing, when solutions are over-engineered, or when you need more innovation.

Writing Your Team’s Tenets

Once you’ve selected your tenets, write them down. The format matters less than the clarity.

The Structure

For each tenet, define:

The principle: A clear, memorable statement of the behavior

Why it matters: The reasoning behind this tenet for your team

What it looks like: Concrete examples of the behavior in practice

What it doesn’t mean: Common misinterpretations to avoid

Example: Customer Obsession for an Infrastructure Team

Principle: We start with the customer and work backwards. We obsess over customer experience, not technical elegance. (Unless you know better.)

Why it matters: Infrastructure teams naturally optimize for technical metrics (uptime, latency, throughput). These matter, but they’re proxies for customer value. We must connect our work to customer outcomes.

What it looks like:

• Design docs start with customer impact: “This reduces deployment time from 30 minutes to 5 minutes, enabling faster iteration”
• We measure customer-facing metrics: time to deploy, time to recover, developer productivity
• We talk to our customers (internal engineering teams) regularly
• We prioritize work by customer pain, not technical interest
• We ask “how does this help customers ship faster/safer/better?”

What it doesn’t mean:

• It doesn’t mean we ignore technical excellence-we need both
• It doesn’t mean we build everything customers ask for-we work backwards from needs, not requests
• It doesn’t mean we sacrifice long-term architecture for short-term wins

When you know better: You’re building foundational infrastructure (like a new consensus protocol) that has no immediate customer impact but enables future capabilities. You know better-invest in the foundation.

Example: Have Backbone; Disagree and Commit for a Distributed Systems Team

Principle: We’re obligated to voice disagreement respectfully. Once a decision is made, we commit completely. (Unless you know better.)

Why it matters: Distributed systems decisions have long-term consequences. We need diverse perspectives to make good decisions. We also need to move fast once decisions are made.

What it looks like:

• In design reviews, we challenge assumptions: “Have we considered the failure modes?”
• We bring data to disagreements: “Here’s the latency impact of approach A vs B”
• Decisions have clear owners who listen, then decide
• After decisions, we commit: “I disagreed, but we’re going with Kafka, so I’m all in”
• We revisit decisions only when new information emerges

What it doesn’t mean:

• It doesn’t mean we argue endlessly-there’s a decision point
• It doesn’t mean we’re disagreeable-we’re respectful and data-driven
• It doesn’t mean decisions are permanent-we can revisit with new information

When you know better: The decision was made, but you discover a critical security vulnerability in the chosen approach. You know better-escalate immediately and reopen the decision.

Operationalizing Tenets

Writing tenets is easy. Living them is hard. Here’s how to make them real:

1. Hiring

Use tenets in behavioral interviews. For each tenet, prepare questions that probe for evidence:

Customer Obsession: “Tell me about a time you had to choose between technical elegance and customer value. What did you do?”

Earn Trust: “Tell me about a time you made a mistake that affected your team. How did you handle it?”

Have Backbone; Disagree and Commit: “Tell me about a time you disagreed with a decision but had to implement it anyway. What did you do?”

Hire people who demonstrate these behaviors. One person who violates tenets can poison team culture.

2. Decision-Making

Reference tenets explicitly in meetings:

• “Let’s apply Customer Obsession here-what does the customer actually need?”
• “I’m invoking Have Backbone-I disagree with this approach, and here’s why”
• “This is an Earn Trust moment-let’s be candid about the risks”

This reinforces that tenets aren’t wall art-they’re decision-making tools.

3. Performance Reviews

Evaluate engineers against tenets, not just technical skills. An engineer who ships great code but violates Earn Trust (hoards information, blames others) isn’t a high performer.

4. Retrospectives

When things go wrong, ask which tenet was violated:

• “We shipped a feature customers didn’t want-did we violate Customer Obsession?”
• “The incident response was chaotic-did we violate Earn Trust by not being candid about the severity?”
• “We debated the architecture for three weeks-did we violate Have Backbone; Disagree and Commit?”

This turns failures into learning opportunities about culture, not just technical issues.

5. Onboarding

New team members should learn tenets on day one. Explain each tenet, give examples, and show how they guide decisions. Make it clear that tenets aren’t suggestions-they’re how this team operates.

Common Mistakes

Mistake 1: Too Many Tenets

More isn’t better. Three to five tenets is optimal. More than that and people can’t remember them. Focus on what matters most.

Mistake 2: Generic Tenets

“Work hard” and “be collaborative” aren’t tenets-they’re platitudes. Tenets should be specific to your team’s context and challenges.

Mistake 3: Stating the Obvious

If your team already does something well, don’t make it a tenet. Tenets should emphasize behaviors you need to cultivate, not behaviors you already have.

Mistake 4: Writing Tenets and Forgetting Them

Tenets on a wiki that nobody reads are worthless. Tenets must be lived-referenced in meetings, used in decisions, evaluated in reviews.

Mistake 5: Tenets Without Teeth

If violating a tenet has no consequences, it’s not a real tenet. High performers who violate tenets should be coached or moved. Tenets must matter.

Evolution Over Time

Tenets aren’t permanent. As your team matures, behaviors that needed emphasis become ingrained. When that happens, update your tenets.

Review tenets annually:

• Are these still the behaviors we need to emphasize?
• Are there new behaviors we need to cultivate?
• Are we living these tenets, or are they just words?

Culture evolves. Your tenets should evolve with it.

For Engineering Leaders

If you’re forming a new team or joining an existing one, defining mission, vision, and tenets is one of the highest-leverage activities you can do.

Week 1: Draft mission and vision. Share with the team. Iterate based on feedback.

Week 2: Identify 3-5 tenet candidates. Consider team composition, challenges ahead, and behaviors you need.

Week 3: Write tenets with examples. Share with the team. Refine based on discussion.

Week 4: Publish tenets. Start referencing them in meetings and decisions.

Ongoing: Live the tenets. Reference them constantly. Evaluate against them. Update them as needed.

This isn’t a one-time exercise. It’s the foundation of your team’s operating system.

For Engineers

If your team doesn’t have tenets, propose them. You don’t need to be a manager to drive culture.

Start with the three essentials: Customer Obsession, Earn Trust, Have Backbone; Disagree and Commit. Write a one-pager explaining why these matter for your team. Share it with your manager and teammates.

If your team has tenets but doesn’t live them, call it out:

• “Our tenet is Customer Obsession-are we starting with the customer here?”
• “Our tenet is Earn Trust-let’s be candid about the risks”
• “Our tenet is Disagree and Commit-I disagree, but I’ll commit once we decide”

Culture is everyone’s responsibility. You don’t need permission to live the tenets.

Conclusion

High-performance engineering teams don’t happen by accident. They’re built on shared understanding of mission, vision, and tenets.

Mission and vision provide direction. Tenets provide the operating principles that guide daily decisions. Together, they create alignment without requiring constant oversight.

Amazon’s Leadership Principles are the gold standard, refined over 30 years of building world-class engineering teams. Your team doesn’t need all 16, but you need the core: Customer Obsession, Earn Trust, and Have Backbone; Disagree and Commit.

These three tenets address the most common failure modes:

• Customer Obsession prevents building the wrong thing
• Earn Trust enables collaboration and speed
• Have Backbone; Disagree and Commit enables high-velocity decision-making

Define your tenets based on your team’s context. Write them clearly with examples. Reference them constantly. Evaluate against them. Update them as you evolve.

Tenets aren’t wall art. They’re decision-making heuristics that scale culture. When an engineer faces a decision and you’re not in the room, tenets guide them to make the choice you would make.

That’s how you build high-performance teams that operate independently, make good decisions consistently, and deliver results.

The mission tells you why you exist. The vision tells you where you’re going. The tenets tell you how to get there.

Define them. Live them. Win.

---

David Lapsley is CTO at Actualyze.ai, focused on distributed systems and cloud infrastructure. Previously VP of Engineering at Metacloud (acquired by Cisco) and AWS executive where he learned the power of Leadership Principles in building high-performance teams.