Getting everyone in the product development process on the same page requires radical transparency, empathy, and collaboration. In the Same Page event series, we’re getting practitioners and leaders together for open conversations on exploring what it takes to build those cross-functional team relationships and how to find alignment. 

In this show, Senior Director of Strategic Programs at GitHub Kyle Daigle joins Abstract VP of Product and Design Matt Colyer to discuss how we can get the most of retros to ultimately improve our processes at the start of the next project. 
‍

Transcript

Matt Colyer: Hey, everyone. I welcome you all to the Same Page event here. If you have a chance, go ahead and type in where you're tuning in from, because Kyle and I are curious to hear where people are from.

Kyle Daigle: Where are you tuning in from, Matt?

Matt Colyer: Sunny California. It's actually a pretty bright blue sky, 72 degrees. Kyle, where are you at?

Kyle Daigle: I'm at home in Connecticut, which has been rainy for the past two weeks, but today is also a nice sunny day, 77 degrees. So we're trying to mimic our best Bay Area weather today, which is not too bad.

Matt Colyer: Nice, Nice. I see Simon's calling in from Munich over there. What's Munich like? I guess it's late. It's probably midnight. I'm not exactly sure.

Kyle Daigle: Thanks for tuning in.

Matt Colyer: 10:00 p.m. 

Kyle Daigle: Still counts.

Matt Colyer: Well, we'll give folks one or two more minutes here to chime in. We've got somebody from LA. How's LA today? Is it hot? We've got a strong European contingent today.

Kyle Daigle: Finland.

Matt Colyer: Beautiful as always. It's hard to go wrong in California.

Matt Colyer: Let's go ahead and get started, because I know Kyle and I have a lot to talk about with retros today. So to get things started, hello and welcome to the Same Page event, where we are going to explore a design first approach to product. My name is Matt Colyer: and I'm the VP of Product and Design at Abstract. And like I said, we will be discussing retros today.

Matt Colyer: Here with me, I'd like to introduce Kyle Daigle:, Senior Director of Strategic Programs at GitHub. And it turns out Kyle and I have actually got some history together. We've worked before previously. I used to work at GitHub. We were product and engineering counterparts, but Kyle, can you tell me a little bit more about your work at GitHub, just more about your background?

Kyle Daigle: For sure. So a couple of things. I've always really been in tech professionally. I came to tech from non-tech. I thought I could make my way by just using computers and going to school for art. That didn't play out the way I had hoped. Tech was a lot more interesting ultimately and a lot easier to keep a family going.

Kyle Daigle: I've been in tech for maybe 15, 16 years, but I've been at GitHub for the last about eight years, joining the company as an early engineer after they raised their first round. So, working in the API and platform space, and then ended up running the AP and platform space from the engineering side, where I got the pleasure of working with you, Matt.

Kyle Daigle: And then now working in strategic programs, which is this interesting cross-functional group of people that work on problems all across GitHub. So whether that be doing mergers and acquisitions, whether it's doing some of the paper cut work that folks might have seen, if you're a GitHub user online, where we're solving a bunch of little niggling problems that folks have with GitHub. Maybe not big new features, but solving some things with existing features.

Kyle Daigle: And then working on some of the more vision and mission related projects at GitHub, like GitHub's Arctic Code Vault, where we took the world's open source code most popular and active of it, and put it in Svalbard, Norway. So now I do a little bit of everything, including running a smaller engineering team.

Kyle Daigle: I've done IC, I've done a larger organization, I've done a smaller organization, a little bit of everything, both at GitHub and previously in FinTech and other tech related companies. I'm excited to talk a little bit about what I think the lessons that I've learned in that. And then also how I think retros have changed from when everything was capital A agile and we all did retros in a very specific way, to now, I don't think it works like that anymore.

Matt Colyer: Totally. Totally. It's a real treat to have Kyle on today, you guys. It's such a depth of knowledge, like you said, I've worked with you as an engineer role, but also as a manager. And then I know you've gone on since I've left and done other great things.

Matt Colyer: So it sounds like you've managed a lot of large important projects though. I imagine everything works 100% exactly as you expected. And you didn't have any learnings from those.

Kyle Daigle: Every single time, nothing to learn, exactly. Next question.

Matt Colyer: Nothing to learn? Exactly. I don't believe that for a minute. So Kyle, why don't you tell me a little bit about maybe the most recent retro or two that you've done on a large project and how you've approached them? What's your philosophy?

Kyle Daigle: So one of the things that I find so interesting about retros is usually every engineering leader, product leader, every leader from every company in tech, in particular right now, always says we have to do a retro. Whether you do sprints or you just say once a month or once every six weeks or whatever the timeframe is, everyone's always talking about, "We're going to do a retro," as if it were something that you just pull out the retro notebook or binder and go, "Step one."

Kyle Daigle: I think the thing that's been interesting is that whether it's a large or small project, I find retros to be less... the goals of them are based on the team you have. It's not so much whether it's 20 people in a retro, though there are tactical differences to doing the large group retro versus a small group retro, I like to focus much, much more on, what do I need to get the team to do in this retro?

