Around a year and a half ago, we rolled out a career progression for Poll Everywhere engineers. I’ve organized my reflections about this work into a step-by-step guide to define an Individual Contributor ladder for your engineering team.
Poll Everywhere was founded in 2007 by three engineers with consulting backgrounds. Our Engineering team didn’t put this progression in place until 2018. 11 years is a long time to go without formal levels.
This flat organization was intentionally chosen by the founders. In the early days, each one enjoyed wearing many hats, jumping into the code as needed, and had reservations about implementing the corporate hierarchy they’d seen at large companies that hired their consultancies.
As our team size crossed 20 people, we started to feel some growing pains. Across specializations, it became harder to focus on shared technical goals and to clearly communicate the priorities of each group. We opted to solve this by adding structure on our own terms.
We developed a concept of leads for each technical specialization. However, as we clarified responsibilities for a handful of technical leaders, Individual Contributors began asking for more transparent expectations for their roles.
On top of documenting engineering responsibilities, I had a few additional goals for the team:
- Inspire engineers to something beyond their current skill level
- Empower leads to participate more in project decision making
- Team buy-in for the ladder
- Avoid aimlessly checking tasks in a list just to advance
Survey the landscape
I started by looking broadly across the SaaS industry to see how our largest companies organize. levels.fyi helped me understand the structure at places like Facebook, Apple, Netflix, and Google.
These behemoths had many more levels than made sense for our team of 20 engineers. I couldn’t identify enough technical problems to justify 5 or 6 levels, let alone a Level 11 Poll Everywhere Senior Fellow.
I ended up with 4 levels, originally called:
Having decided that organizationally we couldn’t support as many levels as the tech giants, I looked to companies closer in size to Poll Everywhere. Rent the Runway, Buffer, and Basecamp all publish their career progressions.
As a small, bootstrapped Rails shop, Basecamp was most similar in size, structure, and ideology. I used their job descriptions to extract a template for our own. Grouping similar responsibilities across Basecamp’s programming levels, I identified categories that unified each set of responsibilities.
Work is thoroughly reviewed with substantial back’n’forth frequently needed before merging.
Work is reviewed with the occasional need for material direction or implementation changes.
Work doesn’t necessarily need to be reviewed, but the general approach may be.
Work happens completely autonomously with no regular need for review.
Fully capable of designing, owning, and running entirely new, novel systems (design billing systems, Trix, Active Record from scratch)
Basic language features are mastered, but some advanced structures may still be unfamiliar.
Deep expertise within at least one programming environment.
Deep, substantial expertise in multiple programming environments.
Recognized widely in the industry for material contributions to the state of the art. Invents new concepts, pushes the whole organization forward regularly.
Occasional issues following patterns and approaches within existing code bases.
Follows established patterns and approaches within existing code bases with ease.
Can provide material feedback on the work of junior programmers and programmers.
Scope of work
Works primarily on tightly scoped, routine problems.
Work doesn’t necessarily need to be reviewed, but the general approach may be. Fully capable of taking substantial features from concept to shipping as the sole programmer (alongside a designer).
Work happens completely autonomously with no regular need for review.
Can set and direct an entire department, like SIP, Core Product, or Research & Fidelity.
Usually less than 2 years of experience being a professional programmer in the specific domain.
Usually at least 2–5 years of experience being a professional programmer in the specific domain.
Usually at least 5–8 years of experience being a professional programmer in the specific domain.
Usually at least 8–12 years of experience being a professional programmer in the specific domain.
Usually at least 12–15+ years of experience being a professional programmer in the specific domain.
Make a template
I generalized the categories into responsibilities applicable to each engineering level.
Make them yours
This template was pretty good but felt too generic. At this point, I wove in company values and existing performance criteria to make it more recognizable at Poll Everywhere.
Next, I applied the template with larger scope and impact for each increasing level of Engineering. When possible, I used internal language to make the descriptions more familiar.
Review with your coachees
I started with my coachees, incorporating their feedback and then opened it up to the rest of our engineers, aiming for general consensus.
I found that most concerns were resolved through more precise, careful language and that there wasn’t much disagreement about the general responsibilities.
The exceptions were project management responsibilities. At the time, we had 2 Product Managers and over 20 engineers. We wanted to protect Product Manager time for bigger picture Product Strategy thinking rather than day-to-day project execution.
Having just read Turn the Ship Around (later Shape Up reinforced this opinion), I wanted to empower the engineering project leads to control their own fate. I argued that even very technical Project Managers wouldn’t know details as well as the people implementing the features.
Though it didn’t exist at the time, I would have loved a resource like Will Larson’s StaffEng. Named after a common job title for experienced technical engineers, Will interviews people, asking about job responsibilities. I found these stories very helpful in convincing my team that technical leadership and impact can often come from areas outside of writing code.
Sit down with each coach and go through the levels to see how their coachees’ work stacks up against expectations of their current role and the one above it. Generally, we expect people to be doing around 75% of the following level routinely before an official promotion.
We do a compensation review yearly in April. After the first year with these levels, I asked the team if they still accurately represented our work. Largely, they did but we tweaked some of the wording to reflect a shift to delivering our projects on 6-week cycles.
After the tweaks, I made a new copy of the levels docs and labeled when it was last updated, linking back to the previous year’s version.
Names for roles
Here’s a mistake I made. Defining an Engineering ladder for Poll Everywhere focuses the expectations around value to Poll Everywhere as a business. However, there’s implicit meaning in job titles used across the whole industry. Engineers often have preconceived notions about what it means to be a Junior or Principal. On top of this, you may end up in a situation where you level someone with a lot of industry experience but less experience in your specific business or the skills that your business values lower than they would expect.
I’d suggest that unless you’re defining levels for a very large company, that you don’t mix titles with levels.
Use existing values and performance frameworks
Our existing performance framework for the whole company was based on a few categories and the idea that there is a spectrum of expertise for the categories in every role. When making a career ladder you don’t need to reinvent performance evaluation from the ground up. In our case, we took the following outline and made it more concrete.
It’s okay to deviate from industry norms
As a small, bootstrapped start-up, we defined one area as important for growth that large companies might not value. At Engineer 3+, we decided that it’s important to the business that Engineers are capable of running a project. This includes scoping work, documenting decisions, managing the release, and critical analyses about trade-offs.
There was a good deal of push back because this is considered Project Management work. Motivated by our internal value of autonomy, I made the case that teams capable of delivering end-to-end value to our customers would lead to a better product and to more satisfied teams building the product.
Ask the right questions
Right now I’m working on a similar career ladder for managers at Poll Everywhere and have found that a few questions lead to much higher quality feedback:
- Do these levels cover the major responsibilities of your job?
- Does the progression from one level to the next makes sense?
- Would you feel comfortable being evaluated against this ladder?
Focus on outcomes
In our communication of this progression, we focused on the impact to the business and less on the amount of effort put forth or the number of tasks completed. Unfortunately, business outcomes (think retention, upgrade rates, etc.) are much less certain than efforts (individual projects and building features).
The more autonomy and creativity you give a role, the less you can articulate “Here are the steps to take for our next big breakthrough”.
Some advice we’ve given people looking for direction is that searching for impact is hard, abstract work and to spend time looking across the organization at systemic problems and then following through with solutions that fix or improve these problems.
Apply them consistently
Ideally, one person (probably you) is involved across each of these discussions to normalize how the progression is applied.
There are going to be strong opinions because you’re codifying rules about how people’s pay is evaluated. Try to really get in your team’s shoes and understand their concerns.
Be very clear when they change
Since these levels are how people are assessed, you must be very clear about when they’ve changed and how they’ve changed.
I hope the detailed step-by-step guide to our engineering career ladder and the research that went into it helps your teams get a better idea of what great looks like at their current levels and inspires them to grow into the next.
I’m Matt ⚡, making encoro for 360° feedback. Want to help your engineers hear how they’re progressing? Give it a try for free.