Book Club: Frictionless

Transcript

Mandi Walls (00:09): Welcome to Page It to The Limit, a podcast where we explore what it takes to run software in production successfully. We cover leading practices used in the software industry to improve the system reliability and the lives of the people supporting those systems. I’m your host, Mandi Wals. Find me at LNXCHK on Twitter.

Alright, thanks for joining us again on Page it to The Limit. We’re doing another book club episode. We haven’t done one of these in a while. I ran out of people I could bully into doing these with me, but this week Daniel has agreed to participate and we have read the new book, Frictionless by Nicole Forsgren and Abi Noda. There’ll be a link in the show notes for that book if you’d like to get a copy and lots of other stuff will be in the show notes today too. I think as we go through all of this, so Frictionless was published at the end of last year and the blurb reads it’s perfect for engineering leaders, CTOs and anyone responsible for software delivery.

Mandi Walls (01:09): This book provides everything needed to transform developer experience, proven measurement frameworks, a seven step implementation methodology and real world strategies that work whether teams embrace AI tools or use established workflows. So for folks who aren’t familiar, Dr. Nicole Forsgren is a researcher at Google. She was last at Microsoft via GitHub and she is the co-creator of the DORA metrics, which most folks are probably familiar with at this point. DORA has been around now about a decade, and the newer SPACE framework which she published in I believe 2021, so that’s a bit newer if you haven’t seen it yet. We will talk about it here, but there’s other, we’ll put more references to that in the show notes. It is worth looking up if you’re not familiar with it. She’s also one of the co-authors of Accelerate. I have a copy of that on the shelf behind me and that was more of a DevOps practice book. Abi Noda is co-founder and CEO at DX, the developer intelligence platform designed by leading researchers. He also came through GitHub and some research there, so they put this book out and I will say it wasn’t what I thought it was going to be.

Daniel Afonso (02:26): Yeah, it’s definitely coming into it with one expectation, but then you get something else. But to be honest now looking at the short description that you were saying, all of these things are there. This is not one of those things where the book promises something and delivers something else. It’s giving you what it promises. It’s not just what we thought it would give us that. I think that’s probably the right framing to say here.

Mandi Walls (03:00): Yeah, the one thing, the subtitle is Seven Steps to Remove Barriers, unlock Value, and Outpace Your Competition In the AI era. I don’t know what you thought about the AI content that was included, but to me, it felt like it had been kind of tacked on at the end and was not necessarily part of the remit when they’re originally planning the book. Maybe you don’t find it in every chapter necessarily. It’s kind of in a couple of places the things that ads are useful but maybe isn’t as integrated as I was expecting based on subtitle including it.

Daniel Afonso (03:34): Yeah, agree. Aside from as someone who wrote a book and add to literal, add an extra chapter at the end because someone requested it to me, that’s kind of what this felt like as well. Chapter 59, I think that’s the one where they focus more on AI, but even then every time AI is referenced, it’s like a bullet point and it’s like they’re enumerating stuff that you could do this for, this initiative, for this communication, for this specific tool for measuring the trust of AI and all those things. So it’s felt like, okay, now we finished the book focused on developer experience, but we know that AI, it’s going to help us get the book out there and that’s true. It helps get every content out there. So I don’t think that this is a bad thing and the content that’s added, its valuable. The thing is it just feels like it’s shallow and they went through the entire book after writing it and see, okay, oh, we can add AI into this bit. We can also add AI into this bit. Oh, we talked about, oh, we can add AI into this bit. That’s how it felt for me as I was going through it,

Mandi Walls (04:48): And I think I wasn’t expecting this to be a book about change management, I think is kind of my assumption coming into it was a bit more about, oh well maybe we’re going to learn about when to choose to have an IDP. How do you actually go about that process? What are you looking for? What indications tell you that maybe that’s the way to go or maybe not the way to go or something like that. And a lot of it unfortunately then is the typical change management guidance. There’s nothing specific to DevX in this particular set of steps. There’s nothing new here. If you’ve been through a digital transformation, if you’ve been through a DevOps transformation, if you’ve been through a cloud strategy transformation, if you’ve been through an agile transformation, if you’ve been in the industry for a while, you’ve lived through all of these or some of them you’ve seen this process before.

Mandi Walls (05:39): If you’ve never led one, if you are basically sort of their target being people who will be running a DevX team or effort, if you’ve never led through a change transformation, this is probably a one-stop shop for you. The stuff is there. There’s enough reference to the foundational work in that space. They do mention Kotter and I’ll link that in the show notes too because kind of where this whole framework comes from is the start your journey, get your small quick wins, use your data, celebrate your wins, all of that kind of stuff kind of flows out of work that’s been done for the last 30 years. So that part, I wasn’t expecting to be in here. I was just like, oh, we’re going to do the change management dance again. Okay, I’ve seen this before. So that was

