In this article, I’m going to talk about career structure, career development, and career titles in a tech organisation. This post is more about organisational development than it is about technology; however, on the grounds that the health of your architecture and technology choices will be somewhat isomorphic to the health of your organisation, I believe this to be a worthwhile read for any engineering leader. I’m also writing this for anyone who is considering joining HBC Tech, so that they can understand our approach, and the meaning we give to our titles.
I’ll cover our motivation and need for a career structure, the core principles that drove our solution, and, perhaps most importantly, our experience in transitioning to that solution in a Dunbar-sized technology organisation at HBC Tech.
“I don’t care about my title.”
Titles are an amazing thing. When I joined Gilt in 2011, I didn’t care about titles; I was happy to shed my shiny ‘Distinguished Engineer’ title from IONA Technologies and join Gilt as a Senior Engineer. It was easy: the general rule was that every engineer at Gilt apart from our CTO was a Senior Engineer, and the democratic, meritocratic, startup culture obviated the need for titles.
However, over time something interesting happened, not quite to me directly, but to the organisation as a whole. Blips started to appear in the organisational title space - a new hire would arrive as a ‘Principal’, and peers would wonder “what does that mean?”. Or, someone would become a team lead, or Director of Engineering, which begged the question: is that higher than an Engineer, or, somehow equivalent? And then blips started attracting attention from outside of our organisational radar: our team would see their peers in the industry getting promotions and fancy titles, and wonder were they somehow stagnating in their careers?
Organisations develop and grow over time; the tech leadership team at Gilt realised in February of 2013 that the organisation needed and wanted a clear career structure, something different from our original loose, startup-y approach. The career structure we landed on at Gilt worked well for us in the subsequent three years. More recently in 2017 we set out to create a career structure for the larger HBC Tech organisation; we wanted to design it carefully so that it would align with our cultural values and learn from our experience. We started with a few principles to guide our thoughts.
Here’s what we felt was important:
Meritocracy (or, you earn your title): No-one is ‘entitled’ to a title: just because you’ve been here a while, doesn’t mean you qualify for a promotion. Ever. We expect you to perform at the next level for sustained period - at least six months - before you can get promoted. A good metric of your success in this regard is that your promotion should be a surprise to nobody; the only surprise should be a colleague saying “Hey, I thought you were at that level already!”.
Equivalence of Individual Contributors and People Leads: We feel strongly about this. We hire talented people who design and build great things, and we wanted to create a career development path that encourages development in the skill that make you great. No one should ever feel that they have to become “a manager” to get promoted. Equivalence should apply to compensation, but also in day-to-day operations: for example, in our Dublin office we extended our regular “Dublin Leads Meeting” to a “Dublin Leads & Principals Meeting”.
We want Leaders, not Managers: When you have talented individuals, working in small autonomous well-knit teams, you don’t need to manage. We develop our leaders from within: for us, leaders are people who love their craft, but also get a real kick out of leading people: showing the way, setting direction, getting alignment, and making the team successful.
Encourage people to try leadership out, with a route back to Individual Contributor: The idea of putting yourself forward as a team lead is daunting for many individual contributors; some of that may be down to humility (“Why do I think I’m better equipped to lead than everyone else on my team?”), or fear of failure (“What happens if I’m just not good at this?”). Perhaps the biggest fear is the idea of losing your grasp on the skills and talents that make you great as an engineer in the first place. We wanted to create an environment where individual contributors could experiment with leadership roles, and have an avenue back to individual contributor later should they so desire. I must confess: the first time I saw a team lead return to an individual contributor engineering role and be replaced by another more junior team member as lead, I honestly thought it would never work. I was wrong. The original lead (now engineer) and new lead just got stuck in at what they were good at, and the team was great.
With these principles in place, the question became “What kind of career structure can support this?”
What do other organisations do about career titles?
We triangulated ourselves off our understanding of organisations like Netflix, Facebook and Google, and how they manage their career structures. Organisations don’t often publish their career structure; however, pulling together from a number of sources and contacts, we saw some interesting patterns:
Netflix: Netflix operates a very simple structure. Ultimately, every engineer is a Senior Engineer, and there is a separate track for leadership, including Manager, Director, VP.
Google: Google has a multi-tier ‘levelled’ system, with individual contributor levels ranging from Level 1: Software Engineer I to Level 10: Senior Google Fellow, and a parallel engineering management track that ranges from level 5 to level 10.
Facebook: Facebook also has a multi-tier ‘levelled’ system. Engineers range from Level 3 - Software Engineer up to a Level 9, with associated Manager and Director roles on a parallel track above Level 5. Anecdotally, once an individual elects into the management track, the intent is that they will remain in that track.
Gilt: At Gilt, pre-2013 we had a structure similar to Netflix (see above!), and we found that this structure didn’t give a compelling career prospect for individual contributors in our engineering teams. Ironically, for a tech team with a strong startup mentality, we looked to the industry and adopted what outwardly seems to be a fairly traditional approach. Based on the Radford methodology, we created a career path and approach that had the following qualities:
Recognised different levels of ability, impact, contribution, scope and influence across individual contributor and leadership tracks; and,
Encouraged folk to jump across the Individual Contributor / Leadership boundary as their career develops.
The roll-out of the approach at Gilt was positive: it became clearer to staff who their peers were, and what ‘the next level’ really looked like. Career development discussions went from the abstract to the concrete. Perhaps the biggest result was that a generation of individual contributors, who had resisted the idea of taking on a leadership role, gave leadership a try and discovered they were good at it. More-so, on our engineering teams, we developed a culture of ‘leaders-who-code’: we found that engineering leads up to the level of Director and Senior Director continued to make significant impacts in terms on engineering contributions. Result!
The HBC Tech Career Path
After HBC acquired Gilt in 2016, the subsequent merger of the tech teams presented a challenge in terms of career paths: which career structure should we adopt, the existing HBC career structure, or, the Gilt career structure? Rather than just pick one of the existing, we took the opportunity to rethink both, and, landed on a structure loosely modelled on the ideas from Radford, Google and Gilt, as per the table below.
|1||Software Engineer I||-|
|2||Software Engineer II||-|
|3||Software Engineer III||-|
|4||Senior Engineer||Lead Engineer|
|5||Staff Engineer||Senior Lead Engineer|
|6||Principal Engineer||Director of Engineering|
|7||Distinguished Engineer||Senior Director of Engineering|
This approach has all the qualities we were looking for: equality of levels, ability to experiment with leadership at the senior level, and supported our culture of valuing leadership and autonomy rather than management and rule.
For each level, we worked out key indicators of what it means to be at that level. For example:
Level of knowledge: how much domain knowledge / expertise is required and expected at a particular level?
Supervision: how much supervision / hand-holding should we expect the individual to need at a particular level?
Sphere of influence. This is one of my favourite indicators: at early levels, the sphere of influence is really ‘self’. As we get to subsequent levels, we expect individual contributors and leads to influence their teams, department, tech, the wider organisation, and the industry & community.
Team size (for leads). There’s some good rules of thumb in terms of team size:
|Lead Level||Title||Team size|
|4||Lead Engineer||7 ± 2 (a pizza size team)|
|5||Senior Lead||10 ± 2 (a large team, or team of teams)|
|6||Director||20 ± 4 (a classroom-size team of teams)|
|8||VP Engineering||~80 (e.g. an engineering site / office)|
|9||SVP Engineering||~150 (a Dunbar)|
- Accountability: what are the systems that you own / are responsible for. How critical are they to the business?
One big learning is that these indicators are only guidelines. I dislike the idea of career advancement being a box-ticking exercise: there is a qualitative judgement that we as leaders need to apply, and sometimes a candidate’s excellence in one area may make up for a deficiency in another, or, make up for organisational blockers. For example, we once had a Director of Engineering with a small team of four or five reports; you could argue that this Director didn’t have a large enough team to warrant the title. However, when we considered his technical ability, the scope of the role, the level of accountability, and, the fact that we would most likely never have a classroom size team in this area, we felt great about promoting.
Qualitative judgement of levels is, of course, hard. One idea we found helpful was to look at peer groups, to ensure that staff at the same level are in the same peer group. If we find that a member of staff ended up grouped with other members who seem at a different level, we re-examine the case to make sure our evaluation has been correct and fair.
Rolling out a Career Path
With our new career path in place we then had to figure out how to roll it out. Ultimately, rolling out a new career structure means you may be changing your people’s titles: we want to make sure that we did that in a sensitive and proactive way. For example: if someone’s existing title is ‘Software Engineer’, then the question is what level are they in the new system (I, II, III)? How will someone feel if they think they’re a III, but we think they’re a II?
We settled on a couple of core ideas to help us make a smooth transition:
There are no salary or bonus adjustments as part of transitioning to the new structure. No one gets a pay cut, no one gets a pay rise: the focus is on getting the track and level right.
We apply the level as is: there are no promotions as part of the levelling. We didn’t want to use this exercise as a way for folk to canvas for a promotion.
We involved each individual in the selection of their level, through 1:1s with their current directors and leads. At the end of the exercise, everyone knows their level (1-9) and track (Individual Contributor / Lead), and has been part of the process.
Individuals can adopt their new title publicly if they wish, or retain their current title. Whatever about our internal career titles, we didn’t feel it was right to force people to change their LinkedIn profiles!
Everyone gets evaluated at their level and track going forward. This is a nice feedback loop back to having individuals involved in the selection of their role! Sure, maybe you did persuade your lead that you’re a Software Engineer III: if so, then you’ll be evaluated against your peers… you better be up to it :)
So then, we began the roll out! With a Dunbar-sized subset of the organisation we formulated a simple plan:
Communicate: let everyone know what’s going on! You really can’t communicate enough on these things: despite your best intentions, there will always be someone who “didn’t get the memo” or wasn’t there when you talked about it at an All Hands meeting. Communicate often across multiple channels, and be mindful of people who may not have missed out.
Educate: after the initial communications, we moved to educate our folk in groups of about 20, with a one-hour walkthrough of the career path, where it came from, why it’s important, and backed up with all the materials. This is a nice ‘classroom’ size: big enough to scale the communications, but small enough that folk feel comfortable talking about the issues, and asking questions.
Get personal: after the education sessions, we ran our 1:1s with folk to settle levels.
Close the loop with HR! In almost every organisation I’ve ever worked for, the system HR uses to store titles and levels has been different from the spreadsheet I’ve been working off. It’s crazy after all this levelling work to think that six months later someone might get an official letter with the wrong title! As a general rule in life, it’s always good to hammer the nail all the way in.
“It’s nice to have a title, so then you don’t have to care about it any more.”
The irony of all of this is that, really, still, I don’t care much about titles! When I was a tech consultant in a previous job we always had this saying: “You’re only ever as good as your last gig.” Likewise, when it comes to titles, there’s no resting on your laurels, proudly shining and polishing your trophy title: you must deliver, every day, for your team and for the organisation. That said, there are a couple of real benefits that we’ve seen from this work:
Having clarity on titles means that any fear, uncertainty, envy, distrust related to previous title confusion is now gone. Everyone knows where they are, and can just get down to work.
Career development conversations just got a whole lot more interesting. Now we can have meaningful conversations with our staff on where they are, where they want to go, and, how they can get there.
One final piece of advice: title systems and career paths are frameworks that exist to help us; they’re a tool that should enable us, not restrict us or box us in. While we have leaders-who-code (e.g. directors of engineering optimising our caching architecture), we also have coders-who-lead on some of our teams (e.g. principal engineers leading teams working on a technical area like ElasticSearch); and, this is as it should be. We flex the framework to our needs. And, if we find that this framework breaks, we’ll fix it, and perhaps write another post to let you know what we learnt.