Layoffs are hard, but we shouldn’t try to make it easier with stack ranking because ranking is inherently one-dimensional and forces you to compare pairs of people. For layoffs, you should want to compare different multi-dimensional teams.

In programming, we know that whatever algorithm you use to sort a list, you need a function to compare two items. But sorting this way only works if comparing is transitive. This means that if a<b AND b<c then a<c. This works for numbers, but you need to be careful when you make your own comparators.

There’s no natural way to order people, so when you make one up, it’s often not transitive. The second problem is that the comparator only has the two people to compare, not any other context. That means that when you are considering the “value” difference in a pair of people you are not using the context of the team that they will be on.

Instead of sorting, consider this visual aid:

I explained this graph in Raising The Bar is a One Dimensional Concept. Each spike represents an attribute of a team member that you value. For example: coding skill, team gelling skill, writing ability, domain knowledge, code-base knowledge, mentoring—you can have as many as you want. Your team members may each excel in some, but lack skill in others. For each member, put a dot somewhere on each spike of the graph and connect it to make a polygon. By overlaying the individual graphs, you can see if you have a balanced team with diverse abilities and interests.

Here’s how I suggest you use this. Let’s say you have 10 developers and you need to lay off 20% of total salary. To decide, try evaluating each member on all the dimensions you value and create a team using your budget to pick the ones that result in the team you want.

Let’s say you start with some obvious top-performer. They have the most seniority, have mentored well, write great documentation. They are all-around a person that you want to keep. The next person to add is probably not someone similar to that. You want to end up with a good mix of junior and senior people, so the next person might be someone relatively unskilled, but perhaps with other desirable attributes.

The key is that you are thinking of that junior person in combination with the senior one, not comparing them against each other. To the extent you are comparing team members to add, you are considering which one is a better multi-dimensional addition to a multi-dimensional team, not looking at them in isolation. As you build up the team, you may notice things the team needs, and pick the next person based on that. You should try this a few different ways, with different starting points, and see if they converge.

Instead of thinking of people that you need to cut, you focus on building the best team you can afford. You should already know how to do this because this is a good way to recruit as well.