SME collaboration, Part 1 of 4: the async interview
Part 1 of 4 on SME collaboration. The async interview pattern: structured prompts, short turnarounds, an audit trail, and no scheduled meeting. Why it works when 'just ping them' doesn't.
This is Part 1 of a four-part series on SME collaboration. The series is the craft companion to the engineering posts running this month — the bot, the packet, the SLA tickets — but the focus here is the workflow, not the tooling.
The premise of the series is the same one that opens Bo’s opinion piece on the same week: 48% of proposal teams have called SME collaboration their top problem for five consecutive years per Qorus’s research. The number doesn’t move. The number doesn’t move because most teams treat SME work as a chase problem when it is actually a design problem.
This part covers the async interview — the pattern that, in my experience, halves the SME response time and improves the answer quality at the same time.
What “just ping them” gets wrong
The default mode of SME collaboration in most shops is what I call “just ping them.” The proposal manager identifies the questions an SME needs to answer, sends a Slack message, and waits. The Slack message contains three to ten questions, sometimes more. The SME reads it on their phone between meetings, decides it’s a half-hour task, and defers. By the time the SME comes back to it, the deadline pressure is up, the answer is hurried, and the proposal manager has been chasing for two days.
Three things are wrong with “just ping them” simultaneously.
Question count. Multiple questions in one message is multiple deferral events. Each question gets read, each one gets postponed, none get answered now. A single question in a message gets answered now because it can.
Lack of structure. A free-text “tell me about our incident response process” is open-ended. The SME has to decide what level of detail, what tone, what format. Decisions cost time. Decisions defer.
No audit trail. The Slack thread is the artifact. When the proposal manager copies the SME’s answer into the response, the connection between the answer and the source is lost. If the answer is wrong, nobody can trace why. If the answer needs follow-up six months later, nobody can find it.
The async interview pattern fixes all three.
The async interview pattern
The async interview is a structured exchange between proposal manager and SME, conducted in short messages over chat or a ticketed surface, with these properties:
- One question per ask. A single concrete question, not a list.
- A pre-built draft. The SME reviews and approves an answer rather than writing one. We covered the engineering of this in the SME draft packet post.
- A short turnaround. A specific deadline derived from the bid timeline, not “as soon as you can.”
- An audit trail. The exchange is recorded against the response in a way that the next bid can reference.
The structure is not heavy. The structure is the difference between a Slack message that gets ignored and a ticket that gets answered.
The mechanics
A typical async interview cycle for a single SME on a single RFP looks like this.
Day 1 (intake + 24h). The proposal manager has classified the response, identified the 8-12 questions this SME owns, and pre-built the draft packets. The first three packets go to the SME via the SME Slack bot. The SME sees three Slack DMs, each with one question, the proposed answer, and a 48-hour SLA.
Day 2. The SME has answered one of the three. The proposal manager checks the response against the bid strategy, accepts it, and queues the next packet. The SME’s queue is always three open at most. This is deliberate — more than three creates the same overwhelm as the original “just ping them.”
Day 3. The SME has answered two more. The proposal manager queues two more. The cycle continues.
Day 7. The SME has worked through their full queue. The remaining open questions are the ones that required deeper synthesis — usually one or two. Those get a 20-minute capture call (Part 3 of this series) instead of an async exchange.
The proposal manager’s chase work is replaced by queue management. The SME’s response work is in two-minute chunks instead of a half-hour blob.
Why it works
Three reasons, in increasing order of importance.
The SME’s interruption cost is lower. A two-minute concrete question fits between meetings. A half-hour open-ended ask does not. Lohfeld Consulting’s research on proposal-process drag names this directly — proposal managers spending more time chasing than building strategy is a symptom of the SME interruption cost being mismatched to the SME’s actual capacity.
The pre-built draft anchors the answer. The SME’s two minutes are spent verifying or correcting a draft, not generating one. Generation requires more cognitive load than verification. Quilt’s research on bottlenecks puts SE time per RFP at 100 to 300 hours; the verification model compresses that materially because most of the SME’s time is spent confirming what the proposal manager already drafted.
The audit trail compounds. Each async-interview exchange is captured as a record tied to the question, the bid, the SME, and the answer. The next bid that asks a similar question can pull the prior exchange. The next person to ask this SME a similar question can see the prior framing. The team’s intelligence gets denser with every bid.
Where the async interview breaks
Two failure modes I’ve watched, in real teams.
The SME doesn’t trust the draft. If the SME has been burned by a wrong AI-generated draft before, they will rewrite the proposed answer from scratch even when it’s correct. The fix is not better prompts — it’s a track record of accurate drafts. The first three drafts an SME gets from a new system have to be impeccable. After that, the trust compounds.
The proposal manager sends too many questions at once. Three open at a time is the rule. Eight open at a time defeats the pattern — the SME picks the easy ones, defers the hard ones, and the queue ages. Discipline on the proposal manager’s side is what makes the discipline on the SME’s side possible.
What’s next in the series
- Part 2 (Day 139): Ticketed asks and response SLAs. Why “just ping them on Slack” fails as a primary surface, and what the ticket form should contain.
- Part 3 (Day 146): The 20-minute capture call. The synchronous meeting that handles the questions async can’t, and why 20 minutes is the right cap.
- Part 4 (Day 153): A KB your SMEs will actually use. What makes an SME contribute back versus what makes them ignore the tool.
The series is one continuous argument: SME collaboration is a design problem, and the design that works has been hiding in plain sight in async-first engineering teams for a decade. The proposal world has not adopted it because the proposal world has not been built for the SME. We’re trying to fix that one part at a time.