We've just finished a two week design and development sprint with a total focus on improving one of the core areas of our product: the check-in. In this post I'm going to talk a bit about the concept of a check-in and how we improved the process on Progression.
Progression frameworks- a two-step process
From speaking with hundreds of organisation about the process of implementing a progression framework, we've observed it most commonly happens in two steps.
Step one is the creation process: other organisation's frameworks are reviewed, subject matter experts are consulted and after many meetings a final framework is created and then distributed to the team.
Step two is where things get interesting: the organisation starts to look at how it can use the framework to inform activities like 1-1s, hiring and training.
We think of our product along similar lines: 1) how do we facilitate the best framework creation and distribution experience? And 2) how do we provide high quality insights and recommendations from the team's interactions with the framework?
So what is a check-in?
Check-ins are at the core of step two. They are an opportunity for a team member and manager to benchmark the team member's skills against those required of them by the framework. The result is a snapshot of how they compare against the framework and an indication of their strengths and growth areas. In aggregate, this data can inform managers on the "shape" of their team and spot gaps in critical hard or soft skills.
Although check-ins are a form of assessment, we strongly believed they should be done in the same constructive spirit that you might work with a personal trainer in the gym. Team members should not be trying to hide their perceived weaknesses and managers should not try to turn the process into a formal performance review.
What's changed since the v1?
We won't lie, our first implementation of check-ins was somewhat clunky and encouraged counter-productive behaviour. In v2 we have made three big changes:
Limiting levels. In v1 we allowed users to pick any skill level from 1 - 5 (beginner to master) for each skill required of them. This led to some users picking 5 for everything and creating an awkward conversation for their manager who needed to bring them back down to earth. In v2 we change this to "working towards", "meeting" or "exceeding" the level required of that role. We think this is a healthier way of approaching the assessment.
Manager input. Our first version simply asked the team member to rate themselves and this self assessment was kept as the snapshot. V2 is much more nuanced. We ask the member and the manager to assess and then take them through a joint process where they reconcile any differences in assessment. This provides balanced data which can be used to generate valuable insights.
Actionable insights. We use the data from the check-in to provide a range of information and suggested actions. An individual team member can see their skill shape vs what's required of them for their role. They can see a break down of skills by skill type e.g. hard vs soft, or human vs craft vs leadership. We also developed something we call "Strength Score" which helps you to prioritise your growth areas based on how your final assessment differs from what is required for the role and your initial self-assertion.
Looks great, how can my team and I do one?
Funny you should ask! We are currently running private, paid beta and are actively looking for teams that would be a good fit for our product. If you think that could be you, we would love to hear from you! Drop us a note at: [email protected].
If you want to start using Progression today, please join our waitlist or email us at hello [at] progressionapp.com.
We also have limited opportunities for teams to work directly with us to set up their frameworks. Please email us if you want us to help you out.
