What is an effective way to evaluate and assess employees on a non-management career track?

Question

My company is growing pretty quickly, and I'd like to make sure we have a career path that lets people move up without tying that exclusively to management roles.

I'm in control of this, and am excited about implementing this. I am having some trouble figuring out how to actually figure out a fair and empirical way to determine whether people should get a promotion.

This is extremely easy with management-track people: the more people who exist under you in the org chart, the higher you are. (E.g., the CEO who indirectly manages everyone is clearly doing something more complicated than a team lead with four people under her.) It's more difficult when it's a product manager who starts managing one of our products, and then keeps managing that product, but hopefully better.

I'm pretty hesitant to use something like volume of features or bugs (not) shipped because they're so easy to game and create perverse incentives. It's also possible these may not actually be causally linked with an individual: maybe a salesperson is more effective not because of his individual effort, but because his manager has built a more effective plan and he's still executing at the same level.

What do big companies that have figured this out do?

My current thoughts are around ways these people demonstrate they're solving harder problems. E.g., are they writing code that's more central to the system and used by more people, or are they speaking at conferences.

Answer 1

What do big companies that have figured this out do?

They use progression frameworks. Take a look at progression.fyi to start with.

The basic concept is that people know themselves where they stand and what is expected of them to progress. It empowers them to chose their own role and makes the whole process very transparent.

You typically have a handful of areas that are used to examine people's behaviour. I like the ones Monzo use for technical people:

The framework covers all the things we’re looking for from engineers at Monzo. We’re interested in these five elements:

• Mastery - Your Monzo knowledge and technical capability
• Impact - The size, scope and value of what you deliver
• Influence - How you change the world around you for the better
• Comms & Feedback - How you interact with others
• Leadership - How people around you become better and more impactful

Next you define a couple of levels, which would have traditionally been Junior, Mid-Level, Senior and so on. Companies often have 4 to 6 of these, and sometimes only call them by their number, or as tier something.

For each level, there are certain behaviours and skills for every area mentioned above. These are the things that someone should know and do when they are in that level.

I'm going to stick with Monzo and compare three levels here as an example. See the above link for more. We're going to use Influence.

On level one, which is apparently very junior, there is this:

• Improves documentation that is incorrect

Level two of six has this:

• Proactively raises issues they spot in retrospectives

But on level three, things are starting to look different:

• Provides valuable input to proposals from their team
• Proactively improves modules, services, systems and codebases they encounter, 'this doesn't make sense, I'm going to do something about it'
• Contributes to scaling engineering hiring (e.g. leads calls, does onsite interviews)
• Builds simple tools or iterates existing tools for the benefit of all engineers

You can see how the responsibilities would grow with that, but also the skills and aptitudes need to grow.

Many organisations allow different ranks within each of these levels to distinguish pay grades for example. So someone who is happy doing just coding can advance and get more reach in their role and be more distinguished and important for the organisation without joining a management track.

What's really important for implementing something like this is that the entire organisation needs to be on board, if you want to make it large scale. The company values need to line up with this kind of transparency.

My current thoughts are around ways these people demonstrate they're solving harder problems. E.g., are they writing code that's more central to the system and used by more people, or are they speaking at conferences.

These all nicely map to the different elements. Someone who speaks at conferences has a higher impact and a greater influence than someone who doesn't. Someone who writes new code on a core system has more impact than someone who writes integrations for 3rd party systems. Again, if you work though the different tiers on the Monzo framework, not only for backend developer but also for product people or even HR, this will become very obvious.

How to set this up

To set this up from scratch in an existing part of your org, or even the entire org, I would suggest you find people to represent the different existing roles and quiz them about what they do, and how they rate themselves in that. Make it clear that this is in no way meant to play people against each other or question whether they are doing enough work. Also make sure that pay reviews don't happen immediately once you're done. People might have been hired on different salaries because of the way they negotiated. If you find out that someone is on too high a salary, freeze it and work with them to get them to perform at that salary rather than cutting it, or you will very likely lose that person.

If that can't be done you can still use the idea of a progression framework to run your own, small-scale program inside your department or part of your company.

I have implemented a similar system for the trainee program I run in my organisation as a development mentor, with three levels that end at someone outgrowing the Junior Developer role, which I heavily based on Monzo and a few others. I've spoken about that in German at the German Perl Workshop 2020, but unfortunately haven't had a chance yet to get an English language recording.

Disclaimer: I do not work at Monzo and there is no affiliation.

Answer 2

Any system will be gamed, especially by nerdy types like software engineers. They will make it a sport. Any metric you find will be exploited. Not even for malicious intent, but just to show you that it is possible. So finding a "fair metric" is next to impossible and trying to do so is a hard and unrewarding process. I would suggest you don't go there.

