Engineers care deeply about observability. We instrument systems, build dashboards, define SLOs, and set up alerts. Because a system you can’t see is a system you can’t improve. We’d never run production infrastructure without telemetry.
Then we run teams with no telemetry at all.
No signal on whether the week moved things forward. No structured way to surface blockers early. No feedback loop that converts experience into better execution. Just meetings, Slack noise, and the vague sense that things are either fine or not fine.
A month into managing a team, I wanted something better. So I built a lightweight weekly framework I call RRE — Recap, Rewind, Execute. Think of it as observability for team performance.
The problem it solves #
Without structured reflection, teams tend to repeat the same problems, lose context between weeks, and operate reactively. Wins get forgotten. Blockers stay invisible until they’re crises. The feedback loop that should make the team progressively better doesn’t exist, because nobody closed it.
Most retrospectives are too heavy for weekly use. Status reports track activity, not progress. What I wanted was something that takes 5–10 minutes to write, creates genuine learning, and doesn’t feel like bureaucracy.
RRE has three parts. Each one does specific work.
Recap — what actually happened? #
Not a task list. Not a Jira export. A brief, honest summary of what moved.
Delivered outcomes. Important decisions. Key milestones. The question is: what actually changed this week that wouldn’t have changed anyway?
This part is harder than it sounds. Most weeks, people have been busy. Busy is not progress. Recap forces the distinction — it makes you articulate what you actually shipped, not what you worked on.
Rewind — where the improvement happens #
This is the part most teams skip, and it’s the most important.
Rewind asks four questions:
- What worked unexpectedly well?
- What slowed us down?
- What should we stop doing?
- What should we repeat next week?
The purpose is to convert experience into better execution. Not blame, not venting. Just honest signal about what the week is trying to tell you. One good Rewind, acted on, is worth ten retrospectives that produced a list of sticky notes nobody looked at again.
The Rewind is where RRE earns its name. You’re not just reflecting. You’re extracting.
Execute — close the loop #
Reflection without action is just journaling. Execute closes the loop.
Define 1–3 focus areas for the coming week. Carry forward the adjustments from the Rewind. Make the learning visible as intent.
The Execute section is also a forcing function: if you can’t write down what you’re going to do differently next week based on what you learned this week, you haven’t actually learned anything yet.
Why it works (when it works) #
RRE isn’t novel. Weekly reflection has been a good idea for a long time. What makes it useful is the constraint: short by design, structured enough to be consistent, honest enough to be worth reading.
The Sinek framing I keep coming back to is the infinite game — the idea that the goal isn’t to win any given week, it’s to keep getting better. RRE operationalises that. It makes “are we actually improving?” a question you answer with data, not optimism.
A few things I’ve found matter for making it stick:
Outcomes over effort. “Worked hard on X” is not a result. RRE should surface what changed, not what was attempted. If your Recap reads like a timesheet, you’re writing the wrong thing.
Honesty over polish. RRE is not performance theatre. If the biggest issue this week was unclear ownership of something important, write that. If you didn’t deliver what you said you would, write that and explain why. The value is in the signal, not the framing.
Consistency over perfection. Weekly rhythm matters more than perfect writing. A mediocre RRE written every week beats a great one written once a month.
What it’s not #
RRE is not a status report. It’s not surveillance. It’s not something I read to check whether people are working hard enough.
It’s a tool for making the team smarter every week. The difference between a team that’s been running for two years and one that started last month shouldn’t just be seniority. It should be two years of accumulated learning. RRE is how you accumulate that learning deliberately instead of accidentally.
I’m a month into this role. I don’t know yet whether RRE will work the way I think it will. But the absence of this kind of structured reflection — in every team I’ve been part of — has felt like a gap worth trying to close.
If you’re running something similar, or have opinions on what works and what doesn’t, I’d genuinely like to know. Find me on LinkedIn.