Originally published Jan 22, 2018
When we talk about organisational models and systems of incentives as applied to companies, the conversation often (as with other topics) falls into dualism - implementation are wrongly pictured as just black or just white, nuance is removed from the conversation and the pitfalls of applying an incentive structure and goal-setting framework to an organisation are a second class citizen.
By system of incentive, I generally mean an organisational framework that allows departments and teams to define and pursue a given strategy, set goals, monitor their progress and celebrate their achievements. These frameworks end up defining which behaviours get rewarded, who progresses in their careers, which teams and individuals are considered high-performers, what metrics are in the company’s dashboards and what colours they’re displayed in.Geckoboard’s Mixpanel example integration with key web metricsIt is clear that these shouldn’t be taken lightly. Every rational individual within a given company will steer their behaviours towards what is rewarded, so these frameworks end up playing a fundamental role in defining the emergent and fractal set of behaviours we call culture. When executives try to create cultural shifts by architecting these incentive systems, they need to simplify the mental model of their organisation to a set of characteristics that need to be optimised. For example, one might be trying to increase throughput and decrease bureaucratic overhead, noble goals, so they deploy a system or framework to incentivise teams and employees to do so.
This post looks at how culture plays such a big role in the effectiveness of the models and framework of choice, and how when heavily optimising for some easily legible traits, you might fail to introduce checks and balances to counterweigh their negative consequences and other n-th order effects.
Let’s talk about OKRs
OKRs are an evolution of Management By Objectives and were initially used at Intel during Andy Grove’s tenure and have since skyrocketed in popularity after Google popularised them. They are one of the most commonly used goal-setting and tracking frameworks. On the surface, OKRs seem fairly agnostic: You have an organisational goal, so you write an objective that reflects it. Then you link it to a series of Key Results (you think would mean you were successful in attaining your objective.OKRs allow departments and teams in large organisations to align their local objectives to the executive and strategic goals , they provide a means for teams to feed back into what their Tribe / Cluster / Department’s goals should be, and they’re supposed to be stretch targets — i.e. achieving 60–70% of your goal should be considered a success.
So it looks like a pretty good deal — and very often, it is.
It provides a framework for alignment at scale, they rally people behind a measurable key result rather then the Product Manager or Department Head’s pet project, they give you clarity and focus and they are ambitiously set to force teams to go the extra mile in achieving their goals.
Now, Google themselves have recognised some of the pitfalls of deploying this approach at scale. There are some easy traps Google found are easy fall into and orgs should do their best to avoid them.
For example: 1. Miscommunicating stretch goal OKRs — misunderstanding and misalignment between teams about how ambitious their OKRs are. If dependencies exist between teams, they’ll often be committing internally to a different threshold of success. Say for example Team A expects Team B to deliver Impact X on Metric Y. Only if Team B delivers on Metric Y, would Team A’s KR that looks at moving Metric Z be accomplished. This can lead to frustration and lots of fingers pointed at other teams. 2. Business-as-usual OKRs — Team-centric OKRs (as opposed to customer-centric) are also a fan favourite. They are chosen by the team to guarantee they keep working on their favourite project and they don’t necessarily move the needle on the company’s strategy. A common counter-tactic is to stack rank all OKRs and guarantee people are always allocated to higher impact OKRs. 3. Sandbagging — is, again, to guarantee team’s goals look like stretch targets but aren’t necessarily so. The team knows they’ll get there if they stay course and they might even have time and energy left for that one great project they wanted to do anyway. 4. Low-value objectives — the name says it. They might be hard to get to, they might keep you busy, but they’re not really worth the effort and they won’t produce impact at the company level. Again, stack ranking might help keep people focused and incentivised to do right by their customers. 5. Insufficient key results for objectives — Google’s final piece of advice is to ensure objectives are appropriately funded by their associated key results. It is easy to set stretch objectives but then only commit to hyperrealistic results (i.e. Business As Usual KRs). Achieving your KRs needs to mean your objective has been fulfilled.Apart from team-level pitfalls with OKRs, there are a few organisational ones that are easy to stumble on and are worth noting: 6. OKR blindness — Now uou’ve set your goals, have a measurable way of tracking their achievement and you’re on your way. Depending on how your company is structured, though, this can easily degenerate into a culture of self-interest and lack of peripheral vision. It doesn’t suddenly make good people turn bad. It can, however, provide the wrong incentive, causing people to forget about the complexity of the business, its changing needs, and oversimplify complex market needs to assume that the team’s only job is to deliver on theirs. Say, in this case, Marketing team A needs your team’s assistance to unblock a major promotional campaign that is likely to increase sales by 20%. Team A doesn’t have any engineering resource, and it would take a developer-day away from your sprint. If none of your OKRs matches that need and you’re tight on time, your incentive structure could mean they get rejected, even if you are the right team for what was, in the grand scheme of things, the right job. In medium/large organisations, which are always subjected to a form of unit/functional/matrix slicing, dependencies are very natural (even between technical teams) and solving them requires empathy, cooperation and a world-class prioritisation toolkit. 7. Incrementalism — Another trap to look out for with OKRs is a strong bias towards small iteration and incrementalism. Because the initial target is quite arbitrary, there is a tendency for continued motion, path dependency and continuity. If a team has set a stretch goal and has spent 3 months toiling away to achieve it, it’s very unnatural to then diverge in their next OKR planning session (which often happens a mere 1.5 months after their current cycle has begun) and set a completely new goal because of a new piece of information. The easiest thing to do is to keep trying to solve the problems you’re good at, iterating and incrementing your product, with little regard to how it fits the company’s current state and its market. 8. Local optima — Inflection points are hard to detect, more so with a framework that is poised to be ambitious, sets SMART goals and offers a clear and legible explanation of the company’s strategy. It is extremely difficult to detect that you might be stuck in local optima while in the midst of the struggle, deep in the build trap. The ability to learn at scale is one of the most important characteristics of fast-paced, high-growth organisations. Creating a structure that allows companies to reinvent themselves is hard and how Apple and Amazon chose to do so is extraordinarily different (Depth vs Breadth). It’s important to give teams the skills to learn as fast as they can, and the freedom to expand and move away from their OKRs if they discover they’re solving the wrong problem, otherwise your perfectly crafted Key Results can be the fastest route to a permanent state of Innovator’s Dilemma. 9. Fragmentation - which is extremely hard to counter as companies grow, is the results of the natural tendency for hyper-specialisation and the entropy and friction that arises from multiple teams trying to solve problems that are too specific. OKRs can make this worse if left unchecked. Teams will disregard others’ goals, build their own solutions to already solved problems, all to reach their quarterly targets. It can lead you down a dangerous road of divergence without alignment, creating force vectors that prevent the business moving forward, rather than propelling it with greater strength in the direction of focus. 10. Premature convergence — Because people are often painfully aware of the pitfalls outlined thus far, OKR exercises can be hard, take away large chunks of every middle manager’s time and end up compromising on least common denominator goals due to time pressures, dependency bottlenecks, budget constraints, legacy tech, top-down directives or lack of team buy-in. These and other factors can aggravate the fact that OKRs objectivity and focus can actually be detrimental if you’re solving the wrong problem. We need to stop and consider they might actually be too specific (hint: if they map one-to-one with a task, they are) and it would be empowering to teams in many organisations to receive high-level direction with a framework for accountability, without implicitly prescribing the tactics to success via proxy metrics.
Teams in regular 3-month cycles may soon discover they’re not able to have the impact they were supposed to, but not have the contingency to change plans as that would mean diverting from a largely arbitrary target. They also often fall into the sunk cost fallacy, and remain convinced that they’re solving the right problem because that’s what they committed to 3 months ago.
What these problems say about OKRs (and other incentive frameworks)
Some obvious patterns emerge when looking at what these pitfalls signal about large scale organisations. One is companies are complex, living organisms and applying a blanket system of incentives (whatever it may be) will oversimplify the network of interactions and behaviours across teams building product. Any framework we choose needs to have strong guardrails and counterweights to account for possible traps, as well as have contingency plans built into them that incentivise teams to stay smart, keep optimising, stay focused, share widely and collaborate to discover what the right problem to solve is.
In the case of OKRs, organisations soon discover that:
a) it is unnatural for people to set unachievable goals b) that dependencies are often poorly reflected in them c) that teams can take advantage of the model to signal success d) that a disconnection between biz goals and KRs, as well as between KRs and objectives often emerge e) that highly-specific short-term goals can hinder creative behaviour and long-term thinking f) that solving for incremental optimisation at a local level doesn’t always equate to global growth g) that fragmented, team-level (or functional) goals can dissolve how much value customers end up receiving.
What will your organisation amplify
This post focuses on OKRs because that’s what most companies have chosen to use over the last 10 years after Google popularised them. The principles of framework-organisation-fit, though, apply to every model in every organisation. Organisations should plot their models, their cultural traits and their ambitions, against the benefits and the pitfalls of their goal-setting framework.
They should also be aware of the fact that while they may be looking at both the model and their org in a mostly unidimensional manner (pros and cons, good and bad), the end result is a complex matrix. Think of it like multiplying an Nx1 matrix by a 1xM.
The resulting matrix is a lot more complicated than its originators.
The end result is an NxM matrix, a complex reflection of how each individual trait of your model influenced every single aspect of your company’s genotype. You should be aware that, unlike on paper, what this matrix ends up looking like is very often extremely unpredictable as there are dependent variables all over the place and hidden layers your model of reality won’t be able to reflect. Likely there will be nth-order effects that will need to be managed. This is fine. Test & Learn, iterate quickly, do your OODA loop as fast as you can once you acquire a better understanding of what the end result actually should be.
Remember that the end result may or may not be net positive for your organisation, so hard leadership decisions will have to be made — has this change provoked the positive effects we expected? Have we managed to contain and turn any negatives into strengths? Are you now better prepared to respond to the challenges you started with?
How to predict the future
So far we’ve looked in detail at how you can create positive change by modifying the incentive structure in your organisation. How OKRs can be that driver but need orgs to either already have or be ready to develop a set of cultural traits that make them succeed. How a seemingly linear multiplication can result in a complex behavioural matrix that can be net-positive or negative depending on your goals, your culture and the maturity of your organisation.
A few tips from the battlefield on how to predict the future and make sure that you maximise your chances of success with OKRs or another strategic objective framework.
1. Don’t push large-scale changes from a single functional lens
Get buy-in. At the exec level. Use it to get buy-in across the whole org. This will not work if Product people set OKRs that no-one cares about. It will also not work if Engineering set OKRs to work on large projects with no view of the impact to the customer. It will not work if you “forget” to tie it to your strategic goals.
Everyone involved needs a deep understanding of why you’re changing the game and they need to be completely involved from the start.
Say you choose a similar structure to Spotify’s Rhythm and the DIBBs framework. It won’t accrue to much if Data used isn’t available, reference-able and prioritizable, visibly linked to the company’s needs and directly connected to its most important goals, if the Insights you’re extracting aren’t understandable and can’t be challenged by teams on the ground, if resulting Beliefs aren’t widely shared, culturally and contextually relevant, and if teams don’t clearly understand the Bets they’re going to make and why.
They need to know the problem they’re solving, how they know it’s a real problem and how they will know if they’re making progress towards achieving it.
2. Map your organisation and reintegrate it to deliver on goals
If you’re organisation is structured in tightly knit, sometimes competing units and they are given mismatched objectives, they will more likely than not aggravate the natural friction — there is natural tension between a unit focused on increasing the Average Order Value through cross-sell, and a Conversion Rate Optimisation unit, who are both given aggressive growth targets.
Your organisation needs tools to solve these problems autonomously, instead of falling back on analysis paralysis, constant escalation and turf wars. So whatever incentive framework you lay out, ensure that:
- people that need to work together are highly aligned, that they clearly understand the goals and the focus
- relative priorities are clear (stack rank if you must)
- small enough groups of people are empowered to autonomously deliver relevant outcomes without having to untie a web of dependencies
- operating principles allow teams to invalidate assumptions and quickly change tactics
- that multidisciplinary voices are participating actively in your delivery pipeline
- ownership of the end product is not so diluted that no one person really feels they’ve accomplished something.
3. Build guardrails and safeguards
With any structure, there will be need to be a clear problem description, a clear rationale to support it, and a sound way of monitoring progress: quantitively, qualitatively or, ideally, both.
If you’re deploying OKRs, take another look at the section on pitfalls and what your organisation will amplify. If there are obvious traps, design your initial plan so that they’re covered. Don’t dismiss them, deploying a new structure is hard so, design like you’re right and test like you’re wrong. Over-communicate. Don’t fail because of the known knowns.
4. Treat it as an experiment
John Boyd’s OODA Loops, assimilated into the industry as build-measure-learn cycles, are categorised as asymmetric fast transients, the ability to change states extremely fast based on new information that invalidates previous beliefs. Whatever the model is, be sure to test small, scale it fast and iterate incrementally.
Feedback loops will be more valuable if they’re bottom-up, people need ways to provide structured feedback that allow you to action new experiment iterations at scale. Change never happens overnight, your new framework will need time to succeed, but it is no less important to keep an eye out for the unintended consequences, the impact it is having on your system, and any tribal behaviour or identity politics that have emerged as a consequence of a new found incentive structure.
If culture eats strategy for breakfast, as Peter Drucker famously said, be sure to give yours the breakfast of champions.