Kyle Daigle: So if you have a newer team, which was the case most recently for me, and so when you asked that, it came straight to mind, you have a new team, the trust might not be there quite yet. So those retros can be a little difficult to get out quality, highly actionable, interesting things that aren't really surface level.

Kyle Daigle: Whereas if you have a team, whether it's new or old, that's five people or I think 30 people, which we've done in the past, if there's high trust and a cultural alignment with the team where they know it's to okay call out when things didn't work, even if it wasn't their personal work, if it's okay to talk about ways to improve both myself, as well as my teammates and potentially my manager or my manager's manager or someone above, to me, when you set up that retro or you schedule it, the first question to ask is, where on the continuum is the team I'm working with right now?

Kyle Daigle: Is it extremely high trust? Have they been here before? Have they demonstrated the ability to have a unique insight and act on it? Because if you don't have that, you can't go to the binder, in my opinion. You have to focus on, what do I need out of this? This needs to both be a retrospective, looking back at the work we did, what went well, what didn't go well, et cetera, but also a trust building exercise.

Kyle Daigle: And so whether that's you as the manager or you as a facilitator, because I think some of the best retros aren't facilitated by the direct manager. It's hard to speak truth to power when you're telling your manager, "My manager, didn't do a very good job of getting the resources that I needed for this team," for example. Whatever that person's role is, I think that's where every good retro has to start from is, does everyone in the room trust each other? And then does everyone in the room trust or can quickly build trust with the facilitator?

Matt Colyer: Totally. It's hard to understate the importance of trust. Like you're saying, you're going to have a totally different conversation with people who are comfortable with each other, versus maybe they're just starting to build that trust. I think you make an interesting point that there are retros about the goals. There's almost like the meta retro. It's like what are you trying to get out of...

Matt Colyer: Maybe for the first one, you do as a group with a new team, the whole goal of it is not necessarily to learn something that happened in that project, but it's more about learning how to do a retro. Your success of the retro is that your team became more comfortable and that built up that trust.

Kyle Daigle: Completely. I think that when I coach and mentor other engineering leaders, I find one of the things that when folks say, "Hey, we need to do a retro with this team," they know something happened during the project. And you're trying to incept the team to get to that point in the retro. I think that's hard, because it's hard to build trust that way when you're trying to facilitate this conversation and steer it to a point.

Kyle Daigle: I find that a great tip and trick is, it's to okay front load your retro with the knowables and do something along the lines of, "Hey, when we worked on this project together, we only had six weeks. That wasn't a timeline that we would have chosen. We knew coming into this and during it that we probably either needed more time or we need to do something based on the amount of time this project had. So does anyone disagree with that?"

Kyle Daigle: Which is my basic favorite trick in every retro is, you don't ask, "Does everyone agree, does anyone agree?" You say, "Does anyone disagree?" Which usually gives folks a little bit more permission to be like, "Yeah." Because it's easier to say, "Yeah, I disagree with that, "more than it is to say, "No, no, no, hold on. I don't agree with that." It takes more activation energy.

Kyle Daigle: And so you say, "Yes, I disagree," and then you can move on from there, but that's way better to parking lot a couple of things up front, that YK you might want to get to, particularly as a newer manager or a newer facilitator to a retro, than to try to, "Did anyone feel any friction with how much time..." To try to get someone to say the thing that you believe the group already agrees. That also gives space for the unique insight.

Kyle Daigle: Because I think if you have trust or you can build trust, the goal of a retro is to give you a unique insight, not something that everyone would have agreed to going in. Otherwise, it's just a very expensive meeting with your entire team.

Matt Colyer: Totally. We have a set of values here at Abstract. And one of my favorite ones is different minds see more parts, and that speaks to that last piece there that it's like, you can't all see it unless you put all your puzzle pieces together.

Matt Colyer: I do want to shift gears for a minute. This conversation is great. I could talk to Kyle for hours, but we also have a lot of other people on the call here. I'd actually like to put a question out, and do our first poll to the group here, and understand who you'd invite to the retro. And then once the poll pops up, there'll be-

Kyle Daigle: This is a good one.

Matt Colyer: Yeah, we can all see the results come in. So please vote. And we'll see, as people are clicking here, and then I'll be curious to see what people, how they typically invite people here.

Kyle Daigle: Me too. I'm very curious about this.

Matt Colyer: I'll give it a little more time. It looks like there's four people have answered. I know there's a lot more people out there than four. Here we go. It's funny, Kyle, when you were mentioning the permission to disagree, I remember early on when we worked together, I was that guy who would stick my hand up at the meeting and be like, "I disagree with you, Kyle." And Kyle's like, "Who is this guy, why is he disagreeing with everybody?"

