Landing the Daily

Lowering the abstraction without sounding like a robot: a Yesterday/Today/Blockers template, which jargon to translate and which to keep, and a speaking technique that stops people cutting you off mid-list.

"Your turn?"

"Uh… yesterday I was looking at the mapping thing. There was a problem with the repository, so I was looking at that. And today I'm continuing with that."

Two "was looking at", two "that", and no hint of what actually got delivered.

There comes a point where communication matters as much as the code, and the daily is the perfect example: it's the moment you have to bring down the abstraction you think about your work with, and bring down the technical level you describe it with.

#The filler isn't a memory problem

What usually happens is that we don't remember in detail what we were on, so we fill the silences with filler.

And here's the uncomfortable part: that filler doesn't read as "I don't remember." It reads as poor time management and lack of preparation. Even if you had a productive day.

The fix is as boring as it is effective: take notes while you work, however minimal. One loose line every time you close something. It all adds up. Then, when your turn comes, you read it.

It doesn't need to be tidy. It needs to exist.

#The golden rule

Before the template, the criterion that orders everything else:

Every sentence has to answer "what does this change for the business or the user?" If you can't answer that on the same line, the sentence is still too technical.

It's the filter that turns a commit log into communication.

#The template

Structure: Yesterday / Today / Blockers.

Granularity: one item per feature or user story. Never per technical step. This is the one that changes the outcome most: it isn't that you speak "more simply", it's that you group differently. Five technical steps are a single item if they deliver a single thing.

#What to translate and what to keep

Here's a nuance that gets missed often: translating everything is also wrong. Oversimplify and you sound condescending, and you lose precision on top of it.

Keep the terms your audience already handles: user stories, development environment, DevOps, sprint. Those words are already part of the team's shared language.

Translate only pure implementation jargon: script, DTO, handler, repository, endpoint, query. None of that means anything to someone who doesn't write code.

#Examples: tasks

The first is the same work told as a process, one item per step. The second is the same work told as a result.

Notice the technical detail doesn't disappear in the good version: it sits at the end, after the dash, as a footnote. It's available to whoever wants it, but it isn't what structures the sentence.

#Examples: blockers

A well-written blocker has three parts: subject + what you need + from whom.

The first describes a state. The second asks for an action, and names who has to take it.

And one clarification that saves arguments: if more of your own time solves it, it isn't a blocker — it's a long task. A blocker is something that doesn't depend on you.

#A complete daily

Yesterday:

• Gathered the information needed to start on the vehicles work.
• Wrote the user stories to track it.
• Started preparing the load of that data into the system.

Today:

• Finishing the data load and testing it in the development environment before touching the real system.

Blockers: none.

None of that mentions a technology, and yet anyone on the team knows exactly where you are.

#Closing each point so nobody cuts you off

This part isn't about what you say but how it sounds — and it's the one people notice fastest.

The technique is called downward inflection: as you finish a sentence, you drop your pitch and slow down. The listener's brain reads that fall as "a complete idea just closed." If instead you finish on a rising tone, like someone asking a question, it sounds like you left the door open — and that's when you're far more likely to get cut off.

Think of it as a plane landing. During the flight you hold altitude and cruising speed: normal conversational tone. On the final stretch, the last few metres before touching the runway, you descend and slow down in a controlled way. That descent is what tells the tower you're landing and not still in the air.

If you cut the engine mid-air, or worse, if you never come down and stay at altitude with a flat tone, the listener doesn't know whether you finished or are about to continue. And that's when they jump in.

The common mistake is putting that drop in the middle of the sentence. It does nothing there: it has to be specifically at the close of the idea. It's the landing at the end of the flight, not turbulence along the way.

#One short flight per item

This works even better in list form, because each item is its own short flight. You start at a normal tone, develop it, and land at the end of that item — not just at the end of everything.

"Gathered the information needed to start on the vehicles work." (land — brief pause) "Wrote the user stories to track it." (land — brief pause) "Started preparing the load of that data into the system." (land)

Each landing marks "this item closed, the next one is coming", and the pause gives the audience room to process before you start the next.

And as a bonus: it makes it much harder for anyone to cut you off mid-list, because you never give the impression of being in the air — which is exactly when people take their chance to jump in.

#What's left

The daily doesn't get prepared in the daily. It gets prepared during the day, in one loose line every time you close something.

After that it's just reading what you already know, grouped by result instead of by step, and landing each point before moving to the next.

#communication #agile #daily #soft-skills