In retrospect on retrospectives
One of the more powerful tools you have at your disposal as a software engineering manager is the retrospective - specifically sprint and team retros.
These represent opportunities to unplug from the hustle and bustle of active work and instead talk about how you work.
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.
========
The above is a slightly edited portion of the book I’m working on. I shared it this week with IndyHackers - a community organization for Central Indiana makers of technology that I’ve long been a member of and recently joined the board.
I posted it because a relatively new engineering manager - or new to a team at least - was feeling resistance from their team about the number of meetings they had to ~endure~ attend.
The conversation eventually got around to retros - the place I often fielded that sort of feedback (I know, feedback about meetings in a meeting … I should talk about effective meetings sometime).
Some feedback from that audience:
I’ve run like 20+ sprint/team retros in the last year and
> Of note: Keep these meetings contained to your team directly - do not include management higher than you, or members of other teams.
this is so important, the couple where we had mgmt come in to observe were just so useless
And:
Two points I'd consider adding are:
Occasionally mixing up the format helps keep the meetings fresh and easier to engage with.
Anyone on the team can own/run these. In fact it may be more impactful to have a "non-leadership" team member do so, provided they have interest in doing so and are willing to learn the skills: keeping the meeting moving through the agenda, recalling the team back to propose when things get tense or head off down a rabbit hole, etc. (Note: this is because I'm a big fan of self-organizing teams. I believe it increases intrinsic motivation.)
Those are both great points!
I go more into format in the full book chapter, and slightly adjusting the flow and order makes a lot of sense. Generally, though, try to keep the format flowing from fraught and negative to positive by the end.
As for who runs these meetings, handing the reins to a team member who is interested in people management is a great idea. The one caution I would add is to maintain the last spot in each round to yourself - you need that space to cover up missing items and reinforce the important bits that others mention.
========
I’m writing this on a late Sunday morning at a coworking office - my relatively new coworking office housed in a former grocery store warehouse.
I skipped sending a newsletter last week while I worked more on the business than in it - setting up new banking and pondering what it is I’m doing here.
In the end, I’ve settled on wanting to help people - specifically software engineering managers at software startups.
It’s a hard job, and one that very little is done to prepare you for.
Talking with some folks last week also reminded me that the failure mode of trying out this job is burnout on one extreme and retreating back to the warm embrace of programming full time on the other.
I feel that, but I also know that on the other side of that messy transition is the most rewarding job I’ve ever had - helping folks to grow their careers.
Which, I guess is ultimately what I’m also trying to do here.
Thanks for being part of the ride, and I’m here for you if you have something on your mind.
Reply anytime; I’m probably refreshing my inbox for your email right this second.