Kyle Daigle: Definitely different types of people that feel comfortable disagreeing or not. I think with trust as a main sticking point of this, one of the things that's always intrigued me is, how do you get the person that's quiet to speak up? Because in my experience, people who tend to be a little bit more quiet or a little bit more reserved are really great at noticing things. They're the ones that see everything going on.

Kyle Daigle: And so how do you get them to raise their hand and say, "I disagree, because I saw something everyone else didn't?" Whereas I was never worried about you, Matt, disagreeing with me or the group.

Matt Colyer: That's a really great point, but let's get to these. It feels like everybody's voted, who's going vote. And maybe Kelsey, if you can chime in and let people know how to vote, it looks like there's a little confusion around that. So it looks like by far and away, everybody tends to invite, it's very inclusive. I don't know.

Matt Colyer: And then the stakeholders, the leaders, and then cross-functional is the second choice there. It's interesting. I definitely have a view, but I'll let Kyle, how would you have answered this question?

Kyle Daigle: I think out of these four choices, I would probably choose the first one, anyone and everyone. But I think in reality, because I would asterisk this unfortunately and say, "I think you need to invite the people who were involved in the project and had some stake in the project."

Kyle Daigle: I think one of the issues sometimes is you want to get everyone and anyone that touched a project, answered a single question, answered a single email. I think it's possible to get feedback from them. But again, when you're talking about trust, it can be tricky to get a good context and good information from a group that is not working tightly together.

Kyle Daigle: So one of the ways that we've done this historically is, each functional group question or option number four here, each functional group can do a retro, and then delegate or delegates from each of those groups go to a meta retro with all of that content. That allows you to get unique insight from say the product marketing team who didn't feel like the engineering team was giving them enough context on something.

Kyle Daigle: That might be hard to bring up in a 30 or 40 person retro, depending on the size of your team and your company. But that might be easy to bring up in a team of four, who run PMM and a team of eight, who are a part of the engineering squad. And then have each one of those people come and be facilitated by a third party from the company or one of the members.

Kyle Daigle: I think that one of the issues I see sometimes is when you invite, I mentioned inviting managers, but inviting leaders to a retro. They'll say, "I'm not going to talk, I'll sit off video, but I just want to watch." Nothing squelches interesting conversation than having the CEO sitting in a room and being like, "I'm just watching." Somehow I feel like that's worse than actually participating.

Kyle Daigle: So in my opinion, it's mainly the folks that are working on the project. I'm curious what you have to say, Matt.

Matt Colyer: Well, I guess mine is less about the people's roles. And it's funny, because that situation you just described happened at Abstract last week. We had this challenge of, we have a whole company and we wanted to do a whole company retro, but then we also had the groups, the engineering group and the product marketing group. And so it's interesting you spelling that out. We definitely have similar kinds of challenges.

Matt Colyer: But getting back to the question, I think the thing for me is the size of the retro. I know you touched on it in one of your earlier responses was like, we've done small retros together and we've done large 30 person retros. I much prefer scaling it down. I try to get the smallest number of people that makes sense, that has an expansive viewpoint. Because I just think the mechanics of doing a 30 person retro, you can do them, but it's incredibly challenging to get everybody...

Matt Colyer: It's just, if you have 30 minutes, and you have 30 people divided up, if you did it exactly equally, it's one minute. And it's just really hard to get a lot of depth out of a minute.

Matt Colyer: So shifting gears again a little bit, I see we have a question here, which I think we've touched on in a variety of answers. Sarah asks... Oh, it pops up. That's great. For a new team, how do you agree to trust?

Kyle Daigle: I think one of the things I do when I have a new team and we're doing our first retro is, so classically in a retro, at least a capital A agile retro, you're getting a bunch of information and feedback and you're collating it all together. And then you're supposed to be taking action items out. You're supposed to say, "I see that we didn't spend enough time speccing out this feature before we built it. Does anyone have any thoughts on how we should take this, and who should take it and go work on it?"

Kyle Daigle: To build trust, I feel like you have to sit much more in the, I need to hear from people's experiences. And then as a manager or as a delegate, you take notes as, "I heard four action items in this. We'll do a follow-up after to work through them and make sure I didn't miss anything." But you let folks share their personal experiences and have another teammate be a delegate to challenge and understand it.

Kyle Daigle: Meaning, if someone's like, "I kept feeling pressured to move my story along. I just had to get it out and I didn't feel like I had enough time." Have another teammate, again, not the manager or potentially a facilitator who's not the manager be like, "Do you feel like the team was giving you that pressure?" Digging a little bit more out, and then that way generally I find that someone else from the team will help validate that.

Kyle Daigle: Because in a trust situation, you need the team to trust each other, which generally managers as one as Matt, the worst case, a manager is like, "We all need to trust each other." And so it is done. That's not how it works. The team members have to decide that they're willing to be vulnerable and share.

Kyle Daigle: And so usually, I stick to either retro formats that help do that, or pull out some of the action item pieces. Can't do that for every retro. The whole point of retro is action items and getting the team to own the change themselves. But when you don't have that trust, it's very hard to get to a unique insight when you don't have it. So you have to focus on getting trust by letting people share their real experiences, I think.

