When KPIs Start Fighting Your Purpose

In one of my earlier articles, I wrote about why I believe a company needs one common purpose. Different teams can have different goals and responsibilities, but there still has to be something common that tells everyone what the organisation is finally trying to achieve.

On paper, this sounds simple. The problem usually starts when we begin measuring people.

Suppose the purpose of the company is that every customer should have a positive experience while dealing with us. Everyone understands it and probably agrees with it. Then we start creating KPIs because teams need targets and performance has to be measured. Sales gets a revenue target, marketing gets a lead target, customer support is measured on tickets closed, operations is asked to reduce costs and technology may be measured on delivery timelines or releases.

There is nothing wrong with any of these measurements individually. A business cannot run without numbers. The problem starts when the number becomes more important than the reason that number was created in the first place.

I have seen this during my own job as well. There were situations where my goals and KPIs were clearly defined and aligned to what the company expected from my role. But in day-to-day work, things were never as neatly divided as they looked on paper.

Suppose we were managing an application for a client and there was some issue in the product. After investigation, we realised that the actual problem was coming from the infrastructure, which was managed by another team. Technically, it was very easy for us to say that the issue was not ours. Our application was fine and the problem belonged to the infrastructure team.

I had often seen people taking that approach. The discussion would quickly become about protecting your own team. Someone would explain why their part was working correctly and then point out exactly where the other team had failed. From an internal point of view, maybe that protected your KPI or your team's performance. If somebody was reviewing the incident later, you could clearly show that the issue was not caused by your team.

But I never felt comfortable looking at it that way. For me, the client was facing a problem in the application we were responsible for. The client did not really care whether the issue was in our code, the server, the network or some other internal team. From the client's point of view, the application was not working properly.

So my approach was usually that if the issue was anywhere within our organisation's reach and control, then we should own the problem and get it fixed. Of course, we still needed the infrastructure team to resolve their part, but that did not mean we should step away from the issue and say it was someone else's responsibility.

I think this difference in thinking is important when we talk about KPIs. If my KPI only tells me to make sure my application team performs well, then proving that the problem belongs to another team may actually make me look successful. But if the larger purpose is to make sure the client has a good experience and gets a working product, then simply proving that I was not responsible does not solve anything.

I have always felt there is a big difference between saying, “This problem was not created by me,” and saying, “This problem is affecting something I own, so I will make sure it gets solved.” The first protects the individual. The second protects the outcome.

This is where organisations sometimes create problems without realising it. We divide work into functions because that is necessary. We give each function goals and KPIs because people need accountability. But after some time, everyone can become so focused on proving that their own part is performing well that the larger outcome starts getting lost.

The same thing can happen in sales. A salesperson may have a revenue target and come across a customer who can help him achieve it, but the customer is asking for something the company may struggle to deliver properly. If the salesperson is measured only on revenue, the temptation is obvious. He closes the deal, achieves the target and gets appreciated. A few weeks later, delivery is struggling, the customer is unhappy and two departments are arguing about whose fault it is.

From the salesperson's dashboard, the month was successful. From the customer's point of view, it was not.

Customer support can face the same problem. If the team is measured mainly on how many tickets it closes, people will naturally become faster at closing tickets. But a closed ticket is not always a solved problem. The dashboard may show excellent productivity while the same customer keeps coming back because nobody has really fixed what he was facing.

Marketing can generate more leads and still make life harder for sales if those leads are poor quality. Operations can reduce costs and still damage an experience that customers value. In each case, the department can achieve its KPI while the company moves further away from the outcome it says it cares about.

This is why I think the difference between purpose, goals and measurement matters. Purpose tells us why the organisation exists and what all of us are trying to achieve together. Goals tell each team what it needs to accomplish. KPIs help us understand whether those goals are being achieved. The problem starts when the KPI becomes the destination instead of remaining a measurement.

I am not suggesting that sales should stop having revenue targets or that support should stop measuring productivity. Numbers are necessary. Without them, managing a growing organisation becomes difficult. But when we create a KPI, we also need to think about the behaviour it will create if somebody starts taking that number very seriously.

If a salesperson maximises revenue at any cost, would we still be happy with the result? If support closes every ticket in five minutes, could customers still be unhappy? If marketing doubles the number of leads, could the sales team actually become less productive? If operations cuts every possible cost, could the service become worse? If the answer is yes, then that KPI alone is incomplete.

I have also seen that leaders themselves sometimes create this conflict without realising it. We may speak about customer experience in meetings, but if every review focuses only on revenue, people understand what really matters. We may say quality is important, but if our first reaction to every delay is only to ask why the deadline was missed, people understand that speed matters more. We may say we want ownership, but if managers are rewarded mainly for protecting their own numbers, people will protect their own areas first.

Employees learn from these signals much faster than they learn from presentations.

This also connects with what I wrote earlier about culture. Culture is shaped by what gets repeated, rewarded and tolerated. KPIs play a big role in that because they quietly tell people what the organisation pays attention to.

A poorly designed KPI can therefore create the opposite behaviour from what the founder intended. You may want collaboration, but if every department is rewarded only for its own result, people start protecting their own numbers. Sales wants to close the deal. Delivery wants to protect timelines. Infrastructure wants to prove the outage was not caused by them. The application team wants to prove its code was working. Support wants to reduce ticket time. Finance wants to protect margins.

Everyone may be technically correct within their own department while the customer is still sitting with an unresolved problem.

That is exactly what I used to see in those application issues during my job. Different teams could spend a lot of energy establishing whose fault the problem was. But from the client's point of view, none of that mattered. The application was still not working.

I always preferred to first own the problem, get the right teams together and make sure it was fixed. After the customer impact was handled, we could always discuss internally why it happened and who needed to change what. For me, ownership was not about accepting blame for everything. It was about not allowing internal boundaries to become an excuse for leaving the final problem unresolved.

I think this distinction is important for leaders as well. You don't want people to hide mistakes or take responsibility for things they genuinely did not do. Accountability still matters. But there is a difference between finding the root cause and spending all your energy proving that your department was not responsible. The first helps the organisation improve. The second often helps people protect themselves.

This is why founders and leaders need to keep checking whether their measurements are still connected to the company's purpose. Sometimes the KPI needs to change. Sometimes another measure is required to balance it. Sometimes the KPI itself is fine, but the manager needs to look at how the number was achieved rather than only whether it was achieved.

A salesperson who reaches 120 percent of his target by creating unhappy customers may not be a better performer than someone who reaches 95 percent while building strong customer relationships. A manager whose dashboard looks perfect because every problem was shown to belong to another department may not be doing a better job than the manager who took ownership and got the customer's problem solved.

After working in organisations and later running my own teams, I have started feeling that the question cannot only be, “Did this person achieve the number?” We also need to ask how the number was achieved and whether that behaviour moved the organisation closer to what it is trying to build.

When both things are looked at together, KPIs become useful. But when we forget the larger purpose, it is very easy to reach a strange situation where sales is achieving its target, marketing is celebrating its leads, support is closing record numbers of tickets, operations is reducing costs and every technology team can prove that a problem was caused somewhere else, while the customer is still having a terrible experience.

When that starts happening, the first question should probably not be what is wrong with the people. Very often, people are simply doing what the organisation has asked them to do. The better question is whether the way we have defined success is actually helping everyone work towards the same outcome.