Game Theory in Management

I’ve been seeing quite a few articles on the topic of how Artificial Intelligence (AI) is becoming dangerous to we humans, and something must be done, or else we’re likely looking at a dystopian future.

Yeah, I’m not buying it. And GTIM Nation shouldn’t, either. Here’s why.

Consider first of all that a computer that doesn’t (or can’t) run software is useless, the proverbial “boat anchor.” The whole reason that the things exist is to run software. True, many (too many?) modern appliances have microprocessors in them, and perform things that would be considered impossible a mere fifty years ago, but that’s a mixed blessing. I’m glad my refrigerator’s ice maker knows to stop making ice when the dispenser container is full. I’d be happier still if it would stop trying to make ice when a big clump forms in the device that pushes the cubes into said dispenser container, rather than creating a mass of ice capable of sinking ocean liners, necessitating a long and highly irksome defrost cycle and resetting process.

Let’s now turn our attention to the only other possible culprit in this whole AI-will-destroy-our-lives scenario, the actual software. What is software? It’s a series of instructions that the machine obeys.

That’s it.

What software is not is a nascent brain-like entity on the brink of self-awareness and, yes, intelligence. Let’s take a look at a couple of news stories that would seem to challenge my definition. The first comes out of China, and … well, I’ll just let Debapriya Bhattacharya’s   words speak for themselves:

BEIJING, CHINA: A humanoid robot was caught on CCTV camera "coming to life" and attacking a person in front of it, who is assumed to be its handler, in a factory in China, the Daily Mail reported on Monday, May 5.[i]

I do not know whom Debapriva was quoting with the phrase “coming to life,” but I can assure everyone that this industrial robot absolutely did not come to life. It is literally as dead as a door nail, unless one is using the term “live” in the electrician’s sense when referring to an energized circuit. It is simply a computer that processes instructions, in this case instructions on when to activate certain servos that allows it to manipulate whatever it’s supposed to be manipulating. Rather than “coming to life,” it was simply activated, and began executing its instructions when it should not have been doing so. It wasn’t attacking the workers in front of it – it was simply, again, activating servos in its mechanical – I don’t want to say “arms,” because I’m sick to death of these things being anthropomorphized – hinged extensions. If those two people weren’t standing there at the moment the thing was activated, there would have been no “attack.” It would have been a mechanical device thrashing about. It’s analogous to a trip I took with my wife and sons to Padre Island, Texas, in my 1986 Cadillac DeVille. While still a couple of hundred miles out, the car started acting odd. It would rev at high levels when I first started it, and the throttle response felt off. I made it the rest of the way to Corpus Christi and, after checking the fam into the beach hotel, took it to a Pep Boys in town. (Shout out to Pep Boys in Corpus Christi, Texas – you guys rock!) They quickly diagnosed that the problems were being caused by a faulty throttle positioning sensor – when the car was idling, the TPS was telling the car’s computer that it was about to stall. The computer did what its programming told it to do, namely, push more fuel into the intake manifold, but even this response was being mis-reported back to the computer via the faulty sensor, leading to more erratic motor behavior. They simply switched out the TPS, and sent me on my way. Notably, I did not take the opportunity of this event to assert that the car’s computer had attained self-awareness, and was about to take revenge on me for not strictly observing oil change intervals. It didn’t “come to life,” or “attack” anything. It was simply executing its programming. Now, if that programming included instructions to “ram yourself into the nearest tree” upon receiving an anomalous signal from the TPS, that’s still not the car attaining sentience. That would be the fault of whatever programmer added such an idiotic instruction.

Next, from CIO, we have an episode from April 2016:

Microsoft released Tay, an AI chatbot, on the social media platform, and the company described it as an experiment in conversational understanding. (snip) Within 16 hours, the chatbot posted more than 95,000 tweets, and those tweets rapidly turned overtly racist, misogynist, and anti-Semitic. Microsoft quickly suspended the service for adjustments and ultimately pulled the plug.[ii]

