Game Theory in Management

In his best-selling book Games People Play (Ballantine Books, 1964), Eric Berne theorized that we all walk around with scripts running in our heads, collecting all the facts we gather in to a structure that resembles a story line – sort of the stories of our lives. Berne also asserted that we have three personas when it comes to interacting with others: the Child, the Adult, and the Parent. These three are somewhat similar to Freud’s Id, Ego, and Superego, but Berne’s analysis turns on how these three personas behave when we communicate with others – hence the “transactional analysis” he presents in his book.

In my not-bestselling (yet) but must-have book, Game Theory in Management, I take Berne’s theory one step further: we don’t have one script running, but three (or one story with a main plot and two subplots). These three scripts mirror the three personas, but with a twist:

·         The Child persona’s script is what we tell ourselves about ourselves. It’s entirely internal, or self-centered.

·         The Adult persona’s script provides the structure for how we ought to interact with others, primarily to in order to fulfill the needs of the Child.

·         The Parent script tells us what we should aspire to, and is often based on our perceptions of those around us and their status.

Because the child persona is the Berne equivalent of Freud’s Id, its narrative tends to be both highly emotionally-charged and irrational in the extreme. If we convince ourselves that we are superlative in some area, and evidence arises that suggests otherwise, or even the exact opposite, we will often reject that evidence, for the simple reason that re-writing any part of our Child’s script is usually excruciatingly painful. A truly humble person has a far easier time of integrating facts-on-the-ground into their narrative(s), and we all know how predominant the truly humble are among executive-level management. One more element – when our narratives are inconsistent with reality in profound ways, we are said to be delusional.

Okay, Michael, you ask, what does all this have to do with June’s theme, of consultants and outsourcing? Well, I’ll tell you. The act of hiring a consultant is a tacit admission that the organization recognizes that at least some elements of its narratives that are in need of revision. However, if the script needing amending is within the purview of the organizational equivalent of the Child’s, then look out. It will not end well.

There’s the story I heard while in graduate school, of a quality consultant brought in to work with an automobile manufacturer. Frustrated in his attempts to call management attention to what he perceived were the basic problems with this firm’s product, he supposedly showed up to a board meeting with an example of this company’s piston, which was cast, along with a competitor’s forged and polished piston, and simply put them down on the table, side-by-side. The difference in quality was so stark that upper management…

…threw him off of the site, and forbade his return. The organization’s internal narrative could not stand the infusion of facts that pointed to a narrative of their being the creator of substantially inferior goods, and they responded in a most child-like fashion in order to maintain their comfortable delusion. The company named in the story eventually went bankrupt.

Of course, many (if not most) consultant relationships do not end poorly, with both the hiring organization and consulting firm benefitting from the eventual outcome. But in cases of extremes in this relationship – where either the organization’s narrative is perfectly sufficient (or even superior to that of the consultant) and no consultation is needed, or else the problem causing the hiring of the consultant is so deep-seeded and prevalent that it challenges the very basis for what the organization believes of itself – then it is very hard to see how any good could come of the relationship.

But then, that’s just one consultant’s (strikethrough) blogger’s advice…

In my blog from two weeks ago, I promised to present a way to advance a given capability (in this case, project management) within an organization following the structure inherent in Carnegie Melon University’s Software Engineering Institute’s (SEI’s) Capability Maturity Model® while avoiding the dreaded “slow roll” (Professor Bud Baker’s term) or silent veto, and that this method had its roots in game theory. But then, in last week’s blog, I took advantage of the occasion of Kristen Wiig hosting Saturday Night Live to lambast their writers for being highly formulaic in their sketch-writing, so it falls to this, the last week of May (and May’s theme) to provide this answer. And the answer is…

…rooted in Game Theory, like I said before, specifically the game known as the Prisoner’s Dilemma. There are various versions of the Prisoner’s Dilemma, the most common being that you are in a situation where you are in prison, and your jailer tells you that if you rat out (inform on) your cell-mate, he will reduce your sentence. Problem is, you know your cell mate will receive the same offer. There are four possible outcomes:

·         You both rat on each other, and both serve 11 years.

·         Neither of you rats on the other, and you both serve 18 months.

