I was minding my own business when I spotted a rant by a friend about “Leadership versus Management”. Here’s the short version:

I’m tired of people propagating a false dichotomy between leadership and management! Sometimes we need one and sometimes the other. At a minimum, we ought to manage systems and lead people! Even so, sometimes we need to manage people while we are also trying to lead them. Enough is enough!

I imagine there was some eye-rolling over coffee.

First, I noticed the Blaming Stance. It’s strong in this rant, as seems common for rants in general. We rant precisely when we want to blame someone for behavior or ideas that we don’t like. We rant because we care and we feel frustrated that others don’t see things as clearly as we do. We rant for a variety of reasons, but at the heart of any good rant sits a large dose of blaming. This article isn’t about that, but awareness of our tendency to blame plays a role in what this article is about: these false dichotomies, how they happen, and what to do about them.

A Quick Definition

When I say “false dichotomy”, I mean presenting two options as though one were forced to choose exactly one of them, even though one could freely choose neither, one, or both.

I don’t mean to turn this article into a seminar on logical fallacies. I suspect that would bore many of you. It would bore me. I mention this only to set the scene and increase the chances that we understand each other.

A Quick Win

If you read something that presents a dichotomy between two options, ask yourself a simple question: “Could I imagine a situation in which I would need both?” Maybe then make yourself coffee or take a shower to give the question time to soak. Do some “Soap Opera testing” where you imagine fanciful and strange situations that strain credulity but nonetheless could happen. Much more often that you might expect, you’ll find situations in which you want the first option, the second option, and even both options. Extra credit if you imagine situations in which you want neither option.

Congratulations! You have inoculated yourself against the false dichotomy. Enjoy your Giraffe Ears. They look nice.

A Quicker Win

The cool, hip meme version of this trick seems to be this:

See? I can be cool.

False Dichotomies Abound

I’m too lazy to search the web for common false dichotomies, but I imagine I could find 100 popular ones. In the general business world we have the one between “Leadership” (influencing people’s behavior while they decide for themselves) and “Management” (deciding for others and directing them to do those things). In the software development world we have the one between “TDD is a testing tool” and “TDD is a design tool”. I bet you have a personal favorite—perhaps the one you encountered most recently—to add to this discussion. You probably want these false dichotomies to go away, but they almost certainly won’t. That leads me to ask two key questions:

• Why?
• What now?

Why

I have noticed a pattern among these false dichotomies:

1. Someone learns something that causes them to rethink what they already knew on the subject.
2. Suddenly they notice weaknesses, limitations, or other reasons to pull away from the old way.
3. They need to tell everybody about their new-found success or their budding excitement.
4. Their excitement causes them to present an extreme version of their thinking, because marketing is hard and people seem to pay more attention to ideas expressed in an extreme way.

And thus is born “OMG! You guys! Stop managing people… and start leading them!!!11!11!”

I imagine there are many more patterns, but I’ve noticed this a lot, and it’s the pattern that I wanted to write about specifically here today.

Not Only False Dichotomy, But Also Blame

Let us apply the wisdom we learned from Jerry Weinberg, who asked us to think about alternative interpretations to the first thing that pops into our heads. Many of you have similar reactions to my friend who rolled their eyes over coffee and ranted. Others of you react by falling right into the pit of the false dichotomy and immediately set about giving up the old way and diving into the new way. Others of you react by screaming at the “obvious” cynical marketing ploy of creating a false moral hazard. Those are three ways to interpret the message “Stop managing people and start leading them!” or “TDD isn’t about testing (you idiot), it’s about design!” Jerry asked us to consider at least three interpretations before reacting. It’s not easy, but it helps.

And I’m not trying to create a false trichotomy here. There are other ways to interpret this message. Imagining three of them is merely a trick to encourage the mind to keep searching: once you think of three, you are more likely to think of twenty.

Many of these common interpretations blame either the presenter or the reader/listener. (Woohoo! Another false dichotomy! Self-similarity achieved.) You could pause now and go read any number of online debates about whether the presenter bears the responsibility for crafting a “better” message or the reader bears the responsibility for understanding and interpreting it “better”. You’ll see phrases such as “snake oil salespeople” and “turn your brain on”. What… just me?

I would like us to consider interpretations that do not blame. One magic question: “What would have to be true for me to behave like that?”

Not Only Blame, But Also Understanding

Well… marketing is hard. Branding is hard. Advertising is hard. I have to feed my family. I need eyeballs. I need to be seen as expert, or at least credible. Outrage sells. Surprising messages sell. All this leads me to present my ideas in an extreme way, otherwise nobody will care.

