In building something completely new, in an underserved market, with no existing products to compare to, the possibilities are endless. Doing it on your own compounds the problem — deciding which opinions to have and which directions to go with your product can become paralysing (believe me).

So as a designer by trade, my instinct is to always set some principles by which to work. Those should be born directly from problems with existing solutions or needs I’m hearing every day.

In looking to understand how existing progression frameworks work, studying several dozen and talking to the folks who created them, I’ve developed a set of guiding design principles for the framework I’m building at Progression Pack.

Some frameworks I’ve seen achieve some, or even most of these items. I don’t think any of them achieve all six.

If I achieve all six design principles, I believe that this framework can be useful to a team of any reasonable size and adaptable enough to grow with that team. It will serve the end users — the makers who need to feel value and momentum in their careers, as well as solving problems for their managers by giving them a vital tool in their every day work and saving them a bunch of time.

I’m building Progression Pack in the open, so my principles are open. Here they are.

1. Not replacing managers, just making their lives better

Your relationship with your manager is your most important one — as the old adage goes, people leave people not companies.

I recognise the value of a good manager, from candid and constructive feedback-giver to your biggest champion. The best managers are mentors and lifelong friends.

What I build shouldn’t be aimed at replacing that vital manager role. It should instead allow managers to be better by freeing up their time and giving them more and better data, so they can focus on the things that only humans can do — talk, understand, support and empathise.

2. Everyone has somewhere to go — even at the most senior levels

Picture the scenario: you’ve got to ‘senior designer’. The only person more senior than you is your manager. You have two options: leave and look for a bigger company, more pay or a more senior title somewhere else, or wait it out and hope they leave.

Neither is a good option. Wouldn’t it be nice if you did still have goals to aim at — perhaps not linked to title, but rewarded in other ways.

As that manager, even though your manager is a non designer and there’s no more senior place for you to get to, you should still have goals.

What I build shouldn’t allow team size or org structure to define where the path ends, for anyone. Learning is for life.

3. Allow people to develop at what they’re best at

‘Hey, I know you really want to go deep on prototyping but this manager position just opened up and this is the only way you’re going to get ahead.’

This is one of the quickest ways to not only lose a very valuable contributor to your output by moving them into management, but push them out of the door when they lose energy every day doing a job they didn’t sign up for.

What I build shouldn’t have defaults which force people to change their job description to grow. Growth should be a trellis, not a ladder*.

4. Scale levels without moving goalposts

You’re working hard, hustling and shipping great work. One level above you is Lead Designer. One more project and maybe you’ll be up for it.

Oh wait, because the team has grown, a few more levels have been slotted in between. Now you’ve got to get three promotions to get where you thought you nearly were.

It wasn’t clear to you before how far you were from lead, and now it’s clear that you’re not getting there any time soon. That LinkedIn message with a Lead Designer job title is looking more interesting. And why shouldn’t you take it?

What I build by default shouldn’t allow new roles and titles to change where people stand. It should be absolutely clear not just how many levels there are, but proportionately what skills go into getting there.

5. No room for ambiguity

Those conversations where you think you’ve achieved a milestone, but it turns out that your manager actually was thinking of something different? Something bigger, more impressive? Not fair. You worked hard towards that milestone, and now it’s like you’re back to square one.

What I build should by default be unambiguous in its expectations on people. Everyone should agree on what has and hasn’t been achieved.

6. Keep it do-able

How are you meant to keep all eight improvement areas in your head, especially when so many of them are dependent on the right project or opportunity? No wonder that goal-setting can be overwhelming and difficult.

The reason so many of the current spreadsheet-based implementations fall down is the sheer size and complexity of them. Achieving one thing at any one time is hard, we can’t be expected to be simultaneously growing in 12 different directions.

The challenge is that anything too reductive will lose the necessary detail to solve the goal above. So that complexity needs to be abstracted away.

Clarity of purpose and a focus on small, achievable goals in a few areas will mean less context switching and more measurable progress.

What I build should be simple and focused for the end user.