Bringing OKRs to life
We’ve been using OKRs (Objectives and Key Results) in the Redgate product division for over 18 months and there’s no doubt we’ve got better at creating them during that time, but there’s always room for improvement, so we’ve recently experimented with a more engaging way of showing progress against the key results.
Why did we do this?
There were two problems we were trying address with this experiment:
The first was that we weren’t seeing teams really engaging with the key results; they weren’t keeping them up to date and they weren’t using them to understand if the work they’d done was achieving the desired results.
The second was that stakeholders were finding it hard to quickly assess how the teams were doing. All the KRs were expressed in a slightly different way, and working out if numbers should be increasing or decreasing and then what they were actually doing took too much time and cognitive load.
Using the principles of gamification and “a picture paints a thousand words”, the Prompt team started to experiment, which inspired some other teams to join in the fun.
The Dev Lead for the Prompt team started with some fairly “out there” ideas to help explain to the team what he was thinking and get them more engaged with their key results. Luckily for everyone the team took up the challenge and designed some great fun visualisations. They included (but were not limited to):
- Mario jumping across pipes — the number of pipes being the features of SQL Server 2017 that prompt supported
- Removing pieces from the dragon that represented the scariness of the parser
- The smoke from chimneys representing the high priority features covered by smoke tests
- Minion faces representing customer satisfaction
The Masketeers team then got in on the action and having analysed 20 SQL Data Masker sets to understand what features were actually used by customers they started colouring the masks to show how much Fig Leaf supported these features. They also used the “Redgate Face Mask” for showing how many people were using Fig Leaf.
What did we learn from this experiment?
All of the visualisations were easier to see at a glance, but some of the visualisations were better at showing progress than others — i.e. which pipe Mario is on and the amount a mask is coloured is obvious; less obvious was removing bits from a dragon (you need to understand what was on the dragon in the first place to know if progress was being made) and how many people should be using Fig Leaf (is five good or bad?).
It became more obvious which measures were bad measures because we had no way of effectively measuring them — customer satisfaction is a classic one of these; the minions were great, but the team had no way of capturing the data to calibrate which minion represented the current level of customer satisfaction. This would have been the same with a numerical key result, but it would probably have been ignored until the OKRs were formally reviewed.
The final potential issue to be aware of falls into the camp of “what gets measured gets done”. By having a specific goal for a measure e.g. 15 SQL 2017 features, then the team focused on this without necessarily asking themselves whether it was still the right thing to do; moving Mario was potentially more fun and motivating than removing part of the dragon. Part of the aim of the experiment was to motivate the teams and make them engaged with the OKRs, but you still need to make sure you have the right goals.
Overall the experiment was viewed as a success — we learnt some things, and identified improvements that can be made for the next iteration of OKR visualisations. Current visualisations include the Masketeers’ horse race track (how many horses will fall at the hurdles?) and the Versioning teams’ endangered list (have they saved the Panda yet?).