Performance Scale

The goal of the Performance Scale is to provide you with a clear guideline for what is expected of you as an engineer, and how you can expect to grow in your role.

There are certain principles that we feel everybody should follow regardless of seniority, and others that are most relevant at a particular level of seniority.

⚠️ Caveat: these aren't strict definitions of Engineering levels. You don't need to be L3 at everything to be a Level 3. We're thinking of this as more of a "Skill Tree" to better visualise skills development. This is also a bit more simplistic than the performance scale you might find in some more mature organisations, for example it currently does not cover higher levels. This reflects the stage we are at as a business and the current size of the team.

• (For reference, expand to see some more fully fledged engineering scales)

💬 Communication

• In general, we try to never stop learning and share knowledge. We should support everyone else on that journey, particularly if they do not have as much expertise in certain subjects. Nobody should ever feel like a learning is too basic to share or feel stupid for not knowing something. Rubber duck debugging should never be frowned upon.
• Communication as an engineer does not just cover your immediate interactions with your team, managers & others around you, but also the code, documentation, tickets and PRs you produce: if you can't communicate your intent and ideas clearly in code and its surroundings, everyone else on the team will have a harder time basing their work off of yours. This involves defining concepts and abstractions with precise purposes that can be understood by others, and making a continuous effort to ensure that naming in the codebase clearly maps to these concepts.
• We want every PR to be reviewed by at least one other engineer. The purpose of this is not necessarily sign-off from a senior team member, but to ensure that everybody on the team has a strong understanding of our codebase and how it is evolving. We try to always follow code review best practices, as reviewers and as authors. If a junior team-mate asks for clarification on parts of a PR, it's a good sign that the code is difficult to understand, and probably needs to be made clearer.
• We try to always follow the "strong opinions, loosely held" approach: we try to always consider other peoples' opinions before defending our own, and don't ever take ownership of ideas. We try not to refer to ideas as "$person's idea", but rather to the idea itself. This creates a more collaborative environment, where everyone can feel like they contributed, even if they weren't the first to mention an idea. (We call this Lachenmayer's Principle, duh)

Levels

• L1
  • Able to spot problems/blockers and promptly escalate to someone who can provide guidance.
  • Proactively seeks out feedback, and is not defensive about receiving ideas for improvement.
  • "Asks for guidance, not answers".
• L2
  • When requested, helps their teammates overcome obstacles, resolve blockers, and complete work tasks. Gives or shares credit where due.
  • Proactively seeks out feedback from others.
  • Provides valuable input to proposals from other team members.
  • Able to write effective PR/ticket descriptions, and understands when to add comments to code that is difficult to understand.
  • Actively seeks to clarify issues with naming or concept definitions in the codebase.
  • Actively listens to others and ensures they are understood.
• L3
  • Able to mentor more junior team members by showing them relevant resources and giving precise feedback.
  • Can effectively share learnings with entire team (incl. non-technical), through eg. technical sessions or writing docs.
  • Helps people in non-technical roles understand technical constraints or trade-offs in a clear manner. Can effectively describe the exact purpose of any given concept (or proposed concept) in the codebase to any member of the team (incl. non-technical).
• L4
  • Able to teach & mentor more junior engineers in scalable/repeatable ways, either through written guides/documentation, or workshops/talks, or any other
  • Represents our engineering team within the industry, whether through technical writing, recruiting efforts, giving conference talks, etc.
  • Creates and actively maintains clear documentation of the systems they're working on.
  • Able to accurately estimate scope of work, and when those estimates are off, coordinates with stakeholders to address risks, and take ownership.

🤖 Technical expertise

• Our over-arching engineering principle is to "do the simplest possible thing that will work". Sometimes, finding this simplest thing is much more work than doing something complex, or just passing the work off to an external dependency, but the simplicity will pay back once someone else (including you, 6 months from now) will have to understand it. One of the most difficult skills to master as an engineer is to understand when complex solutions are truly required, and when a simpler one will do.
• We still have the luxury of having a codebase that is still small enough to (more or less) fit into a single brain. Understanding this codebase, and its dependencies, as deeply as possible, will make you vastly more effective. When writing code, we try to make sure that the code can be understood by everyone on the team.
• At every level, everyone should proactively improve modules, services, systems, and documentation they encounter. 'I'm going to do something about it' should always be the first response to anything that doesn't make sense, whether that means fixing typos, refactoring components, or evolving an API. We should always communicate our ideas for improvement to the team, and always keep in mind Chesterton's fence: don't take down a fence unless you truly understand why it was put up in the first place.