Misaligned Incentives Fuel Organizational Dysfunctions
Sometimes we need to stop fighting the symptoms and recognise that there is a more fundamental problem. Commonly, the fundamental problems is a mismatches in incentives between the different individuals and groups involved in achieving an outcome.
The more I observe organizations, the more I see this pattern of people fighting the symptoms and getting frustrated that things aren’t improving or changing. And the more I see that things are always going to be a struggle because incentives are widely misaligned.
When there is an incentives mismatch, a lot of energy can be expended. Lots of back and forth, lots of blaming, lots of us and them, lots of escalations to management, and lots of politics. The work gets done eventually, but it can be a real endeavour that burns people out and has long-term implications.
I’m surprised that we don’t talk about incentives more often. From day-to-day conversations to tech conferences, it’s not a topic that gets much air time.
Anyway, here are some of the problems I see when incentives aren’t aligned …
Misaligned Incentives Inhibit Productivity
To successfully execute on its business model, an organization needs to deliver value propositions to customers by developing business capabilities which enable their products and services.
For technology-powered companies, many of their business capabilities and products are custom-built using software. And for many internet-era companies, developing quality products at speed is necessary to gain market share and avoid being disrupted.
For stream-aligned teams to build quality products and business capabilities at pace, high levels of cooperation within the organization are required. Teams need the ability to develop, test, deploy, and operate software but they can only do this within the constraints imposed by operations, security, and some other teams. This is where misaligned incentives can decimate productivity.
Over the past ten years, conflict between development and operations teams has been a recurring theme. Developers want to move quickly, whereas operations prefer to go slowly and carefully because they are blamed, and they get woken at 2am in the morning, if there are production issues.
Likewise, security teams are often vilified by developers because they put in place the most restrictive policies that prevent developers from doing basic things like installing IDE plugins or downloading packages.
When operations teams are only measured by how well production environments are running, and security teams are only measured by how secure things are, these problems are always going to exist. People are behaving as the system encourages them to.
The solution is to tweak the incentives. Any team that imposes constraints on another team should be incentivised and rewarded for achieving their purpose while minimising the negative impact. This is what DevOps means to me: aligning the incentives of development and operations so that teams can develop at pace yet still in a reliable and secure way.
I’ve seen DevOps working best when it is implemented using Platform-as-a-Product guided by Developer Experience metrics like:
- How quickly can teams spin up a new service and have it deployed to production?
- How many times per-day is each team deploying to production?
- How often are developers blocked awaiting support from Ops, security, etc?
Development, operations, security, and any other teams involved should all be incentivised to continuously improve these metrics. Equally, they should all celebrate their collective achievement when development teams deliver successful outcomes.
Misaligned Incentives Cause Delivery Bottlenecks
Hidden in all of the talk about self-organizing and empowered teams is the fact that dependencies between teams still exist. An empowered team cannot deliver quality products at speed if they are blocked waiting for work to be completed by other teams.
I recently worked with a frontend team who were frustrated at always being blocked by the backend team. And when I spoke to the backend team, they said they had so much work they just didn’t have the time to do work for the frontend team any faster.
This pattern is one I see a lot. A team has their own top priorities, and somewhere in their backlog is a piece of work which is blocking the top priority of another team. This is especially problematic when the priority of the other team is a higher priority for the business.
You can’t blame a team for working on what they have been told is their top priority, and ultimately what they will be judged on at the end of the quarter. Both teams need to be incentivised to achieve the higher-level business priorities and rewarded accordingly.
I strongly believe that making other teams successful should be celebrated just as much as a team delivering on their own objectives.
Misaligned Incentives Encourage Individualism
I recently spoke to a friend who was complaining that their team didn’t feel like a team. Everybody wanted to work in isolation, and nobody cared about improving the quality, so the code was becoming more unmaintainable over time.
I asked why nobody cared about improving the quality and working more effectively as a team. And I asked if there was a risk that everybody working alone might mean that the team’s highest priority work get’s slowed down by lower priority (due to higher WIP).
The answer was that everybody has personal objectives and there are no team goals. Every person in the team had their own personal list of objectives to complete and was rewarded for individual performance.
This wasn’t a team, this was a group of people working in the same codebase. The incentive from management was that everybody achieves their individual targets. Everybody was acting exactly as per the system’s design .
Time and time again I see this same pattern played out: management eulogise the need to collaborate more, and yet those same managers are setting individual goals and rewarding individual performance.
Misaligned Incentives Prevent Continuous Improvement & Innovation
I’ve seen a lot of management slide decks and presentations over the years urgently describing a need to be more agile, to be customer obsessed, to deliver value faster, and to be able to compete with disruptive startups who innovate at a much faster pace.
Turning the ship around in established organizations is a challenging endeavour. Moving from monthly deploys to daily deploys, and project-thinking to product-thinking requires a complete mindset change across the entire organization at all levels. It’s not transactional, it’s not a big bang, and it’s not a project. It can only be achieved through continuous improvement.
The problem is that management are still pressuring teams to deliver and not incentivising continuous improvement. They still reward teams & people based on how much work they get done or number of hours worked.
In the best organizations I’ve worked with, continuous improvement is celebrated almost as much as doing the actual work. If a team takes time away from delivery work to improve their process they are celebrated. Even if they try an experiment with new technologies or ways of working and it doesn’t work, they are still rewarded because failing is necessary to learn and to continuously improve.
The best CTOs I know go out of their way to give teams regular opportunities to improve, and give plenty of air time in company newsletters and get togethers to the people who improve the system of work. It’s no coincidence that those are the companies delivering quality products at pace.
Misaligned Incentives Lead to Politics
Organizations are a huge contradiction. On one hand people and teams need to collaborate to deliver capabilities and products. Yet on the the other hand the organization chart is a competition. It’s very easy for individual competition to overpower the need for collaboration and become highly political, especially higher up the org chart.
I’ve seen this problem a lot when organizations try to bolt on digital transformation with a digital team. Usually, the digital team builds new shiny mobile apps and websites, which integrate with the legacy technology systems owned by a different team with a different CTO.
There are now 2 CTOs (Digital CTO and Enterprise IT CTO) who are in competition to become the overall company CTO. They both need to gain more power and authority and show they are superior. This can have devastating impact on how software and product gets delivered in the company.
Digital IT still depends on Enterprise IT. Customer-facing work requires changes to existing APIs, databases, and internal systems. A high level of cooperation is required between digital and Enterprise IT teams. Often, it is better to have teams that own full slices to avoid handover and bottlenecks. But that’s not allowed, because it crosses an org chart boundary and one of the CTOs will lose some of their status.
I have seen engineering leaders purposely making harmful choices to the company in order to lock in their personal status. While this varies highly based on the individual, there is still a high influence from the design of the system. I recommend avoiding digital bolt ons and looking holistically at product development.
Misaligned Incentives Result in Unnecessary Technical Complexity
When teams don’t get the help they need from other teams because their incentives lie elsewhere, there is a tendency to over-complicate technical solutions to compensate.
I’ve written about this before so I won’t repeat myself here.
Is it an Incentives Problem?
Next time you see a problem in your organization, or you’re annoyed by individuals or teams who aren’t behaving as you’d like, take some time to look at their incentives. Are they behaving exactly as the system encourages, and as you would in their situation?
