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.