As touchy as this episode is, I’d like to make an analogy to a person who is travelling via starship to a planet where the advanced inhabitant’s language consists of color-coded graphics. Upon arriving, these inhabitants hand our intrepid explorer what we would call a Rubik’s Cube and, by motioning, indicate that they wish it to be manipulated. Wanting to please these advanced inhabitants, the explorer makes several changes to the Rubik’s Cube, and hands it back to them, whereupon they react with extreme umbrage. Your specific Rubik’s Cube “communication,” it seems, has touched upon one of their taboos, and they now hate you and the entire civilization you represent. How is this analogous? I can guarantee that Tay AI did not “understand” the context of the words and phrases it assembled when asked for a response, much like our interstellar explorer. It merely scans available text associated with the original ask, and assembles a response based on patterns it encounters during such searches. If its programmer(s) had included an error trap to ensure that it never replies with a text construction that engages in (or even references) racism or anti-Semitism, this, like the “awakened” Chinese industrial robot’s “attack,” never would have happened.

Now, to the crowd insisting that “something” must be done with respect to AI, let me offer this suggestion: if you replace the term “AI” with “bad programming,” I’m all on board. Poor programming, especially those lists of machine instructions that allow for open-ended responses to (perhaps invalid) parameter inputs, is extremely dangerous.

But it’s not AI. It’s deficient programming.

[i] Retrieved from https://news.meaww.com/terrifying-video-of-humanoid-robot-waking-up-and-attacking-its-handler-goes-viral on July 8, 2025, 19:48 MDT.

[ii] Retrieved from https://www.cio.com/article/190888/5-famous-analytics-and-ai-disasters.html on July 10, 2025, 19:26 MDT.

I’d like to continue to address some of the implications of one of the Scenarios I discussed in last week’s blog, where a “sustainable” organization (i.e., one that stays in business over an elongated period of time) does so despite having pathologies in its business model. Either because of government intervention resulting in near-monopolistic circumstances, or due to the possession of some intellectual property, talent, or material that’s unavailable to competitors, such an organization can stay viable despite committing what we in the PM World would hold to be management science blunders. Consider what happens to the younger employees, particularly those that end up advancing in this organization, when they end up being hired elsewhere. What experiences shape their managerial viewpoints, and business strategy formulation? Will these experiences be applicable to their new environs? Will they even be valid at all? Based on the frequency with which I have encountered the phenomena, I’m guessing that almost all of GTIM Nation has encountered a manager who will reminisce about “how things were done” back at their previous company, especially and particularly if that previous organization is well-known, profitable, or well-known for being profitable.

About All Of Those Time-Travel Movies…

I happen to believe that time travel is an extremely lame plot device, but many of the movies that feature them have one thing in common: the protagonist(s) seeks to go back in time in order to correct a mistake, made by them or another, in order for things to be “set right” once they return to their original time. I think something similar happens when managers advance in their careers, and assemble a kind of codex of management decisions and their ultimate results. Management tactics or strategies that, once employed, result in poor (or even catastrophic) consequences are typically removed from these managers’ repertoire, akin to fixing a previous error, whereas successful management techniques are remembered as such, and only await similar circumstances or environs to be re-attempted. Having had experience forge their management strategy technique collection so, it’s only natural that, when introduced to a new organization, these will employ what they “know” to be successful, and stridently avoid repeating a mistake.

But there’s the rub. Often lacking a complete understanding of the nuances of their new management environment, such managers may employ tactics that are utterly inappropriate for their new circumstances, resulting in chaos, friction, and, often, failure. When such failures occur, these managers tend to blame the organization, typically pointing to an inchoate “reluctance to change.”

This phenomenon is so prevalent that it’s become axiomatic that, when a new upper-management team is introduced into any organization, demonstrated loyalty to the new technical agenda becomes the coin of the realm. Any challenge to the new management approach can be seen as disloyalty, no matter how well-intentioned or ultimately accurate such challenges may prove. Abysmal management flourishes because those introducing the new agenda have insufficient appreciation for the differences in their new circumstances, and anyone who dares to point this out may be tagged with the disloyalty perception, often leading to severe career damage.

Adding to and accelerating this toxic cycle is the easy blaming of these “disloyal” team members when the new, poorly-considered management style proves to be, shall we say, sub-optimal. The new executives weren’t in error, oh no! It was the host organization’s “unwillingness to change.” Very convenient.