Alternatively, I was raised in an environment where I had to be loud in order to be seen. I learned to stand out, to be different, to be extreme, to sensationalize, because otherwise I wouldn’t get the attention I needed as a child to feel safe and seen and loved. In some cases, I wouldn’t even get the food I needed to survive. Fortunately, that didn’t happen to me, but it could have. (And other things did.)

I don’t have the patience to think of a third scenario, so I’ll trust myself to continue, because imagining these two scenarios did the job: I have empathized and even felt compassion for the alternative-universe-me who rants when they learn something new that causes them to rethink their old ways.

I find it difficult to feel blame when I’m too busy feeling empathy and compassion. And believe me, I try. The Blaming Stance is strong in this one.

What Now?

Now perhaps you could find it easier to put on your Giraffe Ears.

• You think the blaming thoughts and let them fall away.
• You feel empathy and even compassion.
• You interpret the false dichotomy as an unfortunate-but-understandable failure.
• You don’t need to rant, even though you’d still like to gently-but-firmly correct.

And that’s what I’m trying to do now: correcting the record firmly, but gently. Feeling compassion for someone does not mean giving them a Get Out of Jail Free card for their actions.

Not Only Management, But Also Leadership

Sometimes we need to manage people, even if we generally prefer to lead them and not rob them of their autonomy. Since we tend to cling to control, we also tend to cling to managing people, because that gives us the illusion of control. Sometimes that leads to a responsibility imbalance that resolves itself violently and at the worst possible time. Sometimes that leads to figurative oppression. Sometimes it even leads to literal oppression. These dangerous outcomes remind us to look for other ways to influence people’s behavior.

Hey! Have you tried learning more about leadership? Leadership means ethically influencing people so that they make choices that align more with the outcomes we’re hoping for. It means giving up control, but the resulting behavior lasts longer and some of your followers become effective leaders, which strengthens your efforts. It’s more complex and more difficult, but also more effective and rewarding.

• Lead when you can, manage when you must.
• Manage systems, but lead people.

It’s certainly not that simple, but I consider that a sensible place to start.

Not Only Testing, But Also Design

Programmers gravitate towards test-driven development (TDD) typically because they hear that it helps them reduce bugs and they’re drowning in bugs. New TDD practitioners therefore tend to use TDD primarily as a testing technique and derive two major benefits: fewer defects and less overall code. You might notice the virtuous feedback loop: less overall code tends to mean fewer places for defects to hide. After a period of weeks or months, when the programmer notices a severe drop in the arrival of new defects, they become bored with TDD as a testing technique and their eyes tend to open to new benefits of TDD: making code safer to change and tests as a source of information about risks in the design. Right about now is the point when they start writing their own article entitled “TDD Is About Design, Not Testing!”

Once the programmer begins to use TDD as a way to focus on refactoring and finding design risks, the testing-related benefits don’t disappear, but they weaken a little. A few defects creep back in as reminders that, in fact, TDD does (and should!) involve using tests to clarify specifications (avoid defects) and detect regressions (detect defects). The programmer then learns to balance the “design feedback” aspect of TDD practice with the “behavior feedback” aspect. They often end up creating a self-regulating system that helps them develop an intuition for when to write fewer tests (in order to focus on design) and when to write more tests (in order to protect against defects).

Before they do that, however, they feel excited that they see TDD in a new way, which explains the excitedly-written articles.

So TDD “is about” both testing and design. And other things. I call this Four Stages of TDD and there might be more stages, because I’m only in stage 4, so I can’t see stage 5 yet. Who knows? My model merely helps me make sense of the learning stages that many programmers go through when they practise TDD.

1. Writing tests first to reduce the cost of making behavior mistakes, meaning code that doesn’t do what they intended it to do. (Test-first programming.)
2. Writing tests first to reduce the cost of making design mistakes, meaning designs that cost more to change than they otherwise could. (Test-driven design.)
3. Writing tests first in tiny, tiny steps in order to smooth out the volatility in the cost of refactoring. (One such way: Test, then commit; otherwise, revert.)
4. Changing how one practises TDD in order to accommodate different contexts, such as whether the language does type checking or how much coupling the application framework imposes on them or the experience levels of the other people working on the project.

It seems that TDD can “be about” many things, and not only testing or design!

And Poof… It’s Gone!

Putting on your Giraffe Ears, checking the logic of the supposed dichotomy, exploring alternative interpretations behind framing the message as a dichotomy… these techniques make the false dichotomy disappear.

Well, not exactly. It’s still there, but you behave largely as though you can’t see it, don’t notice it, or don’t mind it. Any of those would almost certainly help.

Less blame means more psychological safety for everyone!

And when you want to correct the other person, do it firmly but gently. There are entire bookshelves devoted to this topic, so good luck. As a starting point, this is one of the many reasons I meditate.