Matt Colyer: You totally hit it home for me. I've been in those retros and it's an amazing dividing line where it's like people are being very formal and everybody has their mittens on and nobody wants to punch hard and everyone's dancing around it. And then somebody on the team will come forward and just give this very personal, emotional, this affected me in this way. It was like I had to stay up really late and I was exhausted and I missed my kid's soccer practice or whatever the emotional thing was for them.

Matt Colyer: And then it gives permission to the other people on the team, then somebody else comes in. It's like, "I really don't like finding out last minute. I had to miss my date night that week." Or whatever it was. I don't know how you do it, to your point, the incepting part is hard, but once you break through it, it totally changes the tenure of the conversation.

Matt Colyer: I think the other thing I wanted to mention in your response was the facilitation. I often think facilitation is an underrated... It's like everybody puts their nose on their finger, they're like, "Who's it?" It's actually a lot more than that to do a good retro. Facilitating is an active listening role, or it's like you were saying, it's not just having somebody put out an answer, maybe it's just part of that.

Matt Colyer: And then having somebody gently nudge it without judgment or direction. It's hard to ask a question in such a way that's not leading, but a good facilitator really does.

Kyle Daigle: Yes. I completely agree. I think something for me, because generally again, new teams, new trust. Someone from the team's not going to raise their hand and be like, "I'll do it. I was here for six weeks. I'll run the retro." It's usually a manager.

Kyle Daigle: So as a manager, my biggest advice is you say, "Hey, I'm entering this conversation as a facilitator. That means I won't be giving feedback during the retro. I'm not going to give you my experiences. I'll either put them in, in advance and then let the team discuss them, but I'm not going to dive in and out." Because you can't facilitate and provide feedback simultaneously.

Kyle Daigle: Because to your point, you're going to accidentally drive the conversation. I usually say, "I'm not going to be giving feedback right now." If I feel so compelled as a manager to validate someone, I'll be really cliche and be like, "I'm going to put my manager hat on for a second. Matt, when you said that about the date night, I really appreciate you sharing that." I just want to say that, "All right, I'm taking my manager hat off." That's one way to do that.

Kyle Daigle: But then when it talks about leading questions, the best technique, or sorry about not doing leading questions, but wanting to get that real feedback is, the best technique is really just to ask people to share, be quiet and then mirror. "Matt, I heard you talk about how it was hard to go on date night. Does anyone else have an experience where this task led to some hardship for you?" And you just sit there and let it be quiet and let the uncomfortable moment pass.

Kyle Daigle: Don't go, "Next," or be like, "No one? Really?" Don't be like that. Just let it sit. Someone is struggling to figure out if they want to share. This isn't always personal stuff either. It can very much be like, I really don't like the library that we chose to use to build this, but they don't want to say it, because maybe they're not the most senior person on the team, et cetera. That can be a big part of it, a part of it as well.

Kyle Daigle: The other tip is to go to some of the more senior people on the team that you hopefully already have a high trust relationship with, and just remind them of their role in the retro, which is, "Hey, you're a senior person. Everyone's going to look up to you. Can you help me tempo set in this?" Meaning, can you chime in? It doesn't mean own the conversation, but can you help me if it gets quiet? Can I count on you to jump in and share something if you have something to share?

Kyle Daigle: And I find that most senior people or people who aspire to be leaders on the team, it's another great tip as a facilitator to ensure that you're not going to hit that stone wall as soon as you get started.

Matt Colyer: That makes a lot of sense. It's like your trusted, your go-to buddies there. Shifting gears again a little bit, I'd love to go back out to the audience. This time, I want to ask when do you hold a retro? Again, I think Kyle probably has strong opinions on this. I'm curious to see what he says after the audience weighs in. We'll see if we agree or disagree.

Kyle Daigle: I won't to skew anything. Matt and I were, while this is going, I'll tell a small story that Matt reminded me about. Matt and I were able to, I want to say... I work remotely for GitHub. I've been remote most of my career. But we were able to do a retro in person with a very large group. Do you remember, Matt? Got to have been 30, 35 people.

Matt Colyer: I think it was 30 to 40 people.

Kyle Daigle: In person?

Matt Colyer: In person, across, it was product design and engineering, I think.

Kyle Daigle: I think we had some support representatives. It was a bit more cross-functional than you normally would in person. That was a very unique experience, because I feel like even pre-pandemic, at least at GitHub, as a very remote company, folks tend to do it remotely, which has been a blessing and a curse at times. But doing it in person, definitely the when question came in, because you can't fly in 30 people from around the world to a single place in a week's notice. You have to plan that ahead.

Kyle Daigle: I think it was different times for doing a retro, different reasons, et cetera.

Matt Colyer: Well, it looks we've got our answer. The audience has spoken. Everybody likes to do it immediately after. And then I'm curious for the people that said, put it in the chat, I'm waiting, I'm looking at the chat. I haven't seen anything. But in the meantime, Kyle, how would you answer this question?

Kyle Daigle: Generally speaking, I think relatively immediately after. Now, I think that to my little parable there, I think there's two different types of retros, It's like we worked on a task, we worked on a project. We finished it maybe a week after on a Thursday or something like that. I'd like to do the retro to talk about this task.

Kyle Daigle: I think it's also great, given us in particular, or an in person experience, to sit back and say, "I want to look at the half or the quarter or the last six months that we've worked together. Let's go up a level and talk about what we're doing." And so it does depend on what you want to retro on.

Kyle Daigle: If the goal is to say, those are our process work, are we happy with the result of that sprint, that task, that whatever, then you have to do it soon. In my opinion, you have to do it soon after. The longer you wait, the less you'll be able to get the detailed information that you want.

Kyle Daigle: The downside to doing it soon after is recency bias. We just finished, it was a crunch. We got all off the line, everyone's going to raise their hand and say it was full of crunch. But maybe the only last two days were the actual, the beginning was really great pace. And the lesson is actually the beginning and not the end.

Matt Colyer: So personally, I think I'd bias a little bit more towards a little more time in between, just to let things cool. I'd say a week or two, because I do find when you do them immediately after, because there's a lot of, still people are a little bit crispy from whatever the things are that they got burned by.

Matt Colyer: But take a little bit of time, the stuff, it mellows out a little bit, and the stuff that's really important... The other part too is, the stuff that still remains a week after is the stuff that's really important. I think sometimes there's details that just don't matter. And a little bit of time really brings that into focus, that it's like these are the things that actually mattered out of that.

Kyle Daigle: I think some of my bias on doing it soon after also comes from, James Clear talks about habits a fair bit and about how you have to set your environment up to meet the habits that you're trying to do. So if you're trying to eat healthy, you can't have junk food on your counter, because if you see it, you're going to eat junk food.

Kyle Daigle: And so my concern always with retros, when you wait a little bit too long is the urgency of them can go away. And then suddenly it's like, "But we have to have an all-hands on Thursday, which means we can't have the... We're going to push the retro out another four days. And Jonathan's on vacation," and so on.

Kyle Daigle: I always find putting it a little bit closer comes from, this is just the pace, we always do it this time after we close, helps keep it from getting pushed aside or moved.

Matt Colyer: That's simply a thing. It's like you said, it's like if you push it too far, there's a risk of not doing it or just forgetting about it.

Matt Colyer: Along those lines, let's dig into the details for a minute of, are there any templates or frameworks, or I don't know, examples of methodologies that you've found useful doing a retro Kyle? What's your favorite style?

Kyle Daigle: I end up going to two, because I try not to put too much ahead of doing the work itself. I'm one of those people who, if I didn't focus, I'd be like, I got to start a new company. I'm going to go open an LLC and get a 1-800 number and design the homepage, but not focus on the business I'm trying to build. I really only use two formats and they're very, very similar, but they're built in ways that should match the team that you're working with.

Kyle Daigle: And so in my opinion, if you have a team that is well-trusted, that's going to raise things up and they don't need much in the way of prompting, really, I do the four Ls, which I think we might've done together a couple of times. But liked, learned, lacked and longed for. So what did I like about this period of work? What did I learn during this time? What did I lack? What didn't I quite have, and then what did I really wish we had?

Kyle Daigle: I generally try to position it, depending on the level of trust, so that you don't end on the worst thing. I don't like to end retros on what did you long for? I longed for more people, more support, more whatever, and then you go, "Thanks everyone for all of your honesty. Now let's end." I try to end on an upper, but that's a very straightforward task.

Kyle Daigle: Most of my retros are remote. So we'll use stickies.io, which is a web collaborative format where you can do it. I've seen people use Google Docs or whatever. It's more if you like the skeuomorphism of being able to move stuff around and organize them, which I tend to like a fair bit. And so that's one setup.

Kyle Daigle: The second setup, which I've used on my newer teams is the mountain climber scenario, where you envision someone that's about to climb a mountain, or just finished climbing a mountain and you use analogies for everything. So what are the ropes that you used? What are the things that helped the team during this process? What boulders did you encounter? What unseen obstacles did you run into? What was the weather? So a mountain that's hard to climb is harder to climb when it's raining, versus when it's sunny out. So what's the mood, the feelings?

Kyle Daigle: For example, we're just coming out of a pandemic, a task that might've been very easy for a team to tackle into three weeks might be very difficult and still difficult around the world. We're still struggling with this. So that's a great opportunity for folks to raise those things up that are impacting the work, but maybe aren't specifically about the work.

Kyle Daigle: And then finally, what first aid did you need, or would you need next time? What will you do next time differently? What would we need to do?

Kyle Daigle: So that's an easier way to give some people some visual of, a boulder is an obstacle that I ran into, but you didn't expect. That's different than saying, "What did I long for? Or what did I lack?" The visual is also very helpful. You can still do the same thing in stickies.io or another online collaboration tool.

Kyle Daigle: There's another one that we just started using called TeamRetro. As someone who doesn't want to focus too much on the tools. I don't tend to use the various and sundry retro tools that folks have. I just like to stick with stickies, but TeamRetro seems to be just enough better that it might be worth checking out. But I just use those two formats with a lot of facilitation.

Kyle Daigle: I saw a question, that I feel like now might be a good time to discuss from Sonia. Would you suggest taking turns in leading the retro or always have the same person facilitate? Definitely taking turns.

Kyle Daigle: The problem with having a single person facilitate is either they'll end up having a outsider perspective vibe, in my opinion. If you have an L& D person or someone from HR, or maybe a product ops person or someone that you always bring in, having them do that over and over and over again detaches the team from the responsibility, which is, we're going to learn from what we did and make it better.

Kyle Daigle: I also think retro facilitation is a great way for people who want to become leaders, managers, et cetera, to try it out. Because sometimes it can be hard to get good answers and facilitate a meaningful conversation. I always suggest switching, but generally keep the playbook the same. Meaning, these are the couple formats we use. We're not going to research tools every time we do a retro, we're just going to lay it out.

Kyle Daigle: One thing that comes to mind a little bit out of left field, but when you asked, Matt, about retro formats, something that I started maybe six months ago during the pandemic is, I wanted to find a way, how can I retro quickly without introducing another tool? So Geekbot and the various stand-up tools all have sentiment analysis where you say, "How are you feeling today?" And sometimes you swear at the bot.

Matt Colyer: Sometimes. All the time.

Kyle Daigle: It's ... poorly, sometimes you don't. So what I've started to do at the end of every team meeting is I say, "Listen, I want to talk about the last week. I want you to score how you felt out of the last week. That could be your life. That could be work. That could be whatever." At the end of this meeting, how are you feeling? One means you're feeling great. Zero means you're neutral. Negative one means you're feeling not so great.

Kyle Daigle: Pop it into the Zoom chat or whatever your tool is. That's at the very end and then I save that immediately and we end the meeting. So the goal is not to, yes, you're going to see everyone's scores, but it comes in so fast. It's really just a barometer measurement. It's not a, "Matt put a negative one," or whatever.

Kyle Daigle: And that has been such a great tool to train the retro thinking. It helps me as a manager because it's very low cost, but it's done in public. There's something to be said about saying, "Hey, I'm a negative one," in this very safe way in this team meeting. And hopefully that helps bring more to a solid, complete retro, because we don't have to wait for the big retro with the whole to-do, to get a little bit of feedback and know, "Oh, the team's actually doing worse. Oh, wow. We're actually doing way worse. They're feeling way worse. Maybe we need to retro now, we need to figure out what's going on. We don't need to wait for the task to be completed," or whatever.

Kyle Daigle: That's one last framework that I just started using that I found useful. I'd be curious, have folks give it a try to see if it's a cheap way to just, "Hey, I'd love to get the rating, put it in chat," and do it in public where it costs a little bit of something to build trust with the team.

Matt Colyer: It's funny you mentioned that. I have not done the negative one, zero, one thing, but there's two things I really love about that. I think the first thing that I really love is I thought you were going to say one through five. And I was like nobody's going to ever put one. It's like people just never do that. And so by doing it with only three options, you immediately take the air out of that.

Matt Colyer: And then I think the other part about it I really like, I think we are in this time in history where it's like I think people are starting to wake up, that work is not just work. It's your whole, like you said, it's like maybe they had a really bad week. Maybe they're dealing with a family member that has an illness. It wasn't anything you would have known if you hadn't asked that question. It's the whole human perspective.

Matt Colyer: And I think we're all experiencing that, working from home and being in a non-normal environment and stuff going on in the world. It's good to have that information. Because then you can plan differently. If your whole team is having a really bad week, it has nothing to do with what's going on at work. You can still make a change.

Kyle Daigle: I've definitely put negative one. I'm a human too, I'm a bubbly leader, but I had a bad week just like everyone else and I want to be able to show that to my team. I had a team member that shared a negative one, and it was a great conversation starter in the one-on-one that I had to understand, "Hey, what's going on?" And like you said, it was a personal situation that he did not need to share with me, but he had to say that, and I go, "Great. That colors how I can understand your part of the task that we're working on right now."

Kyle Daigle: One of the reasons I was so excited to come on and talk about modern retros, because I think this is a modern retro. It doesn't have to have all the pomp and circumstance. It just has to give you a unique insight, and it has to be worth the cost. The ROI has to be high to get your whole team together or however you're going to do it.

Kyle Daigle: I don't recommend only doing scoring every week and never do any full blown conversation retro, but there's different sizes and moments in time where you can take the time, stop and do this. I think doing a score is just a very easy way to get a little bit more context, make your process, your team feel more cohesive, deliver on time, et cetera.

Matt Colyer: It's a really great point. Actually a good transition, because we haven't talked too much about the, how is it different? We've been doing this for a little while. What makes it modern? I think you touched on it there, but is there anything else you wanted to add to your definition of what's different?

Kyle Daigle: I've been working with someone recently who came from a consulting background, one of the big three and was like, "Hey, so I noticed in the retro, we took some notes, we called out some items, but we didn't really dive in. We didn't really get to the solution." I think that to me, I know we covered it pretty quickly at the beginning, but to me, I think that's one of the major differences of doing retros now, than when agile came out and was very popular.

Kyle Daigle: I think that the modern retro allows us to do more team building, more trust building, more understanding within the team than just process. We need to do the process side too, but there's multiple different tactics to do that, depending on where your team is at.

Kyle Daigle: If you don't get a team to share what they're experiencing, good, bad, ugly, the process fixing doesn't matter. Because you're just going to fix superficial stuff and be like, "I guess this means that we're going to have to mark every new JIRA ticket with this tag. Great. Thanks everyone for the two hour retro."

Kyle Daigle: I want to hear from the team to share where they're struggling. Are they having a hard time learning a new skill? Is something that's happening outside of the team having an impact on the team? I want to hear it soon.

Kyle Daigle: I think that's why when we said earlier, sooner or later, I agree with you on how recency bias can play into good answers in a retro. But I'm always trying to figure out with the modern retro, not modern tooling, not modern frameworks, but just looking at the whole person, the whole team and then the whole organization to figure out, how can I get that unique insight that's going to make us faster, or make us more cohesive, or make us more inclusive?

Kyle Daigle: It's all an opportunity to hear from more people at the company than it is to say, "We came in with this process. We did a retro and we came out with that process." That's to me the old school retro.

Kyle Daigle: Now, there can be a whole retro, in my opinion, where you don't have a process change on the other side. But if the team is more cohesive and more trusting, and they're going to work with each other, how is that not a win? You're not going to come out the other side at the end of a retro and say, "Does everyone feel more cohesive?" Same thing, does everyone trust each other a little bit more?

Kyle Daigle: But a retro is a great way to get you and the team there, without necessarily having to modernize the actual work. It's about the approach to it, the facilitation and the different angles and attack vectors to try and get the same result, I think.

Matt Colyer: It makes sense. If I was going to distill down what you just said, it's like expansive into a single word. It's like the modern retro is more expansive. I think it actually ties in nicely with the chat here. Simon had a similar concern or question, apparently sharing an experience that they had too many retros where there wasn't an impact. And you touched on that a little bit that it's like sometimes there is no impact. And what is your thoughts on balancing action items or changes coming out of a retro and how important is that?

Kyle Daigle: As a leader, if you take an action item or the team takes an action item on a retro, I believe it to be your responsibility to demonstrate that either right before the retro, the next retro or at a team meeting or whatever. So if we say, "Hey, we do have this action item coming out of this. We need to change this way that we work. We're going to take a note on this. Who's the owner of this? Who is going to make sure that we do this?" That might be me, the manager, that might be someone else.

Kyle Daigle: And then before you start the next retro, nothing says trust than saying, "We said we were going to do this and it didn't happen. Maybe we need to postpone that. Or maybe we use this time to focus on making that happen."

Kyle Daigle: I think it's also an activity that ICs can do with their teams. If you're not the leader of a team, it shows great insight to say, "Hey, we did talk about this, but nothing ever happened. Can I step up and potentially make that happen? Or is this no longer important? Can we explicitly say that we're not doing this action item anymore?"

Kyle Daigle: Because to Simon's point, nothing is more trust killing than saying, "This is very important, we're going to take this seriously and we're going to make change from it," and then six weeks later do the same thing, but nothing happened. And so I think as a leader, if you are one, however you can demonstrate, "I heard you, I'm taking action item and I'm going to hold myself accountable for the thing that we said we were going to do together," it's very important, crucial even to doing the retro.

Matt Colyer: That makes a lot of sense.

Kyle Daigle: It can hurt a lot if you don't do it and you're definitely going to stub your toe once or twice where you say, "This is important, we're going to do this." And then life happens, whatever happens, again, in my opinion, it's just another opportunity to be radically candid, be honest, this was on me. I own this. Maybe I shouldn't have owned this. Is anyone else interested in helping to take this on? Or should I agree and re-up right now?

Kyle Daigle: Everyone's feeling, "Okay, that's good." It's much better than just sweeping it under the rug and hitting the restart button on the retro process.

Matt Colyer: Totally. And as a manager, I definitely have had that experience where you're trying to juggle all the different action items and making sure people follow up and you miss a couple. And it's hard, we all have lots of things going on in our jobs. But I liked your suggestion of, at the next retro review, what you did at the last one, and if you didn't do things you already outlined, it's like don't have another retro, as a really good way to make sure you're focusing on the right things.

Matt Colyer: I know we've been talking a lot about building systems and processes here in this conversation. And a lot of that work, we were just saying, it's like I take notes throughout a retro. I think a lot of us actually take notes throughout all of our work. Not just for retros, it's just like, Kyle, how do you take notes? Do you have something you can grab? I've got one by my hand. Let me try -

