One of the hallmark traits of corporate IT is the abundance of perverse incentives. I define perverse incentives as follows:
Any policy, practice, cultural value, or behavior that creates perceived or real obstacles to acting in the best interest of the organization.
Let me give you an example. I once ran a project that needed to purchase some software. In the past, the vendor of that software had required us to license our production and non-production environments the same way and I had created the project budget assuming that licensing pattern would still apply. Based on that assumption, I had published a project budget to stakeholders and in our financial systems. When the quote from this vendor arrived, one of the team members, unaware of the historical pricing model, was incensed at the idea of paying full price licensing for the software in our test environments, and he let the vendor know it. The result? The vendor backed off, dramatically reducing the price of the non-prod licenses to the degree that we had an order-of-magnitude reduction in licensing costs.
For a very brief moment, this reduction in price made me unhappy. Unhappy that I had saved my organization a large sum of money? Yes. Why? Because, in that particular organization, there were many people who saw coming under budget as a bad thing. Why didn’t you do your due diligence on the price of the software before you published your budget? Why did you pad your budget with so much contingency? You’re just gaming the financial system to make your project numbers look good. These were the accusations I anticipated, and as a result my immediate reaction to the news of our substantial savings was simple and negative: aw crap.
Ironically, it wasn’t my immediate management chain that created this perverse incentive. They liked it whenever we found opportunities to save money. It was my peers and our support organizations that were judgmental of projects that came in under budget. But this cultural perverse incentive was powerful enough that for a few seconds I was not as excited as I ought to have been about doing what was best for my organization.
Perverse incentives flourish in corporate IT. Processes, methodologies, best practices, habits, etc are powerful incentives to disengage our brains and just follow the checklist. This frequently means that we are spending time and money on activities that, because we have disengaged our brains, don’t benefit the organization even though the organization has endorsed the creation of everything on the checklist. Not doing those things requires courage and diplomacy, because there are typically organizations created to ensure that you turn off your brain, don’t use your judgment, and just follow the checklist. These types of incentives are what I call process perverse incentives. You normally can’t do anything about the existence of these perverse incentives without help from a very powerful leader, but you can minimize their influence on you by simply choosing to ignore them. This will cost you a pound of flesh, but in most organizations, over time, you will earn the respect of the system.
Another type of perverse incentive is directly influenced by you, because they are based on the way you respond to difficulty on your project team. I call them behavioral perverse incentives. Let me give you a fictitious example.
A manager of a large project has several sub-teams that report status to him in a weekly meeting. The architecture sub-team is clearly not making progress, and they are really poor at communicating the reasons for their failure to advance. As a result, the project manager focuses more on them, grilling them about the specific details of their effort. Under pressure, the architecture lead’s story becomes inconsistent – one minute she characterizes their problems as catastrophic, the next she acts like they face only insignificant problems. In the end, the project manager tells them to get their act together and concludes that the lead doesn’t really understand what is going on in her effort.
Was it wrong for the PM to grill this team? I don’t think so. But – and this is important – whether it was wrong or not doesn’t really matter. It can still create a perverse incentive for the architecture team to lie about their progress, to exaggerate the importance of trivial progress and to minimize important issues.
Did the team need the grilling and public criticism? Sure. Will this motivate the lead to come to the next meeting with a consistent, defensible story about the effort she is responsible for? Absolutely. Will it motivate her to honestly and openly discuss the fundamental reasons why they are struggling, or to admit that they are struggling at all? No. There is now a powerful perverse incentive to hide problems from her project manager. Hopefully, her sense of ethics and professional responsibility will overpower this perverse incentive, but there is no guarantee that this will happen.
Project managers must be conscious of the perverse incentives they create when they interact with their team. They must find ways to create equally powerful positive incentives for the behavior they want their teams to exhibit that counteract the perverse incentives to behave in a way that is not in the project’s best interest.
I have come up with two specific ways to create positive incentives to tell the truth.
1) Thank team members for informing you of problems. When a team member comes to you with a problem, even if they caused the problem by making a mistake, you need to thank them for telling you. Don’t thank them for screwing up, but be certain you say something expressing your gratitude that you know about the problem. It’s really easy to say something like the following, and it reinforces the positive benefits of telling the truth.
Man, I’m really glad you told me about this. Thanks a lot for letting me know. I’d like to know how this problem progresses, can you keep me in the loop?
You might choose to save any criticism mistakes made until the retrospective, unless you have detected a pattern of bad behavior. I’ve often found that team members will admit their own mistakes in a well-run retrospective, which completely negates the need for me to rag on them at all.
2) Be an asset. If your team views you as a solution provider, rather than a project tracker, they will be considerably more inclined to be open with you. Navigate tricky social/cultural/political problems for them. Get them the resources they need. Remove roadblocks. Own issues yourself. Fundamentally, this is the best way to earn the respect of your team and create an incentive for turning to you in times of trouble. They will turn to you because you can help. If you can’t help, or if you hinder, they will go around you.
This topic has been on my mind a lot lately. I’d like to hear your thoughts, approaches you’ve come up with for dealing with perverse incentives, and, of course, examples of REALLY perverse incentives in corporate IT.