The Cliché Defense

There is a tendency exhibited by certain types of managers in certain types of organizations to manage with maxims and administer with anecdotes. Their style often consists of a warmed-over serving of the latest business self-help book garnished with an old war story and a side of the patently obvious. Such people can show a remarkable dedication to oversimplification and a common trait of this managerial style is the persistent use of the cliché.

A good cliché has several attributes:

• It covers a wide range of human behavior with just a few words.
• It sounds specific and focused but doesn’t actually say much.
• It favors style over substance, pretence over production, and affect over effect.
• It has a veneer of truth that makes it plausible and difficult to argue against.
• It must suggest a solution to a problem without requiring the person using the cliché (the cliché-er) to actually invest any energy in implementing that solution.
• It should leave the work of resolving the cliché to the unlucky listener (the cliché-ee). This allows any success to be claimed by the cliché-er, while locating the blame for any shortcomings in the implementation firmly on the shoulders of the unfortunate cliché-ee.

How does one defend against cliché-driven management? I have seen whole teams play the “buzzword bingo” game, gleefully tagging the hackneyed slogans of the oblivious manager. I know of senior executives in large companies who are the unwitting source of merriment for whole divisions based on their fine grasp of the obvious and their predictable production of clichés for all occasions.

The use of clichés is usually quite harmless, though it may detract from actually trying real solutions to real problems. There are legitimate defenses against certain clichés, but I must caution readers that some of these defenses use a technique called “humor.” The best humor is shared between the parties involved and reflects the comedy that exists in the situation. Use of a cliché defense as way of publicly poking fun at the person who is responsible for your continued employment has its perils.

Back to Top

The Cliché: “Do It Right the First Time”

Much of the business of software involves the discovery of what we are supposed to be doing. In a true discovery activity, it is only possible to not make “mistakes” though sheer blind luck—when we just happen to hit on the optimal solution right out of the box.

Imagine walking through a dense forest for the first time. It would be almost impossible to get through the whole forest without taking a “wrong” turn. The journey must necessarily involve a certain amount of eliminating incorrect paths. Sometimes the only way to do this is to actually explore the wrong paths, because we don’t know they are wrong until we try them. In fact, we could argue that the highest source of value in software development is only in exploring new ways to do things. If we are able to navigate through the forest without a misstep, it must be because: we have already been this way before (in which case why are we doing it again?); or we have a map (which means that someone has been this way before). If we can get through the forest both without error and very quickly it must be because someone has built a highway through the forest. If so, we are going toward the same destination, and building the same system, as everyone else. The real value in software is on the road less traveled, but we cannot travel this road without some exploration, and that means diverging from the path.

 Inferences

You normally do it wrong, or at least it takes you many attempts to do the job properly. Clearly, you aren’t smart enough to do it right without my guidance. In fact, without my leadership you aren’t even smart enough to realize that you are doing it wrong at all.

 Defense

If this truly is the first time, we cannot “do it right” because:

• We don’t know how to do it right (because it is the first time).
• We may not even know what “right” is (because it is the first time).
• Doing it “wrong” may be the only way to find out what “right” is.
• We may actually learn more about the problem, the solution, or the business, if we do get it “wrong.” An advocate for this approach was Thomas Alva Edison who was quite famous for getting it “wrong.”

Back to Top

The Cliché: “Work Smarter, Not Harder”

This is a fine cliché, since it strongly implies that the cliché-er is actually being solicitous of the health and well-being of the cliché-ee. There are so many sneaky positional inferences in this cliché that it makes a very effective one. It has that element of truth that makes it difficult to argue against, too. Excessive work may well be a symptom of not having sufficiently thought through the problem. However, many organizations think that software is a product to be produced (rather than a knowledge medium to be populated), so the job of a software developer is to build something (rather than learn something), so the engineers should be working rather than thinking.

 Inferences

It’s your fault you have to work so hard, since you aren’t working smarter, so you shouldn’t complain about the workload. I, on the other hand, am able to see that you are not working effectively even if you cannot. Therefore, I must be smarter than you (as well as having more authority and status).

 Defense

• If we were smart enough we would recognize that we aren’t working smart enough. And if we were smart enough we’d be able to identify the smarter way of working and we’d also figure out how to transition from our dumb way of working to the smarter way of working.
• Therefore, if we were smart enough to figure out how to work smarter, we’d already be doing it. Clearly, we aren’t smart enough to work smarter.

---

Much of the business of software involves the discovery of what we are supposed to be doing.

---

Back to Top

The Cliché: “Quality is the Most Important Thing”

Many organizations make this statement. Some of them even mean it. Of those companies that mean it, a few even act like they mean it. Software is a knowledge storage medium, so a defect is simply a lack of knowledge—it is something that we, as developers, did not know or did not learn and therefore didn’t build into the system. So this exhortation is rather like the “work smarter” cliché.

A defining characteristic of modern software development is that the needs of the system change at close to the speed at which we can build the solution. So there may be nobody who can definitively, and in advance, determine what “perfect” is. Developers may be held accountable to a standard that no one can define.

 Inferences