I’ve seen this exact scenario play out more often than I care to count. The upheaval, the unnecessary conflict, the elevation of the slick politically-savvy or overtly docile team members over the genuinely talented happens over and over, resulting in a thwarting of the natural business tendency of merit to trump conniving (or, in Maccoby archetype parlance, the Jungle Fighters are getting the better of the Craftsmen[i]). As this “sustainable” organization continues on in spite of the pathologies in the business model, the breeding-of-bad-managers effect quickens, as the truly talented will be the first to find an alternative, leaving behind the politicos, dociles, and newbies to fill in the management structure. The newbies will look around them at the dead-handed “success” of the organization, observe the workings of the business model (if partially, as it impacts their specific job), and be inclined to believe that the former is caused by the latter, entering their future managerial codex and awaiting the opportunity to manifest if and when a leadership role becomes available.

In extreme circumstances, the non-merit-based and yet sustainable organizations become long-term producers of just straight-up bad managers. If you are not a Jungle Fighter, but find yourself in such an organization, you might try to correct things, but that’s generally not a winning strategy. It’s probably best to simply recognize what’s happening around you, and guard against employing those management strategies in your future PM opportunities.

[i] See Maccoby, Michael. The Gamesman: The New Corporate Leaders. New York: Simon and Schuster,1976.

Returning to my take on the topic of sustainability from the strictly management science viewpoint, a little bit of Game Theory readily reveals that sustainability for its own sake is not always a good thing. And that little bit of Game Theory comes in the form of the Game Theorist’s favorite analytic tool, the Payoff Grid. Consider that, for any business, two factors will determine its success or failure: whether or not there is a demand for that business’ goods or services, and whether or not the selected business model is workable. For the sake of the grid, let’s posit extremes for both axes, so that there’s either demand for that particular business’ goods or services, or there is not. Similarly, the selected business model is either optimal, or rather poor. Yes, I know that in the real world such things are rarely so clearly defined – Boolean, even – but stay with me. The resulting Payoff Grid would look like this:

In Scenario A1 we see superior management in a market where there is low (or even non-existent) demand. If there were few or no customers to attract in the first place, then high-quality management can’t save such an organization. Similarly, in Scenario B1, not only are there few customers, but in the off chance that one accidentally contacts the business, their experience will likely ensure such interactions are brief. Still no absolute guarantees, but a well-managed organization in a high-demand market is almost guaranteed to succeed, at least in the near- to mid-term, meaning that it’s sustainable. It can be expected to maintain an acceptable return for its shareholders while keeping its customers and employees happy.

All of which leads us to Scenario B2, where a poorly-managed organization finds itself in a high-demand market for its goods or services. An unfortunate connotation that often accompanies the word “profit” is that it comes only at the expense of some other person or organization, but I don’t accept that associated connotation. I think a better way of looking at profit, at least from the macro-economic perspective, is that it’s signaling to the rest of the economy a need for that particular good or service, thereby deserving of more resources being diverted from lesser-needed things, and towards the profit-making ones.

Like many Americans, I live within walking distance of a “strip mall,” a row of retail businesses located in the same building. Several of these store fronts have changed hands over the years, with some of the changes being somewhat dramatic, from food service to electronics repair, video game arcade to dry cleaners, and so on. It’s a classic example of “creative destruction,” in that, once, say, the video game arcade failed to make enough money to pay its rent and other expenses, a dry-cleaning business was ready to use the same space in order to deliver a very different service. The proprietors of the dry-cleaning business probably did not care if the previous tenants fell into Payoff Grid Scenario A1 or B1, only that their business didn’t meet the same fate. Competition in a free market economy is like that. If, through ignorance or vice, management allows pathologies into the business model, the outcomes are typically as brutal as they are foreseeable.

But that very creative destruction is thwarted when the situation is best categorized as Scenario B2, where the organization remains sustainable even when the business model contains significant errors, if not pathologies. When this Scenario unfolds, it’s almost always because of some extraordinary factors, such as pertinent laws allowing for a monopolistic effect to take hold, or the particular good or service being only obtainable from a rare material or talent that the subject organization has obtained exclusively. In the short- to mid- term, such organizations are, indeed, sustainable, in that they are generating income over and above their fixed and variable costs, and appear to be positioned to do so over the long-term.