Daniel Afonso (06:30): Interesting. Yeah, I agree with you. And that was the thing that hit me as I started going step one probably I started seeing stuff and I started going through the same mentions over and over again and then you got from step one and said, okay, in step two we did this and you remember and you have those things that this also feels kind of familiar because we have a change management training like what, five, six months ago at the team onsite for us. And as I was going through some of these bits, I was like, wait, I heard this very, very, very, I’ve seen this before. So I was like, wait, this is change management. So I don’t think it’s, my expectation was I’m going to get a hands-on DevX crash course, I’m going to get a hands on how do you do this, how do you get that?

Daniel Afonso (07:24): And what I got was it’s still very complete. And to be honest, I feel like this is one of those books that if you are starting an initiative and it doesn’t need to be a developer experience initiative though, if you’re starting any initiative at all, this book has all the steps because it has all the change management bits that you’re going to go through. So in each sense, this book can be about as developer experience as about change management as it is, it has developer experience aspects to it, it has a recommendation. I was reading the workbook earlier today as well. The workbook is like 98 pages as well. So the workbook, they also provide very good resources, but it feels like it’s change management. First we give you the tips, we give you everything. And then we included some points on, okay, how do we balance this out as you are doing your DX team.

Daniel Afonso (08:21): In your job and that’s some extra insights. But if you look at this book and you think, okay, this is not developer experience, it’s management initiatives or stuff like 70 or 80% of the book is going to apply

Daniel Afonso (08:36): So you can keep it on your shelf and refer to it. I think it’s a book that allows you to refer to it a lot and it’s one of those things that if you never, like you mentioned, never went through any of these transformations, you’re doing this for the first time or you just want a refresher of gaps because it gives you these things. One of the, I dunno if we should do the shift already for this, but I’m going to say it. One of my favorite bits of the book was step six, which is the one, lemme remember the name of step six, which is the drive change at your scale.

Mandi Walls (09:10): Yes,

Daniel Afonso (09:12): It was my favorite one because it’s the one that touches the beat of when people say, oh yeah, that’s true, but it’s never going to work in my organization because this is the chapter, the step and a bunch of chapters because this book has 60 chapters. I kept going like, oh, there’s chapter.

Mandi Walls (09:32): The format of the book is a whole other discussion. But yes,

Daniel Afonso (09:36): We can talk about that a way, but I like this chapter and this I think was the one that I related with more because there’s a lot of that factor of, well, this would never work in my company or this would never work, and this is the one that says, okay, if you’re in this position, so if you’re a manager, you have executive buy-in, you have all these things, this is a bunch of tips that you can follow. If you are starting with your team, you still don’t have the executive buy-in, you still don’t have the scale. This is what you can do. But also if you’re in the middle, if you have a title but you don’t have the buy-in, this is what you can do. And I really liked this a bit because it was giving you suggestions, it was giving you notes, it was giving those points, but that’s the bit that I thought that the book was going to go into When you have all of these bullet items, all of these points, all of these topics sometimes I was reading, I was like, damn, I wish they actually dived dove wherever my English translation service stopped work.

Daniel Afonso (10:37): They went more in depth with this specific topic. Sometimes I was reading certain chapters, I was like, okay, this feels like someone grabbed a blog post and now this is a chapter in this book. It has all of these tips. But I’m like, okay, but where’s the juice? Where’s the, okay, now I’m doing this, but give me more steps. This is relatable. I’ve seen this happen, it makes sense, but I wanted more. It kept me always like, where’s the rest? Where’s the rest? Where’s the, where’s the rest?

Mandi Walls (11:06): Yeah, I, and I think too, it’s interesting because sort of the voice of the book, the tone of it is more like a consultant rather than someone who’s going to lead you through this process. It’s more suggestions and maybe you could do this, like you said, it’s kind of shallow in a lot of these things. One of the things that I saw some other folks reacting to that had been reading the book was one of the first recommendations is to run a developer survey. Now, if you’ve worked in value stream management and a couple of other things folks that we’ve had on the show in the past, and I’ll link to Helen’s show that we did on value stream management. That’s step one. You have to get people in a room and you have to talk about how things work and that was called out in this book as well as doing individual surveys and talking to people and all those kinds of things. And that seemed to strike folks as something new and amazing and I’m like, well, you haven’t been reading very closely. Everything else has been going on. That is step one for a whole lot of other stuff. And from there it does, it’s a very good summary book.

Mandi Walls (12:12): There’s a lot of stuff in here that you can go into depth with if you’re having trouble through other resources. The parts that are here, the main three components they sort of describe as the essential elements of developer experience are feedback loops, flow state and cognitive load. And there’s plenty of work that’s been done in all of those things. If you feel like you need to go deeper in any of those, unfortunately you’re not going to get you say, the deep discussion of any of these in this book. There’s so much to cover. Like you said, there’s 60 chapters of this book it, it’s organized very oddly. There’s just a lot going on there. So it’s very much kind of skimming the surface of these things and I’m not sure if it kind of assumes what these things are and where to find additional resources or if they just feel like they didn’t have the time and space to go into the more in depth. There’s kind of an interesting,

Daniel Afonso (13:11): And to fit on that, even at times there were points where they were referring to other points on the book that I wish that I was like, okay, there’s sometimes stuff that’s repeated so many times that you’re like, they’re doing the change management stuff in the book as you’re reading it, they’re applying the repeat seven, someone just repeat seven times until you it sticks. I was like,

Daniel Afonso (13:34): I’ve read the start small, keep row and then grow from there. I read this version at least seven, eight times throughout different chapters, but there were times where, oh, as we seen in step three and I’m reading these first, I’m like, what the heck happened in step three? And I kept going to stuff what was supposed to be discussing step this step or what happened on that step and I just kept going in. Okay, cool. But going back to the thing you said in the beginning on the last statement you were talking the developer interviews or the interviews section.

Daniel Afonso (14:14): I found this bit interesting as well because I started relating this with past initiatives that I had and I was doing that exercise because at a previous job I actually did that same thing. I let a bunch of developer surveys, I interviewed 40 developers, did a bunch of stuff, and I was going through some of these things and they were a bit terrible like, oh, I could have done this or I could have done that. Oh, this is why that bit failed or, so it’s still very insightful at these steps, especially if you’re doing these for the first time or you’ve done one recently that might’ve succeeded or might’ve failed or might’ve still be happening. There’s still value in this, but it’s not going to give you the solution. It’s going to give you points for you to think about and if you want, then you’re going to have to do the research after. I think that’s the thing with this book for me is it has all the topics that you could want to go research after reading the book.

Mandi Walls (15:19): Yeah, it’s kind of like starting with Wikipedia, right? You’re getting a summary here and then when you kind of get stuck or find that you’re not getting enough out of it, survey design is a whole other realm of knowledge that you might want to dig into and there’s good and bad ways to design surveys. So if you’re struggling with that, you need to, yeah, I want this survey, I want to do that sounds great, but how do I do it? There’s a little bit of tips here, but like you say, going in and getting more details from other places

Daniel Afonso (15:53): On the workbook, they give you templates as well, which is good. If you look at the workbook that they give you at the end, that was a surprise as well because I thought the workbook would be in the book itself.

Daniel Afonso (16:03): Like, oh, as I was reading through the book I was going on Kindles like, okay, I’m 50% through the book, so probably the last 30% is going to be the workbook. And I kept growing chapters kept going by and I was like, wait, this is heaven. Eventually, where the heck is that workbook? And I get to the last chapter, you can get the workbook at this URL.

Mandi Walls (16:24): Yeah.

Daniel Afonso (16:25): Okay, cool. I have the workbook now. And to go back to the narrative of this is a bunch of topics that I could learn in suggestions, my feeling and what I would like to do with this book is just feed it to an LLM and every time I have questions about any of those things, okay, give me feedback based on the book.

Mandi Walls (16:49): It needs an MCP server. Yeah,

Daniel Afonso (16:51): It’s perfect for that. If you could just feed everything to a model and just prompt it out of it, it’s going to give you a lot of suggest and places to resource. This is a perfect book if you’re ever going to do that exercise. Yeah, I was feeling a lot like that as I was wrapping it. I was like, yeah, there’s a lot of interesting stuff

Mandi Walls (17:12): Here. Yeah, it’s kind of interesting in that we read it straight through and I’m not sure if you actually wanted to use this for a project like this. You might want to skim through it the first time and then go back and read it piece and then completely out of order because it does repeat a lot in between things. Stuff comes back up and there’s two kinds of sections. There’s the section on the seven steps, but then there’s another section on the four practices which are kind of intertwined and they kind of meet in the middle in some places, but the organization’s kind of awkward there. But yeah, I think you’d want to skim through it the first time, take some notes on what’s appearing and then go back and like I say, use it as a reference and if you could turn it into an MCP server, go for it.

Daniel Afonso (18:02): Because for instance, just a bit on stakeholders communication,

Mandi Walls (18:06): There’s a whole lot on stakeholder communication.

Daniel Afonso (18:09): So the thing that one bit that annoyed me itself was there was so much repetition on stakeholders, communication and so much repetition on the metrics. I understand because that’s what happens in real life as well. You are repeating yourself on those things. So I understand that there’s a lot of repetition on this bit, but all that section itself, once again, going back to what I said in the beginning, the stakeholders communication bit can apply to anything that you’re going to do in your own life. So if you’re having difficulty now getting buy-in from stakeholders or thinking about how you should communicate with different stakeholders, this book even has the resources for that. It points you in the right direction. It adds some things that I do in my day to day, but I didn’t fully catch on that I was doing it until I was going through the book. So the bits on, you’re not going to do the same type of messaging for A CTO that you’re going to do for a developer. You’re going to show certain things to a developer that you’re not going to show to a manager. You’re going to show HR something that you’re not going to show finance. So there are all these bits in communication that we do it in our day-to-day. Instinctively I would say

Daniel Afonso (19:26): That I was reading, I was like, I got reminded by the book that this is part of something that we do in our day-to-day that I haven’t thought about it. So I think that the stakeholders a bit was very interesting as well, even though repetitive, it was very interesting at reminding you that some things that we do, we do it unintentionally, but that there’s a reason why we’re doing it. It also gives you some tips. Yeah,

Mandi Walls (19:53): If you had a crazy weekend, the way you talk about that with your friends versus the way you talk about that with your mom, it’s pretty instinctive. You’re not going to share all those details with your mom and you’re going to brag about some stuff with your friends that you would never ever want your mom to know. And that’s kind of where you are with talking to different stakeholders about the work that you do. Certain things will matter more, will make more sense to them. And part of it is their concept of the work that you do is different and recognizing that, yeah, I’m speaking to someone maybe outside the industry, they don’t necessarily understand what we do.

Mandi Walls (20:27): You can temper your messaging that way. And we do that for everybody that we talk to. And that’s kind of like part of our job is making sure that we’re getting the message out as much as possible. So we’re here on a podcast later, we’ll be on live streams or we’ll be writing blog posts or trying to get out there for as much people as possible. So yeah, that stuff is in there and if you haven’t really sat down to think about it, and again, it’s a lot of the change management research goes into this stuff too because you have so many folks when you’re making a large change that are going to be not necessarily impacted directly, but even he mentions in the book, they mentioned in the book that you want to talk about it with finance because you might have licensing terms for software that you want to buy or things like that, or you want to talk about it with HR because it’s going to affect hiring and retention or the ability to promote people and the work that’s important that gets done and those kinds of things come into it as well.

Mandi Walls (21:27): So thinking about that from a management perspective rather than maybe as an IC who’s really just fix my workflow, this all sucks and I hate it was super interesting.

Daniel Afonso (21:38): They even mentioned, you mentioned that and I read through one word came to mind because I had these on my highlights. So when you’re mentioning that, when you’re talking about the stakeholders is the veto test, which was used by the Silicon Valley product group. So if a person has veto power over your project or can stop it from luncheon, there’re a stakeholder. So it’s these things that sometimes we don’t think about in our day-to-day and we remember like, oh, maybe this person should be a stakeholder. So it makes you think proactively on a bunch of stuff. So this can be from communication. There’s a whole section on metrics. There was a chapter focused on how you can present these metrics, which types of charts to use, which ones do you present to your C levels, which one do you present to your managers, how do you do it per teams? There’s all these things are there. So that’s the thing. That’s why I say this is handbook of suggestions and stuff, but the developer experience bit,

Mandi Walls (22:45): Well, so the whole book is called Frictionless, right? And there’s a little bit about where they describe what friction actually is and how it manifests and they describe unclear processes, mixing documentation, complicated tools, lack of automation, nowhere else in the rest of the book is it discuss how to mitigate those things they get mentioned as the source of friction, but eliminating that,

Daniel Afonso (23:09): No, exactly. They just tell you how to come up with the ideas by yourself because yeah, that’s actually true. I haven’t thought about it because you go from talking about friction communication and then when you start the seven steps, you get to a point where they introduce the what’s name, the rice framework. Yeah, it’s rice which stems forward reach, impact, confidence and effort. And they tell you now pick your initiatives that we didn’t tell you how to figure out and measure them with this framework. And then later on they start talking about qualitative versus quantitative data system data versus staff export. Yeah, staff export data. So they get to a point where you’re like, okay, but where’s the beats that you narrow down from the interviews that you did with people to now you’re measuring these initiatives because they’re like, okay, you’re going to interview people, you’re going to take notes of these bits, you’re going to get that data. Here’s how questions you’re going to ask to figure out that part. But now you are expected to once already you finished the interviews to already know, okay, these are the main pain points and that’s not how it happens in real life many times.

Mandi Walls (24:27): No, it’s very messy.

Daniel Afonso (24:29): I was mentioned this before, even with the interviews, I did this as well. I had interviews with a bunch of developers, asked them the same questions to all of them, even went to versions. I was really checking their checklist and I was like, okay, yeah, I’ve asked these questions in the past, but then you get to the end and it’s like, okay, but you still are not able to fully extrapolate all the initiatives. You have some ideas on it, but also depending on where you sit in your role or where you sit in organization or the knowledge that you have at that moment, you’re not going to be able to figure out all those initiatives at that moment. That’s the too existed there.

Mandi Walls (25:08): And I think too, it’s the touching elephant problem. Everybody, especially the IC level, that sort of developers that you’d be interviewing, they have their own viewpoints into the workflows and especially if you’re picking people from around the organization, which they kind of recommend, there’s really no guarantee that they’re all assigned the same workflows anyhow. You really have to be very careful about if you are targeting certain places to make sure you’re only getting the people who interact with that. It’s kind of one of the things that I like best about value stream mapping processes is that it’s a group conversation rather than individual surveys. So you can get a bunch of different people in the room and they may have never talked to each other ever about this workflow and they may all be seeing points of friction in different places that some other team has either mitigated or found different settings in the software and hasn’t shared that out or didn’t know they should or didn’t know anybody else didn’t know it. And there’s a bunch of group learning that can happen there that I think would augment this process for things like DevX because you might find other teams have changed their settings in the build process and it’s improved X, Y, or Z, but they didn’t think about telling everybody else about that. And that part never really surfaces here in this practice. It’s more on individual surveys, assuming that everybody’s individual workflow will mirror what everyone else is seeing and I’m not sure that’s true in large enough organizations.

Daniel Afonso (26:41): Yeah, that makes sense. And the thing is, you were talking about the volunt stream mapping and those type of communication. The thing is I think they show up but it’s already in part five at the end because I remember at a certain point, I’m trying to go through my notes when they’re trying to talk about now that you have the initiative running, how do you keep this going?

Daniel Afonso (27:06): That’s when they start talking about, okay, now you can start doing a Brownback session, start doing this type of stuff. So these bits that would be valuable at the beginning as well. They only show up in the book already at okay, now your initiative has been running, what’s the next step? So I feel like it exists, but once again, it’s one line or two miss it. So it’s those things like it has so much topics, so much substance, but then you don’t, I’m trying to find a comparison and I cannot find a comparison. That’s the thing. Everything is there, but at the same time, I think that’s the best way to say it.

Mandi Walls (27:51): It’s very surface.

Daniel Afonso (27:53): You have everything there, but at the same time isn’t not a bad book. Not at all. That’s what I’m saying. I initially gave it the four stars and now I was talking about that as I was going through the notes and going through it and I changed it to a three because that’s the thing, I might use this in my day-to-day, but it misses the developer experience bit that I was expecting. You mentioned in the beginning when you’re talking about how do you pick your IDP or you talk about the first time that an IDP is discussed in the book and I remember because it stuck with me is they’re mentioning an example, if I remember it correctly, where these organization, they went in, they implemented an IDP, they spent six, seven months or a bunch of months implementing it and then they got to a point afterwards, they’re like, why Nobody is using it. They went talk with developers and they’re like, oh, that’s not what they needed. So this also leads to the next segue, which is one of the things that I really like about the book was the stories, the case studies.

Daniel Afonso (28:58): I think if it had more case studies throughout, I think they did a good job on balancing certain chapters in certain parts with stories because it complimented that chapter very good at certain times. One that stuck with me that I also really liked was, let me remember where the company was from. I think that’s also, I don’t remember where the company was from and I took note about it, but I think it was something on Amazon. Yeah, it was an Amazon director. Exactly. So this person was trying to get the error reports, the errors to go down at different organizations, but then he was trying to reach out to directors, to VPs and they were not getting the buy-in. So what they ended up doing is they started doing a report that measures for every of these people, these teams, the team, the organization owner and the VP that was responsible and started sending that to the executives and they were telling on that story that as soon as they start doing this, suddenly people were even knocking at their door even before they sent, have you sent a report already?

