liveBook · Manning

Role fluidity

As explained in Collaborative Software Design: How to facilitate domain modeling decisions

Role fluidity is the ability of people in a group to recognize and identify with multiple roles rather than reducing a person to a single fixed role.

Role fluidity helps a group avoid treating any person as a fixed role. A role can be a social position, emotion, thought, behavior, or viewpoint, and may be conscious or unspoken in the group. The aim is for participants to recognize that they can relate to several roles—including roles they do not currently express—so they can see one another differently and reopen a stalled conversation. section 8.3.3 section 8.7

Figure 8.6 How roles can get stuck to certain people or part of the group in isolated icebergs within the consciousness of the group. When this happens, the group gets into a conflict and can’t relate to the other role anymore.

Use this image to spot the failure mode: a role becomes attached to a person or subgroup, leaving others unable to relate to it. section 8.3.3

Begin by making room for what is already present. Check-ins and check-outs, sensemaking, climate reports, active listening, and holding space can bring unspoken roles into awareness. These practices are useful when tension is manageable, but high conflict may require a more direct intervention. section 8.3.3

When someone assigns a narrow role to others, facilitate recognition rather than argue over the label:

  • Ask who sees the situation differently, then wait for an answer from the group. section 8.3.3
  • Let a participant name a more specific experience behind the apparent role—for example, not speaking because they do not know which problem proposed solutions address. section 8.3.3
  • Spread that experience with a modest invitation: ask, “Who can somewhat relate to not knowing what the solutions solve?” Model participation by raising your own hand. section 8.3.3
  • Keep “somewhat” in the question. It invites partial identification without demanding that people claim the role completely. section 8.3.3

Turning design camps into shared heuristics

When a group prefers competing bounded-context designs, pair participants with someone who favors the other design. Each interviewer explores the problem the other person believes their preferred design solves. Capture the result as a Question-Heuristic-Answer card: turn the problem into a question and extract the heuristic from the proposed solution. The exercise builds relatability across camps while making decision criteria visible for later discussion and voting. section 9.3.1

Role fluidity does not require a facilitator to decide which viewpoint is correct. It helps participants move from sides to needs. In a disagreement about whether to explore user needs more deeply, asking who could relate to not seeing the connection surfaced that concern among developers, while asking who saw it differently surfaced concerns about time and overemphasizing user research. Both needs could then inform a proposal for continuing the session and scheduling later exploration. section 10.3.2

How Collaborative Software Design: How to facilitate domain modeling decisions covers it

How deep it goes
Defines roles and gives prompts, group-recognition steps, and paired-interview practice, while noting that ordinary listening tools can fail under high conflict.
Examples
Uses a participant labeled disengaged, opposing bounded-context designs, and disagreement over investigating user needs more deeply.
What it assumes
Teaches role recognition from zero while assuming a facilitated group conversation or collaborative design session.
What you can do after
Practice/perform it by eliciting alternative roles, inviting partial identification, and documenting needs behind competing design preferences.
How it connects
Connects role theory with Deep Democracy, active listening, sensemaking, bounded contexts, EventStorming, and Question-Heuristic-Answer cards.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Collaborative Software Design: How to facilitate domain modeling decisions. The section links point to the parts of the book it draws on.