“OKRs S&%k, but we don’t know anything better”
This was a direct quote from a cybersecurity scaleup’s Chief of Staff, but I hear the sentiment way too often from founders, chiefs of staff, COOs, and others in the scaleup ecosystem.
I started encountering OKRs when working with scaleups a couple of years ago, helping leaders fix their ways of working to reap the promised benefits of “Agile.”
A specific BioTech scaleup used OKRs as a “grown-up” way to manage an organization growing fast and needing more management.
It felt like an artifact of “Manager Mode” (as opposed to “Founder Mode”). You could imagine their VC “suggesting” OKRs (and EOS).
When I looked deeper into HOW they were using OKRs, I saw some familiar patterns. I’ve been helping leaders fix their Agile for a while now. It was interesting to see some of my usual nemesis patterns:
- Using new processes to reinforce rather than bridge across silos/functions – manage dependencies rather than avoid them.
- Calling work in different names but still being involved in the details as if it were still early days in the lab/garage/WeWork shared space – instead of providing clarity about the mission and staying at the right altitude—choosing strategically what check-in cadence and involvement is appropriate where.
- Using cool new tools (Monday, ClickUp, Trello, JIRA, Basecamp and Kanban boards in general) but still working on too many things and inflicting context overload and unsustainable pace on everyone.
- Telling people their goals rather than involving them in figuring out the mission and the plan.
We got going fixing their OKR operating system.
We started by focusing their OKRs on the things that mattered, not everything that was happening. We reflected on how to organize around these OKRs. We made structural changes to the organizational topology, complemented by temporary empowered teams.
We rewrote OKRs to focus on outcomes, e.g., “Double the velocity of our search for useful therapeutics,” and brought those into a big-room collaborative goal-setting session where everyone in the company tried to figure out what this meant and what would need to be true for it to be possible (hint—it’s not about working twice as hard!).
We deemphasized mechanics and pedantic processes and emphasized principles. This also applied to their use of agile processes. A dogmatic Scrum Guide compiler would probably have issues, but they didn’t care. They understood Empiricism (it helped that they were all smart scientists) and did what was needed to ensure they had it.
That enabled them to leverage agility (not necessarily agile!) beyond their software/technology teams. They started using iterative, outcome-oriented, empowered cross-functional teams for initiatives such as “Scientist productivity – getting them up to speed and getting out of the way” that involved People Ops, IT, and Business Ops.
The results? Finally, there is more traction towards what’s important without micromanaging. The leadership team finally has time to focus on where to take the company. People feel like players, not pawns. They are becoming more agile (not necessarily doing agile). They are leveraging OKRs (instead of following OKRs).
They had a scalable operating system in place that allowed them to continue to tackle the growth/scaling milestones they would continue to face.