Daniel Afonso (30:16): We are fixing extra error. So we went down and so what I mean by this is, and this was the focus, this was telling you a bit that sometimes gamifying the system or finding the right strategy to the organization and picking into people’s egos because that’s kind of what this ended up turning into makes stuff happen. And this was on a bit of communication. So there were some stories that I really liked and it helped, but that’s what I wish should add more and more stories and more practical narrative throughout the book. So what I mean by this is they had this company, a fictional company, I think that was called Cloud tech.

Mandi Walls (30:59): Yeah, I thought we were going to get a fictional case story through the rest of it.

Daniel Afonso (31:02): Exactly. They mentioned it in step six, I think, which is the cloud tech company. And that’s probably why I liked step six the most because it was the one that this company starts in this position that they did called tech would do, this company now would do that. And I was like, okay, I like this because it gives me the mental model. It gives me the steps that if I was in an organization I would follow and it’s actually being practical to a 0.49. That’s what I wish I had throughout the book. So imagine this company, you are the person X that joined this company, now what are you going to do? So they interviewed a bunch of developers, they asked question, they had these friction points, people complain about this, they complain about that, and you go through all these points. Now they have an initiatives, but before they tell you how they get the initiatives, that’s the first point.

Daniel Afonso (31:50): Now they have the initiatives, now they need to get buy-in, but suddenly they’re having an issue with a VP from the whatever. They cannot communicate with them. So that’s what I wish happened. So I dunno, maybe there’s a next book here where they kind of Phoenix Project this book into a storyline. This is an idea. I’m giving this idea to someone, someone do it because I’m too lazy to write a story on this, but I would love a Phoenix project like book that takes frictionless and turns into a story because you have the full story here. You just need to build a narrative. If this book you do.

Mandi Walls (32:31): Without clojure. Yeah,

Daniel Afonso (32:32): If this book ever exists, I want like 5% of the royalties for ideas or probably more. I dunno. Someone come talk with me. If you get this idea out of me, I’ll help you. I’m not sure you’re going to get any agreement on that,

Daniel Afonso (32:45): But probably not, but I would be happy making. It’s all good. Yeah, I’m manifesting the book. I would be happy if it existed because that’s the thing, the Phoenix project, that’s the thing. It picks the same things that you have in DevOps in agile, we have all these things. It makes it more relatable and it gives you something that you can build the mental model. It gives you this visibility. If we had something with frictionless, that could be the next step is the same way that you got, I don’t remember was the DevOps handbook that came first. That came first and that was the Phoenix project, right?

Mandi Walls (33:15): No, Phoenix Project was first.

Daniel Afonso (33:17): Was first. Okay. So yeah, now they could do the reverse. They do. Someone does the frictionless and now someone does some project out of the DX project out of frictionless, something like that. It would suit it perfectly because people like case studies or people like narratives, narratives fit better and they help build the mental models and that’s something that we didn’t get here yet. That’s the point I was going to make. Sorry, I’ve been thinking. I’ve been talking for a long time now.

Mandi Walls (33:46): No, that’s great. We’re running out of time. But one other thing that I kind of picked up towards the end that I think is a really good tip for folks who want to prepare themselves for pushback, it’s another thing that’s in step six actually, and actually it’s in step seven Steps to remove barriers, that chapter, so they recommend publishing or release creating for yourself a rude FAQ, which I think is a really excellent idea for these kinds of things because when I first started my last job, one of the things that we were doing was DevOps transformations and what we were doing was very much what’s in this book. We were going in, we’re doing surveys with potential customers to say, okay, here’s how our product is going to help you with these top problems that we talk to your users with and you get pushback and we collect up what we had heard from these customers about what they didn’t want to do of this potential change process that we were going to potentially introduce or to sell them as we’re working on this, and I think this is, it’s really something to think about.

Mandi Walls (35:03): Anytime you want to change processes, change tools for people, anything that’s kind of in that you move my cheese kind of attitude where folks are really built in like you want your root FAQ in a way that you have some methodologies for allaying fears. What’s this going to do to their jobs? You want to give people opportunities how they’re going to be able to learn and grow into this new framework or this new process that you’re introducing, how it’s still going to preserve the culture they comfortable in. Any of those kinds of things that prepares you. For the folks who aren’t on board, by default, this book goes in really good in persuading from the financial perspective, yes, they are going to be revenue based incentives for making your software engineers more efficient. Okay, that’s great. But there’s also cultural aspects to this. When you are changing things around for people who are very comfortable with what it’s doing, even if it’s not the best way to do it, you’re going to find folks who don’t want to change and looking at all of these kinds of things from all of that perspective, just being forewarned that that’s going to happen.

