Dungeons & Developers

How to simulate tricky conversations.

December 1, 2022 • 4 min read

You open the door and see three orcs. They’re seated at a fine oaken table watching a glowing rectangle on the west wall, which displays the ominous text “2023 Strategic Planning”. The orcs look up at you, and one says “You’re late.”

What do you do?

Depending on your perspective and experience, the idea of roleplaying may fill you with excitement or dread. Given that, you’ll be either delighted or horrified to learn that roleplaying is a powerful tool in your career development toolbox, and you should be using it more often – just don’t call it roleplaying.

DALL-E is unsure what orcs look like, exactly.

You see, in software, we solve most of our problems with iteration and experimentation. We build most of our skills likewise: trying things, reflecting, and getting better. In a loop. It works pretty well!

Except sometimes it does not. Sometimes you have high-stakes situations that occur infrequently. If one of your reports is invited to give a presentation to the Board of Directors, they could try winging it. Maybe after a few years, they would eventually get good at giving these? You know, in theory – if they ever get invited back after that 15-minute digression about dependency resolution mechanisms.

Now, if your high-stakes task is to produce an artifact – a slide deck, an architecture, that one pin that holds the whole helicopter together – then you can get other experts to verify your result, making sure it’s sufficiently excellent. Yay teamwork.

However, if your critical task is a one-time deal – a difficult conversation, a delicate surgery, landing on the literal moon – then you’re gonna want to practice. You’ll want to simulate the task enough times that you can get good at it before you’re actually, you know, on the moon.

In the context of product development, most of our high-stakes one-time tasks are social. We may need to deliver some hard feedback, convince a great talent to join the team, or negotiate a more realistic project timeline. Although you can rehearse the monologue portions of these situations alone, even the best monologue is a limited tool. It’s usually more helpful to practice these as 2-way discussions.

Enter roleplaying simulation.

Okay fine, I’m talking about roleplaying here. But a big subset of people are going to freak out and get all in their heads if you propose roleplaying. So propose simulation. You’ll be surprised how well people take to the opportunity.

Running a social simulation doesn’t need to be complicated. Choose a situation that your teammate wants to level up on, then try this simple workflow:

  1. Write 2-3 paragraphs about a scenario for the participant. This sets the context for the situation they’ll be practicing, and a goal (e.g. delivering the bad news and negotiating a new project timeline.)
  2. Write a few bullet points for yourself, about the mindset of the person you’ll be playing simulating. This might include questions they’d ask, objections they’d have, or answers they may provide if asked. Most importantly, note what their top priority is in this scenario – what do they want? (e.g. shipping on time, getting a certain title, an apology, etc)
  3. Run the simulation. Explain that it’s not a test, you should try to stay in character, and save analysis and discussion for the end. If it’s a video call, prefer recording it so the participant can rewatch if they like.
  4. Debrief. Let the participant recount how they think things went first, and what they might do differently next time. Keep things positive, especially if they’re feeling a bit nervous or flustered.
  5. Start easy for your first go. Even just practicing the “happy path” can really help folks’ confidence. Once a round of simulation has gone well, you can add curveballs or other levels of challenge to your next run.

Of course, simulation can go far beyond a 1:1 roleplay social coaching session. In Serious Professions like healthcare, military, and aerospace, simulations include whole teams of people with equipment, scripts, and branching rules about how things might play out.

Luckily for those of us in software, our work is typically lower stakes. We can build most of our skills with reading, experimentation, reflection, and the occasional simulated high-stakes difficult conversation.

Next time somebody on your team is facing a challenge that merits it, break out the Dungeon Master’s Guide this blog post and give it a try.

Latest in the series Building Teams.

Liked this? Follow along to see what's next.

© Allen Pike. You can find me on Twitter, contact me, or check out Steamclock.