liveBook · Manning

Shadow

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

A shadow is an unobserved or insufficiently acknowledged social dynamic that hinders a group's collaboration and decisions.

A shadow is a social dynamic that operates partly outside a group’s awareness yet shapes collaboration, decisions, and outcomes. Ranking, cognitive bias, assumptions, conflict, polarities, frustration, and hidden agendas can all become shadows. Left unaddressed, they can block progress and grow into larger barriers; made visible, they can become material for a group to examine together. section 1.3.3 section 4.3.1

Shadows often first appear as a facilitator’s uneasy impression: recurring circular decisions, tension, avoidance of a topic, mismatched levels of detail, or frustration in the room. An impression is not a diagnosis. Power dynamics and psychological safety make public interpretation delicate, so the aim is to notice patterns neutrally and let the group decide whether and how to address them. section 4.3 section 1.3.3

Figure 1.7 Lurking in the group’s shadows, called the unconsciousness of the group, are a lot of social dynamics, such as ranking, cognitive bias, conflicts, and polarities, that can block the flow of a session and stop the group from moving forward and making sustainable design decisions.

Use the group-shadow model to distinguish visible modeling work from the social dynamics that may be interrupting its flow. section 1.3.3

Bring a possible shadow into shared awareness through careful sensemaking:

  • Observe interactions, verbal and nonverbal communication, group positions, culture, subcultures, and environmental artifacts; work on neutrality to receive more information. section 5.2.2
  • Prepare a tentative hunch by asking about conflicts, disagreements, polarities, tension, hierarchy, and possible hidden agendas before the session. section 5.4.4
  • Offer a neutral exercise that makes perspectives visible rather than asserting that a particular dynamic is present. section 4.3 section 4.3.4
  • Use the result to open conversation, invite minority perspectives, and let participants choose the next step rather than forcing confrontation. section 4.3.4 section 1.3.3

Testing a suspected polarity

When a group becomes frustrated while creating a shared model, a facilitator may suspect that participants are discussing different things—for example, a standard product versus a custom-made solution. A sensemaking exercise can test that hunch by asking people to place dots among three options arranged in a triangle. The pattern creates a conversation without claiming the facilitator’s interpretation is correct; the group then decides whether to continue modeling or change direction. section 4.3.4 section 4.3.4

Addressing shadows is not always comfortable. Sensemaking can bring vulnerability or negative feedback, and a group may not be ready to confront what is visible. Facilitators also have shadows: a strong urge to solve the group’s problem can reduce neutrality and unintentionally reinforce the dynamic. Reflecting on one’s own reactions helps preserve the conditions for useful facilitation. section 4.3.4 section 1.3.3

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

How deep it goes
Defines shadows and gives observation, preparation, and sensemaking practices; defers detailed strategies for individual dynamics.
Examples
Uses recurring decisions, topic avoidance, a standard-product versus custom-solution polarity, and dot-placement sensemaking exercises.
What it assumes
Assumes facilitation awareness while teaching observation, neutrality, and tentative inquiry into group dynamics.
What you can do after
Apply it via sensemaking exercises to make possible group dynamics discussable and support a group-chosen next step.
How it connects
Connects shadows with sensemaking, neutrality, ranking, cognitive bias, conflict, polarities, psychological safety, and group culture.

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.