⚖️Engineering Performance & Pay Scale
Picnic
Posted on Jun 4, 2025
Engineering Performance & Pay Scale
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.
Feature work
L1: Follows exact spec, implements concepts as given.
L2: Able to critique aspects of spec based on technical requirements / potential improvements that haven't been caught, is able to define useful concepts that may make things easier / better, use existing concepts in the system to implement spec.
L3: Understanding of how the feature affects the wider system, can give creative ideas for whole new concepts that fit together in useful ways & have future potential.
L4: Active involvement in shaping feature work in collaboration with stakeholders in the wider company, and understanding of the product and business-level impact of any feature work.
Architecture
L1: Works within the current architecture & existing components.
L2: Able to suggest and/or implement changes to existing components / architecture based on immediate requirements.
L3: Deep understanding of architecture & component structure, suggests and/or implements deep architectural changes with long-term impact.
L4: Ability to design and plan the implementation of entirely new and/or novel systems, and able to motivate design decisions with theoretical foundations or design patterns.
Mobile platform
L1: Comfortable within confines of React Native & TypeScript.
L2: Understanding how native modules, linking, push notifications & other platform-specific features work at a high level, comfortable writing basic native code for wiring up external dependencies etc.
L3: In-depth platform knowledge of either Android or iOS, understanding of native design patterns & architectures for more complex features, understanding of deeper OS-level APIs & tooling.
L4: Expert-level understanding of Android, iOS, and/or React Native, ability to implement & design complex native features and libraries that work reliably at scale.
Backend
L1: Comfortable adding to existing features in the existing architecture, with guidance for designing APIs.
L2: Implementation of new features & designing APIs from scratch including persistence, understanding of error cases in APIs, integration of external APIs in a safe way, understanding of scalability.
L3: Understanding of how the system fits together & individual sub-problems, eg. schema evolution, scalability, persistence, caching, RPC, etc.
L4: Ability to design & implement systems that can operate reliably at scale, makes principled trade-offs, validates assumptions through empirical testing and theoretical knowledge.
Infrastructure
L1: Comfortable performing basic workflows within the existing infrastructure, eg. deployment, releases, error monitoring, checking logs. Able to follow basic runbooks.
L2: Understanding of existing infrastructure and how it is defined, able to make basic changes to infrastructure code (eg. increase resources on an existing service). Able to diagnose issues and effectively add tracing, monitoring and/or alerting to relevant services. Able to perform basic on-call duties including rollbacks in collaboration with other engineers.
L3: Able to make clear infrastructure decisions based on application requirements, time constraints, and budget. Ability to write IaC code to perform required changes. Documents all necessary aspects of the infrastructure, including writing runbooks and keeping them up to date. Clear understanding of operational metrics and symptoms of failure. Takes full responsibility for on-call duties.
L4: Full ownership of all matter related to infrastructure. Ensures that the entire team is able to operate effectively in our infrastructure. Clear understanding of security impact of any infrastructure decisions. Manages on-call responsibilities and leads post mortem reviews. Leads negotiations with external providers. Takes full responsibility for any outages, security breaches or otherwise, including external communications if necessary.
Guidance needed / Planning horizon
We want to ensure that everyone receives the guidance they need, and try to provide tasks that are just challenging enough to make you feel like you're growing in a professional capacity.
The "planning horizon" is how far you're expected to plan your activities, ie. identifying risks ahead of these timeframes, adjusting expectation for delivery if tasks are more complex than they initially appeared.
Levels
L1
Tasks are fully defined up front, mostly affect single components or simple interactions.
Active guidance is needed if task turns out to be more complex or can't be delivered as specced for whatever reason
Planning horizon: 1-2 days
L2
Tasks have less definition up front, may have some element of uncertainty and may have complex solutions. Able to deal with ambiguity in task definitions by making principled decisions and communicating them.
Suggests solutions to potential roadblocks, able to deal with hidden complexity in tasks, able to clearly communicate how that affects the plan for the week/cycle.
Planning horizon: 0.5-1 weeks
L3:
Able to take a high-level product goal, and divide it into meaningful tasks in collaboration with rest of product team.
Able to delegate less complex tasks to more junior team members and give them active guidance if needed.
Planning horizon: 2-4 weeks
L4:
Able to work mostly autonomously, and coordinates efforts across the team rather than working in a silo.
Makes sure that people feel included in varying projects, and that their voices are heard.
Able to accurately estimate scope of work and assign tasks to the entire team, and when those estimates are off, coordinates with stakeholders to address risks, and take ownership.
Planning horizon: 1+ months
Pay Scale
We want to ensure that we pay everyone fairly according to their actual performance and level of responsibility.
We also want to set clear expectations, and reduce bias when negotiating individual salaries.
To try to achieve this, we align all of our engineering salaries to the following salary bands:
Level 1: £30k-£50k
Level 2: £50k-£75k
Level 3: £75k-£100k
Level 4: £100k-£120k
Note that this scale reflects our current level of funding, and will be reviewed as the company grows, eg. at the next funding round.
To achieve a certain level in these salary bands, we expect the majority of your performance scale levels to be at this level, or higher. However, this is not an accurate mathematical formula: we do not use these levels as checkboxes that need to be ticked for you to advance.
As a general guideline, we expect the Communication and Guidance Needed categories to be at the given level, as these areas reflect the way you interact with the rest of the team, and the level of responsibility you are given.
Regarding technical skills, we want to encourage both specialists and generalists. Some individuals might have fairly uniform levels across the board, while others have more of a T-shaped distribution, with one (or more) categories at a much higher level than others.