Product tools have created a leadership crisis. Only tools from the outside can solve it. | by Pavel Samsonov | Mar, 2024


Moving beyond rote expertise

“Adaptive expertise is not something that can be taught, but rather something that has to be cultivated.” ―Lieven Verschaffel

Indeed, there is another field that is analogous to product development in this way. It also started in the 70s. It also experienced a radical change to the status quo in the early 2000s. It also features small groups who get together every week or two and follow instructions from a monoculture rulebook that is periodically reissued with minor changes. And just like product development, this group has a shared but ambiguous goal.

Instead of “make valuable software” that goal is “have fun” — but how to accomplish that goal is no less contentious among Dungeons & Dragons players than “how to make good software” is among tech professionals.

Just like the rules that govern product development (Agile, design thinking, and so on), it is possible to learn the rules of D&D by rote. But despite that, you can still fail at achieving the goal of having fun playing D&D, just as you can still fail to ship good product.

That’s because in addition to the rules that are written down in books, there is a second set of rules.

Those are the rules for how to apply the written rules to make fun happen. There’s no rulebook for these rules. They evolved organically alongside the written rules over 50 years of rolling dice, passed on from player to player. These rules are not prescriptive nor enforced by a computer, but heuristic and negotiable.

Pace layers diagram. Fashion (the top layer) weaves at random, while the following layers more progressively more slowly in a consistent direction: commerce, infrastructure, governance, culture, and nature.
The rules of D&D get rewritten every few years. But the rules of how to use those rules live deep down on the culture pace layer and evolve much more slowly.

The unwritten rules are impossible to learn by rote. Players must develop adaptive expertise to use them effectively. And studying how they achieve that expertise is very helpful for examining tech’s own, unwritten relationship with our written rules.

Enabling constraints only work if you know what you want to enable

“The fantasy that RPGs allow programmers to experience is not wealth or power, but being able to complete a quest from start to finish without the requirements changing.” — Anonymous

This second set of rules evolved because, just like product people, D&D players love written rules. A lot. D&D players see their rules as enabling constraints that structure the way they collaborate on a story about slaying some dragons, rather than leaving that collaboration up to chance.

Unfortunately, these rules also contain a very simple reward loop, of the type that most games have. It provides almost immediate feedback: if you are good at applying the rules, you can slay more dragons, and get more power, which you can use to slay stronger dragons. For some players, being good at the rules quickly (as early as 1986!) became more important than the part about having fun.

This is the same reward loop that exists in all “tools for not-thinking:” they tell you what to do, then you do it, and get to feel good that you did it right. But letting your tools define your goals always creates problems. In D&D’s case, the rules were so focused on fighting that the reward loop was actively pushing players towards behaviors that made the game less fun.

And so the players did something that product professionals should strive to emulate: they decided that the rules weren’t in charge of their fun.

This can best be encapsulated by what’s colloquially known as “Rule Zero:” no matter what their book says, the Game Master decides how (or if) to apply the rules. As they attempt to govern the fiction within the game, all Game Masters become game designers by necessity — all the way back to the very first GMs who cribbed the rules from another game entirely and beat them into shape to have fun in the way that they wanted.

A side by side of Product’s “rulebook” (Learning Agile from O’Reilly Media) and Advanced D&D 2.0’s Player Handbook.
The rulebooks tell you what you could do, but they can’t tell you what you want to do.

But even Rule Zero exists within a broader social contract that prevents GMs from abusing that ultimate power. What fun means can differ radically from table to table, and what rules help the group have fun in that way is a conversation that is always ongoing.

And so, when a D&D group sits down at the gaming table, they do so for a common goal and with a common approach designed to achieve that goal. The very definition of a team.

Stop working for your tools, and make them work for you

“You are what you do. Choose again, and change.” — Miles Vorkosigan

Product professionals (whether designers, PMs, or developers) would do well to take away the same lesson: we ask too much of our tools. Doing perfect Agile will not produce good software, but that’s not Agile’s fault.

A lot of people ask me, what should we use instead? My answer is always: use your brain.

It is simply not possible to produce a methodology that works like a tool for not-thinking. Trying to be “tools-driven” with “best practices” is as much of a mistake as trying to be “data-driven” and outsourcing your decisions to a computer. No software, framework, or language model is going to make you immune to sloppy thinking, ambiguous framing, or “check the box” attitudes. Only a culture of ownership can do that.

Your tools aren’t responsible for your goals. You are. Trying to outsource your thinking to tools is an abdication of leadership. A leader sets the direction based on what is desirable, not on what tool is closest to hand. If you see the need to do one thing, and the tool wants to do another thing, trust yourself over the tool.

This is the only way to advance from rote expertise to adaptive expertise and get out of the commodity game.


Source link

2023. All Rights Reserved.