I have never found the need for more than 3 levels of any job: Junior, Mid-level and Senior.

A junior needs help in their own job. A mid-level can do their own job quite well without help. A senior can do their own job well and help out the juniors.

Anything more and we are probably talking about a different job altogether. For example you may have an systems architect. But that is not just a "better than senior developer", it's actually a different job with different requirements.

Any decent manager should know who in their team falls into which category, without metrics to look at. If they don't, they don't deserve to be their manager.

Answer 3

It has been my experience that when goals are set, and reviews are done which outline whether an employee meets or exceeds expectations you can start to determine tracks at that point. If an employee is exceeding expectations, then a new title and pay raise are in order.

Dev1, Dev2, et cet. In addition, you can track an employee into areas where more sophisticated or technical work is required. They do this in the trades all the time. An apprentice, journeyman, and master plumber are all rises in rank.

The key is to have the progression defined, an clear list of qualifications to fit that role, and a path laid out to attain that level.

The maritime industry is also one to look at for non-managerial progressions, where time and competence earns a rise in pay and responsibilities. Anyone could sign on as a "boy", and could become an ordinary seaman, and eventually an "able bodied seaman".

So, mimicking a structure of the trades would do best for you.

It's harder to game a system when you're not going by best throughput, or most number of bug fixes, but rather a fixed set of core competencies.

The effect of this is twofold:

First, it encourages people to stay with your company as they see a progression open to them

Second, it helps management in reviews, as they can point out what core competencies of the next level an employee already has, and what they need to develop.

Of course, the real hard work is going to be setting those ratings/ranks and what core competencies are required for each.

Now, another way this could help is if you have someone who is very strong in some competencies, but weak in others for their chosen path, but may make them a better fit for a different path. This again helps with retention and optimal utilization of employees.

TLDR: Look at how the trades, such as plumber, electrician, and the maritime trades and draw inspiration from them

Answer 4

I think you should also look at how your system deals with people who aren't burning with ambition. People who are happy to have a stable job they're good at. Such people can be a stable core that keeps a department working smoothly over the years while others aim to climb the ladder. Especially in jobs that may not really have that much growth potential in them.

When I worked in tech support, half the people working there were temps - mostly STEM students. They were smart, inquisitive, good problem solvers. But they tended to stay there for only half a year, two years tops really, and then they moved on to bigger and better things. The other half of the crew were lifers, who just came in, did their job from 9 to 5 and went home. Most had hobbies that they lived for - they didn't live for their job, but it was stable, and something they were good at. They carried most of the real savvy and institutional knowledge. The combination of these two types of people made it a really effective tech support desk. We were able to both learn new things but also didn't have to re-invent the wheel all the time.

Answer 5

Rebuild Your Team

Evaluating career levels/promotions boils down to imposing some ordering on the performance of employees. It seems like a pretty difficult problem to solve from first principles, but it's something you can do in less than 5 minutes if I phrase it this way: "Your boss has just offered you a high-stakes, high-visibility project that will get you a guaranteed promotion if you deliver. At the same time, you need to keep the lights on and keep other product owners happy, so you can't put your entire team on this project. Under these conditions, which people would you choose for the elite team, the business-as-usual team, and the maintenance team, and why?" If you can't answer this question with less than 5 minutes of reflection, you probably aren't a very good manager and are not qualified for the task that's been given to you. When you start to justify why you would put a given team member on team A vs. B vs. C, you start to realize the attributes that you value and which you perceive to be essential to good delivery. However, you will probably notice that the combinations of attributes varies from person to person even on the same team, and this is where it gets complicated.