There is some perfect system representation that the developers should know but through a combination of failings (sloppiness, ignorance, laziness, ineptitude), developers have chosen to not achieve this perfection, and need to be reminded that it is important. This perfection can also be achieved without compromising any other of the “most important” attributes of the system (such as time and cost).

 Defense

• Just what is “quality” and who can provide us with unequivocal guidance on it before or while we build the system (as opposed to second-guessing it after the event)?
• Are we prepared to actually do what we need to do to obtain the quality we say we need?
• If we delay delivering the system because of quality issues, then the system is 100% defective (not one part of it works, because the customer doesn’t have it). Is this solution in the best interests of the customer?

Quality, along with all the other attributes of a system, is part of a balancing act. We might deliver higher quality at the cost of delayed delivery or higher cost or reduced functionality. Attaining higher quality is not a matter of just stating the goal; it usually involves discipline and hard work. And sometimes it involves difficult choices.

Back to Top

The Cliché: “Our Customers Are the Most Important Thing”

This cliché has that important veneer of truth. Certainly, few companies can continue in business if their customers desert them, and in the business of software delivering usable knowledge to a customer is the ultimate goal. There is ample evidence that software developers do not routinely think from the customer’s perspective. But simply exhorting people to think of something important is hardly an industrial-strength business practice. Perhaps software organizations should consider building truly customer-centric development capabilities? Of course, that would be more difficult to do than just firing off a cliché.

 Cliché Inferences

You need me (the cliché-er) to remind you (the cliché-ee) that we do, in fact, have customers, because left to your own devices, you software engineers would only develop what you want to: specifically the easy stuff or the “cool” stuff. Besides, software developers really think they are the most important thing.

 Defense

• There are many “customers” for a system. While the paying customers are undoubtedly the “most important,” the people who test, install, support, or maintain the system are also customers.
• The value in a system is the extent to which it makes knowledge accessible and usable. The extensibility of this knowledge—how we can build on it to service future customers—is also very important. In fact, this aspect of building systems is driving the entirely appropriate focus on systems architecture and scalability we see in modern development. Few end-user customers are sophisticated enough to specifically request such features as scalability, but it is important nonetheless.

We could even argue that building the capability of an organization is more important than any particular customer, since it leads to the ability of the company to satisfy many more customers in the future.

Back to Top

The Cliché: “Our People Are the Most Important Thing”

Few clichés have more power to generate a skeptical and cynical response in its listeners than this one. There are many companies, executives, and managers who do truly believe in the people who work for them and, as far as they can, do look out for the interests of their employees. But we have probably all experienced the inflated rhetoric that sometimes passes for statements of worth and concern from executives. Its cliché-ness is not so much in the statement as in the sometimes transparent attempt at control it communicates. Most of us are quite sensitive to being manipulated like this, especially if it is done in a way that is so obvious that it also insults our intelligence.

---

The real value in software is on the road less traveled, but we cannot travel this road without some exploration, and that means diverging from the path.

---

 Inferences

You (the cliché-ees) unforgivably suspect us (the cliché-ers) of wanting to manipulate you into something against your best interests. We are hurt by this lack of trust. Therefore we hope that by assuring you of our true concern for your well-being, our genuine respect for you as individuals, and our earnest desire to not have you think that we are trying to manipulate you, you will become easier to manipulate.

 Defense

• If people really are the most important resource, does the company actually provide them with what they need to do the job?
• In the business of software, people are not the most important resource, they are the only resource. Software development is a knowledge acquisition activity and the only thing that can acquire knowledge is a person. Optimizing this resource requires dealing with people honestly.

Back to Top

Rules of Engagement

As clear as this is, sometimes it needs to be restated. A company I once worked with adopted a set of “Rules of Engagement” intended to govern the behavior of all employees. Heading the list was “the customer is the most important thing.” One visionary company executive turned this around. He restated the imperatives as:

1. The most important thing is to build our employees’ capability.
2. The second most important thing is to build our capability to repeatedly do imperative 1.
3. The next most important thing is to deliver value to the customer.

I remember the alarm this caused, since it reversed the published order of the Rules of Engagement, but the executive was correct.

Back to Top

People Are the Most Important Thing

The company executive reasoned that unless you have good people working well, you simply cannot provide value to the customer. Unless you can repeatedly build and maintain your peoples’ capability, you may provide value to the customer once, but won’t be able to repeat it. And if you cannot repeat your success, you will fail your customer anyway.

This executive knew you won’t work smarter or do it right even the second or third time unless the people working in development have what they need. And you cannot act as if quality is the most important thing or the customer is the most important thing unless you first act as if your people are the most important thing. In articulating and enacting this visionary paradigm shift in their core competencies, this executive was walking the walk, going the extra mile, giving it 110%, and thinking outside of the box.

But in this case it wasn’t a cliché and that made all the difference.

Back to Top

Back to Top