This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We’re always looking for talents to join our team check out our careers page
It’s been 3 years since we revised the engineering seniority and compensation policy. Back then we did a research on industry’s best practices to design our own career progression framework.
It served us well, but it was hard to reason about, and the language it used was overly complicated and biased. To compare the two, feel free to check out Engineering seniority and compensation in 2023.
In 2025 we have made a few changes to our career framework to make the promotion process simple and transparent. In this blog post we will explain how this system works and share our most recent salary bands.
Engineering grades at Feather are numbered from SE1 to SE6, where each level requires a certain level of proficiency across the following dimensions: Tech, System, People, Process and Influence. The salary depends on the grade, and the numbers are publicly available.
Job title | Min salary | Max salary |
---|---|---|
SE1 | €45,000 | €60,000 |
SE2 | €60,000 | €70,000 |
SE3 | €70,000 | €80,000 |
SE4 | €80,000 | €90,000 |
SE5 | €90,000 | €100,000 |
SE6 | €100,000 | €110,000 |
Worth noting that when we talk about salary, we mean the money you take home before taxes. We’ve seen companies doing tricks to artificially inflate the compensation package by adding stocks, perks, and even vacation days (!) in the total compensation.
When we make an offer to someone, it includes their seniority level, their salary before taxes, and their equity package. We also include the benefits – these are the same for everyone in the company.
We review the salary band every year by using the open industry reports. The one in particular that we pay attention to is Rocket X, but we also take into account such sources like levels.fyi and figures.hr.
This system is heavily inspired by the Engineering Ladders framework. In particular, we have adopted the Developer ladder with some minor tweaks to better fit our needs. If that works out well, we might consider introducing the Tech lead and Engineering manager ladders in the future.
This framework does a great job at explaining what behavior is expected from an engineer as they progress through the grades. Each grade is a combination of skills and behavior patterns that are simple to reason about when discussing promotions or hiring decisions:
SE1 | SE2 | SE3 | SE4 | SE5 | SE6 | |
---|---|---|---|---|---|---|
Technology | Adopts | Adopts | Specializes | Evangelizes | Masters | Creates |
System | Enhances | Designs | Designs | Owns | Evolves | Leads |
People | Learns | Supports | Supports | Mentors | Mentors | Mentors |
Process | Follows | Enforces | Challenges | Challenges | Adjusts | Adjusts |
Influence | Subsystem | Subsystem | Team | Team | Multiple teams | Company |
To qualify for a promotion (or a hire) at one of these grades, the engineer is expected to perform at the required level across all dimensions, and they should be able to demonstrate that they have been doing this for some time already.
You can find an expanded description of each grade below. In case we need to go more detailed, we discuss it case-by-case in the feedback sessions throughout the year.
- Adopts: actively learns and adopts the technology and tools defined by the team
- Enhances: successfully pushes new features and bug fixes to improve and extend the system
- Learns: quickly learns from others and consistently steps up when it is required
- Follows: follows the team processes, delivering a consistent flow of features to production
- Subsystem: makes an impact on one or more subsystems or features
- Adopts: actively learns and adopts the technology and tools defined by the team
- Designs: designs and implements medium to large size features while reducing the system’s tech debt
- Supports: proactively supports other team members and helps them to be successful
- Enforces: enforces the team processes, making sure everybody understands the benefits and tradeoffs
- Subsystem: makes an impact on one or more subsystems or features
- Specializes: is the go-to person for one or more technologies and takes initiative to learn new ones
- Designs: designs and implements medium to large size features while reducing the system’s tech debt
- Supports: proactively supports other team members and helps them to be successful
- Challenges: challenges the team processes, looking for ways to improve them
- Team: makes an impact on the whole team, not just on specific parts of it
- Evangelizes: researches, creates proofs of concept and introduces new technologies to the team
- Owns: owns the production operation and monitoring of the system and is aware of its SLAs
- Mentors: mentors others to accelerate their career-growth and encourages them to participate
- Challenges: challenges the team processes, looking for ways to improve them
- Team: makes an impact on the whole team, not just on specific parts of it
- Masters: has very deep knowledge about the whole technology stack of the system
- Evolves: evolves the architecture to support future requirements and defines its SLAs
- Mentors: mentors others to accelerate their career-growth and encourages them to participate
- Adjusts: adjusts the team processes, listening to feedback and guiding the team through the changes
- Multiple Teams: makes an impact not only on the whole team but also on other teams
- Creates: designs and creates new technologies that are widely used either by internal or external teams
- Leads: leads the technical excellence of the system and creates plans to mitigate outages
- Mentors: mentors others to accelerate their career-growth and encourages them to participate
- Adjusts: adjusts the team processes, listening to feedback and guiding the team through the changes
- Company: makes an impact on the whole tech organization
Our old seniority grid went into a great detail about every aspect of the job. We described what is expected from an engineer in regards to hiring, code reviews, writing documentation, collaboration, and many more.
We have found that such level of detail is not necessary, especially because most of these requirements are the same across all levels, and any attempts to grade them would be counter-productive.
We have moved such requirements to a more appropriate place: individual role descriptions. A role description is a document that lists concrete, actionable expectations for every member of the team. We will write about this document separately.