·         You do not inform on your cell-mate, but he informs on you. You serve 18 years, and your cell-mate walks free (this is known as the “sucker’s payoff”).

·         Similarly, you inform on your cell-mate, but he does not inform on you. You walk, and your cell-mate gets 18 years.

Conventional wisdom on the Prisoner’s Dilemma had the best tactic as always ratting out your cell-mate in order to avoid being on the receiving end of the Sucker’s Payoff.

In the 1980s, Robert Axelrod hosted a tournament for competing computer programs playing 200 iterations of the Prisoner’s Dilemma. As  you can imagine, programs employing all manner of strategies were entered, some, keeping with traditional wisdom, informing on the other program every time, others ratting out the first fifty times, but not the next one hundred and fifty, and so forth. One program, submitted by Anatol Rapaport and called Tit for Tat, won the tournament handily. The Tit for Tat program employed the following strategy:

·         The first iteration, it cooperated (did not inform).

·         Thereafter, it did whatever the other program did in the previous iteration.

After Tit for Tat won the overall tournament, some analysts tinkered with its underlying strategy, and developed versions that, say, cooperated the first five times, and then did the tit for tat thing, or else started off by ratting, and then going into the tit for tat strategy, but the alternates always lost to the original. So, the analysis yielded three primary reasons why Tit for Tat won the tournament:

·         It was initially nice – it cooperated the first iteration.

·         It retaliated immediately for defection.

·         It forgave completely and immediately for cooperation.

Many years after I had read the original analysis, and was trying to crack the nut of how to get past people in the organization who were opposed to the advancement of a particular capability by slow-rolling or silent veto, the solution hit me like a thunderclap. In the advancement of a capability (again, in this case, PM) within the macro organization, you really aren’t trying to get everybody to “do” project management: you’re really attempting to get them to cooperate, or at least not defect in the technical program that you are pursuing. It then falls to reason that, in order to secure that cooperation, the implementation phase of the capability maturation program should act like Tit for Tat:

·         It has to be falling-off-a-log easy to plug-and-play.

·         “Retaliate” is a bit strong, but you must be able to identify and respond immediately whenever anyone directly associated with participating in the implementation effort attempts to defect.

·         If the participants are cooperating, then they are golden, even if they are sending you schlock data. Better data can be taught – cooperation can’t.

Following these three steps won’t guarantee a successful implementation, but they will maximize your odds of one. Of course, there are many other factors that can derail your efforts, but I believe having an overall strategy that incorporates these three will improve your chances significantly.

The use of structure in the technical approaches we select in addressing managerial problems allows us to solve recurrent problems with known successful strategies. Often these structures will accommodate analogous situations as well, and we can engage them with a similar expectation of success. But what happens if the new problem isn’t all that analogous, or if the structure is unsound in the first place?

The NBC variety show Saturday Night Live first aired in 1975, and is one of America’s longest-running television shows. It has met with considerable critical and financial success in that time, owing mostly to its mix of talented writers and performers. One week ago Saturday, on May 11, SNL was hosted by former cast member Kristen Wiig, who performed in several sketches as characters she had played during her time as a regular cast member. Her performance reminded me of the many ways that SNL’s tendency to be highly formulaic in their sketch writing has made much of the show, well, unwatchable. Here are some examples of what I’m talking about:

·         Any and all “Gilly” skits. “Gilly” is a mischievous little girl, played by Wiig. She does silly and destructive things, after which her father gravely intones “Gilly!”, and she replies “Yeth.” And, “yeth,” that’s the extent of these skits’ humor.

·         A staple of athlete guest-host, the skit where a sports team is in the locker room at halftime, and dialogue establishes that they are significantly behind. The guest host/team leader tells the story of a previous team that rallied under similar circumstances, having been inspired by some dopey song, a recording of which is played (and usually danced to). In my opinion, this template is vacuous and stupid.

·         Tina Fey’s “impersonations” of Sarah Palin, usually on the Weekend Update segment. These involve no jokes or traditional humor, with the New York City audience howling with derisive laughter at what are essentially nothing more than a string of mean-spirited mocks and insults. When the SNL writers couldn’t mock Palin for anything she had actually said, they made up something for her to say (“I can see Russia from my house!”), and then mocked her for that.

