The Causation Fallacy – or how not to design salary systems

Re-visiting so many of Jerry Weinberg’s books in the past couple of weeks has made me realize some lessons I merely had on the back burner in my mind, waiting to be activated. One of these learnings is the Causation Fallacy, best illustrated by this funny video:

The Causation Fallacy
Every effect has a cause… and we can tell which is which.

Quality Software Management Volume 1 – Systems Thinking, page 90

Stick long enough in the business of organizational change, and you will come across at least one instance of this fallacy happening. Laying out the vision for the change, coming up with a change strategy, and listening to people, you start to hear different stories of cause and effect. Sometimes it might happen that you see a pattern of opinions where the effects stem from – and they might be totally wrong, since so many of the voices your hearing fell for the Causation Fallacy, and jumped too early on some conclusion that looks helpful but causes a strain of other, mostly unwanted effects down the line.

Maybe an example would be helpful. So let me pick one from the past of it-agile, the company I still work with. Back in 2011, our CEOs had the problem that we had outgrown the usefulness of annual performance talks with our superiors. We were roughly 30 back then, had literally no hierarchy beyond the CEO level, and scheduling 30 annual personal development talks was impractical, to say the least. We had quarterly tuning days back then, where we talked through some issues in our current organization and came up with experiments for the time after the tuning days. On one of those tuning days, the annual performance talks issue came up. (It wasn’t the only thing we dealt with back then, but one major experiment relevant to the Causation fallacy came up related to this.)

We sat down, talked, designed, experimented, and came up with the concept of a peer group. Basically, every employer could pick three to four other colleagues to help them advance in their personal careers. The idea was to go through a couple of categories and see that this person grew over time. Peer groups were allowed to change over time, so if you find yourself at one client today with some colleagues, you probably pick them as part of your peer group, and if you find yourself with totally different colleagues at another client in 6 months, you probably want to switch some members in your peer group to reflect that situation while getting you more first-hand feedback opportunity from someone who has seen you do the work, rather than speculating about it. Not everyone was forced to pick a group of peers, so it was voluntary. The tuning days concluded with this experiment, and the plan was to encourage everyone to pick a peer group in the next six to twelve months.

Later on, this experiment was extended. Since the annual performance talks also included decisions about salary, the CEOs were still lost on how to put those decisions on more shoulders. Deciding upon salary increases then also became part of the peer group’s job. Our salaries were mostly adjusted every six months, based upon decisions from the peer groups if you had picked one. One year into this we came to the realization, that most of the peer groups only met right before a salary decision was due with no personal development talk in between. Clearly, we had missed the purpose of why we invented peer groups to start with.

A later improvement separated salary decisions and personal development from each other to fix the system. In hindsight, everything might be explainable by the experiences you make. You can’t always tell apart cause and effect. And as our little story shows us, some good intentions can actually cause more problems than is helpful or intended.

I think there is a corollary here to discover as well. Human tendency probably is to then think this through harder, deeper, and so on. I think the contrary is more helpful. Start with a small experiment, observe the effects, and over time fix the system, but be prepared that your first experiment will be far from perfect, and you might cause many more problems if kept unaware. We eventually did this with our salary process but didn’t pay too much attention to the dynamics as they unfold at the time. The imperfection shouldn’t keep you from trying, though. Just be prepared and pay attention as the underlying dynamics unfold in real-time.

And, yeah, sometimes this leads to situations where some people say in hindsight, they could have warned about the effects beforehand. But unless they fall on prosperous grounds, they will not stick with the whole group as change happens one person at a time. But maybe there is a lesson in here for some later blog entry.

  • Print
  • Twitter
  • LinkedIn
  • Google Bookmarks

Leave a Reply

Your email address will not be published. Required fields are marked *