liveBook · Manning

Interview

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

An interview is a structured conversation in which one person elicits information, experiences, or perspectives from another person.

An interview is a private, neutral conversation used to understand a situation before bringing people together. It helps a facilitator hear perspectives that may be muted in group settings, assess conflict without immediately taking sides, and notice both what people say and how they say it. section 5.1.1 section 8.3.1

Treat interviewing as observation, not interrogation. Listen for frustration, recurring topics, blame, absolutes, silence, and discrepancies between verbal claims and body language. Such double signals can indicate concerns that people minimize aloud, especially when organizational status or resistance shapes what feels safe to say. section 5.1.1 section 6.5

Use interviews to prepare collaborative work without pre-deciding the outcome:

  • Meet conflicting participants separately when privacy may help them speak comfortably. section 5.1.1
  • Probe neutrally and use active listening to understand feelings and perspectives rather than rebutting assumptions. section 8.3.1
  • Conduct consecutive conversations across affected roles to identify repeated concerns, quiet voices, and information held in the group’s conscious or unconscious. section 8.3.1
  • Record observations and reflect on personal shadows to preserve facilitator neutrality. section 6.5
  • Use what emerges to design check-ins, sensemaking, safety rules, or another appropriate intervention. section 8.3.1 section 8.5

Interviewing around a design conflict

Two developers disagree about a redesign and accuse each other of not listening. Separate interviews reveal frustration, finger-pointing, and a dispute that affects quieter teammates. Further conversations show that the team’s conflict concerns software-design decisions and an architect’s departure. Rather than correct anyone, the facilitator listens, identifies what may need to surface, and uses the patterns to plan check-ins and sensemaking. Being heard can itself reduce pressure before the group reconvenes. section 5.1.1 section 8.3.1

Interviews have limits: a facilitator can lose trust by intervening too early or by treating one account as the whole story. Keep strong opinions under review, address concerns to the group rather than exposing lower-ranked individuals, and seek agreement before giving advice. When assessing conflict, distinguish task-related from emotion-related behavior and use observed behavior to judge what intervention may be needed. section 8.3.1 section 8.5

Figure 5.2 A fractal triangle pattern. This triangle is repetitive at every scale. The big triangle comprises three smaller triangles. Those smaller triangles comprise three even smaller triangles. You’ll find fractal patterns also in companies. Patterns exhibited by higher management will be observable on lower levels of the company.

Use the fractal-triangle pattern as a prompt to consider whether signals observed in interviews may repeat across organizational levels, rather than treating one conflict as isolated. section 5.1.1

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

How deep it goes
Explains interview use through observation, active listening, repeated conversations, and translating findings into session design.
Examples
Uses separate developer interviews, conversations with quiet teammates, and resistance from a back-office leader.
What it assumes
Builds on active listening and neutral observation while recommending reflection on personal shadows and power signals.
What you can do after
Diagnose/debug with it: assess conflict signals and choose preparation or intervention for collaborative sessions.
How it connects
Connects interviews with active listening, facilitator neutrality, organizational ranking, conflict resolution, check-ins, and sensemaking.

Also explained in

Compare how 7 books explain interview →

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.