liveBook · Manning

Signal

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

A signal is an observable piece of information, activity, behavior, or event that indicates a change affecting a session, outcome, or result.

A signal is an observable piece of information, activity, behavior, or event indicating a change that may affect a session, outcome, or result. In collaborative work, signals reveal group dynamics, perspectives, relationships, and emerging problems. section 5.4.2

Strong signals are obvious and easy to observe; weak signals are harder to detect and may initially seem random. One occurrence does not establish a pattern, so facilitators connect repeated observations with other signals and information. section 5.4.2

Use signals to manage movement between opposing ways of working:

  • Observe behavior without interpreting it, and consider a threshold when first learning to use a polarity map. section 10.2.2
  • Treat signals as prompts to move between poles, pairing each observation with an action or heuristic. section 10.2.2
  • When a group struggles to identify signals, ask which situations make the polarity feel consequential and what people observe happening. section 10.3.3

BigScreen

During a discussion about standard products versus customized solutions, a clear insistence on the standard-product approach is a strong signal of dissatisfaction. A joke about joining another team’s Friday drinks may be a weak signal of disagreement or possible departure; it becomes meaningful when connected with other observations. section 5.4.2

Figure 10.7 Complete polarity map of Deep versus Wide

Inspect a completed polarity map to see how observations become signals and connect to actions for managing Deep versus Wide. section 10.2.2

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

How deep it goes
Defines strong and weak signals, explains pattern recognition, and links observations to actions without prescribing universal thresholds.
Examples
Uses watch-checking, confused participants, software architecture decisions, dissatisfaction, jokes, and possible team departure as signal examples.
What it assumes
Assumes familiarity with facilitation, sensemaking, collaborative modeling, and polarity maps while prompting observation from concrete group situations.
What you can do after
Apply signals to observe group dynamics, detect emerging patterns, and choose actions that restore movement between polarity poles.
How it connects
Connects signals with polarity management, polarity maps, facilitation, sensemaking, collaborative modeling, observations, and heuristics.

Also explained in

Compare how 10 books explain signal →

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.