How do you marry agility with OKRs for product and engineering teams?
Throughout his career, Mike Pilawski has seen the power of OKRs to fuel autonomous teams. By aligning teams’ priorities and giving engineers shared metrics that convey impact and performance in real-time, their investment in the work increases.
Teams that initially dragged their feet about OKRs eventually gain a greater connection to a mission and metrics they can control.
On an episode of the Dreams with Deadlines podcast, Mike shares why you should forget features in your OKRs and how limiting the distance between engineers and users helps everyone win.
Agility and OKRs: solve problems over building features
Mike’s approach to marrying agility and OKRs is simple but strong: To get OKRs right, he says, forget about features.
Many teams set KRs focused on building or releasing a particular feature, but this approach is fundamentally flawed. “Features are essentially guesses,” Mike explains. “They have a level of uncertainty in them — they are a hypothesis on you being able to address a problem.”
At first, you won’t know whether the planned feature will solve your customer’s problem. You have to build the feature to find out if it does, indeed, address the problem at hand.
Effective OKRs don’t focus on what your team is building but on effectively solving customers’ problems.
Organizations, both large and small, might set out to tackle a problem for their audience and brainstorm three or more paths they could take to solve the problem. A start-up typically has fewer resources to try complex experiments, whereas an enterprise organization will have more options.
Regardless of size, every company should focus on solving a specific problem and gauge success by tracking a metric over time — the same metric the customer uses to describe the problem. Remember: Using the customer’s metric requires knowing your customer’s priorities.
By setting problem-focused OKRs, Mike explains, you’re not prescribing how the team should address the problem. “They have complete freedom to test, to do different hypotheses, to design different products,” he says. “Essentially, that leaves it agile but, at the same time, pretty definite.”
The role of people in OKRs
Shifting an engineering team’s culture away from features to focus on experimentation and solving problems can be a major challenge. For Mike, the key is to focus on what makes the work meaningful.
Yes, most engineers find meaning in the challenge of their work — knowing they’re putting their skills to the best possible use. But a second aspect of meaning can make all the difference for a culture shift: realizing your work makes a broader impact on a community of people.
When engineers feel connected to end users that benefit from their work, the work becomes more than code — and OKRs become more than success metrics. Engineers feel a sense of satisfaction and motivation to solve real problems for real people.
Yet despite the major benefits of connecting teams to customers, many companies get this wrong, according to Mike. He says the biggest problem is that “they start creating layers between the teams that work on features or solving problems and the customers.”
Mike advocates for not having dedicated research organizations within companies. When a UX researcher makes a presentation to engineers and turns real users and their problems into numbers on a screen, engineers lose essential empathy.
“You haven't seen their faces. You haven't seen how it affects their lives,” Mike explains. “It's good to have a research organization and have them work with the teams, but not instead of the teams talking to customers.”
In Mike’s experience, setting aside time for engineers to talk face-to-face with customers transforms how teams work. Hearing about users’ inconvenient workarounds or frustrating pain points firsthand inspires engineers to resolve these issues. Mike says this inspiration sometimes seems to happen almost “magically,” but the magic has a simple explanation: Helping another human is a unique and powerful form of motivation.
Yes, research experts can and should support codifying customer research, running interviews, and analyzing results. But ultimately, Mike says, “Nothing can replace time with customers… You cannot isolate those who create from those who will be using the product.”
Why separating OKRs from performance evaluation works
The role of OKRs in performance reviews is one of the age-old OKR debates. Mike has worked in multiple companies that have made OKRs a central point of performance reviews, and he sees two key dangers with this approach.
For one thing, you’ll see consistent “sandbagging” — employees will set goals they know they can reach rather than ambitious or aggressive stretch goals. “Everyone will set it so they always hit 100%,” Mike says. “Nobody wants to get fired. Nobody wants to have problems.”
But the second outcome is even more problematic: Tying OKRs to performance reviews can signal to teams that they shouldn’t take big risks. “Product development is a risk-taking exercise,” Mike notes. “No matter how much research you do, you always have a hypothesis that this particular solution will solve this problem.”
Let’s say a team has an OKR of increasing a certain metric by 10% — which connects to their performance evaluation and merit increase. To achieve it, they might either increase by 2% monthly or take a big swing that could increase the metric by 20% or 0% in the next two months. Most engineers will take the former route to avoid the repercussions of a failed experiment. When a performance review relies on OKRs, the risk of failure will be too great, and engineers won’t take a chance on the potential for greater success.
The unexpected power of public recognition
Although Mike doesn’t support OKRs as the core of performance reviews, he does see immense value in celebrating OKRs as teams. During his time at Leanplum, teams presented quarterly about what they built and how customers benefited. Then, teams voted on which team delivered the most customer value. The winning team received a budget of $1,000 per person for a team outing.
But Mike noticed something surprising after several quarters of this recognition routine: He had to remind teams to take advantage of their outing. “The prize didn't matter as much as the fact that they got recognition from other teams,” Mike explains. Employees craved the respect of their colleagues more than the tangible benefits of the award.
For Mike, this kind of public recognition can serve one of the key functions of a performance review: rewarding those who put in an effort. He recommends using performance reviews to acknowledge not only those who got lucky with their experiments but also employees’ progress, effort, and improvement. But you’ll maximize motivation when you also recognize and incentivize customer value — ideally, in a gamified way.
“Then you can achieve both goals without necessarily having to tie them into an OKR system,” he says.
Dreams with Deadlines is the one and only strategy meets execution community. We’re a global network of ambitious leaders who are passionate about using OKRs and agile practices to achieve audacious goals and build a better future.
Whether you’re new to OKRs or a seasoned pro, the Dreams with Deadlines community is where you’ll find the knowledge, connections, and resources you need to achieve your goals with greater confidence, efficiency, and impact.
Join for free to get access to our private Slack forum, exclusive events, and curated networking opportunities to fuel your personal and professional growth.
