PM Articles > Kent McDonald > Stop Writing Checks Others Can't Cash

Stop Writing Checks Others Can't Cash

by Kent McDonald

Stop me if you've heard this one.

The members of a delivery team were sitting in their team space a few weeks ago when their product owner, Phil, walked in.

"Hey guys, how are you doing?" Phil asked, stopping by the food table to check out the latest selection of chips and candies.

"Hey, Phil." "Pretty Good." "No complaints," came the various replies.

"Cool," nodded Phil grabbing a handful of tortilla chips. "By the way, I told Patricia with the CRM program that we'd have those TPS Reports done by next Friday."


There weren't literally crickets in the team space, but if there were, their chirping would have been very audible over the distinct lack of sound coming from the delivery team members.

Phil threw a couple of chips in his mouth and looked around the room.

Finally, Brandon, with a slight nervous chuckle, said, "Sorry, Phil, I could have sworn you said that you told Patricia that we'd have TPS Reports done by next Friday."

"Yep, I did say that," said Phil around some crunched up tortilla chips.

"What in the world," asked Brandon, the chuckle replaced with a menacing hiss that indicated he had a few choice expletives he would rather use at this point, "What in the world led you to tell Patricia that? We haven't even started on the TPS reports."

Phil stopped chewing briefly, then started chewing thoughtfully again, until he realized he had already swallowed the chips he thought he had been chewing. "Well . . ." he said, pondering his predicament, "you guys have always been able to pull things through before, and those TPS reports don't seem too difficult. You guys hinted at that yourselves during the sizing meeting."

"Yes we did, " said Franklin watching as Phil took a bite of a chip, then dipped the remainder of it in the salsa before popping it into his mouth, "right before we said they are completely pointless. The CRM system provides all that information inherently -- we don't need separate reports to provide it. The only value those reports provide is to cover the table when you are cleaning a fish."

"Hmmm," said Phil, reaching for another chip.

"And if you double dip one more time, you are going to be wearing that salsa," said Franklin as he got up from his desk to look at the Discovery Board. "In the meantime, what don't you want to get that we are already working on in order to get those TPS reports?"

Phil looked from the chip in his hand to the salsa bowl to Franklin and back at the chip.

"Umm . . . hadn't thought about that. I just figured you guys would figure it out. You've been able to do it every time before." Phil shrugged. "I just know I pretty much had to tell Patricia that we'd get those done since she had already told Gertrude (the Sales Director) that they would have them for quarterly reporting."

So what's going on here, apart from Phil's rather cavalier attitude toward common team food table courtesy?

This is a classic example, perhaps contrived but unfortunately not too far from actual occurrences, of one person writing checks for someone else. In effect, Phil and Patricia are exhibiting some fairly common organizational anti-patterns that can often have a detrimental effective on team success in an organizational setting. They are making promises that they expect other people to keep.

I became aware of promise theory a few weeks ago when my friend Jeffery Davidson pointed me to a blog post titled "Turning Requirements into Promises." That post discusses the idea of Promise Theory and its relationship to software development. Here are the core aspects of Promise Theory:

  • A promise is when someone publicly declares their intention to do (or not do) something.
  • The declaration of intent is up to the perception of the receiver. In other words, it's possible for the receiver of a message to interpret it as a promise when it wasn't intended that way. Said yet another way, it's possible for someone to make a promise without realizing it.
  • Promises may or may not be kept.
  • Different people may have different perspectives on whether a promise was kept.
  • People, groups, or teams are autonomous and can only make promises for themselves. They cannot promise someone else will behave in a certain manner.
  • When someone tries to make a promise for someone else, this is an imposition.

(Concepts paraphrased from The Book of Promises (PDF).)

All fascinating stuff, but what does this have to do with Phil, Gertrude, and the delivery team?

Because people, groups or teams are considered autonomous, their intentions are not known until they publicly declare them (i.e., make a promise). This lack of understanding of intention can lead to a great deal of uncertainty, so project leads seek to gain more certainty by asking people when they are going to do something or get something done. When someone (Phil) claims to speak for another person in an attempt to decrease uncertainty ("We'll have the TPS reports done by next Friday") he's actually increasing uncertainty. He has implied a promise, when in reality he is imposing on the delivery team. The situation described above actually has a chain of impositions that are interpreted as promises. First, Patricia promised to Gertrude that the TPS reports would be available for quarterly reporting. She probably didn't explicitly say "promise," but statements like that are often interpreted as such in business settings, especially when the people involved in those types of discussions don't know who actually has to do the work.

