Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Organizational Dysmorphia - The Cure (Part II)

The first article in this series described Organizational Dysmorphia. This article will go through some concrete steps that can be taken to cure the malady. 

So what should you do if you see symptomatic examples like the ones given earlier? Like giving up any other bad habit, the goal is easier to state than to realize: just quit. Stop quartering your organization in ways that actively hinder the creation of valuable software.

This immediately begets the question: “how?” The steps to fixing the problem - once the symptoms have been identified and denial has been forwent - are context-dependent. There is no prescriptive recipe. However, there is a theme to the steps:

1. Minimize distance

The Lean Software Movement can rightfully be credited with popularizing slow communication as a reason that causes waste during software creation. Both the frequency and richness of communication are inversely proportional to the distance between the two parties that are communicating. Therefore, to reduce waste, reduce the distance between those people whose communication is vital to the creation of the desired software.

“Distance” in this sense can be physical or organizational.  The deleterious effects of large physical distance on communication are apparent to anyone who has tried to conduct a meeting using even modern online collaboration tools. [1]

Organizational distance can be just as harmful. Introduce sufficient layers of intermediate management, laced with poorly thought-out incentives, and you can turn a co-located team of collaborating professionals into a pack of snarling back-stabbers. There is no reason for collaboration in a culture where credit for new ideas is stolen, feedback is substituted with gossip, and one-upmanship trumps team goals.

2. Incentivize teams, not individuals

Developing large-scale software is invariably a cooperative activity. When it comes to delivering working software, set goals that the entire team can rally behind. Giving incentives to individuals can create a culture of distrust and foster local optimization.

An “incentive” need not be a salary-raise or a bonus; or even those given “in kind”, such as a gift card for a free dinner. Even completely non-monetary incentives -- a thank you note or letter of appreciation -- that fails to take into account the intricately collaborative nature of software delivery can do more harm than good. This doesn’t mean that you cannot acknowledge individual effort, when necessary. However, always favor teams over individuals. An example that’s stayed with me is of a manager who acknowledged one of his team-members, who’d worked hard over the weekend, this way: “thank you for your work. I appreciate it. Just make sure you don’t ever do that again!” (Of course, he delivered this with the required amount of humor to not appear ungrateful.)

3. Incentivize results, not effort

This theme follows on from the previous one. There will be no progress even if all team members are pulling as hard as they could … if they’re pulling in different directions. In my consulting engagements, few things sadden me more than seeing organizations actively incentivizing effort over progress. Metrics like bugs discovered, bugs fixed, and even velocity (points delivered per iteration) are regularly praised by uninformed teams and managers.

It appears that humans are hard-wired to “game” whatever metrics they are measured against to gain competitive advantage. Rather grim experiments in the realm of psychology reveal that when commanded or reassured by an authority, humans will take steps to please that authority -- in essence, gaining favor with the authority figure -- even when they know they are physically harming other humans.[2] Dr. Eli Goldratt famously framed this as a principle that’s eponymously called the Goldratt Principle:

“Tell me how you will measure me and I will tell you how I will behave.”

When you incentivize people to reach locally optimized solutions, they will actively behave to reach those solutions, even when they know this will harm the overall goals of the team or organization.

If you’re looking for a metric to incentivize, consider Running Tested Features, suggested by Ron Jeffries.[3] It is designed to optimize successful results, not effort.

Organizational dysmorphia -- like body dysmorphia -- is often a self-inflicted ailment. It can be cured. The first step is admitting that your organization has this malady.

[1] This funny video by Leadercast illustrates the challenges of online meetings to those who have been lucky enough to not experience them firsthand: https://youtu.be/DYu_bGbZiiQ

[2] The Milgram Experiment

[3] A metric leading to agility

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights