What the Checklist Manifesto can teach Technical Teams about Communication
A technical team presents its recommendation. Leadership asks for clarification. The team sends more detail. Another meeting follows, and the decision is still waiting.
A security leader recently described this problem to me. His team needed to explain technical decisions to leadership and translate technical details for people outside the technical team. On complex projects, he said, the resulting delays could stretch into days or weeks.
It is a practical problem: how do you make sure the explanation includes what someone needs to make a decision?
Atul Gawande’s The Checklist Manifesto: How to Get Things Right offers a useful starting point.
In the book, Gawande explores how experienced professionals can miss essential steps when their work becomes complex. Through examples from medicine, aviation, and construction, he examines how checklists help experts consistently apply their knowledge (Gawande, 2009).
For technical teams, I see a useful application: build a short communication checklist from the misunderstandings that appear in your own project conversations.
That gives the team something specific to check before another decision or handoff.
Start with the conversation your team had to explain twice.
A project transcript can show where people interpreted the same information differently. One person may think a date is a commitment. Another may understand it as an estimate. Someone may hear approval for the technical approach and assume the budget has also been approved.
Read the transcript with one question in mind: what needed to be confirmed before everyone moved on?
Consider these fictional exchanges:
What the conversation reveals | A possible check for the next meeting |
“I thought Friday was the delivery date.” “Friday was when testing could begin.” | Have both teams confirmed which milestone the date refers to? |
“I thought this was approved.” “The technical approach is approved. The budget is still under review.” | Has the decision owner confirmed exactly what has been approved? |
“Who is explaining the change to the client?” “I assumed your team would.” | Has a named person accepted responsibility for the client update? |
These items give the team an observable action. The date refers to a named milestone. The scope of the approval is recorded. Someone has accepted responsibility.
A broad instruction such as “communicate clearly” leaves too much open to interpretation.
Turn the transcript into a checklist your team owns.
Inspired by The Checklist Manifesto, I created a reusable AI prompt that helps technical leaders generate checklists from their own project discussions.
The prompt asks the AI to identify points of confusion, connect each proposed check to evidence, and choose a specific moment when the team should use it.
It produces four practical outputs:
A short, technical communication checklist with a clear completion condition for each item.
An explanation of which transcript passages support those checks.
Natural English phrases for the conversations the checks require.
A small trial to help the team improve the checklist.
The AI proposes the first draft. The people involved review whether it accurately represents the project and whether each item would be useful again.
That review matters. A topic missing from one transcript may have been resolved elsewhere. An unanswered question may require technical investigation. The prompt tells the AI to flag those uncertainties rather than invent a failure.
Give the checklist a place in the workflow.
Choose one conversation: an approval request, a client discussion, or a handoff between teams. Paste its transcript and the full prompt into your organization’s approved AI tool. Keep speaker labels and timestamps when available.
Add a sentence about the problem you want to address. For example: “We keep leaving meetings with different interpretations of what the client approved.”
Review the suggested items and keep the few that address consequential, recurring gaps. Five to seven checks can be a starting point; use fewer if fewer are useful.
Then decide when to run them. A checklist for requesting approval might be used before the proposal goes to leadership. A checklist for confirming decisions might be used during the final two minutes of the meeting.
Name the person responsible for running it and the people who need to participate.
For each check, establish what counts as complete. “Has the client update been assigned?” is complete when a named person accepts responsibility. Assuming someone will handle it leaves the question unresolved.
Keep individual project assignments in the action list. Sending this week’s estimate is a task. Checking that the decision owner has the current estimate may belong in a reusable approval checklist.
Practice the language the checklist requires.
For a team working in English, a check can reveal a communication skill worth practicing.
An employee may recognize an uncertain assumption but need help asking about it clearly.
A useful phrase might be:
“Before we close, can I confirm whether Friday is a target date or a confirmed commitment?”
When explaining a recommendation to leadership, the team might practice:
“We recommend this option because it reduces ___. The trade-off is ___. We need a decision on ___.”
These phrases give people a starting point. They still need to adapt the language to the situation, preserve uncertainty, and answer follow-up questions.
At AIR Language, we build English practice around these work situations. A project conversation can provide the material for explaining a recommendation, clarifying a misunderstanding, or discussing a trade-off with a client.
Try it in three comparable meetings or handoffs. Notice which checks reveal a missing answer, how long the review takes, and which questions still return afterward.
Use that feedback to revise the wording and timing. Track other causes of delay, such as funding or technical dependencies, so the team can see which issues communication practice can address.
The checklist approach in Gawande’s book gives us a useful principle to apply: make essential checks a consistent part of complex work. Your own project conversations can help you decide what those checks should be.
Choose the last meeting your team had to explain twice. Use the prompt to create a draft, review it together, and test it in the next comparable conversation.
If your team needs help practicing those conversations in English, contact AIR Language to discuss training built around your actual work.
Reference
Gawande, A. (2009). The checklist manifesto: How to get things right. Metropolitan Books.
Comments