Why your business needs a progression framework

I’ll be the first to admit that some progression frameworks are lacking in substance, often speaking in banal generics and lacking tangible examples. I know this because I’ve written plenty of regrettable howlers.

Without a progression framework, or at the very least a list of expectations for a given role, you’re hanging people out to dry. You’re opening up performance reviews to all those wretched cognitive biases, which is why something is better than nothing but a coherent progression framework is the current gold standard you should be aiming for.

Virtually all tech companies will have have a career ladder that goes something like junior → mid-level → senior → very senior → super-senior. A progression framework describes what is expected on each of these rungs, across multiple dimensions such as skill, communication, engagement, leadership, and so on. It’s called a progression framework because it will make clear how each expectation progresses from one level to the next, as this seminal ‘rope analogy’ example from Radford demonstrates:

When people are hired they’ll be taken through interviews and technical challenges and an assessment will be made on where they sit on this ladder. On this, where things are not clear it’s better to match people against the lower level. This sounds tight-fisted, but acknowledging a mistake and promoting a mid-level hire to senior after a couple of months in the role is easy. You’re doing nobody any favours by hiring them into an overly senior role just because it’s the role which matches the salary they want. This won’t end well, believe. But I digress…

The same assessment is made for each person during their (annual, bi-annual, whatever) performance review, which will be far more accurate than the initial hiring assessment because you’ll have a wealth of direct on-the-job evidence to draw from by then. Making a fair assessment is where a progression framework comes in. A progression framework allows you to articulate, in depth, what it means to be a mid, senior or principal engineer at your company. It’s crucial to developing someone in their career, which keeps people more engaged and less likely to go looking elsewhere for a new challenge. People need to know where they’re at, and what they need to do in order to get to the next level. How can you do this without some sort of benchmark? Spoiler: you can’t.

Introducing a progression framework will be a challenge. You’ll hear cries of pigeon-holing and box-ticking, which isn’t actually unreasonable – it’s usually just a misunderstanding. There’s an inherent fear of receiving critical feedback if you’re not used to it, but feedback is essential to improving performance. Just ask anyone with a personal trainer. At some micro level, you are putting someone in a box called senior, or staff, or whatever. You’re making an assessment and you’re calibrating people against others. This sounds rather awful, mainly because of the unpleasant and dehumanised HR language (“assessment”, “calibration”, “review”). I’ve been guilty of this, of course, but with a bit of imagination you can avoid the jargon.

At smaller companies, especially ones like 37signals, creatives (by which I mean programmers and designers) are working so closely that someone’s skill level and overall contributions will be obvious. You can see what they’re producing and the impact they’re having day after day, so why do you need a new and irritating “box-ticking exercise”? It’s a good question, but manager-lite arrangements with highly technical supervision are just as open to bias as more “professional manager” setups. Recency bias after shipping that popular feature. Primacy bias because you still remember their first ever project which they absolutely nailed. Halo effect bias because that person’s performance peaks are so fucking high despite the fact their day-to-day performance is a flat calm, even atrophied, most of the time.

To earn trust in the framework, you have to be able to demonstrate its value to everyone it affects. In time, it’s likely you’ll get buy in from most, if not all, because people will see it working for them and for their peers. If the worst happens and the whole thing is an abject failure, don’t hesitate to admit it. Throw it away and reset. Lean on your teams to find a better path forward.

If you’re not using a progression framework right now, you should create one. If you are using a framework, be sure to reassess it every couple of years. Always get input from those at the front-line. There are plenty of examples out there to gain inspiration from (or outright steal), but remember it’s always a time-consuming exercise, but one with a high return on effort. Don’t scrimp, just take your time.