In mid-2018, around six months after I took over as VP of Engineering at OneLogin, I began a project to build a “job ladder” and career development program. Prior to that, there were no defined job levels and no standardization around titles (which is not unusual for an organization of the size it was then). It was difficult to tell if people were being paid fairly relative to their skills, experience, and contribution. Turnover had been historically high, and I suspected some of that was people leaving the company to achieve career advancement elsewhere (though the very competitive market in San Francisco, where most of our engineers worked at that time, was also a contributing factor). We did have an annual performance review process, but it was very difficult to assess engineers on their performance or potential when there were no defined expectations for a job level that corresponded to their current compensation, nor was there any real way to determine the peer group to which you might compare a given employee.
I’ll start by pointing out that many tech companies, even ones much larger than OneLogin, do just fine without a formal career ladder (or with very few levels). There is at least one large Bay Area tech employer where everyone is basically a Senior Engineer and is paid very well (in the top 5% of the market) and people who work there seem fairly happy with that approach. In our case, I felt that it was important to establish levels that would give engineers a chance to grow and be promoted relatively frequently and that would correspond to relatively narrow salary bands that would allow us to ensure that we were paying everyone fairly.
Fundamentally, the goal of our career development plan was to help attract new talent, to retain the talent that we already had, and to consistently make our engineers more valuable over time (to the company and to themselves). A secondary goal was to ensure that we were compensating our engineers fairly (in terms of the market, and relative to each other).
Credit Where Credit is Due
I found a lot of great work done in this area, and I borrowed from it liberally. One of the best pieces on the “why” of career ladders that I found was The Software Engineering Job Ladder by Chuck Groom.
When putting together the nuts and bolts of our ladder, we drew a lot of inspiration from Sharing our Engineering Ladder by Camille Fournier at Rent the Runway, including the detailed level descriptions referenced there in document and spreadsheet forms. That was itself inspired by Software Development/Leadership Ladder (Foursquare), which we also found useful. Our other major influence was Software Engineer Title Ladder (Charles Krempeaux).
In that spirit, I’d like to share the program that we designed and encourage anyone who sees value in our program to feel free to borrow whatever they like, as we have borrowed from the sources above and others.
The Plan Itself
It was important to us to have a single document that not only described the various job tracks and levels, but that also embodied our philosophy around career development and the processes required to sustain it. The plan pretty much speaks for itself, so I won’t go into details here, but recommend that you review the plan for details if you are interested:
Engineering Career Development at OneLogin
Note: There are a lot of levels, especially on the management track – but levels != layers (just because there are a lot of possible levels of engineering manager does not mean they will all show up in the hierarchy). Think of the engineering manager roles as levels of skill/experience or influence/responsibility, not as layers in the org chart.
Results
In terms of results, our employee retention in the time since this plan has been deployed has been much improved, with less than 5% yearly attrition over the first 18 months. Our employee survey scores around career development, manager support, and understanding of compensation all improved significantly.
We have also been very successful in hiring, growing our engineering organization by approximately 50% since deploying the plan, while keeping our standards high. We use our career development program as a tool in the recruiting process (we provide candidates with a copy of our career development guidelines, and we discuss where we think they will fit and how they can advance once they get here).
Our career development plan has also helped us tremendously with being able to ensure that our employees are being paid fairly, and it supports our ability to plan and budget for promotions in a way that minimizes friction with our finance team. I’ll give some details on our compensation strategy and processes and how that works with the career development program in a future post.
Lessons Learned
The first version of our career development plan did not have the Associate Engineering Manager level. We did not anticipate engineers entering the management track from the Intermediate Engineer (E3) level until we had a case where that happened and made sense, and we didn’t really have a way to “try before you buy” for Senior Engineers to test the management track, with the ability to go back to the Individual Contributor (IC) track without changing levels (without having to be “promoted” into a higher level to be a manager, then “demoted” back to Senior Engineer). The Associate Engineering Manager position addressed those issues and also allowed us to focus more specifically on first time managers and the kind of support they need in that position.
Another lesson learned was that “hybrid” Engineer/Managers don’t fit cleanly into the ladder. We have had a number of cases where someone at a very high IC level took on people management responsibility (for example, a Principal Engineer taking over a small team, in a player-coach role where they were still contributing as an IC 50% of the time or more, but were also managing people). This has actually happened several times. Our solution to this was to add high-level IC skills/contributions as an alternate qualification for senior management roles, so that, for example, someone coming from a Principal Engineer role into management might be considered an Associate Engineering Manager, but at the higher Principal Engineer level for compensation purposes. After some proving time, that person could be promoted to a Senior Engineering Manager role in this hybrid model (based on a combination of their technical skills and management skills). This is still a work in progress.
While we aim for parity among IC and Manager tracks, it has been pointed out by engineers that the most senior levels on the IC track can be very hard to reach, whereas whoever you have standing around on the management side running the show gets to be a VP or CTO. That’s a fair criticism, and an area where we need to do some more thinking.
Conclusion
Part of the art of managing startup engineering organizations is knowing how much process and structure to apply at which stage of development. Too much structure too soon can be worse than not enough in some cases. Having started several tech companies as employee number one, and also having managed larger organizations, I personally feel that having some structure to engineering roles is useful even very early on and the overhead is pretty low.
