How to encourage and promote your employees using meaningful job ladders

Making your startup a meritocracy, from meaningful job ladders to a transparent promotion process.

Arnaud Meunier
Partech Team Publications
8 min readJul 9, 2018

--

It’s one thing to make sure everyone understands what success means for your company. We recently went through this in our OKR post, explaining how to align your organization top to bottom.

It’s another thing to map this with each of your employees’ job function, their individual career development, and compensation. What does the promotion process look like in your company? How do you help and encourage each individual progressing in their career? What’s expected to do so, and how are you rewarding this? How do you explain salary discrepancies?

That’s what this post is about. From clear job ladders to a transparent promotion process, my thoughts on building a meritocracy.

Wait… What’s a job ladder?

A job ladder defines different progression levels for each job function, explaining the differences between each level, and how you move from one to the other. That means you should ideally have as many ladders as job functions. For Engineering, Product, Management, etc.

These levels definitions shouldn’t have anything to do with people management, or time spent in the company. They should focus on each role expectations, defining a career path and driving your compensation policy.

There’s nothing fundamentally new in this. Ask someone in a consulting firm, or even in one of the large tech companies like Google, Facebook or Twitter how their plans are structured. But for some reason, it’s not that common yet in many startups, when it probably should be, as soon as you cross the 30 employees mark.

Whatever the reasons, and before you run away screaming “Bureaucracy”, give me a chance to explain why I believe it’s becoming increasingly important, especially in fast growing startups.

Why building and using job ladders?

A good job ladder helps you clarify how people can progress within their job, how you reward this, and what’s expected on both skills and impact side. It’s the first step towards building a meritocracy.

Are your people waiting for the person above to die, in order to get promoted?

Alright, that might be a bit extreme. But you get the idea. In the absence of a clear career progression path, most people will likely assume Promotion = Taking my boss’ seat. And that rarely makes sense.

It’s one thing to make sure everyone understands what success means for the company, and how each team contributes to it (Cf. last week’s episode). It’s a different thing to make sure each individual understands how they can progress in their career, what’s expected to do so, and how it’s rewarded.

Now why investing time in this?

  • For one, salaries discrepancies. How do you explain the difference in compensation between peeps within the same job function? And how do you provide guidance there? Same thing for “slotting” your new hires, as you’ll likely recruit people from different seniority and different skillsets.
  • Competition is another one. Particularly for high-demand job functions like Engineering, as people get constantly hunted. Engineers will be more likely to respond to other company calls, if they feel stuck in yours.
  • More importantly, it will help keep your employees challenged on what they love. An Engineer who loves coding shouldn’t feel forced to move to management, in order to get rewarded. Those are actually two very different jobs.

Moving from Software Engineering to Management shouldn’t have anything to do with a promotion. It’s a side move. To a different job function. To a different ladder.

As Alan — one of our portfolio company — say it even more explicitely:

Managing is not the future of the Engineer.

Their CTO Charles Gorintin actually wrote a very interesting piece on this (in french) explaining why and how they’re letting their engineers choose the track that fits them the best.

Defining clear job ladders will help everyone understand how they can advance in their career. It’s a solid — and I believe necessary — starting point to a rational and transparent promotion process.

What should my job ladders look like?

Optimize for clarity, giving actionable directions on what each level represents in terms of skills and responsibilities. Keep it short and readable, providing concrete examples or data points rather than long descriptions. Remember you’ll rely on this during the promotion process.

I like ladders structured by categories — or skillsets — that reflect the job function goals. Defining what’s expected, category per category. For example, Coding skills would be one of these categories in your Software Engineering ladder. From code quality to code structure, going through testing, each level would have different expectations. Another one could be Architecture and Design skills.

Here’s an example, from Alan’s Software Engineering ladder:

  • Technical Skills: Able to write modular, maintainable code. Able to communicate clearly on technical topics.
  • Design: Begins to show architectural perspective. Leads the design for medium to large projects with feedback from other engineers.
  • Code Quality: Leaves code in substantially better shape than before. Rarely introduces production bugs. Provides thorough and timely code feedback for peers. Demonstrates effective use of testing.
  • Impact: Owns or co-owns medium to large projects, executing with minimal guidance.
  • Scope: Begins to work beyond scrum team (ie. identifying and coordinating dependencies).
  • Drive for Improvement: Pushes to become a better developer, ie. independent reading, attends tech talks, takes classes. Helps team improve.
  • Recruiting: Contributes to the Alan tech brand, find and nurture good engineer prospects.

