Structuring a Career Ladder For a Scaling Team

Problem

Over five years time I grew my company from just 2 people to a 45 person strong engineering team. As a startup, it wasn't necessary for us to have a specified career ladder. Individuals were working on different products with each product having a different life cycle. The team was focused on delivery and not so much on development. But as we scaled the team I realized that team members had aspirations and that we needed to provide them with growth opportunities. Accordingly, I needed to give engineers clarity on what was expected of them and what they needed to do in order to move up within our company.

Actions taken

As we began to scale the team I decided that it would be best to formalize a simple organization structure. This consisted of four levels in progression: software engineer, senior software engineer, principal software engineer, and architect. Being a startup we didn't want to complicate things so we tried to keep it as simple as possible. We wanted only those who were self-driven and who didn't care so much about titles as much about personal development over time. But as we increased in size it became apparent that the engineers who were a perfect fit for our startup no longer matched the needs of our growing organization. Moreso, those who had 2-3 years tenure were expecting to move up to the next level but how they needed to go about that wasn't clear. Therefore I had to expand the horizons of our (then) current career, but I didn't quite know exactly how to do so. Resultantly, I began doing a lot of research. This was not a new problem that I was facing in the tech world so I had a lot of information at my disposal. I looked at articles and blogs, and talked to people in my network who had gone through similar situations. I also looked to different but big name companies like Netflix, Amazon, and Uber to see how they structured their career ladders. What I came up with was a unique modification to Medium's very famous growth framework which holistically defines the career ladder of the whole engineering world. I named it 'Moonfrog Growth Framework'. I disposed of the simple four-level system we had and introduced 7 new levels. The number of levels increased to accommodate for all of the competencies and behaviors that we were now looking for as a larger company. Consequently, it decreased the gap between each level. It's designed with two matrices, one is depth and one is breadth. The depth being the levels and the breadth being the roles and responsibilities equivalent to each along with five buckets of competency. These buckets consist of non-coding skills such as communication. Thus, what we have now is a clear set of seven levels and beside them are listed the competencies and behaviors expected. It's all written in layman terms, no abstract or fancy words, so that it's easy for everyone to understand. For example, if you are a L2 level software engineer, what do you need to display when we talk about communication? In your own words, you should be able to explain the status of the product or feature that you are working on and clearly articulate its development during Scrums. I was apprehensive about introducing this new format, afraid that I would receive backlash, but in fact it was well received. I think what aided in buy-in was that I explained that it was a living and breathing document and that I was open toiti changing. But I informed them that it displayed our new interests and concerns and that we have to live by it for a while. And so far it has been doing pretty well.

Lessons learned

• In the early days, when you are just 5-10 engineers, you don't need to worry about a career ladder. What you need is a successful engineering culture. Try to build up those first few individuals because they are going to be your shining lights as the team scales. They will guide all of the new folks coming in. So first build out the company culture that you want your teams to have and then later you can work that culture into your career ladder.
• Don't try and copy another company's career ladder. The team that you are building and your engineers are specific to your problem statement and your business. Just because a document was successful at one company doesn't mean that it's the right fit for yours.
• Do not worry about titles. Try to reduce their value as soon as possible. I did so by introducing numbered levels and started communicating to individuals in that way, level 1, level 2, and so on. I think this eliminates minute but impactful concerns and gives far more clarity to the overall big picture of the career ladder.