IN
CHORUS
October 2020
How I built an
engineering ladder
guide

Note:
This article is cross-posted from Poll Everywhere’s blog.

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:

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.

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 the engineer’s 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 the engineer’s 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 are ours as of October 2020 and the changes we proposed after the first year.

Take-aways

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:

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.

Matt from encoro

I’m Matt ⚡, making encoro for 360° feedback. Want to help your engineers hear how they’re progressing? Give it a try for free.