I've had success with retros since I was introduced to them back in my first role as an engineer. I've always found them helpful from the perspective of improving on the more existential crises that teams I've been a part of run into and a good space for recognising the team's accomplishments as a whole.
One problem I've tried to tackle more recently is when trying to reflect on issues specific to a smaller (or sub) team when doing retros with a broader team. When trying to raise issues, it can be hard to get the engagement of everyone present because they weren't running into those problems or lacked context. The lack of context was also a hard one to tackle because there was so much context to give in the first place and that usually came with a lot of past baggage that came kicking and screaming with it.
Because I had a fair amount of autonomy in my position, I thought this marked a good time to introduce retros that focused on our product.
Finding the right people
Right off the bat, I had a small group of people interested in meeting and reflecting on the work this small team was getting done. My direct report and I were the engineering team behind things, and we had a UX designer that had worked closely with us for two years at that point, and we had a breadth of experience to look back on that we'd not done at that point.
We also had the idea of "product captains", members of the CX teams that would essentially be the experts on individual products we were offering. The product we owned had two, as there were two components to the product that, while similar, tackled different problems and had a lot of nuances that came with that.
Having the product captains come along was one of my main goals for these smaller retros. They were knowledgeable about the product itself, but because of their customer-facing roles, they had a breadth of knowledge about things customers were running into that we might not be privy to yet.
Not part of the formal proposition I was putting forward about starting these meetings up, but doing these smaller retros ticked a box for me as a manager. We'd recently gone remote at the start of the pandemic, and my direct report had only been with the team for a handful of months at that point. I found that introducing these retros to be a relatively small step we could take to get some more face time with other people in the business and some exposure to how they work.
Benefits and new reflections
We now had a space for our small team to reflect on the work we were doing. Great!
One thing that jumped out pretty early on, though (and I hoped this would be the case), is that this was not just a space for reflections about our engineering work. The product captains were bringing a lot of good material to us from their constant chats with customers. That brought about a lot of new conversations that wouldn't have come up in our regular engineering retro.
Those conversations gave a lot of insight into how people were using the product, what they were missing, and if we missed the mark on things we released. It also gave us a new way to celebrate accomplishments because we now had a customer-centric source flavour to the feedback we were getting.
On the flip-side, it gave the product captains a new sense of engagement and transparency that might have been lacking previously. They were now getting more actively involved in the product with a platform where they could raise their ideas and concerns, and they could get a feel for where we were at in terms of delivering the things we were working on, with a rough sense of how far away we might be from launching new features.
Overall, the new meetings breathed some new life into the work this team was doing when we might have been feeling more disconnected.
Retro'ing the retros
We were learning as we went with these new retros, and we found a few things early on that helped us be more effective:
- Make sure everyone is on the same page around the purposes of the retro and what we're trying to get out of them. Not everyone had had experience doing retros before, so it helped get everyone familiar with the process. Interestingly this was one of my first times doing retros outside of an engineering org, and the level of engagement and the number of things raised was exciting.
- Talk about what you're trying to achieve by meeting regularly. I didn't want to throw everyone into a new recurring meeting because it solved some of my issues. But, I saw an opportunity to shape how we worked cross-functionally from now on, and communicating that was important. Framing the retros in that light led to some exciting conversations about team goals, how we measure our success and what aspirations we should have.
On the whole, though, I think doing small-scale retros helped our team by giving us space to talk about our specific problems, and it gave us some new directions to explore now that we were getting different perspectives.
I'd be keen to hear if anyone's tried something similar and what you got out of it, what worked and what didn't, and if you're still doing them.
Top comments (0)