But such appearances can be deceiving. How happy are the customers? And, perhaps more telling with respect to business model pathology detection, how happy are the employees? Organizations that accept (or even welcome) employee feedback, particularly in the realm of improving business practices, are far more likely to succeed than those businesses where a heavy-handed, top-down dynamic and communication style exists. Nepotism, indeed all forms of favoritism that steer decisions on employee’s placement within the organization, can flourish if circumstances conspire to keep the poorly-managed company profitable in spite of such flaws. In this specific Scenario, “sustainability” is actually enabling such business model pathologies to survive, or even proliferate in the minds of those who begin to associate them with the very success that they experience.

So, yeah, generally speaking, sustainability is great to have when it’s achieved through an optimal business model encountering a high-demand environment. Otherwise, it can be, shall we say, problematic…

With ProjectManagement.com’s June theme of “sustainability,” it’s perfectly understandable that many of the contributions are going to be centered on environmental issues, and that’s okay. I have absolutely no intention of challenging those ideas. That approach, however, is not how I see this topic.  Instead, I want to show how “sustainability” ought to be achieved within the management science structure of Project Management.

But first, what, exactly, are we talking about when we discuss “sustainability?” In the management sense, it means to construct and maintain a business model that continues to earn a profit over the long-term. To the extent that such an organization improves the lives of not only its customers, shareholders and employees, but also the community around it is certainly a plus. But even the most community-friendly company can’t go on for long if it fails to turn a profit, meaning, definitionally, it is not sustainable. To be sure, many organizations developed and kept in place business models with serious flaws, and somehow stayed afloat, while others executed relatively pathology-free models, but failed nevertheless. I think it’s fair to assert, however, that central to “sustainable” management, Project or otherwise, is to make the decisions that keep the organization viable over the long term.

Okay, so how does one go about doing that?  It occurs to me that this is right down PM’s alley, in that organizations only make a profit in a free-market economy if they have customers willing to give them money in exchange for their goods and services. And this is where PM assumes its front-and-center role, in that it’s PM’s techniques and approaches that are centered on monitoring cost and schedule performance against a defined scope baseline, all three of which are typically set by the customer, and all three are germane to PM.

Now, I understand that such an assertion runs contrary to the narrative propagated by our friends, the accountants, and taught in business schools across the land, that the point of all management is to increase shareholder wealth, but even here an insight presents itself. Even the Asset Managers will maintain a managerial duty to shareholders, not stakeholders. The latter category may attempt to assert veto status over the project’s completion, or even existence, but the fact is that, again, in a free-market economy, a contract between a client and the organization executing the project legally binds those two entities alone, assuming, of course, that the project is carried out consistent with applicable laws. This is true even when outside stakeholders attempt to lay claim to some moral or intellectual high ground. If the project’s scope is perfectly legal, as are the methods and resources used to attain its completion, then no third parties should have a say in whether or not the project ought to proceed to completion. To try and manage otherwise would be to subject one’s Project Team to the business world equivalent of the “hecklers’ veto,” essentially placing at significant risk any but the most anodyne projects from the outset.

Of course, I am aware that such assertions run directly contrary to my second-favorite target of criticism (after risk managers), the Communications Managers, who often maintain that all stakeholders should have a say in the technical direction and/or implementation strategy of projects. But beyond the validity of the cliché that too many cooks spoil the broth, it’s been my experience that allowing self-identified experts or stakeholders to add requirements or scope that can hinder (or even prevent) a given project from being executed on-time, on-budget is almost always a bad idea. Think about it: do these additional stakeholders have anything to lose if the project fails to come in on-time, on-budget? Indeed, in many instances these have something to gain from your project failing to come to a successful completion, if nothing else for the sense of empowerment that comes from thwarting an effort they perceive to be immoral or unethical. Again, I’m not even going to address the basis for determining whether or not a given project really is immoral or unethical – I’m just saying that, from a purely management science point of view, improving one’s PM technique can only have one rational goal, and that’s to improve the rate at which your projects come to a successful conclusion, thereby enriching the lives of your Project Team, your organization, your customer(s), and even the macro economy. Imagine how the business world would improve if we were to see a dramatic decline in the staggering percentage of failed projects documented in the Forbes article “3 Main Reasons Why Big Technology Projects Fail – & Why Many Companies Should Just Never Do Them.”[i]

For these reasons (among others), I have no problem arguing that the path to sustainability runs through PM.

[i] Retrieved from https://www.forbes.com/sites/steveandriole/2021/03/25/3-main-reasons-why-big-technology-projects-fail---why-many-companies-should-just-never-do-them/ on 9 June 2025, 19:42 MDT.

