At a logistics software company of moderate size, the platform group had a reputation for competence and a calendar that told a different story. In the week before a major release, three of its five engineers were spending most of their time answering questions rather than doing the work the questions were about. This is the account of how the team, led by an engineer named Lena Okafor, introduced one regular status update and discovered that the quietest release in months came from saying less, more predictably.
Monday: the questions begin
The release was a database migration paired with a new routing service. Everyone knew it mattered. Customer support wanted to warn clients about brief slowness, sales wanted to avoid scheduling demos on the wrong day, and the finance director wanted to know whether a vendor invoice would be affected.
By Monday lunchtime Lena had answered the same question about the cutover time four times: once in the engineering channel, once by direct message from a support lead, once in a corridor, and once during a meeting that had nothing to do with it. Each time she gave the date. Each time she tweaked the wording slightly, depending on who was asking and how much detail seemed appropriate.
Her colleague Tomasz, who owned the database side, was having the same experience with a different set of questioners. Between them they had lost roughly half a working day, and nothing had been built.
Tuesday: seeing the pattern
At the Tuesday stand-up Lena did something unremarkable: she wrote down every question that had arrived since Monday morning. There were nineteen, and eleven were duplicates. The distinct ones fell into three groups. People wanted to know what had been completed, what would happen next and when, and what they were expected to do.
That grouping became the template. If those were the questions, those should be the headings of the answer. She proposed a trial for the rest of the week: one note each day at four o’clock, written by one person, posted in a single pinned location. Everyone outside the team would be asked to hold questions until then unless something was urgent.
Wednesday: the first note
Tomasz volunteered as sender, partly because he wanted the interruptions to stop and partly because he wrote clearly. His first note read, in essence:
- Done: staging migration rehearsed twice; rollback script verified; routing service deployed to the test environment.
- Next: third rehearsal on Thursday morning; go or no-go call Thursday afternoon; production cutover Friday after business hours.
- Needed: support lead, client notice text by Thursday noon; finance, confirmation that the invoice run can wait until Monday.
It was under a hundred words. Within an hour the support lead replied with her draft notice. Finance confirmed the invoice timing. Nobody asked for the cutover date, because it was written down in a place they now knew to check.
Wednesday evening: a small adjustment
After the first note went out, the team spent ten minutes reviewing it. Two things stood out. The “Needed” section had been read by the people named in it, which was the whole point. But the phrase “rehearsed twice” meant little to the finance director. Tomasz changed the wording to “test run completed twice with no data loss”, which was both plainer and more informative for non-engineers.
The team also agreed on a rule for urgent items: if something could not wait until four o’clock, the sender would post a short flagged message and fold it into the next note. That kept the rhythm intact while leaving room for real emergencies.
Thursday: the skeptic converts
Not everyone was convinced. The head of sales, Marcus, wrote that he would rather just ask. Lena told him that was fine, but that if he asked he would be pointed to the note and she would answer anything missing from it. That evening he looked at the update, saw that Friday night was the cutover window, and moved a client demo without needing to speak to anyone.
Thursday’s note also showed its value when a rehearsal turned up a slow query. Tomasz reported it plainly under “Done” with the fix under “Next”, and listed a code review request under “Needed” with a name and a time. The reviewer replied before the end of the day. Previously this sort of issue would have triggered a flurry of side conversations and uncertainty across the company.
Friday: the quiet cutover
Friday’s note was shorter still: window confirmed, rollback ready, no requests outstanding. The cutover went as planned. Because stakeholders had received consistent news all week, there was no flood of “is it done?” messages that night. Support had warned its clients, sales had adjusted, finance had waited. The team spent the evening focused on the work.
The following Monday, Lena counted the questions again. The number of direct questions about release status had dropped from nineteen to two, and neither was a duplicate.
What the team took from it
In the retrospective, the engineers named a few lessons that others may find useful.
- The sender should be chosen for clarity, not seniority. Tomasz was not the most senior, but he was the best at writing short, exact notes.
- Naming people and dates in the request section changes behaviour. Replies came faster to named asks than to generic ones.
- A published rhythm lowers the volume. Once people knew there was a four o’clock note, they stopped asking at two.
- Bad news fits the format. The slow query was reported without drama and handled quickly.
The team also noted a cultural effect. Stakeholders who had previously felt kept in the dark now felt included, even though they were receiving no more information than before. They were simply receiving it in a predictable way.
Where the team looked for ideas
While designing the format, the engineers read around on incident handling and operations practice. A piece on shortening the time it takes to resolve IT problems reinforced how much of a fix is coordination rather than diagnosis. Another article laying out a staged route to smarter IT operations was a reminder that tooling decisions go better when updates give leaders a clear view of progress. And the discussion of ways to relieve the strain of constant alerts prompted a parallel thought: people suffer fatigue from questions as well as from alarms.
A parallel outside engineering
Months later, a team member’s family faced a different logistics puzzle. A relative was travelling overseas for a service and several family members were going along. Flights, lodging, local transfers and documents produced a steady rhythm of questions, and the same relative who had been the family’s unofficial help desk before took on the role of sender. One short note, limited to travel, lodging and paperwork, replaced a dozen calls.
While comparing options, the family browsed a US-based medical tourism facilitator’s site, which says it connects international patients with hospitals in many countries and provides quotes, chat support and online appointment booking. The family treated those statements as the company’s own claims, to be checked independently. What stayed with the engineer was the structural lesson: a single organised route and a single organised message both reduce friction.
Practical takeaways for your own team
- Tally the questions for two days and group them. The groups are your headings.
- Choose a sender who writes clearly and can collect inputs by a deadline.
- Publish the schedule and the location, and keep both stable.
- Write requests with a name and a date.
- Report problems in the same neutral voice as progress.
- After the event, review whether the questions fell, and adjust headings.
Epilogue
The platform team kept the practice after the release. They moved it from daily to twice weekly and then to weekly as the pace of work calmed. Lena now says the most valuable thing about the experiment was not the time saved, though that was real. It was the shift in how colleagues perceived the team. Where once they had been seen as busy and hard to reach, they became known as the group whose status was always easy to find.
That reputation took a week to build, cost a few minutes a day, and has outlasted every release since.