For Data Scientists, you’ll likely have an Analysis/Algorithms category (quantitative knowledge, data collection skills, etc). On Management side, it will revolve around people management (growing the team, career & performance development) but also organizational alignment, execution and project management…

Another example: Foursquare’s Software Engineering ladder

You get the idea. Define a couple categories aligned with the job function goal, then explain what’s expected for each level. There are many other examples available out there. But don’t copy/paste them — or worst — dictate what the content should be. Instead…

Leverage your people! That’s why you hired smart people, better at their job than you are, right?

And you want them to be part of this ladder definition process. I believe it’s an essential piece in making the entire thing work. Also, some of these categories definitions will likely be specific to your company, reflecting your core values and how you want to grow the business.

For example, there could be a common “teamwork” category, to encourage and reward the mentoring of less experienced / junior employees.

Alan’s median salaries per ladder level

These ladders should be publicly accessible within your company. Just like the levels people are at, as both responsibilities and accountability increase at each level.

I also like the idea of mapping salary bands to each of these levels. Making transparent how it translates in terms of compensation for everyone. It will help you create an environment of trust.

How about the promotion process?

Now you have job ladders that clearly define what each level means, how do you promote people to the next one? How do you keep the process transparent, consistent, and aligned with the job function goals that you carefully and collectively defined?

Here is an idea! How about having the manager solely decide wether someone should get promoted or not? A dude judging in complete isolation, on criteria he likely doesn’t master.

Yeah, that sounds like a sh*tty idea. One that could ruin all the efforts you put into designing meaningful job ladders.

That’s why a common (and better) alternative is the peer committee one. It has its own flaws! But at least you rely on multiple inputs, and they come from people operating in the same job function. That’s what we did at Twitter, just like most large Tech companies.

Here is an example:

  1. Promotion proposal: Bob initiates a conversation with his manager, who’s supportive of a promotion to SWE 4 / Staff Engineer. Together, they build a “promotion case”, documenting how Bob meets or exceeds expectations for each category at this ladder level.
  2. Peer input: A good indication of a given level is the… peer group of folks at that level. So this promotion gets reviewed (and hopefully backed) by other peers. Is Bob already performing and acting as a SWE4? What do his SWE4 and SWE5 peers think?
  3. Promotion committee: Composed of engineers at (or above) the level across the entire organization, they’re the one taking the decision. The idea is to ensure consistency of the level across job families / different part of the organization.

It’s a fairly good process. Probably a much better one than the “each manager solely decide” one. You build your case following the ladder, you get judged by your peers, and there’s an effort to maintain consistency across the board. Now as your company keeps growing, a couple issues might arise.

A bad promotion process will ruin the best job ladder. Defeating the entire goal of building a meritocracy.

A (not so fictive) example: Bob writes stellar code and is a great team player, but he didn’t get the chance to work on top company’s priorities, falling short in the “Impact” category. Promotion rejected. His team’s OKRs happened to be perceived as “less important” than other teams by the committee. A team he’s now reluctantly going to join, as it seems to be the only way to get promoted. See where I’m going?

In a similar vein, what happens when projects get cancelled? Or when the organizational structure changes, which is quite frequent in fast growing startups? Said differently, how do you weight for what’s outside of Bob control? How do you maintain fairness in this entire process, and avoid understandable frustration, or “promotion optimizations”?

There was an interesting post on the subject, highlighting flaws in Google’s promotion process, from the perspective of an employee: Why I quit Google.

Doing it right takes a lot longer than you’d expect.

There’s no perfect process. Promoting people is not a science. And for that particular category (Impact) there will likely be a delicate balance to maintain between what you want to encourage inside the company, and practical access to opportunity for your employees.

So as you build your ladders and your promotion process, be sure to monitor this. Collecting data points through company surveys, feedback cycles, whatever works. And adjust them accordingly, isolating the exception from the undesirable pattern that you need to remove.

That’s how you’ll build a fair and transparent system. A meritocracy where good people will not only want to work, but keep working for.

As a last example, Spotify published a great series on the career path framework they developed. Explaining the challenges they faced, and how they ended up building their framework on disciplines, roles and steps. As they say it themselves: Doing it right takes a lot longer than you’d expect.

--

--

Arnaud Meunier
Partech Team Publications

EIR @Partech • Former MD @Numa, Eng Manager @Twitter, Co-Founder & CTO @Hickory, Founder & CEO @Twitoaster