Your team shipped on Thursday. On Friday morning the invite for the next sprint planning landed. By lunch the board was full again, and nobody had said a word about Thursday.
I've run engineering teams for a long time. I've sent the invite. I've been the reason nobody said a word.
Claude Silver is Chief Heart Officer at VaynerX. When she joined Debra and me on Corey-osity Unleashed (S1E9), she described a problem I recognised straight away. Her CEO, Gary Vaynerchuk, is a disruptor and an entrepreneur, always onto the next thing. In a company like hers, she said, it's easy to "go fast, fast, fast, fast, fast. But we have to stop."
Stop and do what? "Hand out the roses, whatever they are."
Her line boils down to four words: celebrate, then accelerate. In software, the order matters. Most of us get it backwards.
Scrum Wrote the No-Pause Rule Down
This isn't a vibe. It's in the rulebook.
The Scrum Guide calls Sprints "the heartbeat of Scrum". Then it says: "A new Sprint starts immediately after the conclusion of the previous Sprint."
Immediately. No gap. No breath. The principles behind the Agile Manifesto go further. Sponsors, developers and users "should be able to maintain a constant pace indefinitely."
I don't think the authors meant "never stop to say thank you." The Guide builds reflection into two events. But look at what each one asks for. "The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations." "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness."
Both point forward. Neither one asks anybody to stop and say "well done."
So the process gives you a heartbeat with no rest between beats. If you want a pause, you have to put it there yourself. Most of us don't.
Speed Is the Excuse. It Isn't the Reason.
When I ask leaders why they skip the celebration, the answer is always time. We're behind. The roadmap is full. The next deadline already sits on the calendar.
I've given the same answer. Here's what I learned since. It was never about time. A thank-you takes thirty seconds. A proper one takes five minutes.
I skipped it because finishing felt like the baseline. Shipping was the job. Celebrating the job felt soft.
Here's the trap. Engineers learn to hunt for what's broken. A green build is the expected state. Nobody throws a party for the expected state. We save our attention for the red ones.
Your team notices. They see the incident get a forty-person post-mortem while the clean launch gets nothing. They learn which work this place sees. Then they adjust.
Your Team Isn't Getting Enough Roses
Gallup and Workhuman run a joint study on workplace recognition. In Gallup's 2024 write-up, only 22% of employees say they get the right amount of recognition for the work they do. The number hasn't moved since 2022.
The same article reports longitudinal data from 2022 to 2024. Well-recognised employees were 45% less likely to have turned over after two years. They were also 65% less likely to be actively looking or watching for another job.
For engineering leaders, the next number stings. Gallup estimates replacing employees in technical roles costs around 80% of their salary. Their estimate excludes the lost morale and knowledge walking out the door with them.
Run the sums on your best backend engineer. Then tell me you don't have five minutes on a Friday.
I'm not sure about this part: Gallup's figures cover recognition across industries. I found no study isolating software teams on fixed sprint cadences. I'd bet the pattern holds for engineers, but I haven't seen the data.
My own research points the same way. 99.5% of the people I surveyed said they've had one or more types of bad boss. I share more of it at Step It Up HR. The boss who never notices the work is one of the easiest to become, because it takes no effort at all.
What a Rose Looks Like on an Engineering Team
Claude was clear. Roses come in every size, and leaders need to hand them out "on a micro and a macro scale." Her examples were small. "Thank you so much for showing up." "Thank you so much for working those three weekends in a row."
Here's how I'd translate her advice for a software team.
Put the pause on the calendar
Add a fifteen-minute slot between the Sprint Review and the next Sprint Planning. Give it a name nobody will mistake for a status meeting. Spend it on what went right and who made it happen. No backlog. No tickets.
If the slot isn't on the calendar, the next sprint will eat it. Every time.
Name the person and the work
"Great job, team" is noise. I've written about this before. Say who did what and why it mattered.
Something like this: "Priya rewrote the migration so we shipped with zero downtime. Support had a quiet Monday because of her."
Thirty seconds. Specific. True.
Look for the invisible work
The feature demo gets the applause. The engineer who spent the sprint fixing flaky tests gets silence. So does the one who wrote the runbook, or reviewed thirty pull requests, or mentored the new starter.
Hunt for the work nobody demoed. It's the work most likely to go unseen, and the people doing it know it.
Don't wait for the big launch
Big releases are rare. Small wins happen every day. If you only celebrate the quarterly launch, you celebrate four times a year and stay silent the rest. I made the same argument about celebrating first downs instead of waiting for touchdowns.
Celebrate first. Then talk about what's next.
Order matters. Open the Friday meeting with "great release, now about the Q1 roadmap" and the roadmap is all anyone hears. Give the win its own moment. Let it land. Then move on.
What the Pause Is Not
The pause isn't a pizza budget. It isn't a release party once a quarter with a slide deck about velocity. It isn't a Slack emoji on the deploy notification.
Those things are fine. None of them tell a person you saw what they did.
The pause also isn't a performance review in disguise. If you use the fifteen minutes to slip in "and next time, let's tighten up the estimates", you've turned a rose into a ticket. Your team will spot the move the first time you make it. Keep the critique for the retro. It has its own slot for a reason.
The Leader Goes First
Claude called recognition something "on my head a lot." Her job title has the word heart in it, and she still has to work at it inside a fast-moving company. If it takes effort for her, it will take effort for you.
Your team copies you. Rush from release to planning, and they will too. Peer recognition dries up when nobody sees the boss do it. I've seen it happen, and I've written about why recognition only flows downhill in most companies.
Go first. Say the name. Say the thing. Then watch who follows.
Celebrate. Then Accelerate.
Speed isn't the enemy. I like shipping fast. My background is engineering, and a team in flow is a joy to watch.
But a team running sprint after sprint with no pause isn't in flow. It's on a treadmill. The scenery never changes, and nobody remembers the last mile.
The fix costs fifteen minutes a fortnight. Put the pause in. Hand out the roses. Then plan the next sprint.
When did your team last hear "well done" before they heard "what's next"?