Kyle Daigle: I can't show you because everything is digital. But I do use the Notes app, which is sitting right here during this conversation where I even took notes as you were saying things, for sure.

Matt Colyer: So my personal one, I got lucky. We have a really nice brand design team. So they put together this great Abstract notebook, but I've got my notes in here of my demo list. It was upside down, it's over here.

Matt Colyer: I'm curious how everybody here on this event is capturing their creative process. We're working on a project that we're calling Process Pages. And we really want to understand how people workables over time. And Kelsey here is showing off some of the examples of other people that we've talked to and demonstrating their in progress work.

Matt Colyer: And it could be from all different kinds of disciplines. It could be design, it could be brand design, it could be product, it could be engineering. And what we're really interested in is the people that are on the call today, if you've got work that you're interested in sharing with us, we'd really love to see it.

Matt Colyer: The goal is to collate all this stuff together and send it out to our Abstract audience. And as part of a thank you for that, Kelsey's going to drop a note here that explains a link that you can go ahead and grab some of this great swag. It's going to look different than this, but we've got some other great stuff, if you're able to share some of that work with us. So if you go ahead and click that link at the bottom.

Matt Colyer: And then I guess, I know we only have a few more minutes left before the call is going to wrap up here, but I see that there's one question in Q&A, and if there's anybody else in the audience who wants to pop up with a question, I think Kyle and I will do our best to answer. So starting with this question from Brian, and we've touched on this a little bit of understanding your team of where you are in the trust spectrum.

Matt Colyer: I've got an example of it. I guess I'll start this time, because I always ask Kyle to start.

Kyle Daigle: Thank you.

Matt Colyer: I'll give Kyle a break. But one of the things we found useful is Kyle touched on tools. We actually use Miro a lot for internal retros, just because it's got that metaphor. You can drag and drop stuff. So for some teams who hadn't used Miro previously, it was a good both icebreaker and learning experience to go ahead and pick a GIF. So there was a GIF of your current emotional state.

Matt Colyer: And so people would go to giphy.com, and pick out what that was and to your point, it's also that modern retro aspect. People get a chance to show a little personality at the same time, or just interests outside as a whole human. But then also, we had another column that was just, what was one thing you learned in the last week?

Matt Colyer: And then we did show and tell, we went roundtable, everybody described their little image and then also the one thing that they learned. So Kyle, do you have any tips or tricks to icebreak?

Kyle Daigle: I was going to say, I hate to just plus one the learn bit, but I think my tip and trick is generally that. If you do, one of the formats I mentioned about learnings, generally everyone's happy to share what they learned, and having a senior person or you share a learning that you had during the process is a great little icebreaker to set the tone for folks. And so just making it easy for folks to share.

Kyle Daigle: I tend to stay away from, what's one thing that nobody knows about you, or what's your favorite dessert, or those sorts of things. I find them to be a little superficial, but it's cheap to say I learned something. Or what's something that you accomplished this sprint, that you're just really personally excited about?

Kyle Daigle: It might not be the biggest thing the company's ever seen, but you really loved it. And folks will generally share those. So invite them roundtable, if you normally don't always do in our retro, where you hear from everyone every single time. Have everyone go through one of those and then go to the next step. It generally loosens everyone up to share a little bit more.

Matt Colyer: Cool. Well, I think it's a really great tip and unless there's anymore questions, I guess we'll give it one minute here for anybody, last questions.

Kyle Daigle: I just remember being in Boston where we did the in-person, having done the stickies on a computer, to having the little stickies with the big post-it sticky cards, dragging them around the room, and trying to facilitate physically is a lot more difficult than it is on a computer. We were like, "I'm going to group these up," and a team of 35 people made a lot of stickies. So shout-out to the teams or those of you that are watching that work primarily in person, in a normal circumstance to do those retros. Because I definitely find them to be a little bit harder.

Kyle Daigle: Maybe one last tip about that, since I talked about so many of those stickies, I've been starting to experiment with having folks add information to boards before the retro itself. I don't know if it's better or not, but if you do try it, and you find it to be better, way worse, I'd love for you to hit me up on Twitter or wherever you can find my contact information. Because I'd love to hear if you find that works.

Kyle Daigle: I find in this languishing era that we can be in sometimes right now, it's a little bit easier for team members to sit and think quietly in their own time and add things on the board. And then you immediately let everyone review what's on the board, instead of saying, "All right, everyone add your stuff." So again, not necessarily something I'm saying everyone should do, but it's been something I've been toying with, with my teams. And if you try it and you like it, or don't like it at all, I'd love to hear, to see if this is a new solid practice that we could add to the modern retro.

Matt Colyer: Well, I just want to say, thanks, Kyle. I know this is not... you're taking your time out of your day to come hang out with me and have a chat about the good old times and retros. So, really appreciate it.

Kyle Daigle: Of course, thanks Matt.

‍