In this game, the only way to win is to stop playing.
©2004, 2005 Don Gray and Gerald M. Weinberg
It may look like a crisis, but it’s only the end of an illusion.
– Rhonda’s First Revelation
Sharkey, the sales VP of UberDenke Software Products, firmly believes he needs to have the next release of the UDCRM product in three months. Engelbert, the software engineering VP, estimates a minimum of twice that long – six months – to implement all the new features. During the discussion, Sharkey drops some thinly veiled threats:
- Do you think we need to consider outsourcing this development?
- I wonder why our competitor manages to get software out, but we can’t?
- Perhaps we need to see the company president about the schedule.
Getting the message, Engelbert eventually agrees to “try to get the software done” in three months. Engelbert calls a meeting of the development group leaders and shares the story. “Marketing insists that we ship the next version of UDCRM in three months. Sharkey already has a quote from an outside vendor, so I had to agree to the schedule. Let me know how we’re going to get this done.”
The developers head to their cubes and start to ponder how they will get the work done in three months. No matter how much they try to shorten their schedule, their estimates range from three and a half to eight months to deliver the next version of UDCRM. Engelbert figures that Pamela’s estimate of three and a half months is close enough to three months, so he shaves off two weeks and declares that as the team’s schedule. He rewards Pamela by making her project lead.
Objectives for Play
In the abbreviated story above, there may or may not be a valid reason Sharkey wants the three-month date. There may be legal considerations (HIPA, EPA, IRS) involved. Perhaps COMDEX is in three months and UberDenke needs to be ready to demonstrate the product. Or maybe a key client has agreed to pay to have UDCRM shipped in three months. Sometimes the “Big Boss” has determined that a date (usually 1 January) is a good day to start using a new system. And just maybe, Sharkey fabricated the date out of pure imagination.
Likewise, Engelbert may or may not have had valid reasons for his initial estimate of six months. Based on the new features and changes to infrastructure, six months could be a valid number – even optimistic. Perhaps previous experiences with marketing have always ended with Engelbert’s estimates cut in half, so this time he doubled his best guess for how long the next release would require.
When Sharkey makes up the needed date, and Engelbert starts by doubling his estimate, they become enmeshed in a Liar’s Contest. A Liar’s Contest is a dynamic interaction arising from a conflict between two people who hold different values for an outcome. The winner is the contestant who emerges from the game with his lie unchanged. The loser is the participant who believes the other contestant’s lie and changes his lie to match. Neither of them is ever forced to tell the truth.
A Liar’s Contest can happen between the same or different corporate levels as well as between organizations. Sharkey and Engelbert play the game as peers from different parts of the organization. Engelbert and the developers play Liar’s Contest as boss and subordinates. During the competition, one participant generally starts with some type of an advantage over the other.
The participants’ negotiations tend to be zero-sum situations. Winning for one becomes losing for the other. Generally, the interactions between the participants focus on a single value (three months, six months), not a range of values. They never discuss probabilities, even though the future is always uncertain. You can often stop the Liar’s Contest dynamic by creating win-win situations, agreeing on a range of values, or allowing probabilities into the discussion.
And even though Sharkey and Engelbert finally “agree” on a value for the outcome, the real outcome value will almost certainly be something else:
– A miracle happens. No risks occur and the salaried programmers work long unpaid overtime hours, and the product ships on time. This outcome reinforces Sharkey’s original request of three months. “Those programmers! Always padding their time estimates! I KNEW IT!”
– A miracle fails to happen and the product ships “on time” with serious or fatal defects. Sharkey points out that Engelbert agreed to the schedule, so the current mess is his fault. For extra affect, Sharkey can mention that “The only reason we’re not losing more customers is because of the frantic work of the sales staff.”
– A miracle fails to happen and the project ship date slips to six months – or, often, much longer because trying to do a six-month project in three months usually takes much longer than a well-planned six-month project. The product finally ships with minor defects. Sharkey points to lost customers
and lost revenue and blames Engelbert for the dip in quarterly revenues.
It’s interesting to note that in all cases, Engelbert and the software developers are “wrong.” That makes them the losers, but it doesn’t guarantee that Sharkey won’t lose, too. If he’s still responsible for sales, he may suffer the consequences of the failure to produce a miracle.
Choose Your Position
In a Liar’s Contest, one participant usually comes into the competition with one of five distinct advantages:
Positional Given most corporate structures and climates, it’s difficult to argue with a liar from above you who delivers the “Make it so!” ultimatum. That’s why Liar’s Contests often trickle down through several levels of an organization, producing incredibly far-fetched values of estimates.
Negotiation Experience Some people have more experience negotiating, which gives them an advantage when they press for their chosen outcome. They tie into the culture better (“Be a team player”) and have alternate options (real or fictitious) prepared as threats prior to starting the Liar’s Contest. (“We’ll have to go outside if you can’t do it.”)
Interpersonal Skills The ability to understand people provides additional leverage points. We all want to be successful and to feel competent, yet while the feelings are mutual, the participant who first brings them up tends to put the other person on the defensive.
Psychological Strength Anyone who comes to the Liar’s Contest off-center, entwined in other stressful events, or with generally low self-esteem will be at a great disadvantage to a more congruent opponent.
Nothing to Lose The less you have to lose by lying, the more easily you’ll win most Liar’s Contests. Your potential loss involves both the size of the loss if the lie is discovered and the chance that your lie will be discovered.
When a time delay exists between the negotiation and the outcome, it’s possible that neither party (like Sharkey and Engelbert) will be in the same position, or even with the same company when the outcome is
delivered. If the time delay is long enough, or the record keeping is bad enough, nobody will remember the original lie. Perhaps the reason projects keep such poor records of past estimates is that the people love to have Liar’s Contests and not pay the price of losing.
After Engelbert and Sharkey have played a round or two of Liar’s Contest together, several different effects may be seen in the long term. Sharkey may no longer accept any of Engelbert’s first estimates – he always pressures for a decrease. Engelbert may compensate by padding his original estimate. Since the “pad” can be negotiated away, the reduction dynamic is reinforced. Engelbert may offer more honest first estimates. This does not change the underlying system, so the personal interactions won’t change. The system goes through another evolution and repeats the previously described activities.
This dynamic looks like:
If the Liar’s Contest continues to result in reduced delivery times but worse quality, secondary negative consequences appear. The developers will have a reduced view of Engelbert’s overall management abilities. The long hours developers work attempting to deliver the software will result in mental fatigue and burn out, a further drop in output quality (now on a downward spiral to disaster), and interpersonal stress (family life suffers, feeding back to even poorer quality work). If the economy and locale permit, developers will start leaving for greener pastures in more honest environments. Finally, customers may purchase the competitor’s software due to release quality and cycles.
All in all, Liar’s Contests establish the relationships and conditions for bad things to happen, both now and forever more.
To end the Liar’s Contest, both parties must realize what is missing in their interaction: the other person and the context of the discussion. In our story, each player in the Liar’s Contest saw only his own role. Sharkey saw Engelbert only as an impediment to his success. Engelbert saw Sharkey only as an obstacle. Neither saw the other as a human in the same boat as himself, nor did either player see himself as just one part of the bigger system. The reality is that Sharkey and Engelbert are both parts of an interconnected system. For Sharkey’s sales to increase, the developers need to deliver a quality product. For client expectations to be easily managed, the sales force has to provide realistic delivery dates.
While early delivery may result in increased sales, these sales come at a cost. Increasing sales may mean more customers, but poor quality software leads to increased support costs. Thus, the company may be less profitable than before. Customers may lose time fighting a faulty product. As support degrades, they tend to switch to a competing product. What both the company and customers need is not software in three months, but software with
sufficient quality as quickly as possible.
When the goal is stated this way, both players can support it. This agreement allows for a number of possible interventions that could end the Liar’s Contest:
1. Include pertinent contexts in the negotiations. If Sharkey explains why the dates are important, it could give Engelbert an opportunity to suggest trade-offs, so they could deliver the most valuable product possible within the time constraints. If Engelbert points out the quality trade-offs that the short schedule forces, Sharkey may see that it could cause customers to choose competing software. Sharkey can then work with Engelbert to find a date that will work for both of them.
Ideally, Engelbert would show the trade-offs by bringing real customers into the discussion, but salespeople who like to win Liar’s Contests generally work to prevent actual contact between customers and developers. If this happens, Engelbert should ask the customers if they want to talk directly with him. If the customers do want to talk to him, Engelbert should ask them to insist on it. He shouldn’t volunteer more than that. Concerned customers will make it happen. If the customers are not concerned about lies, Engelbert shouldn’t be concerned either.
2. Avoid all or nothing discussions. Offer options during the negotiations. Consider a range of features over a corresponding delivery time frame. Say, “If you really need that delivery schedule, here’s a list of functions. Start cutting them one by one and I’ll tell you when you’ve cut enough so we can make the schedule.” Or, if it’s feasible, you might say, “If you give me this and this by such and such a date, then we could make that schedule.” Be sure to ask only for things they can actually get for you – not, for example, promises of “perfectly clean component deliveries.” And be sure to have this in writing, in case they don’t deliver and still expect you to make the date.
3. Say “I don’t know.” Instead of saying “that can’t be done,” Engelbert can engage Sharkey in trying to solve the problem by saying, “I understand what you want, but I don’t know how to give it to you. Do you see something I don’t? Can you show me how to do this?”
4. Let someone else do it. Sharkey might threaten Engelbert, “If you can’t deliver, I’ll find someone who can.” Engelbert may defensively insist there’s no need to go outside, but properly engaging outside help can create the opportunity for the inside developers to learn new software packages, techniques, and skills. Or, if the outside developer fails, the sales organization has a chance to learn more reasonable expectations about software development.
5. Add another information path. Include the company president, developers, customers, or other parties who have skin in the game. Again, invite them to ask themselves in, using their power to get what they want and need. If they don’t want in, then it’s no longer a problem.
Nobody has to engage in Liar’s Contests – unless they enjoy it more than they despise the consequences. Understand the dynamics so you can show other people the consequences of starting a Liar’s Contest. A copy of this article might serve that purpose quite well. It has for us.
< Publication Notice> – A version of this article was previously published in Sticky Minds, May/June 2004