Using OKR Based Leadership to Empower Teams
6 February, 2020
VP Engineering at Stitch Fix
In most of the previous companies I have worked with, our goal was to keep empowering teams, yet there was somewhat of a confined matrix around it. So much so, that the teams never truly felt empowered. What we were going to do in the matrix had already been decided. Teams were empowered to find the ‘how’ and maybe contest or argue about estimates in order to inform the ‘what’, and make trade-off decisions around that. These companies would continue to claim that teams were empowered, but in talking to the teams, we all felt rather disempowered.
I did a lot of reading on the topic and landed myself at Stitch Fix where they practice OKR based leadership. Despite all the reading and training available on OKR’s, it really roots down to describing what it is you are going to do and how you will measure it.
With this approach, I have my teams define the ‘what’ together, and not in a way of delivering “Project X”, but in a way that drives an impact. Their objective is defined as an impact and this is the way that they can measure whether they can achieve that impact.
This can be achieved in various ways. It could very well be achieved by delivering on a project. Depending on the impact, it could also be done creatively through a growth hack. Then, mid-quarter, you can decide if it is working and change courses accordingly.
- I feel so much more empowered driving this behavior knowing that all my vessels are being utilized. Instead of a prioritized list of features that people are working and delivering on, every member on the team is now responsible for an impact. Teams become empowered to start making decisions around the ‘what’ and the ‘how’ as you move to speak in terms of impact versus tasks, features, and capabilities.
- The past approach was very list-based, and to some extent, as you deliver on this, you kind of walk away from the impact. Therein comes the phenomenon of delivering a feature and not knowing if it is successful. With OKR’s, the team isn’t done until the impact is achieved. Teams will keep at it by raising the stakes, moving forward, making decisions, learning, and by default, putting enough measurement in it because they are unsure if the feature will work until they measure it.
- Of course, company OKR’s remain of utmost importance. I can’t go in and design an OKR that doesn’t align with the company’s goals. There is some amount of governance around what you are deciding to achieve. The company’s goals can be more specific towards a revenue target perspective, but then your OKR’s should line up to it.
- I feel like organizations become comfortable in a list of things that subsequently doesn’t evoke good questioning. An organization that challenges each other is a healthy organization. OKR’s interestingly provide a very respectful way to do that. It’s often difficult to ask the question of why you want to do a project. I felt a lot more comfortable asking questions in the OKR framework because they are transparent by default and people are more open to them because they are expected. This allows you to really feel empowered as stakeholders, to define the objectives of your team and others.
- This has been a huge personal change in my perspective on how leaders can empower teams and grow empowered teams in this time and age. We are all consumers who consume a variety of products. I have a say in how I interact with those products. Even though I am not trained as a product manager, I am a user first. Even if product managers today are not engineers, they have a good sense of what is difficult and what is easy. Designers who don’t write code know when they are asking things that are standard paradigms unsupported by the browser. I feel as if the roles have now become so intermingled, that there is a real appreciation for each other’s skill sets.
Jackson Dowell, Engineering Manager at Asana, explains how he moved his project forward by coming up with a clear model of the system and problem that provided guidance to the team and helped communicate their efforts outward.
Engineering Manager at Asana
Toby Delamore, Product Manager at Xero, describes how he helps his reports grow in their career and become well-rounded product professionals.
Product Manager at Xero
Toby Delamore, Product Manager at Xero, explains how skip-level conversations and maintaining an attentive relationship with engineers enabled him to keep a finger on the pulse of the team.
Product Manager at Xero
Patrick Chen, Lead Product Manager at Next Insurance, recalls how he let someone else make product decisions and how he managed to mend his initial mistake.
Lead PM at Next Insurance
Paulo Moncores, Senior Engineering Manager at Shopify, discusses why you shouldn’t avoid hard conversations and what role culture plays in handling them.
Senior Engineering Manager at Shopify
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.