Skip to content
Permalink
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
78 lines (66 sloc) 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.
You can’t perform that action at this time.