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:
Junior
Mid
Senior
Principal
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.
Autonomy
JUNIOR PROGRAMMER
Work is thoroughly reviewed with substantial back’n’forth frequently needed before merging.
PROGRAMMER
Work is reviewed with the occasional need for material direction or implementation changes.
SENIOR PROGRAMMER
Work doesn’t necessarily need to be reviewed, but the general approach may be.
LEAD PROGRAMMER
Work happens completely autonomously with no regular need for review.
PRINCIPAL PROGRAMMER
Fully capable of designing, owning, and running entirely new, novel systems (design billing systems, Trix, Active Record from scratch)
Technical mastery
JUNIOR PROGRAMMER
Basic language features are mastered, but some advanced structures may still be unfamiliar.
SENIOR PROGRAMMER
Deep expertise within at least one programming environment.
LEAD PROGRAMMER
Deep, substantial expertise in multiple programming environments.
PRINCIPAL PROGRAMMER
Recognized widely in the industry for material contributions to the state of the art. Invents new concepts, pushes the whole organization forward regularly.
Consistency
JUNIOR PROGRAMMER
Occasional issues following patterns and approaches within existing code bases.
PROGRAMMER
Follows established patterns and approaches within existing code bases with ease.
Mentorship
SENIOR PROGRAMMER
Can provide material feedback on the work of junior programmers and programmers.
Scope of work
JUNIOR PROGRAMMER
Works primarily on tightly scoped, routine problems.
SENIOR PROGRAMMER
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).
LEAD PROGRAMMER
Work happens completely autonomously with no regular need for review.
PRINCIPAL PROGRAMMER
Can set and direct an entire department, like SIP, Core Product, or Research & Fidelity.
Relevant experience
JUNIOR PROGRAMMER
Usually less than 2 years of experience being a professional programmer in the specific domain.
PROGRAMMER
Usually at least 2–5 years of experience being a professional programmer in the specific domain.
SENIOR PROGRAMMER
Usually at least 5–8 years of experience being a professional programmer in the specific domain.
LEAD PROGRAMMER
Usually at least 8–12 years of experience being a professional programmer in the specific domain.
PRINCIPAL PROGRAMMER
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.
ENGINEER X – JOB TITLE
How is the work done? Who decides how time is spent?
What level of problem-solving do they apply to their work?
How advanced are their technical skills?
How consistent is their work?
How effective are they at managing multiple responsibilities?
How broad of a view do they take about their work?
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.
ENGINEER X – JOB TITLE
How is the work done? Who decides how time is spent?
People and team, Judgment, Delivery
What level of problem-solving do they apply to their work?
Content, Delivery
How advanced are their technical skills?
Tools and processes
How consistent is their work?
Tools and processes, Judgment
How effective are they at managing multiple responsibilities?
Judgment
How broad of a view do they take in their work?
Judgment
What do they do to keep learning?
Drive to grow
Scale them
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.
ENGINEER 1 – JUNIOR ENGINEER
Most work is assigned by epic lead or PM. Expectation is that substantial communication and iteration occur before code is merged.
People and team, Judgment, Delivery
Does development work within other people’s functions or specializations. Fixes bugs, makes modifications, and implements features concretely defined by Pivotal stories.
Content, Delivery
Basic language features are mastered, but advanced concepts may not be.
Tools and processes
May be challenged to follow patterns defined in existing codebases.
Tools and processes, Judgment
May be challenged in focusing on and completing a single task before moving on. Working on prioritizing work by value.
Judgment
Can articulate the context of their current story.
Judgment
ENGINEER 2 – MID ENGINEER
Work is reviewed. Expectation is that work occasionally needs changes in architecture, design, or implementation, but that they seek review at the right time.
People and team, Judgment, Delivery
Follows established patterns and approaches within existing code bases with ease.
Tools and processes
Works mostly on clearly defined and scoped individual features or problems. Doesn’t often identify the next steps or uncover unknowns by themself.
Content, Judgment, Delivery
Can articulate the context of the current sprint.
Judgment
ENGINEER 3 – SENIOR ENGINEER
Work doesn’t necessarily need to be reviewed, but the architecture and overall design require input.
Judgment, Delivery
Junior programmers request your feedback as a trusted expert.
Content, Judgment
Owner of multiple services within the system. e.g., Rails App, Viz, Mobile, Poll Renderer, Apps.
Content
Prioritizes own time to deliver at or above expectations on more than one objective. Incorporates ongoing commitments and responsibilities alongside their primary project. Focuses on the most important details and minimizes bikeshedding.
Judgment, Delivery
Consistently participates in all parts of delivering an epic including architecture, project planning, communication, documentation, and execution. Considered essential to the project’s success. Fully capable of taking substantial features from concept to shipping.
Solution seeking, Content, Delivery
Continuously invests in personal development and brings knowledge to the rest of the team (e.g., by reading books, blogs, papers, attending conferences, or participating in open source software.)
Drive to grow
Can articulate the context of the current epic.
Solution seeking, Judgment
ENGINEER 4 – PRINCIPAL ENGINEER
Fully capable of designing, owning, and running entirely new epics from scratch, especially when ideas are ambiguous and not fully fleshed out.
Solution seeking, Content, Judgment
Able to step back and see the system as a whole to question existing assumptions and drastically simplify or improve the design.
Solution seeking, Drive to grow, Judgment
Plugged into the community to be able to recognize and judge the state of the art, incorporating what will benefit PE.
Drive to grow, Tools and processes, Judgment
Invents new concepts, pushes the whole organization forward regularly.
Solution seeking
Acts as a force multiplier across the Engineering organization by making entire teams operate more efficiently.
Drive to grow, Judgment, People and team
Can articulate the context of all running projects and the implications for future work and our future product offering.
Solution seeking, Drive to grow, Judgment
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.
Apply them
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.
Iterate
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.
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.
Our previous performance categories for Engineers
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.
Tread carefully
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.
Wrap up
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 team hear how they’re progressing? Give it a try for free.
