Introducing the Chirp Team Title Ladder

Today we’re introducing the world to the Iora Health Chirp team’s title ladder, which details the roles within the three main functions of our group: engineering, product management, and product design. We’re pleased to share this publicly, as we’re proud of the way we built the ladder, happy with the resulting documentation, and feel that it’s valuable in this industry where titles and their associated expectations are decidedly nonstandard. We’ve taken a fresh look at how title ladders are used in practice, and we’ve rebuilt ours in a people-focused way.

Feel free to jump right to the ladder itself, but for the curious, we’d like to tell the story of how we got to where we are today, the problems we set out to solve, and how it has all been working in practice. We’ll spend some time discussing the process of creating our ladder in the hope that organizations looking to build their own will find plenty of insightful information and inspiration.

The following discussion is centered around the engineering ladder, but the same ideas and process can be (and were) applied to other functions such as product design and product management. We simply began with engineering, so that is where our story starts.

Initial approach: the competency matrix

Back when we were a small startup engineering team of eight engineers, there were two titles: Software Engineer and Senior Software Engineer. The delineation between the two was based mostly on gut feel, but we were small, scrappy, and had little time for formalities.

As the team grew, and it became clear that engineers were building a career at Iora, the desire and need for titles that truly reflected the experience and capabilities of our engineers became clear. There became a need to make sure that we had a formal and standardized way in which an engineer’s performance was evaluated. For that to happen, we needed to ensure that expectations for title levels were clear and that promotions were fairly rewarded based on standard criteria rather than subjective feeling.

Elsewhere in the company, Iora defines six levels for individual contributors (which we denoted with Roman numerals I through VI), with the first being entry level up to the sixth level right before director. Levels are further divided into three groups called “bands”, where each band contains two consecutive title levels. As we set out to define our initial set of engineering titles, this was our starting point.

Our first pass at a title ladder was represented in a spreadsheet by what’s known as a “competency matrix.” Down the left hand side were six title levels grouped into three bands. Across the top were the engineering “competencies”. The competencies we included were “code delivery”, “feedback”, “initiative”, etc. In theory, by tracing across from a title and down from a competency, an individual would know what’s expected at each level. Both titles in a band shared the same description for each competency. The first title in a band corresponded to “learning and beginning” a competency, while the second title in the band meant “showing expertise” in the competency.

Example comptency matrix
It seemed like a good idea at the time

Problems with the competency matrix

This approach worked for a little while, but its flaws became apparent over time. First, while the matrix shows you what’s expected, it doesn’t help individuals map out growth plans. Competencies alone tell us what we do, but not how to get there. Further, simply listing competencies implies they are all equally important at each level, which is something that shifts as you progress in your career. As an entry level engineer, should you focus on code delivery and leadership equally? A matrix doesn’t help answer that. In fact, some competencies barely applied to some levels. Yet because all competencies were listed across the top, they were there along with the others. The lack of ranking competencies made activities such as peer reviews or growth planning difficult, because it wasn’t clear which competencies should be concentrated on first.

The spreadsheet format itself also proved to be problematic. Apart from the difficulty of digesting a specific title level, simply listing competencies for each level seemed to imply that as long as an individual showed success at the competencies, they should be promoted. In other words, it looked like a checklist. The matrix format also made it difficult to distinguish between success and growth in an area, especially between titles in a band. Finally, a matrix didn’t allow for inclusion of intangibles, skills, and behaviors that are characteristic of some roles but don’t fit nicely into a single spreadsheet column.

The result was that people were confused about their title levels, what skills they needed to develop, and how their performance was evaluated come annual review time. If we let that continue, we’d be failing our people, so in 2020, we set out to refresh, revamp, and reformat our title ladder.

Evolving our ladder

It was clear from the limitations of the competency matrix that we wanted to move to a more documentation-oriented format – but how would it change? We wondered: if a title ladder is to satisfy its goals, what questions should it answer? For any individual reading the description of their title level (or a peer’s title level), a good ladder document should answer the following questions:

  • What are the expectations of this level?
  • How are folks at that level evaluated for success?
  • How does someone at that level show they’re ready to progress?

With these questions in mind, Principal Engineering Manager Patrick Robertson, and I set out to document clear, comprehensive answers for each engineering title level in our organization. To get our bearings, we began by reading through a bunch of published title ladders from other engineering teams. Each of us also kept detailed notes about our expectations for folks at each level. We tuned these over time as we observed our engineering team in action, and as we managed various situations and team dynamics. For instance, if anything prompted us to say, “wow that is exactly what I’d expect from a senior engineer”, we’d make sure to note that down appropriately.

