Build a DRT

Requirements

  • People: 3-12
  • Timebox at 30-90m
  • Facilitators: 1

Facilitator Instructions

Session Setup

  1. Choose a Work Activity. This should be something in need of exploration or discovery. The group gathered should all have some way of touching this Activity, even if it’s in their own domain.
  2. Create a Table. Each participant gets a single row, one item of difficulty each. The columns are:
    1. Critical Decision / Assessment
    2. Reason Why Difficult / Critical
    3. Comments / Notes / Solutions
  3. Gather your session together, virtual or hybrid or physical, it doesn’t matter. Each participant should have the ability to be heard by the entire group. Everyone should get a turn in a round-robin fashion. Let people know they should come prepared to participate.
  4. Introduce the session as an examination of our Regular Work, or “Work-As-Done”. We are coming together to enhance our mental models and learn more about navigating complexities in the system. We will talk Real Work experiences, not hypotheticals or models.

To Start

  1. It isn’t necessary to introduce the concept of a DRT beyond describing what we’ll be doing. The title is self-evident, you want to avoid overloading the session with too much theory. Our goal is to look at this Work Activity, closely examine the difficulties, and try to reason what makes that Activity so difficult.
  2. Announce that you are asking yourself the question: “What is the one most difficult thing about doing this work?” This could be a critical decision, an in-the-moment risk assessment, or an ambiguous situation. Make it real, don’t make it up. It needs to be something that has happened to you.
  3. You are giving an example response so be brief and precise, one sentence or phrase is enough. You are the first row: Put your Decision in column A, your Reason in column B.
  4. Once you’ve presented your topic, if others aren’t already agreeing with it, ask if anyone else has this problem here. Get discussion going about your topic, limit it to just a couple of minutes. Notes can go in column C.
  5. How you pick the next person is up to you. Asking for volunteers can be difficult, especially with people new to this. Instead, you may want to treat it as a game of surprise and require each person to call the next person to go.

Sometimes it will be difficult to keep people away from models and rulebooks and procedures. Language like “we do it this way” or “the procedures say to” are signs we’re moving too far in the abstract. Get things back on track by asking specifics about the occurance of the difficulty. I sometimes ask when in their workday it happened, for example.

To End

Timebox this session and keep a timer to make sure everyone has a fair chance to speak. The goal is the journey, there is no real “end” unless you have identified an outcome through your Work Activity (some Examples below do this, like redesigning On-Call).

Example Activity

Each example reflects real sessions I have facilitated. Some of them had outcomes and followup items because a design was being sought, while some were entirely self-contained as learning and collaboration practice. Both types influenced and inspired teams outside of the session, even running DRT exercises of their own.

  1. Your team has a function that is lacking maturity, you’d like to understand the gaps.
  2. You are designing a command line tool for a group of users, you’d like to understand where they are having difficulties in order to design a solution.
  3. Your organization is redesigning how you do on-call coverage and incident response, you’d like to have a deep and wide survey of what it will take to get there (e.g.: I facilitated four DRT sessions for an On-Call reboot initiative).
  4. A task force has been assigned to improve Developer Experience, you’d like to build bridges with those Developers and understand the maturity of their toolset and processes.
  5. An extremely brittle production deployment process has been orphaned multiple times, you’d like to get a diverse user group to collect as many perspectives as possible to triage.

How would each of these be presented in a session? Do this by translating your Work Activity into a simple question: “What’s the most difficult thing I have to do to accomplish this work?” The more specific it can be, the better. The On-Call quadrouple DRT had multiple variations¬†and different audiences, for instance one of them was dedicated to Post-Incident activities.

There will be times the facilitator may need to get creative about framing a Work Activity in a highly diverse group. We had a customer-facing person join for a session about difficult On-Call response, which was more than welcome. We were able to craft a question that helped them pick out a critical decision point in their evaluation of supporting a customer.

Reasoning

Why do this? Is it worth the time away from writing code?

Here are some of the reasons I believe it is.

  • People can let off some steam and air difficulties in how they do their work, together.
  • They feel they’ve made a contribution to a large project that introduces change.
  • Knowing where expertise lies and how people do their jobs helps us identify, as a team, where our adaptive capacity is: we recall who has the chops to help in a time of need.
  • People gain a sense of empathy for their coworkers.
  • Cross-divisional participants gain insight into other expertise, what it takes for that Real Work to get done, which brings teams closer as humans.
  • Expertise is shared through the stories of how people deal with challenges in the very real way they worked on them.

Supporting these reasons is the idea of keeping it connected to a real event that really happened to us. This dials in the memory of the event, giving it substance. The person can strongly identify exactly what the difficulty was, sometimes accompanied by emotional memories.

This is why a safe space is recommended. Encouraging disagreement and calling out problems while feeling freedom from judgement is the type of atmosphere you want. This is not always possible, but we strive to make it be this way. Everyone is attending because they want to help the community improve with the best intentions possible.

Discussion

Decision Requirements Tables as we did them in Practice of Practice Gamelan can be seen as a form of Rapidized Cognitive Task Analysis.

I didn’t know about this term when I started using this CTA technique. I was reading Working Minds and having all kinds of creative doors opening for me, I had started this Practice of Practice Gamelan session and wanted to invent some group exercises around our work. CTA techniques fit really well, especially TRDs.

So I just took it and ran with it. The idea that we are here to talk about real things is a fundamental aspect of Practice of Practice Gamelan that is mirrored in the way a TRD exercise works. As such, it ended up as the backbone of lots of our gaming and discussion, and in different formats than round-robin spreadsheet building. At one point it was such a loved activity at the company that the Marketing team asked me to do a series of Webinar/Podcasts in which I had guests in the SRE space on to answer the question “What’s Difficult About _____?”.

Accellerated Expertise is a recent compendium that summarizes research in expertise. How people display it, how they come about it, and how we can help spread it to our cohorts beside us. The volume is tied to the Naturalistic Decision Making discipline and makes the assertion that we can accomplish accellerated learning through CTA techniques. When I read this after having led so many of our PoPG sessions, I knew I was on to something good.

In fact, another thing this book shows is that the NDM community needs to know about what we’re doing in software. That’s why I built the popg.xyz site, to start cataloging the CTA work I’ve been doing and talking about at SREcon and many other places. I think there’s some wonderful progress we’re making in Tech that the world wants to know about that is greater than code, it’s the way humans need to come together to make code happen.

Matt Davis, April 2024