You may agree that naming is everything in the software industry - from variable names to class names, but how about extending the idea to the names of roles? Let’s say you are a “Senior Software Engineer” - great but what does that even mean? Does the name & definition translate across companies? Does everyone think exactly the same thing when they say “Senior Software Engineer”? The answer to almost all these questions is in the negative.
In such cases, unfortunately, only naming does not address the problem completely! That’s where the career laddering framework comes into the picture. It charts out how each role/position translates to actual responsibilities, skills, traits, etc. This helps to have more clarity about your current role, what is expected of you at each level, how to move to the next level, and so on. Let’s see how we reached the point where we came up with our own career laddering framework, how we built it, and what we learned along the way.
TL;DR: jump directly to the Career Ladders website.
Why did we build the framework?
Back in our initial days as a software engineering organization, we had very few roles. Almost everyone joined as a “Software Engineer”. And not every one of us was doing software/product engineering work, some of us were doing DevOps-related work, some were writing code to build SaaS platforms, and more. This worked for a few years until we were a small team, around 30 members or so.
This was more of a mutual understanding between the mentors and the mentees of what they needed to do and what was expected of them. Some folks joined as technical leads, technical architects, etc. But as a growing organization, this was going to become confusing as more people joined in. That’s when we came up with well structured levels like Associate, Engineer, Senior, Staff, and Principal. These applied to all the streams like Product Engineering, Site Reliability Engineering, and so on.
While these levels were there, everyone’s understanding of them was different. One’s role in their previous organization might have been a tech lead, but it can translate to Senior Engineer at InfraCloud. Engineers needed more clarity about their role progression, what they should be doing more, what skills they needed to gain, etc. So, we decided to define each role more concretely, which became the Career Laddering Framework at InfraCloud.
Building the InfraCloud’s Career Ladders
We looked around at what people have done before in this area. We found an excellent video by Marco Rogers (answers why you need something like this) and Sarah Dresner’s framework (answers how you can do it), as well as Medium’s Growth Rubrik framework, which is another but a bit more involved example of how to build a career ladder.
One other realization was that, while guidance is good, the role descriptions are not something you simply copy and expect to work. For example, as an open source software focused company, values such as community were essential to our existence. Conference talks, blog posts, the School of Kubernetes, and mentoring sessions are some examples of how we engage with and evangelize the community. So we wrote our own detailed 2-page descriptions of roles and what it takes to move from one to the other.
We rolled this out in phases, where newly joined folks were assigned the newly defined roles. Then, existing roles were mapped to these new roles based on where everyone fits in. This involved doing 1-on-1 meetings with the individuals, setting expectations for their progression, and so on.
The InfraCloud Career Ladders
You can access the Career Laddering Framework at https://career-ladders.infracloud.io/docs/
Currently, we have listed the career ladder for the engineering function. Other career ladders will be added later.
We hope you find these useful - but definitely improvise to fit your organization’s needs and goals. We are happy to share more; please feel free to reach out to me on LinkedIn or Twitter. Also, the entire website is available as a GitHub repo at infracloudio/career-ladders, feel free to use it.
