The Top 3 Killers of OKRs I See When Coaching Organizations
There are three main mistakes that people make when setting OKRs ranging from simple administrative issues to wider strategic ones.
Gene Gendel is an organizational design specialist, agile coach and trainer, consultant, and adviser to senior leadership at KSTS Consulting . He is also one of the very few (21) Certified LeSS Trainers (CLT) globally. In this Voices of OKR piece Gene talks about the connection between organizational design and OKRs.
“ Not everything that can be counted counts, and not everything that counts can be counted ” – someone wise said that. Even if the quote is often attributed Albert Einstein, there’s no actual proof he ever uttered those words . But I digress…
The quote usually applies to things that people like to measure. But what does this have to do with OKRs? OKR – it’s a way to measure how your initially-set [strategic] objectives translate into results at various organizational levels. OKRs also come with numbers, metrics, calculations, RAGs, etc.
What would OKRs look like for a traditional organization with a complex structure and many reporting layers? Well, this is not the scope of this piece. Frankly, there is plenty written on this topic. Nevertheless, there’s one thing worth mentioning – as “Os” roll down from top (executive level) to bottom (individuals), and as “KRs” roll back up, through multiple organizational layers (managers, teams, departments), accuracy and relevance decrease, whereas variability/variance/inaccuracy and system gaming risks increase.
But what would OKRs look like for an organization trying to get away from a traditional structure and wanting to become more agile (adaptive)?
First, we need to define what it means to be ‘more agile’? What is the most important factor that defines organizational agility? That’s right – it’s organizational design /structure as culture, norms, values, etc. come much later. When an organization becomes more agile, what we typically see is reduction in the volume of processes, artifacts, and single-specialist roles – people that are responsible for single, asynchronous tasks. This is sometimes referred to as organizational ‘de-scaling’ (flattening) .
By the way, and just to correct frequent misunderstanding of the word’s meaning: agile – does not mean ‘faster’, ‘cheaper’ or ‘more efficient’. Of course, these may come as a secondary or even tertiary result of becoming more agile and responsive. For example, a company responds better to market/client needs than its competitors –> this leads to increased sales –> increased profits –> better economics. However, this should not be the main purpose of agile transformation efforts .
Even large investment banks, with their traditional complex structure – multiple reporting levels, many applications (with application owners), many departments (with department managers), many sites (with sites coordinators) – need to de-scale organizational layers and bring real customers (or internal users) and development teams closer together (GEMBA) in order to improve agility in e.g. product development. Why?
Because, in a flatter organization, where customers and executive management set objectives, and development teams are expected to produce initial (low-level) key results, there would be fewer errors and omissions due to a lower number of translation layers.
For example, a good business objective could be to increase annual revenue by 5 million dollars . This could translate into a requirement of having an X-number of new customer-centric features that, if delivered by a certain date, would help generate more revenue. These X-number of features could now be entered into a product backlog (owned by a single product owner and multiple teams), refined and delivered incrementally, over time, sprint by sprint. The lowest level key-result, in this case, could be meeting teams’ definition of done (DoD) and delivering a potentially shippable product increment (PSPI) at the end of every sprint . Please note that ALL product development teams responsible would be sharing the same objective. By the same token, results would be measured for ALL teams – working together. The next level key-result, for instance, could be delivering a big new feature (or a percentage of an initially requested feature), by some arbitrary interim date .
The intention here would be to have as few translation layers as possible, while cascading up results from-low-to-high, to avoid errors and omissions that could be introduced during translation. Of course, this would only be possible if the organizational design inside, around and beyond teams, was simple (de-scaled).
Word of caution:
These days, ‘agile’ is one of the most overloaded and misused terms .
Agile has become one of the most popular areas, where transaction takes place and business is generated (recruiting firms, consultancies, tooling companies). There are many commercially successful, complex frameworks and tooling solutions (with the word “agile” in them) that are marketed, as “unified & comprehensive solutions”. This constitutes, what is sometimes referred to, as a “ Triple Taxation “– and organizations become a victim of it. This is also a part of a bigger, industry wide “agile” framework-tooling problem . Essentially, these approaches redefine the “old world” with new terminology: projects / programs / portfolios become agile projects / programs / portfolios; PMO becomes agile PMO; BAs become agile BAs, and so on…
With electronic tools that are in close partnership with heavy, RUP -like frameworks (e.g. JIRA + SAFe), neither one of which are focused on improving organizational design, OKRs become just another illusionary improvement .
Companies should avoid falling into the trap described above. Try not to align low-level OKRs (e.g. team project) to higher-level OKRs (e.g. portfolio) by merely “mapping” numbers that are generated at single-team level (e.g. velocity or number of items delivered per sprint) through an “agile tool”, and processing them through multiple layers of projects, programs, portfolios, epics, themes, etc. This approach is prone to *unintentional errors and intentional system gaming*, and will ultimately lead undesirable outcomes, because fundamental problems, such as an organizational structure and its internal communication channels, are not being addressed. Such “cascading” of OKRs may look nicely on reports but because it represents a system that is flawed, it would not be valuable.
OKRs could be a great communication tool and means of providing transparency and managing expectations. But OKRs are only as good as the processes and dynamics they represent, with the latter being fully dependent on an organizational (system) design.
In order for OKRs to be reliable and omissions-resistant, they need to be as simple as possible, and have very few translation layers between the highest-level “O” and lowest-level “KR”. This is a matter of organizational design.
Looking to get started with OKRs? Try Gtmhub FREE for 7 days!