Retire These Metaphors & Reframe the Discussion to be More Effective

For years, we've used several metaphors to describe software product development:

• People-based metaphors, such as:
  • Man-weeks for all the humans working on a project or a product.
  • FTE for full-time Equivalent (as in human beings!)
  • “Resources” instead of the words: people, or human beings
• Construction metaphors, such as: build, which describes how we organize and create a usable product.
• Pregnancy to explain the indivisibleness of some work. This is the metaphor of “Nine women can't make a baby in a month.”

Metaphors do help us make sense of the world and of our role in that world. But these metaphors no longer serve us.

I'm not being politically correct. I'm discussing why these metaphors no longer make sense—even if we think they once did.

Let me start with how we describe human beings at work, the people who do the work.

Human Beings Do the Work

We have all kinds of names for people at work. The first time a manager asked me how many man-weeks my work would take, I said, “Zero. I'm not a man, so no man-weeks.”

He said, “You know what I mean.”

“I do,” I said. “And you can't make me a man. I'm a woman. I will take some number of person-weeks, or some human-weeks, or some female-weeks. But I'm not a man and I'm not invisible. Which would you prefer?”

I think he preferred that I was a little less visible. He had never considered his language before.

When we talk about man-weeks, or FTEs, or resources, when we mean human beings, we make it possible to be less congruent. Those pesky FTEs don't need health care or any of the other perks that come with employment. (See People are NOT FTEs.) Worse, FTE thinking often leads to shared-services thinking. See Why Shared Services “Teams” Don’t Work with Agility.

When we use the word “Resources” for specific people or for people in general, we often miss how unique each person's skills and capabilities are. I bet you've seen plenty of times when a person “failed” in one team and thrived in another. People are resourceful—not resources. People are Resilience Creators.

When we discount the humanness of the people, we become less effective. (See Practical Ways to Lead an Innovative Organization.)

Next are the construction metaphors and how they prevent us from thinking about learning

Construction Metaphors Reduce the Importance of Learning

High-tech product development occurs because a team of people learn together. Yes, those people might also plan together. But they learn as they:

• Prototype and ask for feedback.
• Conjecture about an architecture or an algorithm, and test their theories.
• Build, as in compile, and create a usable version.
• Demo inside the organization.
• Release outside the building for customer feedback.

When we use the word, “build” to describe all of these, we shortchange ourselves. Other people think all we do is type and build. But typing is the least important thing we do.

I bet you, as I, have plenty of stories when it took you several weeks to write some code or tests. Then, something happened, and all that work was lost. It didn't take you another several weeks. Instead, you probably needed several hours. And if you're like me, you simplified the code or tests the second time around. (I didn't know about refactoring back then.)

We learn as we create. And if we want to learn faster, we learn as a team.

I've been part of several construction projects, and they all used an iterative lifecycle. We iterated on the designs. Then, as we discovered the inevitable gotcha's, we iterated on the implementation.

Complex projects require a combination of iteration and increments of delivery. When those of us who aren't in the construction industry talk about construction, we think it's planning and then delivery. So we do ourselves and our construction colleagues a huge disservice when we dismiss team-based learning.

I suspect that's because we've convinced ourselves that so many tasks are not divisible to multiple people in parallel.

We Know How to Manage “Indivisible” Work Now

If people work alone, it's true, that nine women can't have one baby in one month. But why are we talking about women and babies at work?

In product development, is it anyone's job to make a baby at work? No.

Is releasing a product anything like giving birth? No. (No one has to experience birth to know this.)

So why are we talking about babies at work? For these reasons:

• Women don't belong in the workplace because they might get pregnant. We can't have that. Not at work.
• Women also make men nervous about women's sexiness.
• Women threaten men with their competence, so we need a metaphor that puts women down.

I already told the story of my very first day at work in Why Aren’t We Better at XP (or Almost Anything)? “Stop Making It Harder”. Sure, that was 1977.

But the more we talk about indivisible work when we use the metaphor of women and babies, the more we reinforce sexism at work.

I am sure that most of my readers are enlightened women and men and that anyone else's pregnancy, sexiness, or competence does not matter to you.

But the more we use this metaphor, the less congruent we are. Worse, the less effective we are.

Besides, we know how to manage indivisible work. We swarm or mob/ensemble on the work as a team. That's because pregnancy has not one damn thing to do with product development. We are long past the time of a man leading a “surgical” team, the point of Fred Brooks' Mythical Man-Month.

It's time to retire these metaphors and reframe the discussion.

Reframe the Discussion

Metaphors can help us understand the work better. These unfortunate metaphors have met their expiration date. (See what I did there? I used a food or drug metaphor to discuss product development metaphors.)

Instead of dehumanizing our work, let's discuss how people—with all their creativity—can elevate the work. Why not discuss how to optimize creativity and collaboration to make the work go faster?

As for the construction metaphors, I don't yet have a great idea. I prefer the words create or develop for the work we do as teams. I'm still stuck on build or make, which reinforces the construction ideas. Maybe you have a better idea.

And as for indivisible work? Very little of that exists when teams of people collaborate. (See this series for how collaboration changes the product development game: See and Resolve Team Dependencies, Part 1: Inside the Team.)

Finally, let's discourage sexism and leave all this discussion of pregnancy outside of work. Product development has nothing to do with birth. We don't need to let the last century's metaphors reinforce the last century's beliefs. There's enough sexism already at work. Let's not make any more of it.

When you choose a metaphor, check to see what else that metaphor implies. You might be surprised by what other people infer.