This is part II in my series Lessons from the Tabletop: Things I’ve learned about project management from Dungeons & Dragons*. Read Part I here.*

Game masters also have an inside joke: “No plot survives contact with the players.”

When I attempt to drive the plot, dictate the player options and the pacing, the players begin to disengage. The same thing happens on teams when a leader begins to white-knuckle the steering wheel.

A Glimpse Into the Story Link to heading

The heroes are facing almost certain doom.

Upon entering a room full of bones, they catch a glimpse of the artifact they seek. But it turns out to be a fake. And then the bones come to life.

I’ve invested a lot of time preparing for an epic and climactic battle. I spent at least 6 hours preparing this scene, arranging scores of skeleton miniatures.

It is our first hero’s turn to attack…

I wait for them to tell me how many feet forward they’d like to step and which spell they’d like to cast.

Instead, they announce that they’d like to use one of their abilities to teleport the entire party away from the combat… My head rolls in exasperation.

No plot survives contact with the players.

Lesson 2: Knowing When to Let Go Link to heading

As GM, I could have easily hand-waved a reason for the teleportation not to work. I could have forced the players to follow my plan that I had so carefully prepared.

But that would have deprived my players of agency. In the game, my role is to provide challenges — ideally at the edge of achievable — and it is my player’s role to provide solutions. Just because I haven’t anticipated a solution doesn’t make it the wrong solution.

I quickly dismantled the battle scene that I had spent so long creating, and we move on. In the end, it’s one of the most dramatic and satisfying sessions of the entire campaign.

(Of course, I didn’t let them get away completely — but used the teleportation as a way to take them out of the frying pan and into the fire. The analogy for professional life breaks here.)

Even with the god-like powers of a game master, I cannot create a compelling narrative alone; The players drive the plot as much or more than I do. And the party often goes places I never expected — which is fantastic.

When this happens sometimes I can adapt on the fly, appropriating whatever material I had prepared for what I thought would happen. Often though, I end up discarding carefully prepared material in order to go with the flow.

I just have to let it go. Something entirely new and unexpected happens. The story is better for it and the sessions are more fun.

The Solution is Trust Link to heading

Being willing to let go is crucial to success with a team. But it certainly isn’t easy. We get attached to our work, our ways of doing things, and even (especially!) our opinions.

New priorities caused by external events (or internal ones) can necessitate letting go of carefully crafted plans and schedules. New requirements can mean discarding days or weeks of work.

This is ok.

As I wrote in the last piece about goals, it is important to stay focused on the overall objective. A truly agile (not Agile) team must be able to check their egos and find a new path forward even when the landscape shifts.

So how can you foster this open, ego-free collaboration and problem solving?

One key is psychological safety. HBR has written on the importance of psychological safety in the workplace.

At my tabletop, our psychological safety comes from the knowledge that we’re all friends and all only acting out a story — and even then, egos can flare and clash.

On a professional team it is even more difficult to maintain trust and psychological safety. We must repeatedly remind ourselves and our team that it’s ok for anybody to:

  • Make mistakes.
  • Admit (and own) mistakes.
  • Offer a perspective or opinion — anytime.
  • Offer challenges or objections, while avoiding shaming or blaming.
  • Discard work or change plans to accommodate new requirements.

On my own teams, I like to use the mantra “Problems are ok, surprises are not.” as a quick encapsulation of these permissions.

How do you foster an environment for open collaboration?

This is Part IV in “Lessons from the Tabletop: Things I’ve Learned About Project Management from TTRPGS”: