Technical Agile Coaching with Emily Bache

Matty: [00:00:07] It’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matt Stratton. We’ve got a great show as always. I always say we have a great show today, but hopefully we have a great show every day. But before we get into that, how about we hear a little bit from our sponsors? The role of a developer or engineer has evolved into a security-first mindset. The ability to confidently build and deliver your software assets across the globe while also avoiding supply chain threats is a priority for organizations to remain successful. Cloudsmith is software supply chain management for modern DevOps practices. They provide a single source of truth for all software assets while integrating with the package formats your team is used to. With a focus on securing your software supply chain, Cloudsmith is truly at the heart of your DevOps ecosystem. To learn more and receive a firsthand look at their solution, please visit arresteddevops.com/cloudsmith. Rootly helps engineers manage incidents directly from Slack without ever needing to leave the tool. They handle all the boring and tedious manual work during incidents, like creating channels, looping in the right people, and acting as your scribe to document that ever-important timeline. Companies from 20 to 2,000 manage hundreds of incidents daily on Rootly. It’s super simple and easy to use. You can install it in 5 minutes or less. Visit rootly.io to learn more and mention Arrested DevOps for $1,000 off when you book a demo. Do you ever start a query going in your log aggregator, go get a cup of coffee while you wait, and by the time you get back, it’s not the answer you needed and you’ve started to forget what you were looking for to begin with? You don’t have time to waste like that when you’ve got issues that need fixing now. Whether you need to understand your entire overall system or drill down to the individual user level with traces, get the right answers fast when you need them with Honeycomb. Go to honeycomb.io/arresteddevops to use it for free. So for today’s episode, my guest is an expert on technical agile coaching and a well-known author. It’s my absolute pleasure to have a conversation about both of these topics, I guess the topic of technical Agile coaching and being an author, maybe some other topics. Emily Bache. Emily, welcome to Arrested DevOps.

Emily: [00:02:37] Thank you so much. It’s a pleasure to be here.

Matty: Before we kind of get into what technical Agile coaching is, because I’m very curious, and a lot of the stuff I’ve read that you’ve written is very specific about that modifier, but can you tell us a little bit about your background? Kind of what are you doing now and how did you get there? Might help color a little bit of our conversation.

Emily: Yeah. Yes, of course. So, I’ve been a professional software developer for more than 20 years. I started out as, like, a Java programmer and a Python programmer. And I became interested in agile methods and extreme programming in particular, in about 2000, and had some really good experiences with unit testing and pair programming. And I got really enthusiastic about all this kind of stuff. Quite early on, actually. And I got quite into this idea of doing coding dojos. I wrote a book about that, came out in 2011. And I’ve more and more been as a coach and a trainer in my career in the more recent times. And I just published a new book in January, Technical Agile Coaching with the SAMAN Method.

Matty: [00:03:49] Which reminds me, that is something I want to dig into, is what is that SAMAN Method, for sure. And we will, listeners, we will have a link to where where you can get Emily’s several books in the show notes. So make sure you check out our show notes. But so let’s kind of talk about that maybe, you know, what is the method? Like, you know, we don’t want to— don’t give away your whole book, obviously, right? Everybody, you’re going to need to go read the book just so we’re clear.

Emily: But, you know, yeah, yeah, no, I live in Sweden. I, I should have mentioned that probably. I grew up in the UK, which is why I sound very British, I guess. But I’ve lived in Sweden for so long that of course I’ve learned Swedish, and this word samman It means together in Swedish. And I wanted to name my coaching method and it seemed like a good fit. So I’ve been coaching the last few years in a particular style, and that’s what my book is about. So I gave it this name, Samman, so that people would be able to find out more about it on the internet and all of that kind of stuff.

Matty: I was wondering about that when I was looking at the name of it and I, you know, I was like, is that someone’s name?

Emily: [00:04:53] Is that, but it’s the Emily Method really, you know, but no, I mean, I’ve I’ve taken lots of influences from a lot of people, from developing this way of working. So, it’s not just me.

Matty: So, when we think about this idea of technical agile coaching, like, why that modifier? Like, what’s different than maybe what people normally think about what an agile coach does? What’s kind of that demarcation or specificity there?

Emily: Well, I work for a company called ProAgile, and lots of my colleagues are agile coaches, really good agile coaches. And they’re talking to the leadership, they’re talking to teams, they’re doing team building, they’re looking at the processes that are being used, and they’re doing lots of really good work at that kind of, you know, people and process and management level. Whereas the technical coaching that I do is very focused on developers, testers to some extent, but on code and technical ways of working with code, basically. So, it’s a bit different from what these other Agile coaches that I know do. And it needs a different skill set in some ways, and it produces a different kind of result. I think, actually, to be really successful, you need both kinds of coaching. And yeah.

Matty: [00:06:06] I was going to say, I can see that as being a gap in a lot of the transformation, you know, places I’ve been that have gone through Agile transformations and everything is, yeah, traditionally thinking about, from the process, and how do you organize work and do things like that, but then it would get into the, okay, now how do we affect this to our technology, to our product, to the stuff that we’re building? And that’s a practice, that’s software engineering practices, like, go do that.

Emily: Yeah, and DevOps, of course. DevOps is very much about lots of technical practices, and how we write code, and how we share code, and how we decide when to deploy. And yeah, it really goes into that area quite a lot, actually. And I think one reason I call myself a technical agile coach, and not a DevOps consultant, is It’s kind of historical really, I guess, because I found Agile first.

Matty: And, you know, if we want to, you know, play the history, the reason that it was called DevOps is that, you know, Agile System Administration was too long of a name for a conference. So that was what it was supposed to be at first. So DevOps is technically Agile System Administration if you want to, you know, go down to the—

Emily: [00:07:14] I didn’t know. That’s cool.

Matty: So where, and I know I was, you know, reading your blog and, you know, you talk about testing a lot and where are some of those things that you’re seeing has been kind of the evolution, you know, as we’re kind of going through this, when you’re thinking about how you have to think about testing differently, maybe, when you’re trying to put these kinds of practices in place?

Emily: Yeah. Testing is a really important thing for me, but it’s about feedback loops. That’s why. It’s not for the kind of, just because I like tests, it’s because it gives me the feedback I need to actually write good code. And to know when I’m on track, and to know when it’s safe to deliver stuff. So, yeah, testing is a really important part of what I do, teaching people to write better unit tests, test design generally. I spent, actually, a portion of my career as an architect working on more kind of higher, larger tests, larger-scale tests, integration system tests. So, it’s an area that I’m really interested in. And I do a lot of work with approval testing as well, actually. It’s an approach I really Quite a lot. Yeah, I could talk about testing for a bit.

Matty: [00:08:24] Yeah. What is approval testing?

Emily: Approval testing, which changes the assertion, the way you do assertions. In normal or regular kind of tests, you have 3 parts: arrange, act, assert, or given, when, then. And in an approval test, you change the way you do the assertion. Instead of writing kind of assert equals this thing equals that thing, and having both the expected and the actual value kind of in the code, The approval test says, okay, I just want you to verify this thing is correct, and I want you to verify it’s identical to what I approved earlier. So you’re always comparing against an approved version of the output that has come from the system that you’re testing. It’s not something that you’ve written by hand in advance. It’s always recorded from the system, pretty much. And it’s always just a straight diff. If it’s different, then the test fails. So in its essence, approval testing is just like a fancy way of doing assertEquals, really.

Matty: But there’s convention around it, right? Like you said, which is that when you’re thinking about it that way, it’s coming from the system, you’re not constructing it, and you’re just saying, is this different than what I expected? Not, is it this thing I said it should be, but is it different than what I expect? Is that kind of maybe a way to frame that?

Emily: [00:09:35] Yeah. Is it different from what I approved before? So, there’s definitely a human decision there. Do I approve this? It’s an approach that works best when you have tools. So, lots of people have kind of done this, rolled their own, just comparing against the thing that they have in a file somewhere. But when you realize it works so much better if you look at some of the tools that are out there. There’s more than one approval testing tool. I’m involved in 2 open-source projects, Approvals, approvaltest.com, and TextTest, texttest.org. And they’re variants of the same approach, basically.

Matty: We keep talking about, in DevOps and just software development in general, everything about this idea of shifting left. Right? Which is like, oh, shift security to the left, shift operating. And I think what that gets read as sometimes is shift the work to the left. And I think it’s really more about think about, and I think testing was maybe almost one of the first places we saw this misnomer happening where it’s like, oh, developers get better at writing tests, then we don’t need testers anymore because why can’t developers do that too? And the same thing is happening with security where we say move security left, and it doesn’t mean that you’re the people writing the code also have to be your domain experts in security. You still have those people, but they’re involved earlier. This is where maybe the leading question kind of goes or whatever. Is there still a place, like, what’s the— for domain expertise purely from a testing perspective, as opposed to just having developers get way better at testing?

Emily: [00:11:09] I absolutely think that there’s a place for people skilled at testing. I mean, absolutely. But the way I kind of see it is that there is kind of support in some level for helping the developers to write the correct, automate the correct tests, to be looking in the right places for the automation and not getting, wasting their time automating a bunch of stuff that’s not worth writing tests for. So, testers have a strategic role, choosing what is the strategy, what is the areas we need to really have really good automation, and also putting in the work of doing the exploratory testing and finding the new areas that there’s not enough testing, and we need more automation. So, I absolutely think there’s a place for testing expertise in DevOps organisations, even if the developers are doing all the automation.

Matty: And I think this happens in a lot of practices, right, where we look at the task that a particular function does and say, why can’t we just move that to have somebody else do? And it’s, again, back to this, when we were thinking about DevOps methodologies and Agile has been like this, it’s all cross-functional, you know, and that’s a big place where I feel like why DevOps and Agile in many ways are so closely aligned is that I think DevOps is a natural evolution of what we were trying to do in a lot of ways because, and this is me with maybe my chip on my shoulder as someone who spent as long as you spent as a software engineer, I spent that same amount of time as a sysadmin. And I remember the first place I was at when we’re adopting Agile. My question I kept asking as a person who ran ops and I was involved, I’m like, where’s ops in all this? And they’re like, that’s just a function. You know, the people who are helping with transformation were like, and then you have your testers are involved and your, you know, PM and your developers and your architects and everything. And I’m like, where’s, you know, where’s ops? And they’re like, that’s why you have ITIL, right? And then amusingly, if you look at ITIL and then you start asking about how software gets developed, they’re like, but that’s not what I do. So, so DevOps is sort of like, okay, great. Now let’s like, We got close with most of it and then we forgot somebody. And now we’re, you know, and we’ve said before, you know, all apologies to Patrick and Andrew, but like DevOps is unfortunately named because it’s what gives us— that name is what gives us DevSecBiz, QAOps, or whatever, where every time this stuff comes up, folks who’ve been in the movement for a long time are like, but it’s always meant that. But yes, it only— yes, the name only includes Dev and Ops, but it’s always been about being cross-functional and having that domain expertise and being Both, like, I think I hear this as like testers being consultative partners, but then also being able to chop wood and carry water in places too. I think that’s the thing when we, it’s this idea that you’re not shifting the work left. You’re not trying to have one person do the job of 2 people.

Emily: [00:14:00] Yeah. Yeah. No, I like that thing with the developers are doing a lot of automation, but if the, if you’re doing it well, there should be plenty of opportunities for the testers to contribute as well to that automation. And to, yeah, not just kind of advise the developers. But as you say, get involved.

Matty: So yeah, when John Allspaw was running, you know, Etsy and people would say to him, they’re like, John, you do all this DevOps and all this automation. Like, why do you still have a web operations team? And he said, are you kidding? I’ve got so much for them to do. Because now they can lay in that deep expertise. And I think that’s probably true with testing as well. If you’re not sitting and just running regression tests of clicking through the website all the time, which is not, you know, your testers have so much more value and knowledge and expertise to be able to apply.

Emily: Yeah. Yeah. I mean, we’ve been talking a bit about testers now, but when I’m coaching, most of the time I’m actually working with developers. And the focus more recently has much more been on getting the developers to value the feedback they get from unit tests, to work in smaller steps and commit more often, get that continuous integration going, learn to split up tasks, use test-driven development. All of that piece. So, really, my focus at the moment is on developers rather than testers.

Matty: [00:15:16] So, when you’re getting into the nuts and bolts of the technical part of getting better at Agile, what are some of those areas that engineers need to get better at, or are learning to get better at?

Emily: Yeah.

Matty: Yeah.

Emily: So, there’s a lot of focus when you’re working with developers on taking smaller steps and getting better feedback. Because you want to, be doing continuous integration. So, you want to— and that means basically that you’ve got to share your work really often, and a lot more often than a lot of developers are used to. I mean, some organizations, you find people are sitting on their own for days or weeks before they actually kind of push their changes. And you want to get the habit to be pushing small commits several times an hour, if you can manage that. And of course, every commit, should have passing tests, and you should probably be adding new tests quite frequently as well. And the tests need to run in a short length of time, so that usually means unit tests. A lot of developers don’t really know how to design unit tests very well, or they haven’t really prioritized the design of their unit tests because they think, oh, it doesn’t matter, it’s not production code. So a lot of what I’m doing is teaching developers better test design, how to work in small steps, how to refactor safely. All of these things have been We’re in extreme programming from the start, basically. And it seems to me that it’s kind of the basis of the rest of having DevOps, and pipelines, and continuous delivery, is that you’ve got to have a steady stream of small, safe changes coming from the developers. So, that’s the part that I focus on.

Matty: [00:16:53] What do you think? I saw there’s been some conversation I’ve seen on Twitter lately about the maybe the negative impacts of the adoption of kind of the pull request approach, especially internally. Like, it makes sense within large community projects or something like that, but if you kind of think about that PR workflow, it— and the reason I thought about that is when you’re talking about like lots of little changes quickly, like, that doesn’t— you roll things up into a pull request. And also, when you think about that idea of being kind of on your own The PR workflow kind of implies, like, the first time you’re collaborating with somebody is when you submit a pull request, which, at which point, might be an awful lot of stuff, you know?

Emily: So, yeah, I’m not a great fan of pull requests, I have to say. It just seems, you know, you get the pull request review, and you have to drop what you’re doing and go and look at it. And then they find, oh, they didn’t do what I expected, and I need to go and talk to them. And the thing, all this while you’re having this discussion, it’s not getting merged into master. It’s just delaying that integration. And you’re delaying sharing your work with the rest of the team. They can’t build on it until they can see it. So, I’d rather not use that workflow. I mean, the thing is, there’s this great value in code review and collaboration and design discussions and teaching people about good design, and you don’t want to lose all of that. But code review does not have to be connected to pull requests or connected to an integration gate.

Matty: [00:18:24] And I think it’s adopting a practice from collaborative development where you can’t really collaborate, or you might not be able to, you know, but then why are you bringing some baggage with you into a place where, yes, we might have to, you know, in my open source project, pull requests might make a lot of sense because, you know, other, you know, I need some kind of a flow because otherwise I might have thousands of people that are trying to get on my Calendly so we can pair program together all the time or something. It just doesn’t work. But within an organization, yes, I can say, hey, Emily, let’s pair. This afternoon, let’s do that. You know, like, you have that ability, you don’t have to create the friction, because you don’t have that boundary. And I think that’s kind of the danger, you know, and maybe the danger, but yeah, you get it. Pull requests are solving a problem that you hopefully don’t have within your organization, but you’re maybe introducing a new problem.

Emily: Yeah, yeah. If you’re in the same time zone as people and have the same working hours, then why introduce an asynchronous workflow? So, I wrote a blog post a while back about a technique called pre-tested integration, which which has integration gates so that you try and avoid code that doesn’t compile or doesn’t pass the tests getting into the master branch, but without that pull request pausing for a code review step. So, I think that’s the real problem. It’s the delaying integration and waiting for a human to do something. It’s going to take too long. It’s going to break up your flow.

Matty: [00:19:54] And you absolutely can’t do that, like you said, that several commits an hour or several commits a day, right? If you could, you could do as many commits as you want, but I think the implication was that are then active, you know, like not just sitting in your long, you know, and that’s the thing is I think PRs also encourage long-lived branches, right? You know?

Emily: Yeah, effectively.

Matty: Yeah.

Emily: So, my experience is that a steady stream of small, safe changes that everyone, that if you go around the development team and you look at the code that they have on their machines, and just kind of in your head do a diff, what’s different about this person’s machine state of the code and mine? The difference should be only, like, maximum a few hours’ worth of work. So, essentially, the whole team is building from the same foundations. Everyone has a the same view of the state of the code, and is making design decisions based on the same state of play, which means that you can collaborate in a completely different way than if people are on different branches, or they haven’t seen what everyone else has been doing for the past few days. And that’s where you start to really see teamwork.

Matty: [00:21:09] Well, you have a shared view of the world right then, which… When we think about how that collaborative development works, and I haven’t had a lot of experience with mobbing, although I remember I was at DevOps Days Copenhagen a couple of years ago, and in the afternoon, both days, they kind of did a mob exercise, and it was really interesting to watch. And when we think about these different, whether it’s pairing, and there’s also, I’ve been seeing, I think people have certain perceptions about what pairing means? You know, there was, there were again, some, I was watching some discourse on Twitter the other day about someone who was like, there’s no way I could do pairing. I don’t like, it just seems so like disruptive to me, you know, to have to be sitting and doing it. And then the conversation was like, it doesn’t always mean one person talking and someone typing. Like, I think, or does it, right? What are maybe some of the misconceptions people have, or even ways beyond the basics of this sort of collaborative development?

Emily: [00:22:09] Yeah. So, pairing, pair programming is a skill. There are different ways to do pair programming. One way is one person talking, the other person typing. One is one typing, the other one kind of watching and commenting occasionally. And there’s, or it could be that you are collaboratively editing with some kind of editor plugin that lets you both type. You know, there’s different ways of doing it. And one thing is that if you’ve never done pair programming, or never been taught how to do it, or never had any training in it, you might not be doing it very well, and that might explain why you’re not getting much out of it. So, in my coaching, one thing I do a lot, rather than pairing, actually, I do more ensemble working with the whole team. Ensemble working is just another word for mob programming. I just prefer to talk about it because it just sounds a little bit better.

Matty: I like that better too. I will adopt that. Yes. I’m on board, ensemble programming.

Emily: Just more friendly. I work in an ensemble with teams quite a lot, because it’s a way for the whole team to then become aware of new ways of working. As a coach, I can come in and I can ask the ensemble to, okay, I think we’re going to need to write a test now. And, or if they do something, I’m like, ah, could you just back that out a minute? I think there’s another way to do that, that wouldn’t break the compilation quite so drastically, and teach them to do the same change in smaller steps. So, I can step in and mentor them through some of the parts of the technical practices that they haven’t maybe seen before. And the ensemble working technique is also something that I’m teaching to teams, and that’s one of the things that they’ve often found very valuable, because it’s the same as with pairing. If you’ve never been taught, or mentored, or trained at all in the skill of ensemble working, you might not be doing it very well. And that can be frustrating and you might give up. That’s one of the first things I do, just teach the teams to work effectively in an ensemble. And it doesn’t take that long, you know, for about 10 sessions of 2 hours, we— I usually find a team can get the hang of the ensemble working and they’ll often continue doing that when I’ve moved on. They’ve discovered how to do it and they’ve worked out what situations it can be useful approach. They might not do it full-time, but just, oh, we’ve got a new team member to onboard. Let’s do some ensemble working, or, we’re starting a new task. We need to be all on the same page, or, we’ve got a critical bug. Can we look through it together before we all split up and try and search for what’s causing it?

Matty: [00:24:40] I was thinking, I’ve been sort of pseudo-pair programming, I guess, lately. So, I started a new job a couple of weeks ago, and kind of my main goal right now is just getting myself onboarded with the project, with the, it’s an open source project, you know, and like I have to learn how to use it and put it through a bunch of different paces. And I started just live coding, just started streaming as I’m learning and just sort of trying to do stuff. And one of the people who watches my stream all the time is one of my colleagues who’s pretty good at it. It’s just funny. And so if you watch my stream, it’s really me and Paul parroting, you know what I mean? Oh, try this. But even not with that, like I found that’s one of the, I think one of the reasons people like the live coding stuff, you know, as something to participate in is because it’s not like watching someone do a demo, you know. So like, I, you know, I’ll sit there and I was, you know, 2 weeks ago, because I have a new Apple Silicon Mac and Docker acts differently on that, and I was trying to go through something and then I was like, oh shoot, it won’t build it. You know, I built the container but I can’t push it up to Fargate because, oh, it turns out Amazon doesn’t take ARM containers, so we gotta figure out how do we rebuild the container? And all these people in the chat were like, oh, did you know you could do this? Or why don’t you try this? Or, oh, go try that. And the same thing, they’re watching and I’m like, why isn’t this working? And someone’s like, oh, you know, you’re redeclaring that variable over there. And you’re like, ah, but it’s not in that actually kind of way. You know, it’s very collaborative. And it’s what it’s making me think about is I’m like, I almost wonder if that’s, if people are getting more into this idea, both because the idea of collaborative development is becoming more less of a new idea, or people are more aware of it in their day-to-day. But then also, as we’ve been in this virtual, extra-virtual world we’ve had to be, like, we’re finding things like basically pair programming as entertainment now. I don’t know. I don’t know where I’m going with that, but I saw that parallel, and I’m like, huh.

Emily: [00:26:37] It is. I mean, the past year has made it very natural to hop onto a video call with people, and very natural to share your screen and show the code you’re working on. But, I mean, I think the barrier to collaboration, in some ways, has gone down with everyone being remote. I’ve certainly been doing a lot of coaching the past year, remote ensemble, and it’s working pretty well, I’d say. Different pros and cons compared with being in the same room, but overall, I’m a fan.

Matty: So, here’s a question I like to ask people when they’re on the show, because I am fascinated with learning. And everybody learns differently. So, how do you learn? You, Emily, like personally, what’s your approach when you wanna learn something new? How do you do it?

Emily: Oh, that’s a— I love learning new things. And I like practicing on little Code Carters. That’s for learning about programming languages. I mean, there’s some Carters that I’ve done so many times that I can do them again in a new programming language, and that’s a way of learning it. Then there’s, I also love designing exercises. If I want to learn refactoring techniques, or if I’m not happy with the refactoring that I was doing on some code, I’ll try and design an exercise where I can practice my refactoring techniques and get better at handling that kind of situation. I mean, my GitHub is just covered in small little Code Kata exercises and little snippets of code and ideas for, you know, a little, you could do this and see if you can solve this coding problem here. So, I do a lot of that. But, I mean, it’s always more fun learning in a group. If you can get a little ensemble together, or if you can get someone to teach you, I mean, I go to training courses with teachers, you know, that’s a good way to learn stuff too.

Matty: [00:28:20] We talked about, we’ve both been doing this for a while. And I think when we look at things like Agile, and we look at even DevOps, which compared to Agile is not very old, but has been around for quite some time, and I think when you’ve been part of a change like this over time, it’s, I think it’s easy to get disillusioned and feel like, oh, this is not what it was supposed to be about, or we really haven’t made things better. But I don’t believe that, by the way. Yeah, I completely understand how it can feel like that. But sort of, that’s my question is when you, when you look back at how practices around how we develop and build and run software have changed, over the years? Is it getting better? And where can it get better? It’s definitely different.

Emily: It’s big and diverse. It’s big and diverse. I mean, I’m working with an organization at the moment where some of the codebase is 30 years old, and it’s written in C, and it’s still very kind of traditionally designed with architects and stuff. And I’m going in there and helping them to write better unit tests, which I guess that’s changed. 30 years ago, they weren’t writing any unit tests. And now they are, that’s better. And I’m helping them to do that better. And then some of the other teams I go to, one team I worked with was doing JavaScript and React, and it was all like the latest JavaScript stuff. And they were really good, actually. They were very agile in the way of working. And I found there wasn’t a lot I could teach them, honestly. They were doing so well. So, I think it depends greatly on where you are and who you’re working with. And so, in this large organisation, even within that one organisation, it’s incredibly diverse. If you are in a place where it’s If things are not getting better and things are not the way you want them to be, you could think about going somewhere else. I think there’s a lot of places out there that are doing really well. And that’s something that’s in the Accelerate report as well, just a huge variety of organizations and where they’re at, and where the elite ones compared with the low performers is just a different world.

Matty: [00:30:26] So, overall, it’s getting better.

