In my OKR Masterclass I list the 3 top benefits to using OKRs:
- They explicitly demand our teams do product discovery work to determine the best combination of code, copy, design, business model and value proposition that will drive our desired customer behaviors.
- The more discovery we do the more empathy we develop for our customers and users ensuring we continuously improve the customer-centric nature of our culture.
- OKRs drive organizational agility by forcing us to change course based on newly discovered evidence (the fundamental definition of “agility” rather than “agile”).
There’s a foundational element that underpins these benefits: the ability and capability to build learning into our ways of working.
There are at least two sides to this conversation (probably more). On one side you have to build a culture that actually wants to learn. On the other, you have to provide your organization with the tools and resources it needs to do the work needed to learn. This post will focus on the tools side of the conversation.
Continuous access to learning
“Make learning the path of least resistance.” – Astro Teller
When it comes to supporting learning work teams need to understand both what is happening in the systems they’re building as well as why it’s happening. It still amazes me that in 2022 there are organizations that don’t instrument their software. In a medium where every click, field entry, error message and user event can be recorded, aggregated and analyzed there are still companies who refuse to do so.
Slightly better but still frustrating are the companies who do instrument their code but then restrict access to that data to specific individuals or skill sets. I used to work at a company where only the “business intelligence” had access to our site usage data. If you wanted to learn something about how a feature you shipped was performing you had to get into the BI queue. You had a finite amount of “BI time” your team could spend and if the CEO had an urgent need, well, he’d jump the queue leaving you even further behind in the dark.
If we’re going to set OKRs as goals for our teams they must have access to analytics. That access has to be universal and simple. The front-end on these reporting tools needs to be user-friendly and a basic requirement for every product development team member. Anyone, at any time, should be able to run a report to understand how something the team shipped last week performed over the weekend.
There is an ever-changing and seemingly infinite number of analytics providers. Use the one that works best for you but, most importantly, use one. Ensure that “the cost” of instrumenting your code is built into your estimates and don’t restrict or ration access to the output of these tools.
The same holds true for other enabling tools like A/B Testing platforms, design systems and technological choices that enable continuous deployment of code to production. Every one of these tools (and there are more) enable your teams to bias towards action and learn more quickly whether what they’re working on stands a good chance of delivering real value to the customer. Speed is critical! The faster your teams learn they’re working on something that isn’t going to deliver the expected results, the faster and easier they can change course (agility!).
Qualitative insight should not be forgotten here either. The tools here often are less technological. Without the “why” the “what” the analytics tools deliver is not nearly as useful. Supporting qualitative learning means providing a budget to hire recruiters and customer interview participants. It also involves investing better relationships across disciplines to ensure that, for example, Sales isn’t going to hinder access to customers but instead, participates in that process. While this is not a “tool” per se, it is a critical function of learning that must be supported.
Finally, there are qualitative learning tools that provide services like unmoderated user research and other voice of the customer insights. Buy your teams the licenses they need to get this insight.
Knowledge sharing and transparency
Ok, you’ve invested in learning tools. Well done. Now, how do we ensure that the learning they’re generating is broadly accessible? How do we reduce duplicate efforts across the organization? The next set of tools we need to invest in are those that drive knowledge sharing and transparency. In an ideal world, when one team learns something, the whole organization learns it.
There is no perfect tool for knowledge sharing. In my career I’ve probably tried them all. From wikis, to Confluence pages, to Slack channels to email, the teams I’ve worked with have tried every form of communication to share knowledge. The best tool for your organization is the one that works. This means there will be some experimentation and some failure (this is learning too!) about which tools drive the transparency your teams need.
Sometimes it’s not a tool at all but an investment in time. One company I worked at ran a weekly “demo day” (hardly a novel concept) where any team could sign up to present. The kicker was they could present anything they wanted to. It didn’t have to be working code. Over time, teams would share experiments they ran, learnings from those experiments, videos of user interviews and prototypes they had built. This scaled up to a point (about 400 employees or so) but beyond that it was hard to get the attendance necessary for broad shared understanding.
One of the key bits of information that teams need to be transparent about is how they’re tracking towards their OKRs. In addition, that progress rarely exists in a bubble so what are the dependencies of that progress or lack thereof? Providing your teams with tools to track their progress while visualizing the connection between other teams’ work and the overall corporate strategy improves each team’s context for decision making. I’ve shared various ways to track, make transparent and visualize OKR progress in a previous blog post that scales up your investment based on the size of your company.
It won’t be free, but it will be worth it
Tools cost money. Working blind costs more money. If you’re going to give your teams the creative freedom to work with OKRs and discover the best way to solve your customers’ pain points and needs, you’ll need to provide them with the tools for continuous learning. To maximize that investment you’ll need to make the output of these tools broadly available and transparent. OKRs work when progress is clear and attributable. The more we can enable our teams to learn continuously and to share broadly, the more likely they’ll be to hit their goals and drive your company’s success.