Firefighting to Flow: Forecasting For Developers - Interview with Tom Ridge

My guest today is Tom Ridge and we got talking about things like having difficult conversations on teams, different team dynamics, and of course, everyone's favorite topic that is not hotly debated, agile software development. And I thought this is a really interesting conversation because I got to see how Tom was navigating some real big issues with projects falling behind schedule and things that they did to try and make up for this. again, using data and trying to make decisions in an agile software development fashion. So, I think that you're really going to enjoy this one. There's a lot of interesting takeaways. So, sit back, enjoy, and I'll see you next time. Is I like it cuz I used to use um Riverside and I really liked Riverside, another streaming platform or like uh podcasting platform I guess, but they were losing a lot of my data. So, I would finish these podcasts and then I would go to get the the media and I'm like, "Hey, like it's not there." And their support was like, "Oh, we see it on our side." And I'm like, >> "Yeah, but that doesn't help me." So, I moved to Streamyard. Haven't really looked uh back since, but sometimes the UI is just a little little finicky, but uh that should be okay. >> Cool. Well, Tom, if you want to kick us off, I would love to hear about your career journey. And like I said before we started recording, as early or as late as you'd like to start and just we can kind of walk through some of that and >> see what's going on. >> Yeah. Uh hi, I'm Tom Ridge. Uh I'm currently based in South Australia and I've had a bit of an uh I wouldn't say it's like super unusual career path into uh software engineering and engineering management by extension. Um but I fought I think for the longest time to kind of like that I actually was very interested in computers. Ah no it's just a hobby and then um I I kind of came into it pretty well late by my standards. I was about sort of 23 uh and got my first job as a uh Flash developer and animator. And I was horrible at animation and I'm still terrible at animation. This was like way back when. Um, and I I could absolutely tell my um my boss at the time getting sort of somewhat frustrated with me and I think there was they were probably a little bit relieved when I sort of uh had to wrap up my contract early to go move to the other side of the country, which a whole other story. >> Um, but like I I got hooked on on software development. I got hooked on um at the time one of my colleagues there introduced me to the Ruby programming language. So I got kind of um brought into that ecosystem and culture and and that um the Ruby community in Australia has always been really really supportive and a really really great place to be. So um but my now wife uh was at that time full-time in the Royal Australian Air Force. So it was kind of this this uh opportunity to um really go live across the other side of the country with her and then kind of like really go like are we are we doing this or not relationship wise. >> Um so that is all a propro of um that was right around like the the GFC and so trying to get like a job as like an entry- level kind of engineer and sort of and for some reason thinking I was too old. Um I ended up I ended up kind of like getting into it via um just building very basic like web applications for customers when we were living in Sydney and then um working when we moved to Queensland working as a support engineer for a um Queensland health e-learning kind of department before like just going from um more and more uh sort of programming um and to finally sort of you know getting what I'd always sort of wanted like a Ruby job with a um a sort of client-based consultancy in Brisbane. Um more recently, I say more recently, I've just ticked over eight years with them, so it's not that recent, but um I got a job through the Ruby community at um company called Culture Amp, which is where I work now. Uh we are a uh employee experience platform. So, we manage everything from like engagement surveys to one-on- ones with your direct reports to where I've been focused for the most of the last say five years on um the performance side of uh our product. So, things like manager reviews, feedback, uh calibration sessions, things like that. And uh when I came into there, I was still coming in as an engineer. Throughout that experience, I um and the job before I'd sort of had a bit of a taste of team leadership and then an opportunity came to run teams here at Culture Amp. And I did that for a uh a good long while up until about 2 three years ago where I sort of switched back to engineering. And uh my most recent manager stint though was actually um over the last month and a half I sort of been back into the manager while still doing the the soft engineering bit. Um, so I was kind of like back and forth on the engineering pendulum over the last eight years or so. >> That's awesome. And I have a whole I guess like a bunch of thoughts were coming to mind as you were walking through that. Um the first um and I think this is probably a really good thing for folks to hear because when I talk with engineers or aspiring engineers obviously right now uh job market very challenging especially for new folks and one thing that if I understood correctly you said the current uh company that you work for came up as an opportunity I'm assuming through networking in the Ruby community. Y >> could you talk a little bit about like how that came to be? Cuz sometimes like if I'm telling people, hey, yeah, you got to get your resume out there and apply to jobs, but also like network and that can look so different for everyone. I feel like I don't have like a lot of great examples because I need to rely on other people that have like had success with that. So this is one of those. >> Sure. Um so uh as it so happened at one point in time one of my uh bosses ran the Brisbane Ruby meet up. So um I was in attendance pretty regularly there anyway um and was starting to give talks and um through there I met a good friend Rob um and Rob who uh previously worked at Cold Ram um was on the Ruby Australia uh committee um and uh I' I've met a lot of people through that community generally and just got to know them and become friends with them over the years. um if you ever get the chance to go to like a Rails camp or a Ruby retreat, they're fantastic sort of unconference events. But Rob was always someone that did a really good job of just kind of like like nudging me in the shoulder and telling me you should do that, you should do that. So that's how I ended up giving my first conference talk. Um that's how I ended up jumping on the committee cuz he was wrapping his time up and I ended up being on there. Um and there was a bit of a joke at the time. Um sorry to digress a second. Ruby Australia community is like responsible for organizing um things like conferences to those unconferences to um really predominantly sort of like helping um communities and meetups kind of really you know uh enable people to kind of like learn and develop with Ruby um and seeing that thrive in businesses alike. So I had a bit of a stint on there and the running joke at the time was that uh the treasure at the time and folks would use it as a bit of a hiring and recruitment ground for culture. Okay. Um and so pretty much all of us that were on the committee at some stage eventually kind of found our way on there. Um so it was a great like even from the job before that it was just like you know gotten opportunities through that that same sort of community and just kind of by being willing to kind of um go there and make friends and and and sort of talk with people and get to know them and just learn um or like take part in that community was really valuable. Um, and to your point, it's the same advice I get to other um, like, you know, other folks more on the junior end of the spectrum. Um, it's just that it's a it's always a really really good idea to get out there and and to just meet real people and and, you know, maybe share a meal or a conversation. >> That's awesome. Yeah. And so thanks for thanks for kind of walking through that because I you know when I'm kind of nudging people in that direction it's like okay there's hackathons, there's meetups, there's like anything where you can try to surround yourself with other people. It's one of those things that I I realize as I say it to people, they're probably hearing it going, "Yeah, but like that's not going to guarantee me that I get a job." And I'm like, "Well, that's not really how networking works. like that's something that you put time and effort into and you have to be genuine. It's not, oh, I'm going to go to the meetup and just like I'm there to hand out my my resumes and um like sort of get the interview like right away. It's like no, like got to invest time. It's about building those relationships because it's not a guarantee, but if you're not taking the opportunity to actually network and build up the relationships, then those opportunities never have a chance to exist. >> Yeah. Yeah. 100%. And and like you said, it's it's a long it's a long-term game. Um I mean the the other side of things too is just uh half the reason I I push folks in that direction um was actually speaking to one of the people I was managing today about the same sort of thing was just hey just if for no other reason than to get like a little bit of a diversity of opinion outside of what you might get in your own team or the the company and start thinking about problem solving in different ways. Um yeah, it's it's um like it is generally where you can get a lot of job opportunities, but you um really just go there for the intent of being a part of that community and maybe making a few new friends and learning a few new things and as long as you're engaged in that, you'll you'll probably have a good time. >> Yeah. And like excellent point, right? So my my intention was not to say the only opportunity is for jobs. But yeah, like if you're going there, there's already going to be so many other things that like your ability to learn about things you haven't heard before, different perspectives, and then like it's almost like this the side effect of being around that kind of thing is potentially opportunities and networking. So again, yeah, thank you for walking through that. The um the other thing that you Oh, you kind of touched on it a couple times, right? going from uh engineering into management and then back and then forth. Uh so uh I guess I'm curious in the beginning when you were taking those steps towards like you said like team lead kind of role and then into management. I'm curious and I don't know I don't know the best way to ask this but kind of like did you did you see that as like a natural progression? Is that something where like you're actively trying to chase it or did it fall on your lap? Like what did that look like for you to go from an IC into management? That's a really great question. Um, a little bit of both like in terms of the falling into my lap and sort of seeing as a natural progression. Uh, I had at the previous company that I worked at before Culture Amp, I I tended towards taking like a um, you know, natural ownership over increasing um, increasingly larger sort of pieces of work. uh and when I'd sort of come to contra part of the reason that I wanted to initially kind of focus on engineering was cuz that I I saw out gap uh gaps my skill set that I wanted to kind of remediate uh but I also very much I always have sort of enjoyed um being uh a part of a team where I can help that team accomplish its goals whatever that may be but like also sort of work with other individuals and really sort of like help them achieve their goals. I think if you think looking back on now one of my happy places just like you know when you can sort of see like doesn't matter if it's like people orgs or whatever you can see like potential there that just needs the right kind of structures and environment to really kind of grow and thrive like that that's that's fun that's fun to sort of see that come out and then uh in terms of falling in the lap bit our um part of the organization was undergoing a restructure and my team lead at the time kind of came to me and said look hey there's this this opportunity coming up for this small team It wasn't necessarily like the most um ambitious looking team on paper. It was it was designed to be like we're going to be building up this new kind of uh structure similar to what Spotify squads were at the time. Okay. >> Um and this team's remit is kind of small improvements uh across the product. You're going to be responsible for kind of training people into our part of the domain as as a camp, which is what we called them. and uh you're going to you know like help sort of prevent um bugs and issues from getting to one of the teams and that um ended up being a really successful team on a number of fronts. Uh so one was just we because we were always had a really good relationship with our product manager in that team still do he's awesome. Um and our um we also had a QA in our team uh who was between the three of us, we'd sort of naturally form that sort of product leadership trio anyway and worked really really well to kind of uh not only regularly kind of deliver value and improvements, but we trained everyone coming into the camp. We uh trained a number of sort of junior engineers up uh and then we just started taking on increasingly bigger projects um and delivering those on time as well. So, it just sort of seemed like that was working quite well. Um, >> and when you feel like you're uh, you know, sort of hitting regular sort of product release milestones, you tend to feel pretty good about how the direction things going, >> right? Yeah. And that's Yeah, that's really cool, right? Because you end up finding sort of this rhythm or this momentum where like obviously in software development there's going to be things are changing all the time, right? If if you had a team that was constantly changing in terms of the people, right? Then you're spending a lot of time and there's can't remember it's like storming, norming, forming, whatever the you know if you're if people are constantly changing then it's like okay well like how do we actually you know we have to spend time learning about how individuals like how we work together like what's effective for us and then how we navigate whatever domain we're working in like individuals might approach that differently. like there's there's so many variables, but when you can start to keep things some parts of it consistent and I find that at least personally when some of the team members at least are consistent and finding some patterns that work, um I'm going to use the word process, but I don't necessarily mean like it must be super rigid, but you have some things that seem to work and you seem to stabilize on them. Then you can do some things like okay well we can move domains and if you keep a lot of the other variables the same you're like hey look like we can still be effective or the domain stays stays the same hard to speak and um and then you you know you onboard some new people and then it's like hey look like we can expand the team and you're keeping some of the other variables the same is that kind of how you found like that team was able to navigate and steer through things >> yeah on on both fronts I think you've actually like uh you you've encapsulated exactly what happened. So in the early days because we were sort of onboarding new people into the camp, a lot of the process sort of remained the same and we're able to kind of bring people in pretty easily um before sort of moving them to their forever teams whilst we still had like a a group of people that were fairly stable. Uh and then later on um to kind of digress to a little bit of history lesson like we acquired the the now performance product uh and so our team was asked to kind of second over there and go and work in a new domain. But because yet the team had remained pretty stable and like there were you know some processes and ways of working that were pretty normal for us. Um we were able to go without there and then smash out a couple of projects pretty easily. So that worked out that that worked out pretty well and uh pretty much all of the team ended up sort of staying in that area of the um uh product by one uh by one team member who decided to sort of stay where where we were uh based over at the time. >> Awesome. And like so you mentioned like the trio, right? And I I think this is interesting because I don't know I find >> I find obviously different places operate differently but I I feel like some people may go through most or all of their engineering career and not necessarily experience something like that. So for example um like I I have had something very similar to what you're talking about like with having a trio. um at Microsoft right now like we have at least in the teams I'm working with we have like engineers and we do have product managers and engineering managers and so the uh the product managers we work with kind of do depends on the team right because as platform teams especially I find that a lot of a lot of product is driven sort of by engineering needs so and I don't what I'm about to say is I'm not trying to like minimize roles or anything like that I A lot of the value that I get working with project managers is their ability in this current setup, their ability to help navigate with other teams. Like what are other teams doing? What are their milestones? Like how do we start bridging some of these gaps? So I find that more like closer to some like types of project management that I've I've experienced before. But in the past, it's been like I rely on product managers very heavily to go talk to customers and get the user feedback and help translate like what are users struggling with or opportunities like how do we translate that into like engineering. So like we partner that way and QA not now at Microsoft but when I used to work at a smaller startup I worked with QA and I ended up having like we kind of moved on on my teams at least our QA away from like less like manual testing more into like test strategy is kind of how we looked at things. Anyway, that's just a little bit of background. So I was kind of curious when you're thinking about like a trio coming together. How does like can you talk through that like what that looks like um for folks that maybe haven't heard of that and like and why you find that beneficial? >> Yeah, sure. Um was actually it's really interesting about that last part that you were saying too about that sort of shift between manual testing to test strategy because we sort of undergone the same thing. >> Um the >> and I realized that was very loaded. There was a lot of stuff there. No, it's interesting. Um the so initi so with the initial trio that we had with the the first team that ran at uh at Culture Amp that was partially to is um like even outside of like the the trios that kind of like already existed at Culture Amp that time where you typically sort of see for folks that um are listening you typically sort of see a product manager you know probably a designer and a tech league sort of forming that leadership group of the team. So for my team that was mostly about small improvements and bugs. I had our our senior QA for the entire camp. Um we had a product manager and myself who didn't really have like a designer attached to us. Um and in that case with our team and all the different things that we were trying to do and just like our remitt that both kind of just covered our team and then the broader camp. Uh it was it made a lot of sense to me particularly as someone that was just really stepping into leadership at this company for the first time that I've got these people here with like experience that need to know what's going on on a daily basis that need to know what I'm doing. I probably need to know what they're doing and together we can try and strategize you know and come up with a plan crossunctionally about how we're going to tackle that day that week that month. Uh fast forward to now. Most uh not all sort of product teams at Cultramp will typically have like a team lead which is um more or less like a engineering manager um a technical engineering manager at the head of the team. They will have a designer typically um and a product manager and that will sort of form that that sort of trio. So you've got uh different people able to represent you know the why, the what and the how in terms of how we go about building and delivering product. Um and generally like one sort of point of accountability for the people and the outcomes of the team which tends to be the team lead. Um so in terms of how that that works like uh since sort of doing other sort of leadership things for me again that's just uh I find anyway that the best outcomes that we're going to get is when we work crossunctionally and and kind of like understanding that uh understanding like not only like what our customers want and why will help us shape like you said those engineering solutions that we might actually build. So rather than building something that's unnecessary or not valuable, it's going oh okay you want you want this you say you want this particular solution but I can give you that same outcome over here for less time and energy and effort um to uh you know particularly when working with uh designers like actually going ahead and and figuring out how to uh problem solve how to like enable users to actually go through the the very features that we're trying to build in in a reasonable Um, and a lot of the the best designers and teams that I've worked with have been just super tight with our front end engineers in particular just in terms of that that close collaboration as well. And between the three of us, you know, gradually starting to build a strategy for going, look, we've got all this thing things that we're trying to all these outcomes we're trying to achieve. like how do we do that with the time that we have, with the team that we have, with the tech we have and then and then like you said too, like you know uh with the other teams around us in the ecosystem and and what they're working on and when. Um but yeah, that's uh I found that generally to be uh a pretty successful model. Um and I it's it's not uh everyone's kind of coming at it from like a slightly different angles. you're going to have points where you're going to like disagree or like >> Sure. Yeah. >> Uh you're wanting to uh have like sort of like challenging difficult conversations, but >> um everyone I I've I found a cult in that sort of position's always come up with a pretty >> uh pretty openly and like sort of earnestly in terms of just trying to like get to a good outcome. So, it's been pretty good. >> Well, that's the I wanted So, again, thank you for walking through that. I think that's a helpful like framing to see how these pieces come together. But yeah, the the next part that I wanted to kind of uh pick your brain about was around healthy conflict, right? So when you have individuals that are representing sort of different areas, it's of course like you're saying, you're coming together with a common goal, right? It's not. We're going to take three people who obviously don't want to work in the same direction, pit them against each other, see who is the best Pokemon battler or arm wrestler, whatever it happens to be, just like it's not like one person comes out as the winner. That's not the goal. So when you put three people together that are representing different functions to reach a common goal, you're still going to have situations where like based on the framing and the perspective, someone's going to be thinking like, hey, like I think that we really need to like I I value, you know, these sets of things. Someone else might value these sets of things. Of course, there's common values. So, I'm curious when it comes to like difficult conversations, like what and I don't even know where I want to go with this question necessarily, but like what are the types of things that need to happen in order to get to a point where you like you can have difficult conversations that and again maybe for folks listening when I'm saying difficult conversations I mean like you have to have like a healthy debate. It's not again not to like who speaks the loudest or it's like a shouting match or something. It's how do you get to a point where people feel comfortable that they can say like hey like this is my opinion I am willing to listen to yours like what does that look like to get to that spot? >> Yeah. uh in terms of what it looks like to get to that spot. Um I'm just thinking about like one of the the cases where it's like sort of been really successful for us. And I think um no matter what like you've got to have like a strong sort of basis of psychological safety like let alone for like the team but like for that that trio up front, right? Um the you kind of talked about it when we were talking about like sort of you know the the value like that's not how you network right. So like even when you're working it with the same um you know two other people and your job is to kind of like lead that team to uh success and to an outcome uh every day. uh you really have to uh decide like is this a you versus them thing or is this going to be like a you you all together thing and to try and figure out like how does everyone like to work? How do you like to take and receive feedback? Uh >> what is what is your favorite thing to do on a weekend? uh why is uh why is it like a terrible idea to talk to Tom before he's had a coffee at like 9:00 in the the morning sort of thing, you know, and and really kind of like get there get in there and build those relationships and get to know each other. Um but really sounds like going, hey, if you build strong psychological safety, then you can have those uh kind of difficult conversations. But it's more just about like when we actually empathize with each other and when we understand each other better as humans, it's a lot easier to kind of go, "Okay, cool. you've told me this thing like that we need to do this by this date. we've got all these other kind of competing um priorities like just it's a easier step for me to take if I've got that empathy there to go okay just help me understand why like help me understand where you're coming from so that we can actually broach that conversation you know they're not saying it cuz they you know uh at this sort of like level and stage those those folks aren't like saying that they want something to you because they're just trying to give you a hard time or they're just trying to get like ideally they're not just trying to get like a a marker in their promotion. they're saying it either because maybe like it's actually the genuine best thing for us to work on or it's like priorities have changed and then you know if you can kind of build the right environment where you can kind of come up those conversations with empathy but also kind of create a space for you to be curious about it as well. Um, >> uh, it's not that I I would wouldn't say that I don't then have difficult conversations, but it takes a lot of the sting out of it already if we're kind of able to approach it with that curiosity, empathy out of the gate. >> Yeah, those those two things that you said right at the end there, um, I think are like my my key things that I I personally take away from that. And when I'm I'm as you're talking, I'm like I'm trying to do some reflection because I'm like, if I'm going to ask this question, I should probably think about it for myself, too. Um, so like the the idea of being genuinely curious, right? Like if you're going to be debating with people and again, you don't want to go into it to be like, I'm here to stir the pot and piss people off. It's like like we want to move forward in a direction and you might have perspective on something, an opinion. You might have data to back that up and that's great. So you're coming at it from a direction. If someone is like, I don't agree with that, or I have this other approach that happens to be at odds with yours, instead of just going immediately to like, okay, well, how do I like, how do I bury this person? How do I make sure that like my answer is the right answer and I come out on top? Like, if you're if you're if your thought process is that way, you're already you're probably not going to be very successful at this. But the the opportunity to like to stop and go, okay, well, hold on. like I I know that I like have trust and respect with this person. If they have a completely different approach and I'm exaggerating, right? I'm saying completely different, maybe it's slightly different, whatever. It's something that I didn't come up with. It's something different than my solution. If I like take the opportunity to try and listen and understand genuinely, not just let them speak so that I can jump in and say, "Okay, um then and you can actually learn from them. There's probably information that you didn't know. there might be the same information like the same data but you're realizing oh they're valuing these other things or stakeholders are valuing these things differently and now that you know that like maybe that does kind of shift your perspective but the first part was really like making sure that you're being genuinely curious and interested uh when people have different opinions because without that I feel like you're not really setting yourself up to like be willing to make progress And the the other part that you said around empathy, I kind of chuckled when you said it because I I strongly believe in it and it sounds it sounds kind of funny, but like when you're like, "Hey, like you know, what do you do on weekends?" Right? Like when I talk to people about forming better relationships at work, it's not like you have I'm not saying you have to be best friends with everyone at work and hang out with them and and all that. Like you can keep everything totally separate, but when it comes to like actually having better working relationships, I feel like if you can create a little bit of opportunity to be curious about the person and like what they are like as a human and not just like exactly what they do like in their role. Uh I say this a lot for people trying to have uh like especially better working relationships with their manager because some people that I talked to were like my manager doesn't know anything about me. Like I feel like I my 101 ones are status updates. I'm like you can take it sounds kind of silly. Take some of that time and just like talk like talk like people would like >> create some space where you can learn about each other, right? Um again I'm not saying you have to overshare with your manager and you know I'm just saying >> a little bit of opportunity to be like this is another human being. >> Yeah. Yeah. Totally. But actually that last part of just even having again it's hard right like it's hard when you're the direct report to the manager but just even just having that little bit of u moment to kind of go look hey like if this is for this relationship to work really really well for both of us like I just like I feel like I don't know you well enough so can we like like and just sort of sit in that a little bit and just be home like I'd love to get to know you more like let's actually talk about anything other than work for like the next you know 20 minutes or whatever it is. Um, to your point though, the other thing was we so I've I've pretty much only ever run remote teams apart from >> the job before now. Um, and one of my favorite standup questions was we just do like a standup rituals. We we do like a question of the day. >> Um, and it was just like yeah, like a short question just to get to know each other better. Um, my favorite questions were always the one where I'd give them um something they could be really really opinionated about but that had zero consequences. So like objectively worst biscuit or uh what's like objectively worst like cookie or like the um the food that you think is entirely overrated something to kind of get a reaction out of someone and to get a few laughs maybe but like not not to kind of like start arguments over and it was uh yeah it was good fun for that. That's funny because um like I haven't tried that at work um but uh I re I recently in the past year I've been going to the gym for forever as long as I've been programming but um my wife does CrossFit and last year I said I'm going to stop bodybuilding I'm going to go do CrossFit with my wife and one thing that they periodically do because CrossFit has a lot of like community aspect to it but they'll they'll sometimes do like a question of the day and it's very interesting because like I'm not not a psychologist. My wife is a therapist, so she knows all about this stuff. But I I find it very interesting that we take these opportunities at something like CrossFit for it's a lot of community building trying to you know like the environment that you're dropped into with that is very supportive, right? Like you on some days like yeah like you're technically you have scores and stuff. So uh it's like who you know if you finish the workout fastest your time's going to be better than someone else. So there's like there's competition and stuff built into it, but if someone finished first and say there's someone in the class, it's actually me a lot of the time. I'm very slow. I'm strong, but I'm very slow. My cardio is terrible. Um, so like I might be last a lot, but there's going to be people that are like cheering for you and stuff in the class. And I find that like, you know, I feel a lot of that comes from really simple things that we might overlook. things like a question of the day, things where you're just trying to get to know people a little bit better. And it's it honestly does not take, what's the right way to say this? It's it's simple. Sometimes people might not find it easy because they're like, "Oh, maybe it's awkward or I don't know how to do it." So, I don't mean to say that it's easy, but some of these things are so simple to do because it's literally just be a like a decent human being to other people >> and then some of this stuff just happens, right? >> Yeah. Yeah. Yeah. I actually I was thinking about what you were saying when you saying I love I I love that part where you're saying that some people are just like sort of cheering you on as you're you're wrapping up and I wonder like how much just like those like those small acts of just you know uh creating community creating that you know question that day uh really helps people see each other as like you know just other humans kind of going about it um and creates a much more supportive atmosphere than otherwise might have. Uh >> yeah, I think a like I know it like I don't have I don't have evidence. I don't have like a data or like studies that like show this, but like I feel like it genuinely helps a lot because when you have enough of this over time, you see people as other people. Like they are living their lives. They got families. Some of them don't. Some of them move in jobs. Some like there's they're just other people. And instead of looking at them like like I'm taking the CrossFit example. instead of being like, "Hey, you're you're direct competition to me and like you are time and numbers because that's all that I'm kind of equating myself to with you." It's not like in the in the moment when you're trying to, you know, push past and see if you can get the best time or something. I think a lot of people anyway, it's they're focused on themselves. But if you were highly competitive, I am not. Um, then then you might be kind of doing that like, "Oh, I got to out this person, like I got to beat, I got to get the best score." But when you're done, like you're absolutely cheering everyone on. And I think that a lot of it comes down to because you're seeing them as other people. And for people that are listening to this, I realize that might sound super fluffy, kind of woo woo, but um like I would say this, I'm sure there's other other uh sort of careers and professions, but in software engineering like it's it's people like you are solving technical problems, but you're not doing it alone. And uh the the people part is so important. >> Yeah. Yeah. Yeah. 100%. Um have you ever seen Nick Means's talk? Eels >> just delayed a little bit there. >> Yeah. Yeah. I think it's just gone up. >> Yeah. Sorry. Have you seen Have you seen Nick Nick Means's talk uh Eel's Tower? >> I have not. No. the basically the the entire point of the talk is exactly what what you were talking about where uh >> okay >> the the big takeaway like without spoiling too much is like hey like you know it actually took a lot of people like and a lot of buying a lot of relationship building just to get the Eiffel Tower built. Um it's a fantastic story. Um, but it's just anyone who uh who works in engineering really just kind of that thing like you want to build great things, you're going to have to do it with other people and you're going to have to find those points of connection no matter how small they are. Um, and even like to to your point too, if like you're having a hard time with your manager, just like yeah, just finding those points of connection, like there's always something. Um, and it's always a good like uh when you find it too and you just start riffing on um your uh actually but we had a new starter the other week and uh he and I were talking about just a a shared love of a partic like of D&D and and a particular video game and just kind of like riffing on that and it was just it was great. It just immediately kind of set the scene for the rest of the conversation. It's awesome. >> Right. And it's like it's a it's a very simple thing, right? I'm not again not saying that it's easy for someone to do that because if you're listening to this you're like you might be going okay like sure you want me to go talk to my manager about about video games and it's like look like I'm saying it's simple but if you start like break like easing into it finding opportunities where you can have >> small conversations about things that aren't necessarily work um or they could be work too and you're finding different things to talk about but the point is like trying to understand more about the other person in in a more natural way. Like I I think it it can go super far. I have >> employees on my team. And by the way, I think especially for managers, like if there's managers listening to this, if you're like, I don't know anything about my team. I highly recommend take all of your next one on's just take the one-on ones and go talk to your people about about them. Uh again, don't force them to go talk about their private life if they're not interested in that. But like I have I have an employee that loves to hike. I have uh an employee that uh she's, you know, very focused on, you know, her son going through school and things like that. Uh I have another employee who's getting more into the gym. Like there's you can all these things that you start spending time with people. One of the things that comes out from that is that people really feel and it's it's it's not like an illusion, so I don't mean to say like it's going to be dishonest here, but like people really feel that you do care for them. they they realize that like they can trust and respect you. This is the type of stuff that when you build it up over time like you as managers or you know senior engineers or anything like sometimes yes the the title and the role gives you gets you a little bit of that trust and respect but I never want people to rely on that and to be like look my title says X therefore you must. It's like, no, you still have to go build and earn the trust and respect. And it can happen a lot through these little conversations where people are like, "Oh, you actually do listen to me. Like, you do understand me. I am heard. I am seen." And so, I feel like that's just a again, it's such an opportunity to to get that from the people that you work with. >> Yeah. Yeah. That's it is actually genuinely one of the best parts is because when you get to know them as a person and you can help them as a person and then you see what they they accomplish, it's just that much more gratifying as well as a as a manager. >> Um. Right. >> Yeah. >> Cool. >> Yeah. And so Tom, I I know like we talked a little bit before and I don't I don't want to necessarily put you on the spot. I know you said for for some of the things that we're talking you have slides. I don't know, not to necessarily share cuz I think there's might be some some technical things, but I wanted to give you an opportunity if there was aspects to to some of these things that if you wanted to take the opportunity to like we can kind of shift the conversation to touch on some of those things more specifically. >> Yeah, sure. Um, so maybe it's worth actually starting with a little bit of uh context. So uh was it this would be almost 5 years ago now. Um so I I am Australian. Uh I'm based in South Australia. And at the time about 5 years ago, most of my team were uh based in Melbourne. We did have some folks in Queensland. We had one one person in Argentina um and one person in the States. Uh but most of our uh team members were based in Melbourne. The reason I sort of set that up and and the reason I talk about um that with respect to our work is that you know at this point in time we were sort of like midway through uh our u second project that had gone like well beyond a deadline and most of my team are stuck in uh lockdown in Melbourne which means that you know they they really weren't able to kind of like leave their homes and their 8 hours a day that they were spending at work kind of sucked. So, um, in the reason I sort of set that scene up in order to kind of like give some context. So, I see if I can figure out how to share the screen here. Uh, like >> I can switch the layout if uh >> I should I will I've got a a double monitor. It just might look a little bit big. So I might just say okay let me try this and then I can add to stage and I think >> I think we got it. >> Yeah. Cool. Okay. So the reason I set that context is so at culture amp uh in the area that I was working we run a performance product. It runs twice a year with the second time around through a project that's gone well behind deadline. Um, and uh, part of that too is that when you go very far over like what an estimated deadline was, you know, your product manager and designer aren't just going to go sit there waiting for things to happen. But we've got this problem where because of those sort of end of year pressures. There's also this pressure on to have like all these things in place uh, come performance cycle season. And I really what I'm trying want to do and thinking about is how to take this massive build measure learn loop and not only get faster at going through that loop like you know building the product you know measuring did we actually do the thing taking that learning in before we build something again but also reducing the size of it as well right so we want to take it from there to there like ideally and so the reasons um let me just stop sharing for a sec. There we go. Um, the reason I said I set all that context up is because like we've got an opportunity with a um, we had a a newish sort of like tech lead kind of join us at that time. Uh, we had a new product manager coming in and sort of looking at some like future work coming up. Something needed to change, right? Because otherwise, like on paper, the team's great. Like great psychological safety. Um really good kind of like environment for the team to be in. Everyone kind of gets along with each other, but like clearly something's going wrong because we're just missing >> uh important kind of time frames. So, uh it's around this time that I'm I'm thinking a lot about like, okay, well, we can cut our work small. We can kind of go back to how I used to work in that previous team where we were delivering pretty regularly. Um but what do I do about like estimation? like we still need to be able to communicate when something's going to be done, but we're by any means of measurement clearly terrible at it. Uh so we tried we tried stuff like um confidence intervals and like percentages and um I just couldn't get past this general idea that um what I was asking folks to do is to spend a lot of time thinking about all the possible sort of variances in in work and all the things that might happen over the the course of a period of time and go like give me a magic number right that it's going to somehow satisfy uh you know our stakeholders in that equation. And that, you know, if we're on target, great. If we're off target, you know, we could kind of manage that conversation, but the longer that conversation goes on, the more friction there is, right? >> Um, and you, as much as I I would like it not to be the case, it's very easy for like estimations to become expectations and it just it's unfortunately or or fortunately like, you know, at the start of the project, you know the least about what you're going to do, >> right? Yeah. So, um, what I was sort of like thinking about this and sort of ruminating on this and just kind of going, look, you know, the fact is like we're always wrong about this. I don't really want to keep focusing and putting all this energy and and attention into estimation. Uh, so I'd rather focus on like did we deliver the value? Can we make the work smaller? Brothers get to be, you know, really make the team as good as we can. And around this time, my colleague uh Mark Barber sort of said, "Oh, you should definitely check out Little's Law and what what you what do you mean?" Like I was pretty new to like actually really focusing on like delivery um as opposed to just the technical stuff. And um he kind of gave me like uh the little equation. And I'm going to share my screen again. Let me go. Fine. Sorry, it's not the >> All good. No worries. Uh, let's see. There we go. Share this window. >> There we go. >> Share. And we'll we'll hit play on that. That'll probably ask me again. Yep. Share. Let's go find it. Uh, sorry. We'll probably need to edit some of that out. Um, this like I mean like I've reduced it a fair bit, but effectively and and sorry Mark, your your image is on the screen now. It's a good thing you're okay with it. Um, like the amount of time remaining on like your work is, you know, equivalent to the amount of stories done divided by your work in progress divided by your average cycle time. Now, there's a bit of nuance to that and we'll we'll probably talk about that, but really like if you like boil it down, it's really just like, you know, the time for a queue to process is like uh, you know, the size of Q divided by how fast the cube moves. You know, that's you see that when you're you're waiting outside to go into somewhere. you're like, "Oh, it's moving pretty quick. I'll be in in 5 minutes. Oh, it's moving pretty slow." Or, "It's a long queue. It might take me a while." And so, um, he sort of suggested I start tracking in Jura like all of our stories and like their cycle times. So, like how long did it take to move from in progress to done? Oh, come on. Where's my mouse now? There we are. Um, it wouldn't it wouldn't let me go to the right. Um, >> you're trapped. >> So, uh, >> so yeah, we we started tracking that in a spreadsheet for this small project cuz I'm like, "Okay, cool. You're telling me I can get this magic eightball and I'm going to know when my work's going to be done." Yeah, sure. Power, whatever. But we'll we'll try it. And um, at the time I sort of skunkked it a bit because uh, stakeholders like, "Oh, when's it going to be done by?" I'm like, "Oh, we we've you know, we've given it an appetite of 6 weeks." which was true, but I was just like, well, I'm I'm pretty sure it's small enough project that the risk is not there. But we tracked it all in a spreadsheet, had a look at that stuff moving through, and it was it was pretty accurate. Like we we didn't have everyone in the team working on that project, but we were able to go, yes, we're going to land within this date and this date. Uh so we took a couple of learnings out of that uh and we started importing that into the the next project. So number one was we were already uh pretty engaged with a good refinement process by that stage. Like we'd started adjusting like our refinement in a kind of like a canbanesque thing. So we'd started moving um you know we'd had like a prioritized list of work and as we go into our refinement sessions we time box them to about an hour and a half but we just kind of work our way uh from top to bottom just gradually refining the work and bringing it up so that the stuff at the top there anyone could grab uh and we could kind of run with and execute with. The reason that was important was to just it really enabled folks to have like a really clear understanding of why we were doing something, what they needed to do, and they could just kind of pull the card and execute on it. >> Um, which was good cuz then it meant like folks that it might have been a growth opportunity for could grab it as well as folks that just wanted to bash it out. Um, but it became like the team's work. Uh, the other things um because we already had that in place like the rest of the stuff we could do quite well. So, one thing with uh Little's law and that uh coming up with like an actual like forecast as opposed to an estimate is that that's going to work best if you have small size projects like you scope your projects as small as they can. Uh and if you have your cards uh the same size, so you try and like make your your uh slicing as evenly as possible. We'll talk about why in a second. Uh you also want to try and keep your work in progress limits manageable. So that uh if you have too many people working on too many things, the amount of time that you're going to spend on like say code review will go up just because there's not enough people to be able to context switch. Uh and then uh what else we do? Just think about anything else really. those were we talk about this later but also sort of look looking at sort of things that would like block us. So >> okay >> um if if whatever reason uh there was something that needed additional discovery or maybe like it's already in the flow of work and we we know that we sort of hit into a little bit of a blocker we would sort of swarm around that. So >> okay, >> bigger picture what we started doing is we took the learnings out of that project really was that we we could see that we could deliver and we could forecast but we also knew that there like that equation is only part of it. So I said you know you divide by the average cycle time you're really dividing by the average cycle time as your lower bound but your upper bound also includes the amount of variability in that cycle time. So the game for us became okay like in order to kind of be as accurate with this forecasting as we want to be we need to really kind of reduce that variation. We need to reduce that variability. Um and that for us over the we started you know doing things like user story mapping. We were already doing like the refinement sessions. We were getting really aggressive about our slicing. Uh we were really kind of like mobbing around and and pairing up on issues that were like blockers in order to kind of move them through. really kind of meant that over time our cycle time really kind of like dropped into like a sort of steady state and we'd still have a certain amount of variance, but that was like two days. >> So, uh, with that two-day variance, what that meant was that I could pretty accurately go to our stakeholders with each release. Uh, we're going to release, you know, this week sometime between this time and this time pretty consistently. And over time enough trust kind of built up where the questions stopped being about okay well when's this thing going to be delivered and started being like okay how are we measuring the value uh what's coming up next what are we thinking about this and that and the other which are much much healthier conversations with your stakeholders and hey why is this three months behind you >> right >> I have uh I have two questions that as you're chatting through I had um I've had historically teams uh not at Microsoft prior to Microsoft doing canbanes style work. Um and even before that without can because I wanted to ask about whip limits uh the other thing was really around uh estimations or and when I saying estimations here I mean like the thing that you're mentioning about getting things to be uh similar in terms of size let's say. Yeah. Um so the first question I wanted to ask is like uh did you have any strategies or did it come together more naturally for um managing the how much debate or time goes into like getting on the same page for how how much effort or the scope of something and to elaborate a little bit I know you're not exactly saying this but uh if I've done like story point estimates and stuff like the the typical thing would be like someone's like that's a three and someone's like that's a a a million and you're like well okay and then you have this debate for 45 minutes and you're like okay well you probably could have done it in the 45 minutes. So like what what did that look like? That's the first question around getting people to like kind of align to hey we the goal is to get things to be similar size. >> Yep. Um, so for me, uh, there's different ways of doing this, but for me that the the way that I would kind of like the axes kind of slice on was go like the question I'd ask is, is this around 3 days worth of work? And and that's uh you do it, okay, cool. But you're still estimating. And that's true. But the difference is that you can quickly answer that question. You have to think a lot about like like I don't know where I'm going to be in like a month's time. Um, let alone my my work, right? But I do know like yeah I think I can work on that for 3 days and that's probably going to be about done. That's a very quick kind of answered question. The reason I I ended up kind of couching to that was cuz that was sort of um starting to become present in some of the data that we were already collecting required very quick thinking like you could just answer that question. Yes, you'd get different um you'd get a little bit of var variance in terms of like who was asking that, whether that be an associate or a junior engineer um to a a senior. Um but the way that I kind of took that was that that variance would ultimately be baked into like that variance in cycle time anyway. So as long as most people like, "Yeah, I think that's right about 3 days." I was like, "Okay, great." Um and as it happened anyway without cycle time and and we were working on a particularly legacy code base around that time uh that 3 days was mostly pretty consistently 5 days but it didn't matter. It just like are we getting something consistently the same size. Um and enough of that enough the data to kind of back that up would proved out really well. And in terms of constraining the time, um, because by that stage two, we'd kind of done everything we could to go to really refine and shape that work. Um, if the answer was no, it was usually a case of going, well, one, do we need to slice that further? So, it is 3 days worth of work that we feel comfortable. Um, and we just immediately jump to that question because that was usually pretty revealing. If the answer was no, sometimes it does need to be like five six days, but we just put like a lot of good um we just make sure there was good signal around it. So I know if you I don't know if you find the same thing, especially with like like purely technical pieces of work that you just kind of need to manage. So we just do that same thing. We just keep a lot of visibility on it. We probably treat it as a priority, which meant that if if folks needed like reviews or jumped in, we just do everything we can to get it out of that that queue, that system of work as quickly as we could. >> Yeah. And that that totally makes sense. Um, and like you're saying, there's sometimes there's work where maybe it's not even that it's complex, but you're like, "Hey, look, like for me to get through that. I know like I basically in my head I know exactly what I have to do and it's going to take me like I'm just going to have to grind through it for it's not going to be 3 days, but like I feel actually pretty confident that if I can churn through it, like it's going to be five, six days, whatever. uh but the risk is almost low in that case because like the complexity isn't necessarily there. When the complexity and the amount of like ambiguity in what's being done is great and that's the reason for the the five six whatever it days then it's like okay maybe that is uh let's go back to the drawing board and kind of chop it up a bit. But the the last thing that you said that is literally the the next question I have is is around whip limits. And so, um, >> I personally, I think I only had one team where we, I don't want to say took this seriously. A lot of my, um, a lot of my teams were like, uh, I would call them continuous improvement. So, if we tried something and it wasn't working, great, let's try the next experiment, keep evolving. But I had one team that kind of arrived at like canbanish and uh, the the isish part is like retrospectives and whip limits. That was kind of what we focused on. And we had what I thought was a pretty good system for like we set some whip limits, we were tuning them and stuff and I was curious like how like did you have to do anything to get people bought into that? So for example, you were just saying okay like if we have to get people onto code reviews to start pushing things through or whatever like how do you get a team to be into that versus like hey man let me just work on my story like I want to get my work done. >> Yeah. Yeah. Uh I mean going a few steps back like even before we started this process um that buyin was pretty crucial. I mean, we had a good basis of psychological safety, but I I met with every single member of the team and kind of going, look, this is what I'm thinking this in terms of our strategy, like how I I think we could be working a little bit better. And everyone ultimately ended up also contributing, you know, their own two cents, their own opinions about things we could tweak or things that they'd like to change, right? Which um most of those ideas in some form of fashion or like some component of it would make it into how it worked. And that also proved to sort of uh increase that level of buying because folks actually felt like they had a stake in it um because they did um on the ongoing uh sort of basis in terms of getting by for like things like whips and and working together as a team. Um, like you said, that that just took a while of kind of reinforcing going like having you just kind of like wind back a little bit like even with like the the slicing like I'm a big believer in um that I only really want to be doing something if it actually serves the team. So if it doesn't serve the team then we it's there's no point. Um, so same with like the the buying on the whip limit like so what we would start doing is we would set a team goal and all we'd have like we wouldn't be so kind of rigid to go look we're going to try and get this many stories done by the end of the sprint. We go look this is the outcome that we're driving for. Um, and you can pull in cards whenever but this is the outcome we're driving for. And over time we started changing that conversation and a lot of the engineers the team were already really great at this anyway but it it became a lot more about uh the team really owns its work. This is the team's work. This is the team's cons. This is the team's goal. Um and so if we didn't hit that goal, it's not one individual's fault. It's it's on us as a team anyway, >> right? Um and then so for the whip limit stuff um part of that too was um beyond just like helping reduce that variance and cycle time part of that was just that um a lot of a lot of what was baked into what we were doing was about making sure that we were sharing that that context and knowledge and understanding across the team and about um optimizing for like learning and and development and growth. So sometimes that meant that uh without whip limit it typically meant that there was at least one group of people pairing and and sharing knowledge and kind of like going back to what you were saying earlier like building relationships, building trust or just leaning onto that mentoring bit or just just collaborating. Um sometimes it might mean an individual was going off and doing a tech health thing but at the same time the priority we're still you know uh we're working on this particular goal as a a group of people. >> Yeah, that's awesome. I think in in the situation situation the team I had the so the scenario where I had folks that were kind of operating this way. I think one of the things that I don't know if it was like the the side effect of the whip limits or the other way around, but like being able to have this conversation of like this was we did monthly releases and and two week sprints, but being able to to say like this is what's going into the release and being like, hell yeah, like that's exciting. uh was pretty cool because if you okay if we had a lot of stuff that was in progress and we would reach like the end of the month and we're like okay well you can't ship the 17 things that are in progress so like that means that yeah sure the next sprint we're going to we're going to have a ton of stuff that lands that's going to feel great and so maybe on average overall throughout the entire year maybe it ends up being the same let's say but uh I would actually argue you probably not because with too many things in progress there's a lot of overhead for context switching. That aside that having folks being bought into like this feels like exciting and like hey if I actually help you with this thing somehow like if we work together on this doesn't matter if it's oh you need me to start reviewing this. We had uh for digital forensics sometimes it was like we needed to generate data for mobile phones and it's like hey like you're wrapping this one up and like we know we want to get this one in. let me go generate the data for that. Like, >> yeah, like I'm a software developer and for me to go send a bunch of text messages on a phone or something like maybe that's not the most thrilling for me, but what is really exciting is that I can be part of landing this feature with you and like I'm going to go start on that right now so that you know that's the next thing in in whip that we can unlock. >> Cool. When you're done, you know, or you're getting help from someone else to wrap up that work. Great. we can kind of basically swarm doing this work so that we can get this one last thing in and having people rally behind that. That's why I'm saying I don't know which way it was like but >> both I don't know >> how and how good does it feel when you're in that spot where like >> it feels like everyone's got each other's back and it's just like helping to kind of realize that things you just you don't feel like feels so much better than just sort of like feeling like you're you're alone and it it feels like you're okay cool such and such is helping me now we're free we're going to go help you know uh such and such other team member and then it's like it feels like you're all kicking goals together, which is just really great. >> Yeah. And like again, for folks that have been in that scenario, if you've never been in that scenario and the only sort of working environment has been like I pick up the next feature or bug fix for me, I go work on that mostly in isolation. Maybe yeah, I get got to get people to sign off on the code review. Maybe I have a design doc and that's the only other time I'm getting feedback. like when those are your only sort of touch points, it it often and I'm not saying it's impossible to work this way, but it I feel like it often is kind of like a group of individuals versus like a team of people working together. And when you have that experience of like like anyone on the team has your back at any given moment, it feels like it's really cool because I'm sure lots of people have experienced this at some point in and maybe not if you're if you're very junior, but at some point in your career, you've been, you know, you've been working hard on stuff and you're kind of looking around you being like, man, like I don't know, like I feel like I'm doing a lot. it doesn't feel like you start to kind of look at maybe what other people on the team are doing and you're like it doesn't really feel fair or like how are we only getting this much done and it just kind of feels like frustrating and sometimes like >> I don't want to say why even bother but kind of like I don't know like if I put in more effort it's not really going to >> it's not moving the needle on anything and it just feels demotivating and disengaging but you literally invert the entire feeling when you're like wait a second like everyone else is willing to jump in and help and it's it's wild how much that transforms things. >> Yeah. Yeah. It Yeah. Yeah. 100% that and it just becomes that uh it it just becomes that extra kind of like uh engine for like driving and building like safety and trust in the team and like actually creating a like creating a a team of of people as opposed to like a bunch of individuals. Um >> yeah. >> Yeah. we have um there's without getting into the details of it but like I think in the one of the teams I have right now they're starting to experience a little bit of that they're dealing with a couple of uh couple of technical challenges that have surfaced over the past few weeks and it really feels like the few of them that have worked in different parts of that they're like they're jumping in to support each other. It's a and it's a live service and stuff too. So sometimes that means they're they're working at different hours where like maybe aren't their their normal core hours, but like you know I'm trying to make sure they're supported like hey I know you work late like start late the next day take the day off whatever. Like I'm trying to do what I can but it's really cool that like I'm not chasing them to be like hey you got to go help so and so like go get this stuff done. They're just in it and they're like you know they're proud of their work. They're happy to help each other. And like for me like that's a proud feeling. I can't take the credit for it, but like I'm like, "Hey, like that's what I want in a team because I love to see them help each other." So I I kind of I think that is because you know they know each other well. They've been working on you know they work together and it's not just well sorry it sucks that your work is on fire. I'm going to go take the next feature. >> Yeah. Yeah. Yeah. >> Um and so Tom, now we're coming up on time here. Uh, is there anything else from like in terms of the the slides and stuff that you had that were like other maybe sort of like final core points to >> Yeah, I mean um >> to touch on >> go through that again. >> I realize I kind of interrupted you because I had a couple of questions, but >> I I loving the the conversation. Um, let me go. Where are we would help? >> Hey, talk about this. Wait a second. I have a question for you that's going to take up uh all the rest of the time. >> It's just going to show that I could continue talking about this for uh at length for ages. Uh so actually let me skip past. I wish I didn't have the animations in there now. Um >> animations are the best parting uh So we talked a little bit about like some of the team impacts of things like work in progress limits uh refinement uh I'd reinforce the things like uh having a user story mapping uh map like just at the start to try and like deliberately help reduce the size of your scope. So reducing that input even before it gets into your queue is really really valuable. But again, just kind of like as with everything else, right? Like all of the strategy and stuff that we're applying is also about like sort of building that sort of like shared understanding, getting people like aligned um and understanding of like the outcomes that we're driving over. So before we've even like you know done any really serious wireframing like having that user story mapping is great just to kind of uh think about something about going look actually maybe we can achieve this this way or this way which can really help uh permeate its way through that design solution without necessarily being as you know detailed as we we have to we have sometimes had it in the past I should say. Um, >> okay. >> And just even like doing one of the things that I would find a little frustrating too with not only kind of being over schedule is because we're in this place where we were doing too much uh work up front is we'd release something and then we get all this kind of feedback that would have been great at the towards the start of the project or earlier in where we could have actually made really significant changes to that architecture to kind of support it. So for me, like part of this is really just about like like we're wrong on our estimates. We're probably wrong on what the customer wants, even with all the data that we have in front of us. Let's get this out there as soon as we can in a state that we're, you know, like reasonably happy with, but like a really small version of it, so that we can actually go, "Yeah, cool. We're wrong here. Let's go fix this up and and and let's like actually like iterate and improve." Um, what are the other stuff? One of the other things I didn't talk about with whip uh too is just by deliberately setting that whip limit a little bit less than the team. Um, one of the big things that I wanted to reduce was the amount of stress in that team, right? Like so if all my estimates are kind of based on like a whip limit that's about at least 20% less than the team's overall capacity. like if someone needs to go on holiday or become sick or you know anything kind of like happens on that short term doesn't matter I've got like buffer you know I don't have to worry about that that's just not a problem and that takes all the stress out of the the team um talk about slicing um and that's kind of a little bit of a visual of what we've been doing with regards to slicing in terms of just kind of you know moving that up where like a lot of my focus in those sessions are really just kind of like on the next two to six weeks and talking about it and that more complete picture of what we're going to be trying to do. And over time, like what we'd find is like that would ultimately end up in less rework. Uh you and I talked about like test strategies towards the start of this conversation. And a lot of this for us too would also involve like shifting left on quality. So we'd have those questions like you talking about the different things that we'd be testing for, how we were going to test it. So that by the time we released it, uh we felt really confident in what we're releasing. And the difference in the amount of like bugs that we tackle between releases before and after this was um quite dramatic in terms of just just cuz we're thinking about lots of small things. It's easier to reason about small things. And I suppose that's probably the main takeaway of any of this. It's just it's it is fundamentally easier to reason and think through and plan around small things. anything you can do to make it small and consistently small, you're going to end up with a a a better result in terms of like the flow of that delivery and then your ability to repeatedly deliver results. Um, and then ironically like we were both had more meetings in terms of like we had a refinement session, we would have our retro, we would have like, you know, demo sessions, but overall we'd spend less time in meetings because a lot of that context was already kind of there in those cards. Um, when we were doing that slicing and that refinement, uh, we talked about 3 days worth of work. Uh, and you talked about like different ways that we'd sort of slice. So we might slice by uh instead like instead of just like is it three days worth of work, we'd look for like different themes in the story. So we'd go like hey is there >> okay? >> You know like if the card said like admin or um another role like a manager like in the actual card like as an admin or manager I want to be able to do this. Like that's a straight sign to me that that's something that we can slice there in order to kind of like make that work a little move through a little bit more smoothly. So maybe we just deliver the admin portion first or the manager portion or maybe we'd start like splitting out like different functions or just looking for anything like an and or an or in the the story would you usually be a good indicator that we could kind of like take that work out and kind of slice it a little bit smaller. Uh we talked about uh that's the other cool thing. Um, okay. We talked about like lower whips for like bottlenecks and kind of using those to help with swarming. Um, the other thing is just creating that visibility over the stuff. Like I wouldn't say I'm I'm ever going to be the biggest fan of Jurro, but one thing is nice is that you can um create these little um kind of visible markers over like how long something's been in a particular column for. So if you've got a sense of like okay well the max something should be in progress is like 3 days you can start having a look at that and maybe having open conversations that you stand up to go look hey like we said this was our goal this is currently like 3 4 days in progress do you need a hand or is it under control or you know is there stuff that we can take off your plate so that you can focus on this task um and actually have like meaningful conversations about the work. >> That's a really interesting one. Yeah, >> because uh I at different I think there's all sorts of different reasons why this kind of thing happens in in like whatever type of syncup meeting you have. But you might have say more junior people that perhaps they're they're hiding behind something and it's like oh no it's it's getting done and it's like well I mean it's it's not we can see it right. Um, and it's not it's it literally there's a whole, you know, unlimited other reasons why this type of thing happens, but it's visible. And now it's not a matter of like no one's there to make you feel bad about it. It's not a personal thing. It's literally this is what we were talking about in terms of timing. It's not there. And like, hey, like we're a team. Like what do we do? Right? Like it's do you need help? Maybe this person was, you know, they were sick for two days and um they only got just started on it in the first day and it's like, okay, like it's very explainable. No one's chasing you down to to punish you. It's just like we're a team. How do we make this kind of go in the direction that we said it was going to go in? >> Yeah. What do we >> 100%. >> Yeah. And I think you you've covered off quite well there that like some folks might be like a little bit like sort of like fearful of like that being like some kind of accountability sort of sledgehammer >> uh aimed at them. >> But that's not again like that's that's not the the intention so much as going look hey like we said it was this maybe we were wrong. Maybe like you said maybe you might need more support. Maybe whatever the case might be is that like this system works best when we're able to kind of move those cards from like you know uh to-do all the way to like done as smoothly as possible. And if there's stuff that we need to fix so that like that happens more smoothly or if there's more support that we need to give that we're not giving like those are really valuable feedback points for the team and you shouldn't really have to wait till retro to get them right. you should be able to kind of uh action those as they're they're coming up and and continue to kind of create that environment where like yeah, okay, cool. We dropped the ball here. We need to pick it up. Let's figure out how to do it as a team and like actually focus on that or okay, cool. >> And the word you used was we, right? Like it's not you dropped the ball, it's me. >> Like even at the start of this conversation, if you have a look at like me going our team was behind the eyeball estimation, like that's my responsibility as a as like a delivery lead right at the time. So it's it's about that sort of like shared sense of ownership and like everyone kind of being in that to kind of see that outcome through. Um, and you know, like as long as you've kind of got that that data behind you, and this is a actually a little snippet of the spreadsheet we had at the time, it's easy to start like building up that clearer picture over time of, you know, where are you spending your time? And for us, that ended up actually like um eliminating that there were some areas where we had external dependencies that were costing us more time than we wanted. and we're able to actually sort of send engineers over into other teams to for secments to improve that experience uh to help you know further reduce our cycle times. Anyway, um but yeah, ultimately in a nutshell like we were able to use this to really kind of forecast our our delivery using that cycle time and we'd see like in that same sort of spreadsheet uh that cycle time go down. And I found out recently a colleague of mine has actually found a much better way at kind of like fishing this data out of Jura and using some like AI tools to kind of actually generate a lot of this automated reporting which I'm I'm really curious about because even though I'm a staff engineer, I still want to try and see a bit more of that data. And um it it really did make a a big difference for us uh over time in terms of our predictability. Um, and like I said, you know, it gets to the point where, you know, uh, we we were able to kind of like shift that conversation away from like dates and deadlines because ultimately, you know, if you know it's like when like the the train's coming like every 5 minutes, you don't care about what the schedule is. You just know that you're able to get a train in 5 minutes. Um, and that's kind of where we're at, which was really nice. It's a that's such a good uh analogy that slightly unrelated but to the same same thought process. We had uh one of the teams that I I managed, we were the sort of the first to get to a point where like any any commit we pushed up and we had a build come out of it. We were like literally you can take that and ship it if you want. Um and like that was the goal of the other teams, but like it never it shouldn't say never. It wasn't really at that point. And when we would have like uh our one team had a smaller piece that would uh get released standalone but also would get released bundled kind of hard to explain but it could get packaged into a larger suite of pro uh products. Um if they had to cut like a a hot fix or something they would be going okay like what do you guys have to do to get your stuff ready? We're like just take whatever is there. Just take whatever is there. And >> it was like we had to coach people to let them know like hey like if you even want us to add one more feature and you want to ship it like it's fine like we literally if it gets committed we have full confidence. So we're like well how much time do you need to go test it? We're like >> if it's in we have confidence >> 100%. Um, yeah. I mean, I think that's I'm going to cut the the slides off there, but like that's I mean that to your point, right? Like that's that's sort of like ending up confidence bit was just uh where we ended up where we were like quite confident in whatever we were kind of like pushing out. We'd gone from like say two releases in 12 months to like um in a very short space of time like uh 10 in just as many months. Um, and part of that was just from treating that work as a queue and from like optimizing everything around like let's make movement through this queue as smooth as possible. Like let's let's really optimize for those flow metrics. Um, we were able to really kind of like turn around and do that. But um, the last point you said that like your team was already in that position when like hey the commit's there we're at the point where doesn't matter like we as long as our commits there it's all good. It's such a gratifying feeling as a team to know that like it's it's just takes all the stress out of the equation. Like you just feel like you're hitting a winner every every time you step up to bat. >> Um >> so you have you know you you get to that point with your you know continuous integration systems. you the the parts you were talking about were, you know, even imagining going through uh your your sprint commitments and stuff. And like again, if you're able to get your work structured in a way where if someone was like, "Hey, look, like we're halfway through the sprint, like are we able to take what's here like halfway through?" And if you're like, "Yeah, like you're not going to get the stuff that's not done obviously, but we've already been able to land things in the sprint." Like that's pretty cool, right? like getting to this point back to what you were saying and I can't don't have the exact quote but basically having like the smaller pieces right like when you can break things down smaller you can land them faster you can understand them better you can reason about smaller things better um a lot of awesome things happen so I think that's it's a good takeaway >> awesome well Tom I wanted to say thanks so much for for chatting through this with me um if folks wanted to get in touch with you Where are the best places to to reach out to you? >> Yeah, thank you for uh thank you for having me. It's been a awesome chat. Uh you can typically find me uh on LinkedIn these days. Uh you'll see me on Tom uh Tom Ridge on LinkedIn. Uh the other place you can find me, I do have like a substack. I post in both places somewhat hazardly at the moment, but I should be getting back to it shortly. Uh so particularly if you're interested in Elixir stuff, I will be writing a fair bit more about that shortly. >> Cool. Awesome. And I'll make sure I'll get links and stuff from you after and I'll have them in the description and all that so I won't mess it up. But uh yeah, Tom, thanks again. Uh I think for me this was like a super good reflection of a bunch of things that I have touched on in my past life and it was really cool to see how you were able to bring these things together and have like what really feels like an awesome success story of taking something where you're like we're not doing a great job to like hell yeah we're crushing it. And I am sure that feels amazing. >> Thank thank you and thanks thanks for the feedback. Thanks for the chat and uh yeah uh for my part minor apologies about the um having to skip through a few slides and animations towards the end. >> No worries. >> Cool. >> Awesome stuff. Okay. Thanks again Tom. >> No worries. Thanks so much for watching. Take care. See you.