I’m the fourth of five children, so I know first-hand what a pain older siblings can be. Since they’re older, they tend to have a significant physical edge, at least until puberty comes along, meaning that, if any conflict turns into an actual scuffle, they will almost always win. The outcome of any confrontation was virtually guaranteed to not be decided in my favor, no matter the merits of my position. Some other burdens of having multiple older siblings, at least in my observation, include:

• When the parents go out for the evening, the oldest sibling remaining at home was “in charge.” Fascinating how being temporarily “in charge” bestows on an older sibling the ability to utterly change the foods that may be consumed, television shows that may be watched, or even bed times.
• Prior to even considering buying new clothes, any and all potential hand-me-downs must be evaluated and proven utterly unworkable before such purchase and, no, failing to fit properly is not an accepted reason for committing to new clothes purchases.
• Want to “ride shotgun” (meaning to occupy the family car’s front passenger seat if one of the parents isn’t in the car)? Forget it. Even “calling shot gun” first isn’t usually accepted if you aren’t the oldest travelling child in this situation.
• Statistically, only- and oldest-children tend to perform highest academically, and a strong majority of Nobel Prize winners are either only or oldest children. Why does this matter? Ask anyone who’s been there what happens when you present your report card to your parents, and it is notably inferior to your older siblings’ when they were at that grade level.

Don’t misunderstand, I’m not complaining at all. I perceive all of my older siblings as wonderful, brilliant people, for reasons which I’m sure will come to me. But they do tend to tilt life’s playing field before you even have a chance to run down the access tunnel.

Meanwhile, Back In The Product Project Management World…

Many Management Science historians will trace the genesis of Project Management to Product Management, as originally developed (formally, at least) by Proctor & Gamble, in 1931[i]. The “51331” memo, penned by Neil McElroy, proposed a new management role for a “brand man,” the person who would be responsible, not for the processes involved in creating a given product, but for the product itself.[ii] This shift in managerial focus would (obviously) have many long-term effects, eventually bringing about its ideological sibling, Project Management. So, having this sort of genesis is totally cool, right? We’re all just one big, happy Management Science branch of the same family, right?

Well, no.

For starters, Product Management is largely free of, in my opinion, the deadliest foe of Project Management, namely, scope creep. Products are what they are: if the consumer wishes to buy it, they will, and if they don’t, they won’t. It’s that simple. On the other hand, Project’s Scope Baselines describe something that has yet to come into existence. If the customer is paying a contractor for this to-be-realized scope, and it doesn’t look like what the customer intended, the contractor can be pulled in to court for remedy. And, if something changes with respect to the original understanding of the scope, the contractor has to write, submit, and hope to have approved Baseline Change Proposals (BCPs). Clearly there’s no equivalent in the Product Management side of things, due to the aforementioned take-it-or-leave-it character of the transaction(s). So, while a staggering number of Projects fail due to Scope Creep, our older theoretical siblings, the Product Managers, end up looking great by comparison, since they never have to deal with that particular business model pathology.

Then there’s the whole deal on how Project Managers (typically) attract business as compared to Product Managers. Consumers in free market economies can kvetch endlessly about television commercials and other forms of mass marketing, but the fact of the matter is that such promotions pay for an awful lot of (if not the majority of) produced entertainment. Project Managers, on the other hand, usually must assemble a proposal team to address a Request for Proposal (RFP), which is characteristically awarded to the organization that can convince the client that their Team can deliver the requested scope for the lowest price of any of the RFP respondents. Besides this anxiety-producing aspect of the business-attracting function, in the contractor organizations I’ve worked, the Subject Matter Experts (SMEs) on the Proposal Team are rarely paid for their time. These are expected to put in free overtime after they’ve worked their current Projects, since their time can’t be charged directly, and indirect accounts are highly scrutinized and seldom lavishly-funded.

“Mom always liked you best!” was Tommy Smother’s famous line to his (actually, younger) brother Dick. I’d like to adapt it to Project Management’s ideological older sibling, Product Management, thus: The Business World treats you better than it treats us!

[i] Retrieved from https://mspm.cmu.blogs.elliance.com/2020/05/13/51331-the-origins-of-product-management/ on May 24, 2025.

[ii] Ibid.