Aiko led a small platform group, and her team had a problem that no dashboard could show. Every few weeks an outage would occur, the engineers would fix it competently, and then the messages sent to the rest of the company during the incident would be vague, late or both. People outside the team learned about problems from customers instead of from her. This article follows her diagnosis, her fix and the routine she used. If your team resolves incidents well but communicates about them badly, the same incident communication practice may help.
The symptom: good fixes, poor updates
Nothing was wrong with the engineers’ technical judgment. The trouble showed up in what they typed into the shared channel. Typical messages read “looking into it” for forty minutes, followed by a long paragraph full of internal service names once the problem was already solved. Managers asked the same three questions repeatedly: what is hurting, what the response is, and when more will be known.
Aiko’s first instinct was to schedule a training day on incident handling. She hesitated, because she had seen such days before. Everyone nodded, took notes, and the next real incident looked exactly like the last. The content was not the problem. The habit was.
The diagnosis: they had never rehearsed the writing
When she thought it through, Aiko saw that her team practised the technical side constantly, because outages forced them to. But writing a short, calm update under pressure happened only during real incidents, when stress is high and the stakes are real. Nobody had ever tried it in a quiet moment and received feedback.
It resembled a swimmer who only ever swims in rough water. Experience accumulates, but the mistakes do not get corrected, because nobody is watching closely enough and the moment moves too fast. What the team needed was a small, repeatable exercise in calm conditions, with someone honestly telling them what worked.
The fix: a ten-minute drill with a fixed shape
Aiko designed a drill she could run in a stand-up slot. It had the same shape every week.
- She read out a two-sentence description of an invented problem, such as “the sign-in page is slow for some users and nobody knows why yet”.
- One engineer had four minutes to write a status update of no more than five lines.
- The group checked the draft against three questions: could a non-engineer tell from the text alone what is affected, what the team is doing about it, and at what time the following message is due?
- The author rewrote one line using the feedback and read it aloud.
The rule that mattered most was in step four. Only one line could change. That kept the feedback specific and prevented the common failure where a draft gets rewritten from scratch and nobody learns which change helped.
What the feedback sounded like
In the early weeks, comments were blunt but useful. “You used the name of an internal service nobody outside this room knows.” “You said you were investigating but not what you had ruled out.” “There is no time for the next update, so people will keep asking.” Each remark pointed at a fixable habit.
Aiko set one ground rule: criticise the sentence, not the person. She also took her own turn writing updates, which made it easier for others to accept comments. Within a month the team had a shared sense of what a good update looked like, and the drafts started to resemble each other in a healthy way: plain words, a stated impact, a stated next step.
Why the quiet setting mattered
It is tempting to think that pressure is the best teacher, and that engineers simply need more real incidents to become better communicators. Aiko came to the opposite view. Under real pressure, attention is consumed by the technical problem, so there is almost no spare capacity to notice how a sentence reads. A quiet slot on a Wednesday gave the team spare capacity. They could pause on a clumsy phrase, argue about whether “degraded” or “slow” was clearer for customers, and try again right away. That kind of immediate retry is nearly impossible during an outage and it is exactly where the learning happens.
Raising the difficulty
After the basics settled, she made the exercise harder, because a drill that never stretches anyone stops teaching. She shortened the writing time to three minutes. She added a twist, such as “the cause turns out to be a change your own team made”. She asked for an update aimed at the executive team rather than at support staff, then at a customer-facing audience.
Each variation targeted a particular weakness the group had shown. The twist about their own change exposed a habit of passive phrasing that sounded evasive. Working on it did more for the team’s credibility than any process document could have done.
What happened in a real incident
About two months later, a genuine slowdown hit a payment-related service on a busy afternoon. The engineer on duty posted a short update within a few minutes, naming the affected function, saying what was being checked, and promising the next message in twenty minutes. The next message arrived on time. Support colleagues stopped sending direct messages asking for news. Afterward, a manager remarked that it was the first outage where she did not need to ask a single question.
Technical recovery took about as long as it ever had. What changed was the behaviour around it, and that behaviour had been built from small, honest rehearsals in calm moments rather than from a lecture.
Lessons worth borrowing
- Isolate the skill. Writing an update is separate from fixing an outage, so practise it separately.
- Use a time box. Four minutes forces choices that an open-ended exercise lets you avoid.
- Change one line. Narrow adjustments teach more than wholesale rewrites.
- Keep it calm. Rehearsing when nothing is burning lets people think about their mistakes.
Not every team member liked it at first. Some felt silly writing about invented problems. What turned the sceptics was simple: the first real incident went better, and they noticed. The wider topic of getting a group to change habits, rather than just opinions, is explored in the site’s guide on managing the cultural side of adopting DevOps ways of working, and the discussion of early obstacles from too many tools to shifting attitudes covers related ground.
Finding a partner for the drills
Aiko eventually asked herself whether an outsider might design better exercises than she could. If your team reaches that point, you can search the DevOpsTrainer directory, with listings for trainers, instructors and coaches in DevOps, plus formats for team workshops as well as individual upskilling. A good fit is someone who can name the specific habits your group needs to fix.
For individual engineers who want a longer view of where such skills lead, a sober roadmap for building a career in this field places communication alongside technical depth.
Starting your own version
You do not need approval or budget. Choose a ten-minute slot you already own. Write three invented problem statements. Decide on a five-line limit and three questions for judging each update. Take turns, change one line after each round, and write down the habits that come up repeatedly. Within a month you will probably have a short list of fixes that apply to your team in particular, and a calmer way of talking when the pager goes off.