Evidence-based Management

Fix Your OKRs – Back to First Principles

Context

OKRs (Objectives and Key Results) have become the latest management framework to suffer the fate of becoming popular too quickly, to the point where in many organizations, OKRs are a theater/charade with little useful substance or benefits. That’s a shame because OKRs have huge potential if used effectively. So let’s go about fixing your OKRs!

Why OKRs

Let’s start with the basics. What are OKRs even about?

OKRs aim to help you execute effectively on what matters most (your strategy), while overcoming silos, politics and turf wars, the ongoing grind (aka whirlwind), and other management challenges. To face all of these challenges, OKRs provide organizational alignment and focus.

As defined by WhatMatters.com:

OKRs – an Alignment Framework – a collaborative goal-setting methodology used by teams and individuals to set challenging, ambitious goals with measurable results. OKRs are how you track progress, create alignment, and encourage engagement around measurable goals.

Let’s now dive into HOW OKRs (used well) set you up for success and what might go wrong.

Achieving Focus – Focusing on the few Strategic Objectives

OKRs should help you focus on your strategic priorities. Having a small set of strategic objectives reduces context switching and provides a rallying cry that helps cut through silos and politics.

Choosing where to focus is hard, though. It’s much easier to define an OKR for everything – and then when everything is important, nothing is really important. and that’s exactly what we often see out there.

So with that in mind –

Avoid … mapping all planned initiatives to OKRs.

Try … rallying around 1-2 OKRs.

Working IN the business vs. working ON the business

Another way organizations drown themselves in OKRs is by having OKRs for everything.

Running the business doesn’t require OKRs. Key Performance Indicators (KPIs) can be used to manage/monitor operational work.

OKRs should be used just for development/growth work – work we do to change how we do things.

As you might imagine, This distinction helps reduce the number of OKRs significantly, leaving a set of fewer, more focused objectives.

Development/Growth/Transformational work typically involves more uncertainty and complexity than running the business as usual. In this environment, a lot is unknown – What’s the best way to achieve the goal? Does the goal still make sense?

Our way of working ON the business might need to look different than our way of working IN the business. (see this article for a deeper dive on what working ON the business might look like, leverage the perspective of Private Equity firms who focus on working on the business to maximize value creation)

This environment calls for evidence-based management – a management approach designed to improve outcomes when facing complexity through unleashing empiricism, self-management, and cross-functional collaboration.

OKRs are designed to be an evidence-based management approach. But there are a couple of key principles and practices that need to be in place for that to take place.

Rally around Outcomes (rather than managing outputs/activities)

One key aspect in ensuring OKRs enable evidence-based management is the type of goals we use. Managing outputs and activities can work reasonably well for working in the business since that work is typically operational and defined.

On the other hand, Using output/activity-based goals to work ON the business fixes plans, specifications, and designs too early. It reinforces a “factory” mindset where people focus on their deliverables rather than the wider problem/opportunity. And it lends itself to heavy-handed command and control.

For complex, uncertain work, you should set goals using outcomes. Outcome-based OKRs unleash self-management, empiricism, and people’s creativity to explore/discover. They create environments where people are empowered to work together to solve problems. This is how you should be working ON the business.

One of the challenges with managing through outcome-based goals is that you need to wait longer to see outcomes – making it tempting to manage through outputs or even activities. But remember – the role of OKRs isn’t to manage the day-to-day. It is to provide alignment around where to aim. People can use other processes to manage their work toward the OKRs.

Instead of breaking outcomes into outputs/activities, experiment with identifying intermediate outcomes. This is challenging but satisfying (TIP: Slicing outcomes is similar to identifying a Minimum Viable Product, Minimally marketable features, and Slicing Stories… so your Product leaders and Agile practitioners can help out on this front). If coming up with outcome-based KRs is too hard, Start with making sure at least the qualitative Objectives are outcome-focused and, over time, evolve from output towards outcome KRs.

Aligned Initiative over Command and Control

When leaders want to align their wider organization around their strategic goals, they often cascade OKRs throughout the organization. This strict cascading means that by the time you get to the people who will work towards the goals, they are bound to tasks/activities and don’t have the maneuvering room they need to seek the best way to achieve the goal, not to say reconsider what’s the best goal. This looks quite similar to OKR’s predecessor – Management by Objectives (MBO) which was very control-oriented. And it results in people who are disengaged. (did anyone say “quiet quitting”?)

There’s a false dichotomy that many leaders fall for, which is the belief that alignment requires control. Actually, alignment and control are two separate aspects that can work in concert to create effective management. Donald Reinertsen calls this Aligned Initiative. David L Marquet talks about Intent-based Leadership. Henrik Kniberg, in his usual brilliance, maybe nailed it best in this diagram describing Spotify’s “Aligned Autonomy” engineering culture principle (Jason Yip elaborates on this principle here).

Why does initiative/autonomy matter so much? There are two main reasons. The most important one is that in the creative work that working ON the business requires, the best solutions emerge from the people in the trenches. And by providing them with a clear goal and empowering them to take the initiative, we dramatically improve our chances of achieving the desired outcomes. A secondary benefit is that people are intrinsically motivated by being empowered and provided with the right level of autonomy.

The key, then, is to achieve alignment without strict cascading. Leaders should use OKRs to provide context and direction. To inform about why rather than prescribe what/how. Teams/groups then come up with their OKRs. The connection can be reinforced as part of the “Why Now” for each objective. Teams/Groups share their intent with each other and with relevant leaders to help ensure alignment in an environment of empowerment/autonomy.

(This might seem like a complex process to pull off… the good news is that there’s a lot to learn from agile ways of working about facilitating such processes. For example, I helped a fast-growing biotech startup create an approach for cross-company OKR planning leveraging a process similar to SAFe’s PI/Big Room Planning)

Figuring out the right Cadence

A key aspect of evidence-based management is the feedback loop. Many organizations set OKRs for the quarter and then forget about them until the end of the quarter. It’s like setting your sales quota and only checking back at the end of the quarter. Recipe for disaster, right?

The other extreme is to micro-manage OKRs to death.

It’s all about finding the “goldilocks” cadence that provides frequent enough transparency and the opportunity to inspect and adapt at the right level. There can be a different cadence for everyone involved in achieving an OKR as compared to the cadence involving all stakeholders interested in that OKR. The right cadence also provides an opportunity to reinforce/communicate strategic priorities and focus.

The Scrum framework provides one example of how such a cadence could look. Consider a cadence that involves Planning, Reviewing, and Retrospecting with a clear distinction between the team working on the OKR and its stakeholders.

Cross-functional Alignment

Leaders struggle to manage the cross-functional collaboration and dependencies many OKRs require. The coordination overhead makes it tempting to divide and conquer and cascade the OKRs into focused/defined OKRs for each function/group. The problem is that this immediately turns into output/activity focus and ends up with the same challenges described earlier in the Rally around Outcomes section. Why? Because functions cannot own cross-functional outcomes.

So what’s the alternative? To organize around OKRs. After identifying the few real OKRs, assess who’s needed to work towards each of them. If they require cross-functional collaboration, create an empowered cross-functional work team to make collaboration easier. Another benefit of organizing around OKRs is that working on a team around a clear business strategic goal with a clear, quantifiable metric that the team is empowered to have a direct impact on boosts the feeling of purpose and creates better engagement and motivation.

Disconnect/confusion between OKRs and agile ways of working

I often see teams and organizations that struggle with the relationship between OKRs and agile ways of working. They’re unsure of the best way to relate OKRs to their Backlogs and feel there’s a redundancy between the agile and OKRs cadence.

Hopefully, at this point of the discussion, you can see that OKRs and agile ways of working are very similar. Both are based on focus, cross-functional collaboration, alignment, empowerment, and empiricism.

So how do we address the overlaps?

Some OKRs map cleanly onto existing teams/groups in a product development organization. In this scenario, they can inform the creation of Product Backlog Items for the team/s to focus on (or the creation of Features/Epics in a higher-level backlog ). If a new product development team or team of teams is created to focus on a cross-cutting OKR, the OKR can become the Product Goal / Vision for this new group. In both cases, how we’re doing on our OKRs should be inspected during Planning and Review events and inform decision-making. There’s no need for an additional ongoing OKR cadence. Quarterly or so OKR review/planning can replace “Release Planning” with a higher focus on outcomes/impact. If needed, this OKR review/planning can include a “dry run” planning exercise along the lines of SAFe’s PI Planning to make sure that the OKRs are both aligned with the business stakeholders and realistic.

There’s a wider opportunity here, though. While Scrum was created as a framework for managing product development, it is appropriate for working on any complex problem. As we’ve established earlier, work to achieve OKRs is typically complex, even when it’s not product development work. The natural next step is to apply Scrum (or other agile ways of working) as the approach to doing the work towards achieving the OKR. Scrum can become the operating system for working ON the business.

All together now – OKRs AND Agility for the win

To sum up, OKRs and Agile/Scrum aren’t in conflict. Looking at OKRs with Agile/Scrum lenses reinforces the first principles that OKRs are based on. To successfully leverage OKRs, you should:

Focus on working ON the business vs. IN the business
Stop starting, start finishing – Focus on a few key strategic initiatives (maybe even just one)
Rally around outcomes rather than micro-manage outputs/activities
Provide alignment and enable initiative through empowered teams/groups
Organize around value – leveraging OKRs
Leverage agile/scrum to execute on OKRs
When in doubt – go back to first principles – Alignment, Empowerment, Focus, Empiricism

If you’re curious to learn more about these principles and how to apply them – a good place to start is the Evidence-based-management framework. The Scrum.org Evidence-based Management Training (PAL-EBM) workshop is a one-day workshop that explores this space and can be a great way to start fixing your OKRs or, better yet, get started the right way…

Agility / Evidence-based Management and their role in improving returns in the Private Equity…

In this article, I’ll explore the need for and the attributes of an agile business operating system related to Private Equity (PE) portfolio companies. It hopefully helps leaders of such companies and PE professionals focused on the operations side expand their perspective on what “Agile” and “Agility” mean in their world and how they can help them improve returns realized in their investments.

Dealing with common business challenges through agility

I’ve been helping companies improve their operations for more than a decade now. A repeating pattern is where a very successful company is facing growing pains affecting its ability to scale to the next level. Some examples of the challenges I’m called in to help with:

Losing the Ability to Innovate You often see companies that grow successfully to the point where it seems their ability to innovate stalls. When you look deeper, you see them struggling to cope with growing technical complexity, coordination costs across teams, and leadership bottlenecks. This affects product innovation as well as GTM innovation and other key business processes.
Time to Market / Time to Learn — The more complex the organization, the more time it takes to deliver value or close a learning loop. And in an environment of volatility, uncertainty, complexity, and ambiguity, this hurts your ability to compete. The bigger you are, the more you resemble the incumbents you once disrupted. Everywhere you look — product development or how the company runs its key business processes, there’s more and more friction and slowdown.
Losing Key Talent — Talented people are looking for an environment where they can thrive — where they have the right level of autonomy, where they work on interesting problems with minimum friction and headaches, and where they can see the value and connect to a worthwhile mission/purpose. As companies grow, the way they operate becomes less and less attractive to talented people. They feel bottlenecked, stuck, and mired with more and more legacy and start looking for greener fields.

Business/Organizational Agility — The New Business Operating System

Addressing these challenges by improving our ability to innovate and deliver, solving complex problems, in an environment of uncertainty, is what we call “agility.” It essentially translates to having a scalable ability to build/try/measure/learn, in fast cycles, customer-facing products as well as business/internal processes, in a way that is aligned with the company’s strategic focus. You might also call these OKRs, Distributed Leadership, Nimble, DevOps, Lean Startup, or Scrum.

While Agile was created in the IT/Software world, more and more organizations are realizing that its principles and thinking apply broadly. Business/Organizational Agility is emerging as the term used for this new and improved “business operating system” that applies these agile approaches across the organization from product development/IT through revenue-generating activities such as Sales/Marketing all the way to how the C-suite/Senior executives are working as a team on the biggest gnarliest challenges the company is facing in executing and validating its business model.

This new “business operating system” typically requires some virtual reorganization to teams and teams of teams that own products/experiences/value, adoption of evidence/data-driven ways of working, and a leadership style that provides clarity and empowers teams to figure out how to work and how to achieve their goals. It includes work on focus/flow, empiricism and continuous improvement at all levels of the organization.

A useful definition of the essence of this agility is provided in the Evidence Based Management (EBM) framework created by Scrum.org. This framework can also be used to assess a company’s maturity on the journey towards being an “evidence-based managed company” or operating on an “evidence-based operating system.” The EBM framework purposefully stays away from prescribing ways of working.

In recent years I’ve been working with more and more companies that are applying these “Evidence-based agile operating systems” across the company.

The trigger to “upgrade the operating system” is sometimes pro-active internal leadership. More frequently there’s a major event driving it. This can be a major new threat/opportunity, a major change in leadership, or an investment/recapitalization event. This is where the Private Equity (PE) connection comes in.

Private Equity — Betting on improving the value of companies

Generally, at least in my understanding, PE firms search for opportunities to “improve” assets in the form of companies. This improvement can be described as taking a company with current value (CV) and tapping into unrealized value (UV).

These opportunities are identified and validated via a Due Diligence (DD) process. Traditionally, PE “deal teams” focus on this gap between CV/UV and forming an investment hypothesis around what might be the return on investing to realize this additional value over a certain number of years. At this point, the PE deal team has essentially a set of “bets” that if successful will create outsized value for the investors.