After a few months of observation, we were ready to start on the ladder in earnest. To write it, Patrick and I split up the titles two at a time, each of us taking one. We set a meeting two weeks into the future as a “due date” for each title writeup. In the meantime, we reviewed our notes for each level, and thought about the engineers who reported to us – What do they do well? Where do they need development? What do we expect of them? We’d write down what we believed was a complete picture of the title level. When we met next, we read and discussed our writeups, and made adjustments as needed. One thing to note was that we didn’t try to make them perfect or complete just yet. That step would come later.

As we met about each title level, discussed each writeup, and double checked that the three goal questions were addressed, we discovered a common format for each title level entry. The entry for each title level included six sections:

  • Summary: Short description of the role
  • Typical Tenure: Number of successful years it typically takes from promotion into the role through progression into the next role. Everyone’s journey is different, but anything under the minimum or over the maximum is considered unusual
  • Focus: Short description of the key drivers of success for the role
  • What Success Looks Like: A more detailed description of the responsibilities and competencies of a person at this level
  • Evaluation Criteria: The questions, that when answered affirmatively, would indicate that an individual has been successful within the role
  • Growth Path: An overview of the skills an individual must possess and demonstrate in order to grow into the next title

With each title level drafted in this standard format, the real work began. For each level, we gathered all engineering managers who had at least one individual at that level who reported to them. We asked managers to read the writeup about the level in question while thinking about their direct reports and how they’d evaluate against it. We then held a forum with those managers – the goal being to refine and clarify the entry. Over the course of a couple weeks, we did this for all six levels which resulted in title entries that every manager was comfortable with.

Once all title levels had been refined, we then consolidated them into a single document and walked through the whole thing from start to finish. The idea was to make sure the progression and growth paths made sense. We caught a number of inconsistencies by going through this exercise, and fixing them resulted in a cohesive “career story” that could be followed from entry level all the way up to the senior staff level. We completed it all by writing an introductory section that described the format and the goals of the ladder itself.

The final step of the process was to solicit feedback from the engineering team at large. We had already made sure that folks knew this was something we were working on, so it wasn’t a surprise when we introduced it in a whole-team meeting. The ladder was shared with everyone in a Google document, and we held an open comment period. The comment period generated a lot of really good feedback, observations, and suggestions, many of which resulted in edits to the ladder – some even prompted complete rewrites of some paragraphs and sections! Managers were also encouraged to spend some time in their 1:1s walking through the relevant sections with their team members.

Only after all of this was complete could we call the ladder finalized. While this seems like a lot of work to produce (it was!) we believe each step of the way was incredibly important. Starting with just the two senior engineering managers allowed us to set a direction and decide on a format. Getting managers together to refine and finish each entry allowed us to include different perspectives and get feedback early on. Conducting an open comment period let us further refine, adjust, and clarify based on the impressions of the people most affected. Together, collaboration at many levels helped ensure a collective sense of ownership and a smoother path to acceptance of the new ladder.

Where we are today

Shortly after completing the title ladder for the engineering side, our Director of Product, Chris Vossler, began replicating this process for the product design and product management titles. The work done on the engineering ladder helped lay the foundation for the rest of the titles, giving Chris a great starting point with format, goals, and other groundwork. The product management and product design ladders were completed in record time, and we are incredibly proud to have a comprehensive title system for our entire Chirp team.

In the handful of months that the revamped ladder has been in effect, we’ve already had much success. We’ve been able to communicate with clarity about what each title level means. The ladder has helped us through one quarterly feedback cycle and one annual review cycle, enabling peers to provide their colleagues with effective and targeted feedback supported by the expectations of their role.

The ladder has also helped us in our most recent round of promotions. Individuals who vaguely felt “ready” for promotion finally had a reference to use when creating their self-assessments. There were others who, after completing their self-assessment and comparing it to the expectations for progression, found confidence and reinforcement that they were in fact ready for promotion. Getting everyone on the same page as to what each title means helps reduce feelings of imposter syndrome and other potential bias, and gives everyone agency over their own career progression.

For those not yet ready for promotion, our ladder has enabled managers to conduct grounded, objective conversations about where growth and development is needed in order to progress. Because of this, individuals have been able to use the ladder to set goals that put themselves on a path towards progression. Once again, a clear ladder is a tool for ensuring that employees have agency over their career path.

Our work is far from done, though! We’ve just begun to include the questions from the evaluation criteria sections in our quarterly peer feedback questionnaires. Over time we’ll see how this works and will tune that process accordingly. Our hope is that thinking about these questions frequently will generate more objective data on individual performance. Finally, we’d still like to revisit this process to produce entries for managers, directors, and other roles within the organization.

Refreshing our title ladders has been a great experience overall, and we’re so very happy to share it with you today!


Enjoy career-planning and goal setting? Love the idea of clarity in title expectations? Want to work somewhere you’re supported in this?

Great news, we’re hiring!

Check out our engineering team’s job listings today!