·         “Garth” and “Ann,” supposed folk-music recording artists who readily offer to sing on Weekend Update, but don’t have any songs at the ready. Instead, Fred Armisted and Kristin Wiig sit there and make up songs on-the-fly, while trying to sing the same words and melody. It was never funny, but now it’s foursquare in the Unwatchable category.

·         The skits where a new girlfriend is brought home – usually by Fred Armisted’s character – to meet his extended family, who all greet each other by excessive kissing, usually open-mouthed, even among brothers. Any sign of discomfort at this bizarre behavior comes as a shock to this family. Again, started out as simply unfunny, and through repetition has become unwatchable.

·         “Pig,” the Target cashier, also played by Kristen Wiig. Pig comments excessively on the items that customers purchase, and will go and fetch things for herself when they strike her fancy. Early versions would have a manager step in and announce “Classic Pig!” when Wiig would proclaim some improbable use for various items. Male guest-hosts are invariably shoe-horned in to the skit as stock boys with an unrequited crush on Pig.

·         Film shorts featuring Laser Cats. Cute the first time, not so much the second, and now unfunny and careening into unwatchable, no matter which celebrity is snuck in to the film short.

·         Lady Gaga’s film short on being in a threesome with Andy Samberg and another male cast member (I can’t remember which, ‘cuz it was unwatchable).

·         The “Secret Word” skits. A take-off of Password, Wiig plays the “celebrity” member of one team, but always says the word that her partner is supposed to guess. This “celebrity” is a washed-up Broadway actress who, when not blowing the secret word, waxes interminably about some previous part she had played. Started cute, but through repetition has become unwatchable.

Since Kristen Wiig appears in many of these examples, I’m tempted to reverse-engineer the structure that SNL writers employ and describe it as being characterized by a certain laziness of thought, with an expectation that Wiig’s timing and comic ability will make up for it. I don’t know – maybe there’s even a skit template library that the writers invoke when they are fresh out of fresh ideas. The point here is that, even in the most successful of franchises, structures and templates and canned strategies, even the ones that had perhaps lead to previous successes, can end up resulting in very poor management decisions.

Even on Saturday Night Live.

Building on last week’s blog, where I discussed the insightful framework posited by Carnegie Melon University’s Software Engineering Institute’s Capability Maturity Model®, I pointed out that the CMM®, while asserting the five levels that organizations go through when attempting to advance a given capability, didn’t do as good a job of showing how the organization advances from level to level. One book on this topic by Kim Caputo, CMM Implementation Guide; Implementing Software Process Improvement (Addison-Wesely Professional, 1998) discussed six steps that should take place in-between each CMM® level:

1.      You introduce the nature of the capability improvement to the macro organization,

2.      and then scope out the exact nature of the participant’s activities with respect to the capability advancement.

3.      Launch a pilot project, and (presumably) bring it in on-time, on-budget.

4.      Widespread group assimilation follows the pilot project,

5.      then institutionalization takes place,

6.      followed by an audit to see if you really have achieved the next level.

Now, Ms. Caputo readily admits that there is, in her words, a “chasm” in-between steps 3 and 4, with devastating results. If widespread group assimilation does not take place following the successful completion of the pilot project, the implementation team is forced to start over again, and re-introduce the capability being sought, re-scope out requirements for the actual participants, etcetera, etcetera. But here’s the catch – the implementation team only has two, maybe three bites at this apple before the organization just gets tired of hearing about the need for the particular capability enhancement, and tunes you out.

If I understand Ms. Caputo’s points correctly (and I believe I do), she councils enhanced communications among the implementation team members and those who decline to participate. By drawing out their unstated or poorly-stated reservations, she believes that the parts of the organization that are attempting to avoid contributing to the implementation effort can be persuaded to change their minds, and contribute. Frankly, I don’t agree – I’ve always felt the communications aficionados wildly overstated their techniques’ abilities to improve management.  It was during this time, when I was attempting to solve the problem of members of the macro organization electing not to engage to the extent needed for a successful implementation (a behavior Ms. Caputo calls “the silent veto”), that I had a key conversation with Bud Baker.

