TTRPGs are a case study in how to engage with systems at a higher level. They show us that success doesn’t come from knowing all the rules—it comes from knowing what you want out of them.
“We shape our tools, and thereafter our tools shape us.” ―Marshall McLuhan
Tech has an unhealthy relationship with tools: we use them to define our goals.
On the surface level, software tools homogenize our thinking; we reach for the solutions that the tools we have at hand are designed to create. But tools for the mind are even worse: our methodologies, frameworks, canvases, and processes succumb to what John Cutler calls the Way of Ways until they replace the initial goal entirely. The mission statement inevitably shifts from “make good software” to “follow the method” with predictable results.
I don’t want to pick on Agile too much — it’s not Agile’s fault. The problem is not with frameworks — it’s with a lack of leadership necessary to define goals beyond “follow the book.” This keeps happening, and will continue to happen until leaders start doing things differently.
But if changing tools and frameworks is not the solution, what is? What can leaders do differently?
In this situation, a user researcher would study analogous domains to see what lessons we can learn from a field with a similar dynamic.
So let’s take a little detour out of tech.
Watch your step.
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.
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.
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.
Product tools have created a leadership crisis. Only tools from the outside can solve it. was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
