Skip to content

Latest commit



77 lines (66 loc) · 4.53 KB

File metadata and controls

77 lines (66 loc) · 4.53 KB

Engineering Principles

This document describes the kind of engineering team we are, and in some cases aspire to be.

It’s important to write it down so we can achieve & perpetuate it. We do this by using it as the basis for:

  • Hiring. Job descriptions & bands, crafting of our interview process.
  • Individual growth & feedback. Job bands & discussions about opportunities.
  • Team growth & improvement. Goals, KPIs, and associated projects, ceremonies, and time allocation.

Tactically, it can & maybe should cover:

  • Best attributes & behaviors. E.g., we geek about new technologies and generally, learning things
  • Habits & general best practices E.g., we own it in production and ensure we have ways to see if it’s working
  • Goals & high level time allocation E.g., we make time for quality and use that time to do proactive things like clean up code, write tests
  • Desired results E.g., we’re seen as one of the top engineering teams by folks outside Envoy

Our principles:

We maintain high standards

  • We know perfect is the enemy of good, but we aspire for great.
  • We keep things small and simple. One layer of the onion at a time. Commits, PRs, tickets, communication.
  • Moving fast and decisively helps us deliver value, learn and improve, and achieve quality faster.
  • We embrace that change is constant. The industry, technology, our customers, our business, and our team will change and as such, our code will and should change.
  • We build durable habits and practices.

We take pride in doing things right

  • We feel personally accountable and responsible for the health of our product, code, and systems.
  • We make doing the right thing to do easy to do, and invest the time to do it. E.g., taco, great tests, guilds.
  • We leave code better than when we found it
  • We care about standards and tech debt, and push back when we need to
  • We automate repeatable tasks
  • Features are not done until they have long term support (runbook, logging, metrics)
  • We deeply understand the importance of creating proper tests

We act like owners and keep context

  • We love engineering and technology, but we solve for our customers and the bigger teams 1st.
  • If we can’t unanimously articulate why we’re doing something, we don’t do it.
  • We solve problems we actually have before ones we might.
  • We use data to tell us the story. If we don’t have data, we prioritize getting it.
  • We make decisions as a group after informed discussion. Decisions are not dictated from the top, or from the person making the loudest noises, rather they’re based on merit, options, and criteria.
  • We look for problems and inefficiencies and find elegant solutions before they become major issues.
  • We act with appropriate urgency when the situation calls for it.
  • Ship it. We ship relentlessly and fearlessly yet with pragmatism.

We lift each other up

  • We’re happy when helping others succeed. We prioritize pushing, helping, and teaching each other.
  • We make sure everyone has a voice. We crave diversity of experiences, backgrounds, opinions, ideas, and locations and feel uneasy without it.
  • We keep things rational, objective, and shared.
  • We work together toward shared goals
  • We start with trust in each other and build from there. We assume good intent and skill 1st.
  • We’re humble. None of us is as smart as all of us.

We’re High I/O

  • We overcommunicate. Our PRs, tickets, docs, code, emails, etc. all have enough context to help the reader.
  • We ask and listen 1st
  • We track and share our work early and often, in service of others

We continuously get better

  • We live to learn new things and constantly improve our craft, like staying up to date on new technologies, tools, and techniques.
  • We’re inspired by what's possible as well as what people inside and outside Envoy know, and eager to incorporate the best. We use and contribute to open source, for example.
  • We try things then learn from them and iterate. Retrospectives > postmortems.
  • We learn by doing, more so than talking
  • We encourage cross-pollination of work so we don’t establish gatekeepers of work.
  • We aim to not be bored, because we know we’re at our best when we’re not.
  • We love and seek feedback. PRs, data, tests, asking people….it’s all good.