Earlier in my career, I left a senior engineering position to pursue new challenges at a different company. Following the interview, the team assessed that I should probably start as a mid-level engineer, but I was assured to not worry, because the organization was flat and titles didn’t really matter. A year into my employment with this new company, I received a promotion, but not to senior—to Principal Software Engineer.
The reasoning was that another mid-level engineer on the team was also ready for a promotion, but my manager thought I was “more senior” than that co-worker, so a different title was in order. Needless to say, titles felt quite arbitrary and receiving the promotion was less satisfying than I’m sure it was intended to be.
Why Having a Well-Defined Career Ladder Matters
Without a single source of truth to point to, managers and leaders may find that they each hold a different interpretation of what it means to be a mid, senior, staff, or principal software engineer, based on their personal experiences and bias. Having a well-defined career ladder is an essential tool for teams to find alignment, and to have productive conversations around career development and growth opportunities. It not only removes ambiguity and subjectivity from the process, but goes a long way toward promoting equity as well, especially when paired with transparent salary bands for each level.
At DockYard, we went through several iterations of the Engineering career ladder, starting from a very basic format, to adopting a more transparent and unified company-wide roles and competencies matrix. We eventually landed on a more refined matrix that offered additional growth paths for those at the senior level, and put more emphasis on how someone could level up across multiple technical and soft skills dimensions.
The “Starter Kit”
DockYard started out with what Marco Rogers referred to as the “Starter Kit” in his 2019 LeadDev conference talk, Creating a Career Ladder for Engineers. Our starter kit consisted of three levels: junior, mid, and senior. It was accompanied by a document that read very much like a job description, as it laid out the responsibilities and competencies expected of each level.
This model served us well for some time, but as the company matured and additional engineering manager positions were introduced to support a growing team, we started hearing more questions about what specific skills team members needed to develop in order to attain the next level. They generally understood the definitions of mid and senior engineering titles, but struggled to process how they could move from one to the next.
The Roles & Competencies Matrix
In 2019, DockYard’s Employee Experience team launched a new internal initiative. Rather than having each department maintain their own documentation on roles, responsibilities, and career growth paths, we decided to:
- Move towards a more standardized matrix format
- Aggregate each of our discipline-specific matrices into a shared spreadsheet that anyone within the company could easily access: one tab for engineering, one for design, one for project management, etc.
The roles and competencies matrix resembled an inverted version of the format adopted and published by Camille Fournier for Rent the Runway. Across the top, we defined the various levels that existed for a given discipline at DockYard. Along the vertical, we listed the competencies expected for each level, and grouped them by category (technical skills, soft skills, etc.).
You can view a read-only example of what the Engineering R&C matrix looked like once we went through this revision.
Compared with the starter kit document we began with, this was a huge improvement. It was easier for team members to use the tool with their managers to discuss which competencies they needed to develop in order to advance, and it challenged managers to find opportunities to get their reports exposed to new challenges.
We also included two additional roles that had been introduced to DockYard over time: the Engineering Manager and the Architectural Engineer roles, both of which provided support to those fully dedicated to client work on the technical track, but had unique responsibilities worth calling out in the matrix. Note that the Architectural Engineer role was unique to DockYard, given its split focus at the time between R&D and client consulting, but the takeaway for any team adopting a similar matrix is that the levels and/or roles defined, along with their respective competencies and responsibilities, need to make sense for that team’s broader organization.
What’s After “Senior”?
Up to that point, we had only formalized roles and responsibilities within Engineering, but had stopped short of evolving the career ladder. Eventually, it became clear that having a single “senior” title was too limiting.
The previous revision had several drawbacks:
- It provided no visible growth path for the many senior engineers that DockYard had.
- It wasn’t clear whether the Architectural Engineer role was a step above Senior and how someone could transition into that role.
- There wasn’t enough differentiation between newly promoted seniors and those who had been in the role for many many years and were finding unofficial ways to widen their impact across the organization (e.g. by organizing and leading discipline-specific activities and discussions on non-client work days, mentoring, innovating through open source development, etc.).
- The matrix failed to identify what competencies were necessary for an engineer to assume the role of Tech Lead on projects, or rather, it made an assumption that all senior engineers could function in that capacity, which, to our experience, has not proven to be true.
Our next iteration of the roles & competencies matrix took some independent research, a series of workshops with a subset of engineers, engineering managers, and myself, and several review cycles before we landed on something that felt right for us.
Through this process, we retired the Architectural Engineer title and added Staff and Principal Software Engineer levels to offer new growth avenues for senior engineers looking to stretch their technical leadership skills and increase their impact beyond the scope of a single project. In addition to their high output on client projects, their non-client work time might consist of leading initiatives that help foster a stronger engineering culture, defining strategies for addressing common technical challenges, driving efforts to increase knowledge sharing, tackling particularly complex problems in R&D, and of course, mentoring and elevating others within their area of expertise.
We also adjusted the Engineering ladder to one that was inspired by Etsy, while continuing to maintain a matrix structure for capturing the information. The biggest benefit of Etsy’s model is that it allows engineers to more granularly assess their level across a number of competencies, in a manner that is decoupled from their actual titles. For instance, perhaps someone is at an “Expert” level for Problem Solving, but only “Intermediate” for Communication. This lets them identify key areas to focus on for their personal development.
You can check out an example of the format we landed on to learn more. A change you’ll notice compared to Etsy’s career ladder is the absence of descriptive level names, such as Beginner, Intermediate, Advanced, Expert, and Leading Expert. By using level numbers instead, we made a conscientious effort to remove any potential bias or imposter syndrome that may emanate from the terms “Expert” and “Leading Expert.” The result is arguably less intuitive, but it felt truer to DockYard’s guiding principles.
An Iterative Process
A robust career ladder can positively influence an organization’s overall employee engagement and retention. But just because your team already has one doesn’t mean that it is one and done. Just as there is no “one size fits all” ladder for tech companies, you will need to periodically reassess and evolve yours to keep up with evolving organizational changes and team growth.
There are many great examples out there. Study them. Use them as a starting point, but most importantly, find what works for your team, seek feedback, and iterate!
As a Dockyard partner, your goals become our goals. Get in touch today to learn how our team can help you find success, faster.