Bud Baker is a professor and the Chair of the Department of Management and International Business at Wright State University. However, before he got his high-falutin’ title, he was, like me, a columnist for PMNetwork magazine. Those were PMNetwork’s halcyon days, when the monthly columnist lineup included people like Professor Baker, Neil Whitten, John Sullivan, Paul Dinsmore, Deborah Bigelow, and me (needless to say – but I’ll say it anyway – PMNetwork’s columnist lineup is nowhere near this level of talent today, except maybe when Bud sends in some of his work). While wrestling with this crossing-the-gap issue, I spoke with Bud, who said the act of withholding the participation level needed to perform a given implementation was called “the slow roll” from his days of doing project management consulting for the United States Department of Defense. The organization targeted for the enhanced capability knew that there was a finite amount of energy behind the push for improvement and, if they could participate just enough to see the overall effort lose steam, they would be able to go on doing their jobs the way they had been, without appearing to be the reason the sought-after improvement effort failed. It was both insidious and perfectly predictable.

So, what is the solution to overcoming the dreaded Slow-Roll? The answer comes from a highly analogous situation from Game Theory, and is…

…coming next week (yeah, I know this is the second week in a row I finished with a who-shot-J.R.-style cliff-hanger, but it is a rather complex problem).

There is absolutely no truth to the rumor that I’m paying Cameron under the table to proscribe our monthly themes based on subjects that I’ve extensively researched while writing my books.

None whatsoever.

However, I am, once again, thrilled at the selection of Methods and Frameworks as May’s theme, because my first book, Things Your PMO Is Doing Wrong (PMI Publishing, 2008), was largely predicated on a project management adaptation of Watts Humphries’ seminal book in software management framework, Managing the Software Process (Addison-Wesley Professional, 1989). In it, Humphries introduced the concept of the Capability Maturity Model®, upon which Carnegie Melon University’s Software Engineering Institute® would base its further research on the subject. (Incidentally, in my opinion, PMI®’s attempt at adapting the CMM® to a project management environment, the vaunted Organizational Project Management Maturity Model®, or OPM3®, was just dopey. I was actually in attendance at a PMI® Congress where a member of the OPM3® committee was selling the inchoate mess to the masses. He actually said “We’re developing a structure that will allow people to go where they want to go.” And that was the intellectually insightful highlight of his remarks!)

The Capability Maturity Model®, or CMM®, posits that organizations seeking to advance a capability typically go through five “levels”:

·         Level 1 is represented by chaos. Everybody is doing their own thing, or nothing at all, so that, paradoxically, you can actually have areas of advanced expertise in a Level 1 organization.

·         Level 2 is very basic, but at least everybody is doing the same thing. Same forms, same process, etc.

·         Level 3 is known as “defined.” If the proverbial beer truck hits the heroes who got you to this point, then the capability advances your organization has enjoyed don’t unravel. The written procedures and training are in place to ensure that the macro organization’s capability doesn’t reverse itself.

·         Level 4, known as “managed,” is characterized by your organization being so darned good at the capability that you are in a position to export it to other organizations.

·         Level 5 – “optimizing” – nobody ever really gets to Level 5. Here, your organization is so good at the capability that you are routinely discovering long-standing problems in the industry.

Originally the CMM® was directed at the development of software projects, but other management science specialties and arenas took a look, and basically said “Hey! That’s exactly what happens when we’re trying to advance a capability in our areas!” And, before  you knew it, Carnegie Melon University’s Software Engineering Institute had patented, copyrighted, and just generally legally protected the daylights out of the idea (which is why I’m having to constantly insert the little ® symbol).

Now, the problem with the Capability Maturity Model®, brilliant as it is, is that it doesn’t actually tell you how to advance from Level® to Level® (think I’m being excessive? SEI actually made the word “level” a protected term in the model.). This is where I focused my research for the first book: assuming that the Capability Maturity Model® was applicable to project management, how does one actually advance from Level to Level? I discovered the answer quite by accident, hiding in the realm of Game Theory – specifically, the game entitled The Prisoner’s Dilemma, and its optimal strategy for resolution, Tit for Tat. The way it works is…

Oops! Out of room for this week. I’ll dive in deeper next week, but for the full analysis (and the surprising implications that stem from it), you should probably buy either of my books – or make comments on this blog page along the lines of “hurry up and get us the rest of the 411 on this stuff!”