Emily: Okay.

Matty: We’ll be optimistic and say it’s getting better. The optimism is a thing I’ve always struggled with. So, as we’re kind of wrapping up, what is one thing you would tell people that if they want to get better at how they’re collaboratively developing and operating software, what’s the one thing they should work on? If they could only pick one thing, nobody gets to pick one thing, but let’s say you did.

Emily: Keep learning. Have time in your schedule for learning new things. I do. So, do you want me to talk about the learning hours that I do?

Matty: Yeah, that’s actually fantastic. Let’s hear about that. I was just going to say, what do you have to plug for us? So, let’s hear about these learning hours.

Emily: Yeah. So, this is a part of the coaching I do to try and get this idea that learning is a normal part of your work, because you’re a knowledge worker. Learning is something that knowledge workers do. So, I have these hour-long slots with the team where we just, like, we’re going to learn a new technique, we’re going to talk about what the thing is, just quickly, 5 minutes or something, new idea. Exercise, we’re going to work through something that lets us practice this skill, and then we’re going to have a chance to reflect. And so, I’ve got lots of these learning hours designed, exercise, theme, topic, lesson plan. And I do that with teams a lot, and I’ve got to always adding to my collection of learning hours.

Matty: [00:31:53] I love that. And I think it’s something that a lot of us struggle with because having an intentionality around learning, like everybody will, you know, if you ask them, nobody says, I hate to learn things. I don’t want to learn anything else. But I feel like we, we feel like we have to squeeze it in where we can, you know, and then how many people are used to the life of triple book calendars? You know, your time, like you barely have enough time to actually deliver. Much less than you’re having to, you know, you, and so if you’re waiting for slack time to come, you’re going to not get it. And it’s, I like the idea of having intentionality around that. And I think the intentionality goes beyond just, I block out an hour of the week to learn. Like the way that you said it, it’s got a structure to it. This is, this learning hour is about this. And I’ve been trying to do just with, again, with the live streaming stuff I’m doing with my coding, I’m just like, okay, I need to have a plan. But I have it on my calendar. I do it once a week. You know, it doesn’t mean that’s the only time I’m working on learning stuff, but you have that. Do you see that people have challenges protecting that time sometimes in an organization?

Emily: [00:33:02] Absolutely. Yeah, that happens. But, you know, I put it in the schedule. It’s in everyone’s calendar. This hour, everyone’s going to get together, and we’re going to do some learning together. Learning is always more fun in a group, and you can encourage one another, but yeah. Okay. It does happen that people say, oh, we’ve got a crisis. We can’t come today.

Matty: In some ways. So I could kind of see it going in either direction where it could be a little easier to protect if at least that’s the whole team versus when you’re trying to do that as an individual, you know? So at least once, maybe once you get it into part of your, ’cause I think that’s the trick of it, right? Like so much of getting better about this stuff is so much about time management is actually teaching other people how to work with you. In a way, you know, a little bit like how to have people understand expectations, I guess. So I, and so when you, when, so when those expectations are part of the function of the team versus Emily does it this way and Joe does it this way and Matt does it this way, you know, when you’re trying to overlay your personal way of doing it, I think is harder, but I could also see how it’s easier to then make a decision as a team that, well, we’re just not going to do it this week.

Emily: [00:34:16] I don’t know.

Matty: Don’t give up though. Try this and have intentionality about your learning.

Emily: Yep. Yep. Have good ambitions and you won’t always succeed, but you’ve got to have the ambition in the first place.

Matty: You know, you’ve got a new book out. We’ll put a link in the show notes.

Emily: Yeah. Yeah. So my book has got a full description of the Samahan coaching method and the way I do that, which we didn’t even talk about. We did it, actually, because it’s basically ensemble working plus learning hours. And we’ve talked about those things. So, that’s what it is, basically. And I’ve got quite a lot on Twitter, if you want to follow me there.

Matty: Fantastic, Emily. Thank you so much for being part of the show today. Listeners, if you go to restofdevops.com, you can find the show notes for this episode. And you can, as always, you can find us on Spotify, iHeartRadio. We’re on Audible. And as always, this is Arrested DevOps. And remember, there is always DevOps in the banana stand.