Next in the chain of impositions, Phil promised Patricia that the TPS reports would be done by next Friday. This is a more specific promise than Patricia's but seems reasonable since Phil is more closely aligned with the delivery team. It still doesn't make his statement a promise, and in some respects it's even more unforgivable, because he actually knew the team's intentions as described on their delivery board, which in effect is their promise to the organization - we're going to work on these things in the next two weeks.

So if we look at what Promise Theory tells us on the surface, we'd be led to believe that the TPS reports will not be done by next Friday. They did not have the intention to work on the TPS reports in the intervening time, and they didn't make a promise to do so, but were rather imposed upon by an outside force. However, we're reminded by Yogi Berra that "in theory there is no difference between theory and practice. In practice there is." In many organizations, people and teams react to impositions in one of two ways. The either give the "f-you" response and basically ignore the imposition, or they go into hero mode and treat the imposition as if it were a promise they actually made. In the latter case, they will move heaven and earth to keep that so-called promise, often at the risk of not keeping other promises they actually did make. Paradoxically, the f-you response is actually a healthier response in the long run, because the hero response encourages people to continue to make impositions on the delivery team. This is evidenced in Phil's response in the dialog above. Even though he probably had a good idea that the team was not currently intending to work on the TPS reports, he figured he could go ahead and say they'd have them done, because they had pulled out heroic efforts in the past to fulfill an imposition, usually upsetting other promises the delivery team made.

People's perceptions of other's promises are heavily based on trust. If the delivery team has a long history of adopting promises made on their behalf and keeping them as if they were their own, that type of behavior will be expected. Along the same vein, if I habitually make promises I don't keep, any explicit promises I make in the future probably will not be treated as promises, and there's a good chance the people I communicate those promises to will make contingency plans.

With all that in mind, what practical use is Promise Theory? It suggests ways different groups can behave toward each other to effectively and cooperatively satisfy a particular need:

  • Don't write checks for other people. Don't impose an action on another team. Rather, ask that team if they can do something, and if so by when.
  • Validate assumed promises. It is very easy to misinterpret a statement as an intended action. If you think someone just promised to do something, confirm that is what they meant. There is a big difference between "I could do something" and "I will do something by next Friday." It may be appropriate to cement that understanding with an explicit "I promise" that may be appropriate (although it could feel a little heavy-handed).
  • Trust but verify. Whether you believe a group will keep their promise is heavily dependent upon your past interactions with that group. The better the history, the more likely you are to implicitly trust them. In all cases, it's still best to verify along the way that the promise will be kept.
  • Build contingencies. There is always the chance that a promise will not be kept, either intentionally or despite the best efforts of the promisor. It's always wise to consider some contingency plans in case the promise is not kept; doubly so when the historic interaction with the other group does not represent a sterling record.

Phil's plight, described at the beginning of this article, actually starts with Patricia. In her interaction with Gertrude, she shouldn't have explicitly told Gertrude the TPS reports would be available for quarterly reporting. Rather, she should have acknowledged Gertrude's desire for the TPS reports at that time and promised to find out if that was possible.

Next, the conversation between Patricia and Phil could have gone the same way. In this case, Phil could have promised to find out when the TPS reports could be finished, instead of blithely "promising" (imposing, really) a date on behalf of the team.

It would have been even more expedient for Phil to invite Patricia to the Delivery Team's area so that they could talk about the issue with the team. That would give Patricia the opportunity to explain the desire to have the TPS reports for quarterly reporting, and it would give the Delivery Team the opportunity to ask the intended use of the TPS reports and point out that information may be available from an existing source.

In all of these approaches to Phil's dilemma, the people promising an action are making a promise they can keep. Patricia may turn out to be unconvinced by the team's argument and still ask for the TPS Reports, at which point the team can make their promise by indicating when the TPS reports would be included in an iteration for delivery.

As for Phil wearing a bowl of salsa, that's completely within his control.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.