TBM 229: Winnable and Unwinnable Games (Part 1)
Imagine a framework or a way of working as a game. I know there are limits to this analogy, but stick with me. Imagine an environment where the "game" makes sense, is challenging, and feels winnable. Playing those games is fun and rewarding, even when we don't win.
One of my key motivations for doing so many North Star Framework workshops is that the framework, with some effort, created a positive game. Teams enjoy autonomy and can link their work to sustainable business outcomes.
Consider the things that make a good game. Good games have
Clear, attainable goals that players understand
Maintain a balance of difficulty, ensuring challenges aren't overly easy or excessively hard.
Timely feedback and rewards boosting player motivation.
Engaging gameplay mechanics captivate players and sustain their interest.
Signs of small victories or incremental progress can motivate them. This could be through progress bars, intermediate rankings, or minor accomplishments.
Meaningful choices that impact the outcome, fostering player agency.
Immerse players in a compelling environment or narrative.
Calibrate progression and learning curves, promoting mastery over time.
Variety in challenges, environments, and mechanics keeps players engaged.
Social interactions, such as cooperative or competitive play, enhance the gaming experience.
Accessibility in terms of difficulty, controls, and inclusivity broadens the game's appeal.
High replayability ensures the game remains fresh and exciting for repeated plays.
Sounds fun! It makes sense that something like the North Star Framework with its mix of 1) actionable inputs, 2) balance, 3) aligned autonomy, 4) a sense of impacting the "big picture", 5) coherence, 6) the ability to set meaningful goals, 7) intellectual rigor, 8) practical application, and 8) difficult but doable by design…is a fun game.
Even better is when the team actively co-designs the North Star Framework game!
Unfortunately, many people devise games for their teams and companies that are inherently unwinnable, or winnable but not helpful or valuable to customers, employees, and "the business".
For some, it is a lack of experience; for others, different factors are at play.
Sensing a losing game
Experienced product developers develop a reasonably honed skill (some call it a spidey sense) about situations that are doomed to failure. They still fail—all the time—but do so less frequently and with less downside.
They sense that point where too many limiting constraints, too many drivers, and not enough floats almost guarantee failure. They know that either 1) you reduce drivers, 2) reduce limiting constraints, or 3) add floats, or 4) add ENABLING constraints…or the effort will fail with a very high probability. Ideally, our experienced protagonist would do those things and change the game.
If faced with this common but brain-bending game involving multiple teams, communication issues, and a lot of uncertainty and constraints:
…they would never commit ("say") to a deadline far off into the future ("do") unless they could drastically alter scope. Options might include: limiting work in progress, shaping efforts, limiting dependencies, asking A, B, and C to work together more closely, visualizing all the work in progress to understand constraints, committing to a thin slice across the effort, etc.
Experience tells us to change the game unless you are someone who benefits, like a program manager who loves chaos and watermelon charts.
Here's a webinar I did on drivers, limiting constraints, floats, and enabling constraints:
Playing losing games
However, even experienced product developers frequently agree to play unwinnable games or flip the game to something winnable but not very valuable.
Why? Some reasons include:
They are new to this particular game.
If they are new to a company, they might simply underestimate the thrash in store for them. "X said the dependency wasn't a big deal; how was I supposed to know that part of the org was in a mess?". It's easy to make this mistake.
They don't understand this particular game.
Even experienced people make the mistake of misunderstanding what led to the success of their prior environments. They may assume that because "accountability" and "ownership" were frequently discussed at [HealthCo] that success in the new environment is largely a function of accountability and ownership. "We just need to improve accountability and ownership."
Like any "just," this is likely only part of the picture. Experience is contextual. I always remind managers that they may not have the full picture, even if they've worked at some of the top companies in the world. Just because you worked at Google, Amazon, or wherever doesn't mean you understand what is happening anywhere you go.
They play the game in a low-trust / low-confidence environment
In a low-trust, low-confidence, or low psychological safety environment, our realistic experience product developer may choose to
Play an underpromise and overdeliver game they are guaranteed to win (but is not great for the business as it optimizes for internal low-trust, not customer value)
Adopt a framework with proxies like "story points shipped" or "sprint goals complete" that isn't optimal, but management buys in. In a sense, Scrum is designed to build trust in low-rust environments. It is a finely choreographed game of commitment, in which a team can play "play by the rules and demonstrate they can keep a promise" (regardless of the impact). This way of working isn't ideal for a passionate and experienced problem solver, but it might be the only option available.
Fight the system, eventually burn out, and leave the game for another.
Play the pragmatic change-agent game, focus on what they can control, and lightly nudge the system for the better for a few years.
Play the game everyone else is playing: say yes to everything, optimize for appearing busy while knowing nothing ever gets done, so there will be no repercussions. Grumble about planning activities but understand that no one trusts the plans anyway, so phone them in.
People rarely admit to playing #5, but it happens. It's just not worth arguing.
There's a wicked loop that makes #5 "stick":
It is one thing to have experience. It is another thing to walk into a NEW, low-trust environment (where people may also have flawed mental models about product development) and figure out how to change the game without cooking yourself. It wasn't like Satya Nadella was walking into a new organization with no software development chops and no formal authority! And that was STILL really hard. Imagine if Nadella were to walk into a company with no development, product, or operational chops. Would he succeed? I'm not sure—a skilled PE firm might do a better job of achieving a successful—but uninspiring—outcome.
In effect, this is a new, very difficult game—the "try to fix a low-trust and low-confidence environment" game or the "try to get stuff done regardless of low-trust and low-confidence" game. All the while playing the "stay employed and hopefully semi-enjoy my job" game.
Game Clashes
It is vital to understand that at any given company, at any given moment, many games are being played. Those games are being played and redesigned continuously and clash frequently.
Examples:
The leader that waltzes in and asks, "I'm not sure what all the fuss is about; why didn't you align with that other team?" sees the game differently. They see dependencies as negotiable and their peers—the leaders of those other teams—as influenceable. The front-line folks listening may be unable to play that game (or think they can't). They tried in the past and were called "complainers".
The engineering manager who sees development as primarily about promising and finishing predefined projects will perfectly play that game, even if it isn't ideal for the company or customers. The inexperienced developer, filled with passion and hope, gets confused. This wasn't the game they signed up for (in their mind). They think it is wrong, but their manager is confident that this is the real world. "Please leave interacting with customers to the product manager; otherwise, we will get dinged for missing deadlines," the manager argues.
Some of the biggest names in tech are known for what amounts to "promotion-driven development" (PDD). The basic idea is that "talented people want a project that is completely within their control, and then be left alone to finish it and get a promotion." Projects are selected based on promotion-friendliness and doled out by engineering managers. Contrast this with teams that see the game as a team game and the game's goal as truly helping customers—big difference.
Each of these examples shows a clash between games and the perception of games.
In any work environment, you will experience a clash of games.
The Puzzles
This leaves us with a couple of puzzles (meta-games even?)
How to design the best game for a given context, assuming a healthy situation
How to introduce the right game in less-than-ideal circumstances
How to resolve a clash of games
If this interests you and you want me to continue this exploration, please leave this post a ♥️. I will write a Part 2, Part 3, and Part 4 if there is enough interest.
Thanks!
You have described my day job without even seeing my day job.
Please do write the rest... Pretty insightful stuff!