How often have you seen business KPIs your org/team does not directly influence pushed your way? Did you try to push back? Did you try to reduce the scope of the KPIs to what is only doable by your team alone? If you did, read this article to find out why you should not have.

To be more specific, let me describe a generalized scenario I witnessed many years ago.

The Project

Once upon a time, there was a product that included many moving parts and teams: UI/backend with several teams/DB/DevOps, and even QA. The product was successful for years, but lately, several releases were, put it lightly, less stable than desirable. Subsequently, customers lost some trust in it. Our story begins when the org decided to turn that around and set a new yearly KPI to improve the trust score. Trust score is measured by surveying customers. KPI is straightforward: move the score from X to Y. While this is the right business KPI, many teams pushed back on having it in precisely this form on their charter. UI team lead argued since the UI team is only responsible for the UI, they would want to have something like: "reduce the number of negative comments related to UI specifically."

In the end, all teams have their reduced-in-scope KPIs created. And everything seemed fine at the beginning. Almost a quarter later, something odd happened. While nearly all teams reported fantastic progress, the results of the answers to the binary question about the stability of the product (do you think it is stable?) were mostly the same. So while each team delivered everything they committed, their leads had a difficult task to deliver news to their teams/orgs that, even though they had achieved the goals, results still needed to be better (by a lot).

So, what exactly has happened? Business KPI was formulated on the highest level and passed down to different orgs. Each team created corresponding KPIs limited in scope to only what they could achieve. As a result, no one in the company (among engineers who knew how everything worked) was assigned to this high-level KPI. In such cases, if the company is lucky, when everyone finishes doing their part, hopefully, everything will be resolved, but more often than not, people will see sub-optimal results in the end.

Such a situation also means that you do not have an org structure that follows UODP principles, but this is a topic for a different article. After all, only some have the luxury to start yet another huge re-org, and one must provide a more straightforward solution. Also, in many cases, big reorgs do not work anyway (a lovely song that tells the story of why)

So, What To Do?

A straightforward answer is that each team helping with the business KPI should have a high-level KPI on their charter. And on top, to have sub-KPIs reflect more specifically what the team can deliver.

There is always a question that comes immediately: wait, why? Why should I (the potential owner of the KPI) own something that our team can not impact alone should be assigned to me? This is unfair!

Yes, this is unfair. However, it reflects the harsh truth of how the team will be perceived. Many of us find comfort in hiding how our work results will be perceived beyond the curtains of measuring only what we can impact.

So back to our example. We started with UI and one of the backend teams. Both teams allocated the owner from their side for the high-level business KPI: "improve trust for our product from X to Y" KPI.

Magical things started to happen immediately. Now, by having business KPI directly on the team's charter owner has begun to ask the right questions. UI folks start asking: can our team do more and help the backend team, which is accountable for many more complaints than the UI team? And overall, everyone was asking: who is driving the initiative overall? Do we have a sync between all stakeholders around this? Where/how do we report progress? The moment a person realizes that they are on the hook (partly) to deliver business goals, all these uncomfortable questions (for most of the managers) start to pop up.

The fascinating part is, from time to time, if you practice this, you will find that there are no answers to all these questions. No one was appointed as a high-level business KPI goal owner at all, and no one bothered to put in the room all the stakeholders. And in such case, your team has an opportunity to spearhead the effort org/company-wide.

But back to the example. Immediately the change led to the creation of the v-team that horizontally cut across many different departments. After just the first two meetings, v-team realized that the UI team, for example, has way more to offer than they thought at the beginning of the year. They found that the ideal solution might be a UI service that allows customers to self-diagnose and self-debug backend problems. This would enable customers to self-resolve 70% of the cases themself. Before this, the backend team, working in silos (same as the UI team), never even learned what it is possible to do in a quarter on the UI side of the options. While the UI team, who usually would be the first line to triage customers' issues, did have some ideas on how they could potentially build service to help the backend team, it was never a priority for them to do.

The End

So, start your UODP journey by putting business-level KPIs on your charter. If your organization already has a v-team and high-level owner, this will allow you to find it much sooner and become a part of the v-team. If not, this will enable you to immediately start a new v-team. Also, you will always know how your team is perceived, and there will be no surprises when the performance review time comes.

And the last thing, there is one excellent rule of thumb on how to test whether your KPI is a good one. Ask yourself: can you come up with a situation when all of your KPIs are green, but the company business goal is still red? If the answer is yes, you might be trying to hide what is essential behind what is easily (directly) changeable by you. And remember, there are no things that you can not be changed by you, there are things that you can easily change (things that you directly own) and things that are harder to change (owned by someone else), but there are never things that you can not change.