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 that there was something beyond their current skill level
- Empower leads to participate more in the day-to-day decision making for their projects
- 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
- Basecamp Junior programmer: Work is thoroughly reviewed with substantial back’n’forth frequently needed before merging.
- Basecamp Programmer: Work is reviewed with the occasional need for material direction or implementation changes.
- Basecamp Senior programmer: Work doesn’t necessarily need to be reviewed, but the general approach may be.
- Basecamp Lead programmer: Work happens completely autonomously with no regular need for review.
- Basecamp 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 about the 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 I – 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 II – 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 III – 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 IV – 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. Time and complexity. 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 won’t know details as well as the person 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 copy of ours as of April 2022 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. Our internal language defines Software Engineer 2.x where 2 means the second level of our IC Engineer ladder and x is 1, 2, or 3 to describe their tertile of skill at that level.
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. Here’s an example for IC Engineering that contrasts early career skill and later career skill. 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, we 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?
- Do you think the progression from one level to the next makes sense?
- Would you feel comfortable being evaluated against this ladder in the future?
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.
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.