Students of DevOps quickly learn that software delivery is as much about people as pipelines. Teams make promises to each other on calls: “we will have the environment ready”, “we will review it before release”, “we will tell you if the interface changes”. Then those promises meet reality. This question-and-answer guide examines the habit that stops most of that drift, a short written follow-up after the conversation, and answers the questions learners raise when they first hear about it.
What exactly is a written follow-up?
It is a brief message, sent by whoever organised or best understood the conversation, that repeats back three points: the decision reached, the date attached to it, and the plan if conditions shift. It is not minutes, not a contract and not a formal report. Think of it as a mirror held up to the call so every participant can check the reflection.
Why do verbal agreements drift in the first place?
There are at least three mechanisms, and each is well understood from everyday experience of how people remember conversations.
- Selective recall. Each participant retains the parts that matter to their own work and loses the rest.
- Reconstruction. When details are missing, people fill gaps with what seems most plausible, not with what was said.
- Time pressure. Calls end quickly, and the next task starts before anyone clarifies the loose ends.
None of this is a character flaw. It is how human memory works, which is why the remedy is a process and not an exhortation to “pay closer attention”.
Does it matter more in DevOps than elsewhere?
The need is general, but DevOps raises the stakes because work crosses boundaries by design. A change in one team’s service can affect three others, and the people affected may not have been on the call. A written note travels to them; a memory does not. Our overview of cross-functional team structures and their trade-offs describes the same dynamic from the organisational side, where the quality of hand-offs between functions decides how smoothly work flows.
How long should a follow-up be?
Shorter than you expect. Two to five sentences cover most situations. Length is not a measure of care; a long message hides the single important line. Put the most consequential commitment first, then the date, then the change rule.
What should it contain for a typical technical agreement?
Consider a call in which a platform team agrees to provide a test environment for an application team. A useful note might state:
- The deliverable: a staging environment resembling production in the ways that matter for testing.
- The date it will be ready and the person responsible.
- Any restrictions, such as shared use or a limited lifetime.
- How the application team will be informed if the date slips.
Four lines, and almost every common source of later friction has been addressed.
Who should send it?
The person who is waiting on the outcome has the strongest incentive, so they should usually send it. However, anyone can. A practical team rule is that the person who ends the call by saying “let me confirm that in writing” owns the message. Teams that make this explicit avoid the opposite failure, where everyone assumes somebody else will write.
Is it not just more bureaucracy?
Candidly, the result turns on how it is carried out. Bureaucracy is process that consumes more effort than the risk it removes. A two-line message costs minutes and prevents rework that can cost days. Work on organisational change, such as the points raised in our article on managing the human side of a DevOps transition, repeatedly finds that people accept lightweight habits and reject heavy ones. The follow-up note belongs firmly in the lightweight category.
How does it relate to managing risk?
Many delivery failures trace back to an assumption nobody examined, such as who owns an interface or what the rollback window is. A follow-up note is a cheap way to expose assumptions while they can still be corrected. This connects directly with the thinking in our practical treatment of risk in reliable delivery: risks that are written down can be discussed, and risks that stay in people’s heads tend to be discovered by production.
What if the other person replies with a correction?
Celebrate it. A correction at this stage is the habit working as intended. Thank the person, update your understanding, and, if the change is material, send a revised note so only one version remains in circulation.
What if nobody replies at all?
For low-stakes items, treat silence as consent after a stated period. For anything costly or hard to reverse, ask for an explicit “yes”. A useful phrase is “unless I hear otherwise by tomorrow noon, I will proceed on this basis”, which gives silence a clear meaning.
Can a follow-up be too blunt?
Yes, if it reads like an accusation. “Per our call, you committed to X” puts the reader on the defensive before they reach the second line. Prefer first-person phrasing: “I understood we would X; please tell me if that is not right”. The content is identical, but the tone invites collaboration, and collaboration is the whole point of the exercise.
Should the note go to everyone on the call?
Usually yes, and add anyone who will be affected but was absent. The wider circulation matters in distributed teams, where a person in another time zone may learn about a change only through the note. A short distribution list avoids the situation in which one team acts on the agreement while another has never heard of it.
Where should the notes be stored?
Wherever your team already looks for decisions: a ticket, a project channel or a shared document. The best location is the one a newcomer would check first. Avoid private inboxes, because a record only its author can find is barely better than a memory.
Does it apply to dealings with outside professionals?
Yes, and the structure is identical. Teams sometimes need advice outside engineering, such as a chartered accountant for questions about how a training budget or contract is recorded. A browsable online directory that lists chartered accountants can be filtered by place, area of specialisation and whether the discussion takes place remotely or in person. After any such conversation, the same short confirmation applies.
How can a learner practise this?
Use your training projects as a rehearsal space. After every pair session, group lab or mentor conversation, send two lines stating what each person will do and by when. Keep the messages in one place. Within four weeks you will own a modest archive that demonstrates, concretely, how often memories diverge and how often a note resolved it.
What is the simplest template?
Copy this and adjust it:
“Thanks for the call. My understanding: [what was agreed]. This will happen by [date], with [person] responsible. If anything changes, [how we will tell each other]. Please correct anything I have misstated.”
What is the main takeaway?
Agreements that exist only in speech decay quickly, and the decay is invisible until it causes rework. A short written follow-up makes the agreement visible, shared and correctable. It costs almost nothing, it suits the collaborative spirit of DevOps, and it is a skill that students can build well before they join their first team. Adopt it, keep it brief, and judge it by what it prevents, rather than what it adds.