Why are we saying bets/hypothesis? Because there’s a level of uncertainty around whether indeed these bets will create the value they’re intended to. There’s also uncertainty around the company’s ability to change/transform in the way these bets require. Some bets require creating products, and some change how products are sold/serviced. Some require different organizational structures. Regardless of the type of bet, one other thing to consider is that if this was such a sure bet — wouldn’t current company owners move forward on this already? In some cases, the answer is that they couldn’t without the funding brought in by the PE round. In other cases, the answer is that making the change isn’t trivial, and requires a strong capability to innovate and deliver in the company.

Validating Change Readiness as part of the PE Investment Hypothesis

One inherent but sometimes implicit bet is whether the company is change-ready. Does it have the culture and operating systems needed to execute the investment thesis? While traditionally PE firms focused mainly on the financials, more and more are realizing the importance of assessing and thinking about culture, team health, and other operational aspects as part of the investment thesis. Looking at modern due diligence processes, you might recognize elements of Lencioni’s 5 Dysfunctions of a Team framework (or The Advantage), eNPS/Glassdoor results, or other cultural / talent-oriented aspects. The EBM framework described above provides an additional facet to explore and think about.

If gaps are identified, working to become a lean, mean, agile change-ready company using an evidence-based operating system should be considered part of the PE “100 days plan” — as an enabler for working on other elements of the business transformation plan.

Focusing Agility Where It Matters The Most

Having a company-level evidence-based operating system doesn’t mean every activity in the company should be managed in an evidence-based manner. This way of structuring/working is especially useful when working on developing — developing products, services, or generally “ developing company #2” (the company you want to become). Running ongoing operations might or might not require this way of working.

One exercise that a PE deal team can run with the leadership team of a portfolio company is to assess each element/bet in the investment thesis and categorize bets according to uncertainty, complexity, dependency, and impact. Then, based on this analysis, choose the ones that would benefit the most from an “evidence-based management approach” and plan how to manage them this way. This might mean organizing a cross-functional, empowered, focused team of the portfolio company employees and external SMEs (if relevant) that will work in short cycles to create useful increments of value in this area and review them frequently with other stakeholders. It might mean creating high-level “Goals” and providing people with clarity on the Bet while giving them the space to explore alternative ways to achieve the desired outcomes via trial and error in the trenches.

The Day-to-Day Challenges of the 100 Days Plan

Some interesting challenges typically stress the business operating system when executing a transformation.

People struggle to balance their day job (Company #1 the current company that needs to continue running) and transformation work (Developing Company #2 — the one we are working to create) — how much capacity to assign to each? Does it make sense to manage the day job and transformation work as part of the same bucket? Who’s in charge of each type of work? Who mediates when there are conflicts? What I hear from CEOs in these situations is that frequently these conflicts between the day-to-day and the transformation go all the way up to their table, resulting in delays, frustrations, and feelings of disempowerment in times when people are already sensitive to any cultural changes and there’s increased challenge to retain top talent.

Another common friction/frustration area is goal-setting. What should we focus on now? what’s realistic to achieve? Are we involving people who will do the actual work in goal setting? OKRs are a popular goal-setting mechanism. But they’re not as trivial to implement as they might seem… One common anti-pattern is to set too many OKRs, top-down. ( A better way is to provide alignment via Objectives and let teams come back with realistic Key Results. There’s much more to say about the effective usage of OKRs in a PE environment, maybe later…)

This balancing act between operational and transformational work, alignment and autonomy, is a key area of focus for business/organizational agility. In my experience, Patterns such as “product ownership” and “developers”, while they sound very IT/product-centric can come in very handy.

Organizing around Bets

Another common sign of trouble is when teams are overly dependent on other teams to the point that their progress is frequently blocked and spend precious time coordinating and managing across the organization rather than executing. This can manifest as leaders of teams being extra busy in trying to coordinate the complicated network of dependencies and the desire for more and more “coordination/management layers” such as PMOs, project managers, and the like.

A preferred play is to reorganize around value — rethink team structure and bring together the people collaborating closely in executing the transformation, into empowered focused teams that self-manage with minimal overhead. These teams might include people from different functions — for example, Product Management, Marketing, Sales Enablement or Finance, Legal, and HR. This virtual team structure should be aligned with the key initiatives the company is focused on.

Continuing the conversation

Disclaimer: If it’s not obvious by now, I’m not a PE expert. I wrote this article based on my experiences as an agility coach in the trenches with PE portfolio companies, conversations with former clients who went through a PE transaction later on, conversations with CEOs, and my research into the PE space (I found the ParkerGale Private Equity FunCast especially useful btw). I’m sure I’m butchering some PE lingo and process. Please, call me out on it!

Hopefully, this article, as imperfect as it is, convinces you to take a different look at agility as something you or others in the PE ecosystem you work with should care about. If it has, or if it hasn’t, I’ll be happy to hear your reactions or comments and am of course happy to help you explore further.

Originally published at https://www.linkedin.com.