Mandi Walls (36:18): So you can think about it a little bit and when you find them you’re not surprised is I think a good tidbit to take away from this as well, to be able to say yes, there are going to be people who aren’t going to be bought in by default, who aren’t going to see this as a double plus unlock for themselves. I will say I feel that way about some of the AI stuff that we’ve got available to us. I don’t want to produce garbage as my day-to-day job, so I want to be able to take pride in producing good stuff, not necessarily what I’m getting from an LLM. You would put me in your rude FAQ because I’m not on board with all the things you want me to do with that. So there’s going to be lots of folks, regardless of how minuscule you feel the change is, you may find folks who feel like you are upending their entire life with the changes you want to make and being prepared for that is a really good tip.

Daniel Afonso (37:11): Yeah, because the point, these questions, they come out of friction and I think that’s the good point of this. They made a very good narrative on this. Friction causes pain, friction causes fear, friction causes discomfort, and that’s a lot of time people are going to give it straight to you with questions that maybe at the moment you might not want to answer. That’s where the root FAQ shines. One thing that I also, I think it was early in the book, I don’t remember when it was, but it’s one bit that I think realize applies to projects but also applies to careers super well and that I actually do personally as well, which is one of the bits they were saying is as you start the project, keep documenting all the wins that you have, all the things that you can get because then it gives you a timeline of everything that happened.

Daniel Afonso (38:09): It gives you a brag book, it gives you something that then when you’re thinking, okay, how am I going to present this? You can do that. And this is also career advice. I do this in my dayto day. Every time I do something that I can consider a win, I take note of it because then when performance review shows up, it’s pretty helpful. It’s there. So these supplies follow your projects. Eventually some executive is going to come out to you and tell you, okay, what value did you generate? Obviously you might get some metrics and there’s a lot of stuff in the book, but if you have this documentation ready to go, it’s pretty good. One thing that I just remembered is I was thinking, okay, where’s the DX in the book more? I feel like towards the end that’s where you start seeing more actual practices showing up. So when you get to the third practice, which is make technology sustainable and effective, talking about okay, treat these as a product

Daniel Afonso (39:08): Tool standardization. When you start talking about tiers like the gold tier, silver tier and bronze tier, which is basically just TLDR, the gold tier is the one that you’re going to be supporting 24 7 people can adopt immediately. So this can be like opinion opinionated frameworks that teams can adopt whilst then the level of support and availability and risk decreases as you go through each tier and then they start talking about tech depth. I feel like as they’re going to the end and they’re like, okay, your project is implemented. That’s where they say, okay, now here’s some developer experience tidbits and think that’s important to you. And they start giving you some more insights. Yeah, I wish there were more of this throughout the book, but I always remember because I remember when the GoldTier showed up and I seen it in this bit, I was like, yeah, I wish there have been more references like this throughout the book because this is something that just, it’s more practical already and it’s something that someone can do in their job in the right day and actually applies to deciding how you’re going to support initiatives, are going to support projects, what you’re going to cover after your experiment or your initiative has been done.

Mandi Walls (40:28): I think would, the product mindset stuff is super interesting and we’ve started seeing that with cloud migrations early on, being able to treat the services that you provide to development teams as an actual product. They are users, they are consumers of the things that you, especially as infrastructure or in this case DevX or as platform engineering or as DevOps or whatever you’re calling any of these teams, you are providing a service to consumers who happen to be your coworkers. And thinking about that as from a product mindset has been I think hopefully very helpful to folks who have been working on these initiatives to be able to say, yes, we want it to look like X, Y, and Z. We want it to help people accomplish these problems and do these things. So that, and like you say, that whole third practice part, there’s five chapters in there that, yeah, I wish that part had been longer.

Daniel Afonso (41:24): And even then the part after the fourth one, that’s when they talk about space for the first time already. So the SPACE framework only shows up at the end already. And even then, it’s interesting because that’s one of the notes that I found. They mentioned that the space framework, as it was mentioned in chapter 24, I went to check, it was not mentioned on chapter 24. It showed up. They mentioned it for the first time on chapter 21 and then on chapter 23. But the interesting bit is then you go to the AI chapter and they say the space framework as it was mentioned, introduced on the previous chapter. And I was like, yeah, okay, that explains where this chapter was at the end. But that’s not the point of what I was trying to say. It was just some fun fact that I picked up here. I wish that this has showed up earlier because they introduce a new change to the space framework,

