One of the more powerful tools you have at your disposal is the retrospective.
These represent opportunities to unplug from the hustle and bustle of active work and instead talk about how you work.
You might already be doing a flavor of retrospective tied to incidents and outages – many security certifications require such things.
These retrospectives are focused on a particular point in time and what went wrong, how it could have been prevented, how you fixed it, and how you’re going to keep it from happening again.
Lots of prior writing exists on this type of retro, but the only bit I’ll add is that these can be fraught. Be careful to explicitly make them blameless and concentrate on the problem you’re solving, not the people involved.
Mistakes and bugs happen, and can happen to anyone. Outages are an organizational failure, not a personal failure.
With that out of the way, I’d like to concentrate on two other flavors of retrospectives: sprints and team.
These represent a wider lens of focus. It’s not a point in time, but a larger period of time, and can be focused on particular areas.
They are also more meta and less tied to specific problems.
Many organizations skip these, feeling it’s a meeting that takes away from active development time and effort.
Poorly run ones can also feel like a waste of time or “just another meeting” to your engineers. And poorly run ones of the past have already ingrained a deep pattern for them to match.
I’d argue, though, that these meetings represent the best time to accelerate development for your team because they are a chance to step out of the process and interrogate the process itself.
Taken seriously, sprint retros and team retros can uncover trouble spots in processes and opportunities for improvement. They’re also extremely handy to break out of 1:1s and reinforce patterns you might have noticed across individual engineers.
Of note: Keep these meetings contained to your team directly – do not include management higher than you, or members of other teams.
You are trying to create a psychologically safe space to release pressure and uncover opportunities to improve. It’s difficult to pull off if there are outside parties participating.
If a higher up wants in, let them know that you can update them later or schedule a separate meeting.
Keep these constrained and regularly scheduled. Schedule the next one at the end of the meeting.
As far as format, I’d recommend:
Context setting
Recap the time period involved and set the table for what you’re about to discuss. If it was a difficult period, acknowledge it. Acknowledge any obvious wins and obvious challenges to try to dry up the obviousness from the options.
If the team has changed, highlight the new participants or acknowledge the missing members.
Remind folks of the format: the questions to come and the need for every participant to answer.
Ask these five questions, in this order
The questions are in a particular order, largely from curmudgeonly to hopeful and from past to future.
I settled on this order over many trials, noticing that starting with what went poorly tends to get all the bad stuff out in the open, setting a better context for later questions. I also noticed that ending with what went well and what we should start will shift the mood into a more positive place coming out of the meeting.
1. What went poorly?
In bad sprints or months or quarters, the “poorly” section can get deep and dark – this order ensures your team leaves the meeting and goes back into their work stream on positive notes and hopes for improvement. Starting with this question gets all the dirty laundry aired; it starts with the problem(s).
Critically, this is not the time to solve these problems. And it’s not the time for you to grow defensive about any of them.
This is laying the cards on the table and figuring out what sort of game you’re playing.
It might be necessary for you to start if your crew is hesitant to air their grievances – this isn’t often the case but is sometimes necessary. Occasionally, you need to lead the team and demonstrate that criticism and problem identifying is fine – you can’t fix problems unless you identify them first.
And trust me, your engineers have likely spotted lots of problems – you need to make it so that they are comfortable in sharing them.
Sometimes, that means you go first.
2. What could be improved?
This represents a natural follow up from the first question and gives a small opportunity for problem solving – starting the climb out of the morale hole you might have dug in the first question and getting the meeting squarely into a solution-focused mindset from here on.
3. What should we stop?
One of my favorite jokes involves a man visiting his doctor.
He tells his doctor, “Doc. It hurts when I do this.”
The doctor replies, “Easy. Don’t do that.”
Sometimes, it’s the same with teams and processes. The easiest changes to implement are often the times you can stop doing some action or step. What can we eliminate from our workflows and processes?
4. What went well?
Finally, we start the uphill climb in earnest.
This is the opportunity to publicly praise, and, unlike with what went wrong, I’d encourage you to save your contribution for last.
Going last gives you the opportunity to close on the note you want and to either double-down on existing team praise or spread the praise to some corner that was missed.
Think holistically on what went well and what behavior you’d like to reinforce or what team member could use a deserved boost.
5. What should we start?
To close, we jump from looking backward into the past and move into the future. When we leave this meeting, what are we going to start doing? Where do we go from here?
What’s next?
The takeaways and action items
Like any meeting, we close with a recap which includes a summary of the topics discussed and any action items we have agreed to undertake along the way – up to and including that you need some time to think through some things and will get back to the team with outcomes.
Get the next retrospective on the calendar
I’ve run these retros at various stops in my career and have found them extremely valuable as public forums to air issues that might have come up in private contexts and to iron out sticky spots in processes or to discover friction among the team or in the process that needs to be sanded out.
Structured this way, they also serve as a type of release valve for the team as a whole.
I mentioned earlier that software engineers like to complain about their jobs and work. Some of that is the nature of the job – you’re constantly fixing problems and identifying other problems. Eventually, the eye wanders outside of code and into the working environment.
Engineers _will_ complain.
If they aren’t complaining to you or other managers, they’re complaining to each other in Slack DMs, over beers, over lunch, in text messages.
And those environments don’t diffuse the complaints or resolve them; they amplify them and darken their context.
If you let this go unchecked and unmitigated, it will eat away at the core of your engineering culture. A culture that is “good vibes only” often masks an underbelly of dissatisfaction.
That underbelly manifests itself when engineers start complaining to colleagues outside of work and then to recruiters – and then they leave for greener grass to start the cycle all over again.
Your job as a manager is to stop the cycle for as long as you can.
Doing it in a team environment gets the team working in a shared context and doing these questions in this order gets them quickly into a solution-oriented mindset and leaving the meeting in a sunnier place than they started.
This is part of my Editorial framework, a set of modular tactics and strategies that help software companies ship with speed, alignment, and safety at the same time.