You can and should solicit feedback from the engineers themselves (you didn't say what industry you were in, but your language strongly implies engineering in general, and software engineering in particular). Not only do they certainly have some strong opinions, but if their views don't line up with yours, that's a big red flag that you need to spend more time understanding their perspective. One way to do that is to pose the same question to them, as a survey with private responses. My guess is that you will find a surprising amount of uniformity in the responses, because folks generally have an intuitive perspective of levelling. You can frame this survey as a kind of informal peer review that does not correspond to any actual restructuring. Be honest and say that you are asking for their help in formulating a levelling guide, and this is one step in the process. Some of them will probably want to give you direct feedback on defining levels, which you should incorporate.

Also, you need to expand your scope by considering folks outside of your team. If you could poach staff from another team, which ones would you go after first, and why? Who are your rock stars that you jealously guard from poaching? Who would you be happy to lose? Which folks around the company are in demand by other managers? Talk to other managers and see if your perspectives align (ask them what their company-wide dream team would look like, etc.). Obviously, there will be both similarities and differences among managers, but also across organizations which have different demands, products, and responsibilities. You need to take into account the varying motivations when evaluating feedback.

Define Levels

I think simbabque's answer covers this decently well. I agree that Monzo's definitions are clear, clean, and a good example to help you make sure you didn't miss anything obvious. Of course, you will want to adapt it for your company/industry, but that should be pretty easy.

What I will add is that while many large companies define parallel tracks for managers vs. individual contributors, those same companies usually stop the IC track well short of the highest manager levels. Obviously, few CEOs will accept an IC that is considered a direct peer on the org chart. And some companies will argue that when an IC gets to a certain level, the scope of their responsibilities is so broad as to be equivalent to a [S]VP/President anyway, so might as well give them a management title. I personally think this is a mistake, because while the broad scope may be true, people who wish to fill those roles don't necessarily want to lead an entire VP org or larger, and giving them a title without an org dilutes the levelling definitions for VP+.

Thus, if your company has a substantial engineering force and many manager levels, I would suggest that you push to define parallel IC levels as high as the upper management will tolerate. Even if you have no engineers who are currently qualified to fill such positions, defining them gives folks something to aspire to and provides more steps on the career path than just plateauing at your typical IC mid-level cap (somewhere near the middle of middle management).

What should an IC at such a level do? Well, they shouldn't just be heads-down working on their pet projects with no oversight. They should be peeping in on significant projects being executed around the company, offering consultation and working to provide consistency around design and architecture across orgs. But they should also be able to pop into any meeting of same-level executives and give a technical briefing about the projects managers wish to discuss. Many times managers conceive of project ideas with little engineering input, and invent fanciful deadlines and expectations. Other times, managers will oversell a project because they are a smooth talker, and a credible technical voice can lend a more realistic perspective without looking like managers sniping each other for position (because other managers can often tell when a project is getting oversold, but calling that out comes with political consequences).

Many times there are broad technology choices which have impact across the whole company, and leaving these decisions to managers who consult with their tech experts turns it into political football rather than a pursuit of the best solution. Having high-level ICs to offer technical perspective can mean the difference between choosing the best solution vs. choosing the solution championed by the most influential up-n-coming manager whose IC rock star chose it as their pet project. But that also means making sure that you promote the best people to such levels, exactly because their actions can have an outsized effect on the rest of the company.

Challenge Assumptions

I would also encourage you to rethink the idea that "more reports == better manager". I think most folks here can tell you about a manager who ran a large org, but poorly. The reasons for getting promoted are sometimes only tenuously related to performance, and actually dominated by networking and personal connections. The fact that you led with that example suggests that perhaps you are not willing to think deeply enough about the topic to do a good job. Try to think if you can identify any managers you know who are running an org which is "too big for their britches". I would be surprised if you can't name any. Then think about how they got there.

My personal yardstick for "good managers" is: "promotes good people, and weeds out the bad apples." Promoting good people sounds easy, and yet, I can name lots of times when I saw a less-than-good person get promoted because they are good at "personal sales" more than actual performance. But even more important than promoting good people is getting rid of bad apples. This is one of the hardest, least appreciated aspects of being a manager. Bad managers know when they have someone who is slowly (or quickly) poisoning their team, but simply don't act because they lack the spine and wish to avoid conflict. Of course, a good manager has to know when such a person is killing their team, their org, the manager's reputation, etc. But acting on it is even more challenging, because it involves doing something unpleasant with a person who is, by definition, not fun to deal with.

Sometimes, the bad actor is just on the wrong team, has personality clashes, and could succeed on another team. Finding that other team and helping them to transition successfully is the mark of a truly great manager. That's turning an all-around bad into a win-win. Other times, the person is just a bad apple, and needs to leave the company for the good of the company. Getting rid of those folks is both the least pleasant and most difficult task for any manager. But the managers I respected the most are ones who did exactly that. Getting rid of a bad apple can improve the quality of life for dozens of employees, no matter how much it sucks.

You may find, when talking to your ICs about levelling ideas, that some things you think are important really aren't important to them, and the things they bring up may be surprising and enlightening to you. Unless you have already excelled in their role and have substantial experience, you should listen to their feedback carefully and with an open mind. After all, when you choose to promote someone based on the levels you helped create, you want everyone on your team to say: "Yeah, that was a good promotion. I see a clear path for myself here." If that happens, you'll know you succeeded. The peers are often the final judge.

Answer 6

Seniority.

A classic metric for determining progression in non-management roles is seniority - how long an employee has been working in a particular role, either at a particular organization, or in the industry in general. While it does have the downside of only being loosely coupled with the sorts of improved competence you actually want to measure, it does have the advantage of being both easy to measure and difficult for employees to game.