Earlier chapters established what an input script is and what role it defines, the baseline of mutual understanding the orchestrator owes the participants, and the discipline that lets a script travel beyond the orchestrator who authored it. The durable-message chapter introduced the durable message and named the four interlocking concepts that together form the operational foundation of coordinated work. This chapter establishes one of the four: the discipline of role-playing.
Role Assignment Comes First
A teacher running a group project does not begin with instructions. The teacher begins with role assignments. Group A is researching France, Group B is researching Brazil, the leader of each group is named, the rest are researchers reporting to their leader. Until those roles are assigned, no instruction the teacher gives later has anywhere to land. A volunteer coordinator running a flood relief effort does not begin with team briefings. The coordinator begins with role assignments. Maria is leading the drywall removal team, here is who is on Maria's team, here is what your team is responsible for. Until the volunteer holds the role, no briefing later can be acted on. A manager starting a new project does not begin with task assignments. The manager begins with role assignments. You are the project lead, you are the technical specialist, you are the client liaison. Until those roles are inhabited, no task has someone to do it.
Role assignment is the prerequisite condition for coordinated work. Working orchestrators do this naturally, every time, without naming it as a step. The framework names the discipline so it can be invoked precisely throughout the rest of the series.
A participant who has been assigned a role and is inhabiting it is a role player. The student who is researching France is role-playing the researcher. The volunteer removing wet drywall on Maria's team is role-playing the team member. The new hire shadowing a senior employee in their first week is role-playing the trainee. Working life is full of role-playing — the same person plays many roles in a single day, taking on and putting down roles as the day requires.
Two Acts
Role-playing has two architectural acts. The first is taking on a role: the orchestrator authors a role description and dispatches it to a role player, and the role player receives it and takes on the role. The second is reacting as a role player: the role player, now holding the role, exercises the capabilities the role grants within the scope the role description specifies. Both acts are required for any coordinated work that depends on roles. The first establishes the role-playing relationship; the second is what the role player does once the relationship is established.
Taking on a Role
The role description is an input script in the form the boundary-conditions chapter named, and taking on a role crosses the input boundary the same way every input script does. At the moment the role is taken on, the role description crosses out of the orchestrator's hands and into the role player's, and the role player begins holding the role for the duration the description specifies. The orchestrator can change the role only by authoring a new role description and dispatching it — the same discipline every input script honors.
Reacting as a Role Player
Once assigned, the role player exercises capabilities within the role's scope. Reacting as a role player involves observing what is happening, recognizing when something requires action, and acting. The role is held continuously for the duration the role description specifies. While the role is held, the role player is paying attention, and the capabilities the role grants are available to be exercised whenever they are needed.
Three capabilities are foundational.
The first is responding to requests. The role player receives a request addressed to the role and acts on it within the role's scope. A role player monitoring temperature responds to what's the temperature with the current reading. A role player tracking project status responds to what's the status with the project's current state. The form the action takes — a quick reply, a dispatched task, a coordinated effort — depends on what the role calls for.
The second is reacting to current conditions. The role player observes what is happening and acts on what they observe, without being asked. A lifeguard at a swimming pool reacts when someone is drowning. A security guard monitoring a warehouse reacts when an intruder appears. A team leader monitoring their team reacts when a worker gets stuck. The form the action takes depends on the role; the pattern is the same.
The third is reporting status. The role player produces outgoing information about the state of the role's work, so the broader coordination has visibility into in-flight performance. A security guard logs hourly checks of the warehouse perimeter. A team leader sends a daily summary to the manager who staffed the project. Reporting status is what makes role-playing observable from outside. Without it, the orchestrator and the rest of the coordination are blind to how the work is going. With it, the coordination has the in-flight visibility it needs to intervene when needed and to leave well enough alone when it is not.
The list is open. The types of reactions are only limited by the imagination.
The Foundation
Role-playing is one of the four interlocking concepts that together form the operational foundation of coordinated work. The other three — the durable message, the message handler, and the messenger — depend on role-playing the way role-playing depends on them. Without role players, durable messages have nowhere to land, and the work of the message handler and messenger has no destination. Without durable messages, role assignment has no artifact to carry the role description. Without the message handler and messenger, role descriptions cannot reach the participants who will inhabit the roles.
Working orchestrators have always operated under this foundation. Before any team works, the team is assembled and roles are assigned. Before any project starts, the participants know who is doing what. Before any message is sent, the recipient is in a position to act on it. The framework's contribution is to name what working orchestrators do naturally, so the rest of the series can build on it without re-establishing it each time.