Running Technical Meetings & Conducting Technical Discovery

An FDE spends as much time in meetings as in an editor. This tutorial covers how to run a technical meeting that doesn't waste everyone's hour, and how to run a discovery session that actually uncovers the real problem. The method of discovery (what to learn) is covered in Chapter 3 — here we focus on running the session itself.

Table of Contents

• Running Technical Meetings
• Before the Meeting: The Agenda
• During the Meeting: Hold the Floor Lightly
• After the Meeting: The Follow-Up
• Conducting Technical Discovery
• The Discovery Session Format
• Capturing What Matters

Running Technical Meetings

A technical meeting is any session where the point is to decide something technical with the customer — scope a build, review a design, triage a bug, plan a rollout. The goal is a decision or a clear next step, not a status update (status belongs in writing).

Why it is useful: a meeting with no structure produces a meeting everyone resents. A meeting with a stated purpose and an owner produces decisions the build can run on.

Before the Meeting: The Agenda

Send an agenda. Not a novel — three to five lines that say what we'll decide and who needs to be there.

AGENDA — Integrations sync, Thu 10:00
Goal: decide which 2 of the 4 source systems we connect first.
1. Current data flow (5 min) — you
2. Which reports break without System C? (10 min) — customer
3. Pick the first integration + date (10 min)
Decision needed from: Ops lead

Explanation: the agenda states the decision, not the topic. "Discuss integrations" is not a goal; "decide the first two" is. People show up ready because they know what's expected of them.

Best Practice: name the decision-maker. A meeting where nobody can decide is a briefing, not a meeting. If the decider can't attend, reschedule or pre-decide.

During the Meeting: Hold the Floor Lightly

Your job as facilitator is to keep the conversation pointed, not to perform. Three moves cover most of it:

• Open with the goal. "We're here to pick the first integration — let's land that in 25 minutes."
• Park tangents. "Great point, let's capture it in the parking lot and stay on the decision." Then actually capture it.
• Close with the commitment. "So: we build System C first, you send credentials Friday, I demo next Thursday."

PARKING LOT (from today's call)
- Single sign-on for the portal — revisit in Phase 2
- Mobile app access — customer raised, not in scope yet

Explanation: a visible parking lot stops tangents from derailing the meeting while proving you heard them. Things in the parking lot either die or become real work later.

After the Meeting: The Follow-Up

Within an hour, send a short recap. This is where most FDEs drop the ball and the decision evaporates.

RECAP — Integrations sync
Decided: connect System C first; System A second.
You: send read-only DB credentials by Fri.
Me:  working prototype by next Thu; demo at 10:00.
Parked: SSO, mobile app (Phase 2).

Best Practice: the recap is the contract. If it's not written, the decision didn't happen — people will remember different things. A five-line recap prevents a one-hour replay next week.

Conducting Technical Discovery

Technical discovery is the meeting where you learn how the customer's system actually works before you build — what data exists, where it lives, what breaks today. (The mindset — interview to learn, not to pitch — is Chapter 3's territory. This tutorial covers how to run the session so it produces that learning.)

The difference from a normal meeting: you talk less, and you steer toward concrete instances, not opinions.

The Discovery Session Format

A 45-minute discovery session has a shape. Winging it produces a tour, not discovery.

DISCOVERY SESSION (45 min)
0:00  Warm-up — "walk me through a normal Tuesday." (let them talk)
0:10  Map the flow — "where does the data start, where does it end?"
0:25  Find the pain — "what step do you dread / what goes wrong?"
0:35  Quantify — "how often, how long, what does it cost?"
0:42  Confirm — "so the real problem is X, not Y — right?"

Explanation: the session moves from story → structure → pain → numbers → confirmation. Each stage hands the next one its raw material. You end with a confirmable problem statement, not a wish list.

Note: discovery is a loop, not a one-shot (Chapter 3 covers the loop). This format is one pass of it.

Capturing What Matters

During discovery, capture three things, in this priority:

1. Verbatim quotes — "we reconcile these by hand every Friday" becomes gold in the problem statement.
2. The surprising fact — anything that changed your assumption. That's the real finding.
3. The data map — where data is born, where it dies, what touches it.

Common Mistake: scribbling features. "They want a dashboard" is not discovery — it's a request. "They spend 3 hours Mondays copying numbers" is discovery. Capture the second thing.