Workshops and interviews
Discovery is where an assessment earns its credibility. A workshop that collects opinions produces a report; a workshop that surfaces the actual workflow, with the people who perform it, produces a plan.
Designing a discovery workshop
Objective
A single measurable outcome for the session — for example, "a mapped release process with handoffs and cycle times."
Participants
Cross-functional by design: engineering, operations, security, product, and at least one person from the business function the change affects.
Duration
Two hours is the practical limit for a working session; longer sessions should be split by topic.
Pre-work
A short survey or a request for existing process documentation, so the session starts from a shared baseline.
Standard agenda
| Time | Activity | Purpose |
|---|---|---|
| 10 min | Introduction | Welcome, objectives, and the shape of the session |
| 20 min | Current state | What exists today — environment, tooling, process, constraints |
| 30 min | Key areas | Deep dive into infrastructure, architecture, security and compliance |
| 30 min | Working session | Participants identify pain points and propose improvements |
| 20 min | Actions and next steps | Summarise, assign owners and dates |
| 10 min | Q&A and close | Open floor, follow-up commitments |
Facilitation rules
- Ask for the last real example. "How do you deploy?" produces a policy. "Walk me through the last change you deployed" produces the process.
- Map handoffs explicitly. Most delay lives between teams, not inside them.
- Time the steps. An estimate from the facilitator is an opinion; a participant's estimate with a recent example behind it is data.
- Record disagreement. Where two teams describe the same process differently, document both versions. The discrepancy is a finding.
- Assign actions in the room. An action without an owner and a date does not survive the meeting.
- Keep the output visible. Capture on a shared board so participants see their input recorded, not transcribed later.
After the workshop
- Distribute a summary within two working days: findings, decisions, actions, owners, dates.
- Maintain an action tracker between sessions.
- Send an optional feedback survey to improve the format.
- Schedule follow-ups based on the actions, not the calendar.
Templates: workshop plan · customer needs assessment
Interviews
Workshops reveal the process. Interviews reveal the constraint behind it — the reason the process exists in its current form.
Structure
Each interview covers seven topics, adapted to the interviewee's role:
Role and responsibilities
What the person owns, how their team interacts with others, what they are currently measured on.
Technical environment
Tools and systems in use, whether they meet the team's needs, known limitations.
Processes and workflows
The steps actually followed for development, deployment, testing and incident response; where the bottlenecks are.
Collaboration
How teams communicate, what tools they use, where collaboration breaks down.
Challenges
The recurring problems that cost the most time; the one thing they would change.
Future goals
What would help, what they expect their role to become, what support they need.
Security and compliance
For relevant roles: the controls in place, how evidence is produced, where controls obstruct work.
Question technique
- Prefer "walk me through" over "do you have."
- Ask for a specific instance when the answer is general.
- Follow the friction: when someone says "it's fine, but…", the "but" is the finding.
- Ask what would break if a step were removed. The answer identifies the control the step is protecting.
- Close by asking who else should be spoken to — this is how the stakeholder map gets its edges.
Confidentiality
Interview notes are attributed to a role, not an individual, in the summary report. Direct quotes are used only with permission. The purpose is to improve the system, not to evaluate the person.
Templates: interview guide