Daniel Afonso (42:20): It becomes spaced because if you don’t know what it stands for, so space, it was satisfaction, performance, activity, communication and collaboration, efficiency and flow. And then when you get to the AI chapter, they introduce the T, which is trust, which is when you are analyzing AI tools and analyzing stuff. And I like that chapter, those two chapters because once again they were practic, they showed you, okay, how do you apply space framework for, what was it? It was for adopting something on your CICD I don’t remember. But they did a practical example on that and then they did the same thing for an AI tool. So I like that bit as well. They were practical. They gave me insight. I was like, okay, I can see how I can apply this. When they talked about the RICE framework, it took me a while until I was like, okay, oh, this is how you use rice.

Daniel Afonso (43:15): Okay, this is how you use another calculation. I had to see the images that I got there because they introduce it, they keep mentioning and then it takes a while to build off. But yeah, I think that’s overall it was a fun read. I would recommend the book if you are starting any project and like I said, any change management, if you’re starting any initiative, you have bits on this book that can help you. You can abstract out of the DX factor and you have bits on stakeholder communication, bits on building metrics, bits on dealing with developers. So there’s a lot of Intuit, I might even refer to this book in the future because there’s parts here that when you’re talking about friction, you’re talking about these parts. It’s an interesting read but gets repetitive. It doesn’t go as in depth as I was coming in expecting it from the alters as well because if you read other j Read Accelerate, it’s a whole different book.

Mandi Walls (44:25): Very different. Yeah,

Daniel Afonso (44:27): For sure. So that’s the thing. I was expecting something and I other, I don’t think it’s a bad one, but I don’t think it was also something I’m like, yeah, I really love this book. I am going to advocate for everyone. Just buy it, buy it, buy. It’s helpful, but it’s not my piece of deal. Let’s say it that way.

Mandi Walls (44:49): Yeah, I would agree with that. I think if you feel like you don’t have the expertise to lead something like this, this is not going to be the technical manual for you. This is going to be the management manual for you. It’s not going to give you direction for how to choose tools or things like that. That part is definitely not here. I understand why it’s not picking tools that disappear or change or whatever is very difficult and you don’t want to be constantly updating your content. So I understand why that stuff isn’t there. Even the abstractions of those tools though are not really here. So looking at it from that perspective, that’s not what you’re going to get. What you will get, like you say, is all of the management frameworks and the communications pieces, the data pieces. If you’ve never gone through that experience before or haven’t seen it done well and you want the first principles of that, definitely go there.

Mandi Walls (45:44): If you have no idea one way or the other, whether you should read this or look at it at all, I would say start with the papers on the space framework and work out from there as that will give you more of a, is this really for me or not out of that? And we’ll link all this stuff in the show notes. I’ve got a ton of other things that I’ll link to that we’ve talked about and some of the background work and other things you can dig into. There’s plenty of homework off of this one if this is something that you are looking at for your organization and maybe interested in. But for 10 bucks like,

Daniel Afonso (46:20): Oh yeah,

Mandi Walls (46:21): It’s a cheap intro to any of this stuff and it’s like 350 pages or something like that. So not super long. It’s not a doorstopper by any means. So yeah.

Daniel Afonso (46:33): And it’s definitely an easy read. It’s not one of those where you have to stop. Okay, let me fully focus and understand what’s happening.

Mandi Walls (46:43): Yeah, I wasn’t going backwards and forwards on this chapter.

Daniel Afonso (46:45): Yeah, sometimes that happens. It reads super well, which it’s already, it speaks for the writers, it reads super well. But I’m still pitching that someone turns this into a novel type because I see money into it.

Mandi Walls (47:05): Alright, well we’ll leave folks with that. If anybody out there thinks that this is a project you’re taking on, that would be interesting for sure. Maybe they already have it in the works. We’ll see. But yeah, so thanks for joining us today on this episode of Page It To The Limit. We’ll be back in a couple of weeks with something else. In the meantime, we’ll wish everybody an uneventful day that does it for another installment of Page It to the Limit. We’d like to thank our sponsor, PagerDuty for making this podcast possible. Remember to subscribe to this podcast. If you like what you’ve heard, you can find our show notes at pageittothelimit.com and you can reach us on Twitter at PageIt2TheLimit using the number two. Thank you so much for joining us and remember, uneventful days are beautiful days.