Why (and when) you should create an Engineering Charter for your team

Every engineering team has their “way” of engineering … what they value, how they approach certain decisions, how they interact with one another. When a team is small (acting pretty much as a single team), this can be implicit and everyone (including new hires) will normalize quickly and act in a consistent manner. Everyone on the team knows what the character of the team is, but there isn’t really a need to write it down.

A critical stage in the growth of an engineering team is when the team is too big to act as a single team, with a single set of priorities. Communication gets unwieldy, standups are long and painful, and areas of longer term focus and ownership are unclear. The team then splits into smaller teams, each focusing on a certain area or initiative. (Note: there are many ways to divide your teams, with significant pros and cons. Perhaps a topic for a future post.)

This is when you need to write your Engineering Charter.

Having a published Engineering Charter enables your various teams to focus on their work and act with autonomy, while remaining aligned on the fundamental principles that are important to all and should be followed consistently. When a decision needs to be made, engineers can use their detailed knowledge of the specific situation, map it to the charter, and act, without undue process and synchronous communication slowing them down. Common sense should rule the day, but for tough situations, the charter can serve as a north star and tiebreaker.

There are also strong benefits of a written charter when you consider how your team will continue to grow. With every new engineer joining, there is a risk they can understand the culture and principles of the group differently, depending on which team they join and who their onboarding buddy is. Over time this leads to cultural “drift”, where your original set of values is now diffuse and you didn’t even see it coming. Furthermore, sharing your charter with potential candidates, and even with the outside world, can make sure to attract the right people who will be successful at your company and help filter out those who won’t.

In short, a written charter will help your team scale.

A Recent Example

Now that I’ve hopefully convinced you that writing a charter is a good idea, let me now share what we came up with at my most recent company (Pave).

We decided on 6 primary principles, each becoming a section with supporting and clarifying points. One risk in creating a document like this is feeling like certain things are “missing”, and then continuing to add to the document, making it longer and longer. We did our best to resist this tendency.

People Come First

• Hire for aptitude and attitude; skills can be learned
• Diverse groups make better decisions
• Be supportive and empathetic
• Find your passion
• Work smart, not just hard
• You are not your code

Act Like an Owner

• Balance the short and long term
• Leave things better than you found them
• You are empowered and responsible
• Question goals: Fully understand “why”, not just “what”
• Exercise good judgement, so we need less process
• You can change things

Focus, Focus, Focus

• Clear team priorities are more important than who does what
• Only tackle one or two big things at a time
• Stop starting, start finishing
• Be Agile without constantly switching gears
• Reserve capacity for the little things that come up
• Focus is more important than utilization

Slow Down to Speed Up

• Have retrospectives, and act on them
• Automate away what is most repetitive and costly
• Build self-service tools to enable others
• Scale communications with documents and videos
• Make hero engineering the exception, not the rule

Delight Our Users

• Listen to our users, using any signal we can get
• Ship often with high quality
• Find problems before they do
• Take pride in a world class product
• Ground decisions around value delivered, to all customers

One Engineering Team

• Self-managing pods are the key to scaling
• Engineering excellence requires collaboration across pods
• Communication is a core skill for our engineers
• Make decisions as a team: Disagree and commit

Now what?

Once we’ve created our charter and formalized it, are we done? Of course not! We will continue to refine and adapt our charter as our company and team evolves. We will share key updates with everyone to make sure the words and intent are clear. The right charter today will not be the right charter in a year. But in the meantime, the charter plays a critical role during a significant growth phase of the company. Hopefully you can put this into practice at your company!