Increasing OKR Impact with Bottlenecks
Do you feel that, despite having a great strategy, cutting-edge practices, technology, and ideas, your delivery is still too slow? Are you struggling to respond quickly enough to emerging opportunities and threats? If so, you might be trying to solve this problem with algebra instead of calculus. Let me explain.
When managing a business, we fundamentally do two things:
- Run the business
- Change the business
Well-managed businesses typically use Key Performance Indicators (KPIs) to run their business and Objectives and Key Results (OKRs) to change their business. Both functions introduce changes, but the big difference is that OKR-related changes are linked to long-term strategy, while KPI-related changes are typically tactical and focus on maintaining operations. The right balance between these functions ensures short-term resilience (KPI-driven) and long-term evolution (OKR-driven) in response to external forces, such as political, economic, social, technological, environmental, and legal factors.
Algebra vs. Calculus
To frame the problem, let’s revisit the analogy of algebra and calculus. Algebra is primarily about understanding relationships — how one variable affects another. For example, if you increase resource capacity in one area, how does it affect the overall output?
Calculus, on the other hand, is about understanding change over time — how things move and evolve dynamically in space and time. It’s not just about relationships but about flow, velocity, and acceleration.
The challenge many businesses face is that they try to solve problems with an algebraic mindset, focusing on static relationships (e.g., increasing resources or team sizes) rather than embracing a calculus mindset, which looks at how the system as a whole flows and adapts over time.
The Challenge of Scaling
In my experience, challenges often arise when a business starts to scale. As the frequency and complexity of change demands increase, they can outstrip supply in terms of capacity and capability. However, the hidden truth is this: the rate of change is not proportional to the total supply of resources but rather constrained by the slowest process, person, or technology in the chain of activities needed to deliver.
Get Fred Pernet’s stories in your inbox
Join Medium for free to get updates from this writer.
Here’s a simple example from technology:
Imagine 100 developers create an average of 10 valuable features per day, but quality control engineers can QA only 5 valuable features per day. If you double the number of developers, what happens? You guessed it: the output remains at 5 valuable features per day because QA becomes the bottleneck.
The Theory of Constraints
This phenomenon is brilliantly explained in Eliyahu Goldratt’s book The Goal, which introduces the Theory of Constraints. Goldratt illustrates how identifying and addressing bottlenecks is critical to achieving business goals. (The Phoenix Project and Zone to Win offers a similar perspective but focuses on knowledge work.)
But here’s where the problem gets worse: In a “push” system, work piles up at the bottleneck. For instance, if QA can process 5 features per day, but developers continue creating 10 features per day, a backlog of untested features quickly accumulates. After 10 days, you’d have 50 untested items.
In my experience, this issue is suprising common in agile transformations, where teams might adopt agile methodologies operating in cross-functional teams but still operate in a push-based system. Work is pushed between teams, third parties, and specialists, creating inefficiencies. Tools like JIRA can inadvertently obscure this problem, much like trying to watch a football match through 11 different CCTV cameras (one per team member). Before you know it, there are 22 balls on the pitch and no referee to blow the whistle!
The Solution
The solution is surprisingly simple but counterintuitive: convert the “push” system into a “pull” system. Use the spare capacity generated by this shift to improve flow between stages.
Returning to the developer example: If QA can process 5 features per day, developers should deliver no more than 5 features per day. The remaining capacity can then be used to automate QA processes (e.g., through DevOps). This creates a continuous improvement loop. In practice, this is implemented using a Lean-Kanban board with work-in-progress (WIP) limits at each stage of the workflow.
In Summary
If you feel stuck in slow OKR delivery despite great strategies, tools, and ideas, it may be time to shift from an algebra mindset (studying relationships) to a calculus mindset (focusing on the end-to-end flow and movement). By setting up the right workflow and converting push systems to pull systems, you can free up capacity to accelerate delivery, improve quality (more on that later) and the best part is it cost you very little to do it.
Have you seen anything like this in your organisation?
🚀 To book a free consultation call with me please click on the link
