Short on time? Start here
A program that exists only in meetings forgets itself. People leave with different versions of the decision. A dependency becomes an assumption. A careful tradeoff turns into "someone said." Two weeks later, the group spends another hour reconstructing what it once knew.
Writing gives the program a memory outside any one person. Good TPM writing is not a transcript and it is not a flood of status. It preserves what future action depends on: the decision, the reason, what was deferred, the owners, the dates, and the risk that remains.
Write so the absent person can understand what changed and the present person knows what to do next.
Start with this moment
Helios Support is replacing its case-routing service. In a design review, engineering, operations, and product agree to launch with manual fallback for one low-volume region. The meeting feels clear. Everyone leaves quickly.
Ten days later, operations believes the fallback will be staffed around the clock. Engineering believes it will be available only during business hours. Product believes the low-volume region was removed from launch entirely.
No one is careless. The program simply has three memories.
Mateo, the TPM, does not schedule a meeting to debate who remembers correctly. He assembles the evidence, names the unresolved operating-hours question, and asks the accountable owners to close it. After the decision, he publishes six lines. The recap is short enough to be read and precise enough to be used.
What is really happening?
Communication is part of the program's architecture. A technical system has interfaces through which state moves. A program has interfaces too: reviews, decision records, plans, dashboards, escalation notes, and handoffs. When those interfaces are vague, human beings compensate with memory and private interpretation.
Diagram: Program memory is a living loop from conversation to decision, action, evidence, and an updated record.
The record is not valuable because it is written. It is valuable because it stays connected to action and evidence.
Writing also clarifies role boundaries:
- The decision maker owns the decision.
- Subject-matter owners own the accuracy of their evidence and commitments.
- The action owner owns delivery and updates.
- The TPM owns clarity across the interface: the choice is captured, ambiguity is surfaced, links are usable, and the record is revisited when evidence changes.
The TPM is not the team's permanent note-taker. If you capture every sentence, you may become a human storage system while the program remains unclear. Preserve the pieces that govern future action. Ask owners to correct the substance. Teach the system to maintain its own memory.
A day in a TPM's week
On Monday, Mateo notices that the launch page says "manual fallback available" but does not name hours, staffing, or owner. He marks the statement as an unresolved operating assumption.
On Tuesday, he sends a difficult but neutral message: "The launch plan says manual fallback is available. Operations and engineering currently have different assumptions about coverage. We need the operations owner and launch owner to decide coverage by Wednesday. I can host a fifteen-minute close if the written options are not enough."
On Wednesday, the owners decide on extended business-hours coverage with an on-call trigger for high-severity cases.
Mateo writes the six-line recap:
- Decision: Launch the region with extended-hours manual fallback and an on-call severity trigger.
- Rationale: Volume is low, but severe cases need a path outside staffed hours.
- Deferred: Twenty-four-hour staffing will be reconsidered after two weeks of live volume.
- Owners: Operations owns staffing; engineering owns the trigger; product owns the regional launch choice.
- Dates: Readiness check Friday; launch Tuesday; review two weeks later.
- Risk: Unexpected after-hours volume may increase response time; the on-call trigger is the control.
On Thursday, he links the recap from the launch page and decision log. On Friday, the readiness review starts from that record instead of retelling the meeting.
The writing has done its job when the program can move without Mateo narrating it again.
Pause and think
- Which important choice in your program exists only in people's memories?
- What does your status report repeat without helping anyone decide or act?
- If you were away next week, where would the team find the current truth?
Try this today
Find the most consequential meeting from the last seven days. Write a six-line recap using the pattern above. If one of the lines cannot be completed, you have found open work.
For a difficult message, use four parts:
- Shared fact: What can all parties verify?
- Observed change: What is now different from the agreed plan or expectation?
- Request: What decision, action, or answer is needed, from whom, and by when?
- Offered path: What will you do to help close it?
Remove blame, mood-reading, and decorative urgency. Keep the consequence. "You ignored the dependency again" creates a contest about character. "The interface date moved from May 8 to May 22, which removes the integration buffer. We need the two engineering owners to choose a recovery option by Thursday. I will bring the impact comparison" gives the program somewhere to go.
Add this to your TPM compass
Write your personal communication charter:
- I write when the program needs to remember ____________________.
- My updates will help the reader decide or act by ____________________.
- I will separate known facts from assumptions by ____________________.
- I will make ownership visible by ____________________.
- I will not use writing to ____________________.
- When the evidence changes, I will ____________________.
Then choose one reusable form for your compass.
Option A: Six-line recap
- Decision
- Rationale
- Deferred item
- Owners
- Dates
- Remaining risk
Option B: Four-part difficult message
- Shared fact
- Observed change
- Request
- Offered path
Keep the form near the place you write. A small, trusted pattern is more useful than a perfect template you never open.
Keep this thought
The TPM often becomes the keeper of connective tissue. The danger is believing that the tissue must live inside you. It should not. Write the connection down, give it an owner, and place it where the people doing the work can keep it alive.
A good record does not prove how much you attended. It lets the program remember enough to move.
Go deeper when you need the operating method
Use the flagship TPM course when you need detailed meeting systems and artifacts: