5 Essential Reads For Software Delivery Management

Hello everybody and welcome to Cloudflare TV. And hi from a very, very sunny London, wherever you are. I hope it's a nice day for you as well. I'm Alex. I'm a delivery manager here at Cloudflare. And today I'm going to be talking to you about what I do to and how I strive to keep relevant in a job that requires some skills and some knowledge that is not really taught in the academical world or at least which wasn't taught, you know, 15 years ago when I was considering my studies. So I work in a really fast-paced environment. Obviously, software delivery is like that. So I'll speak about the books which I've read, which have helped me in really improving my skills, what I learned from those and how I actually use them in my day-to-day job. So I hope you'll like that. Please feel free to drop me any questions throughout this session at livestudio at Cloudflare.tv. And I'll answer these towards the end of the session. So I can check them here. The producer will provide me with the information. So for a bit of background information about me, I am a non-engineer and I work with engineers every day. So you can imagine that this actually, sometimes it gives me this imposter syndrome. And when my first real degree, believe it or not, was one in, oh, sorry. My first real degree was in C++. So I have this degree somewhere at home. I couldn't find it actually to show you a screenshot. But I was part of the generation that did the exam with pen and paper. And I'm not joking, but a lot of my colleagues don't really believe me when I tell that story. So it's safe to say that I didn't really pursue it further. So I went on to focus more on communication management, specifically program management. And after some years in working in advisory and in logistics, I decided to take a 180 degree turn and I moved to a very small software startup. And then I had to figure out really quickly how I can bring value to software delivery. So what I ended up doing is what I do best, I read. So I read everything that I could get my hands on in order to learn really quickly so that I can keep up with what I had to do with the environment and with gaining more and more credibility in front of my engineering counterparts. So today I'll be speaking to you about the five more interesting books that I've read in this field and which I actually strongly recommend to everybody who would like to work in software delivery management and who works day to day with engineers, even if they have a different background. So you'll see an autobiography, a manual, some nonfiction books with particular frameworks for delivery management, and also a novel. And I know it's maybe unusual to see novels for this, but I promise that this fits. So probably my favorite book in this series is actually Accelerate. I'm going to start with that. This is a collaboration between Nicole Forsgren, Jez Humble, and Jin Kim. Actually, you see the authors here. You can even tweet at them if you're interested. Also a note, you have a QR code. If you want to find out more about the book, it will send you to the publisher's page. So if you want to just learn more about it. So many people might know one of the authors. Jin Kim is kind of the father of DevOps. He's the one who educated us in the field with the DevOps Handbook and a lot of other publications as such. However, the one that I talked to you today about is Accelerate. This was published in early 2018, so a little bit over two years ago. And it covers a few years of research and interviews with practitioners. And this book focuses on how to build and how to scale high -performance organizations. And I'm literally, so I have it here. It's actually my second copy. It's full with notes and underlying ideas because I read this twice as I was preparing two different jobs, one of them being the Cloudflare job a few months ago when I was doing the interviews, and it was actually really, really helpful. So what I learned from this book, I'm going to try to summarize it in three bullet points, even if I know that it's very hard to do so. The first thing is how this book really links technology teams to driving business value. And it uses real data to strengthen this hypothesis that DevOps and lean software is the most effective way to deliver software. So not only that, but it focuses on having a loosely coupled architecture and a fast feedback loop. And if any of you is working in product management or is a product manager, you will realize that there is a really, really strong connection with what you do every day. So these things actually are highly predictive to a high-performance software delivery company. So one of the other things that I really, really liked, because a big part of my job is to think, not to think, but to apply metrics. So to really understand what makes a team successful. So what do we deliver? How do we deliver it? What metrics are important in order to maintain a high level of delivery? So this book sets up this framework for metrics, and it focuses on three different ones. So you have business metrics, team metrics, and delivery metrics. So in business, obviously, every company might focus on their different things. So obviously, you look at revenue, but some businesses will look at amount of users that they have active conversion. So if you move from free to premium, the length of time to close a deal, so on and so forth. So obviously, the book doesn't focus on what metrics should you have as a business, because this is better discussed together with your leadership team. In terms of team metrics, it focuses on the metrics particularly for engineering teams. So how they work, what makes them happy, what's a risk in the team. So obviously, it looks at happiness and burnout. So it seems like two very simple categories. And the third piece is, you would say that probably is the one that I care about most, but actually, just focusing on delivery metrics is not enough. So it looks at two types of delivery metrics. Well, one of them is tempo, and one of them is stability. So for tempo, you can count the number of deploys, what is your lead time from commit to deploy, you know, how quickly actually are you able to close that feedback loop, right? And then in terms of stability, this is more on system stability. So the change failure rate, mean time to recover from failover. So when something happens, how quickly can your team gather around, fix the problem and return the system to its previous stability, right? So you will see some teams struggle with that. And it actually takes, you know, minutes or hours even and some other teams are really quick in a couple of minutes, they've fixed everything. So that's why it's really important to look at this because it really impacts the end user. Yeah. So the way that I use these metrics is also to make sure that we address tech debt. So I know that this is a very sensitive topic in most software organizations. Because we, as we were saying, we want to ship things quickly, and we want to deliver value to users as soon as possible. However, sometimes if we take shortcuts, we will accumulate tech debt. And actually, from this book, I understood how important it is to tackle this tech debt and how to keep track of it and how to find the right balance, right? So I use all of these points in my role at Cloudflare also because delivery management is a new function in Cloudflare. So we're setting up the structure for the metrics, we're linking back to other parts of the business, especially with customer support, sales, product management. And on the other side, I use these to engage with my engineering counterparts. So this book is really well structured, it captures the data over the years. And it's looking at the evolution of DevOps, tying it with the performance of the companies supporting these kind of teams. So as I said, this was published in 2018, with the set of data for about five or six years, if I'm not mistaken. And what I'm looking forward to is actually them, hopefully this year, 2020, they will publish the new set of data, you know, so for 2018, 2019. So you have two extra years of really understanding how to accelerate your business, right? So I'm pretty sure that this is not the last time that I'm going to be reading my book. I just hope that what I underlined is still relevant. Right, so the next book that I wanted to talk to you about is, believe it or not, App Development with Swift. This really had an impact in my career. Because as I mentioned, this will be a manual, so you won't see the authors because it's Apple Education, and it's part of this, everyone can code programs they have. This is really like one of those manuals that you have in school, and you need to work from it every week, you need to do homework, and you need to really digest all of this. So a lot of software developers are self -taught, and this always mesmerized me, to be honest. So I mentioned that I have this unused degree, and it helped me to work a little bit with HTML, with a bit of CSS at the beginning of my career, but I wasn't really excited about that, so it wasn't the focus of what I was doing. But a couple of years ago, what I decided to do is do a bootcamp, and I just found a bootcamp on Swift. So I learned Xcode in Swift because I said, okay, I want to know if I can build an iOS app. So I spent these three months going to the bootcamp, and I got a lot of support from my then iOS team, and I learned a lot. And a big part of it was because of this book, because I followed the structure of it. So it starts you really at the beginning with very small things like, you know, what's the shortcuts to open the terminals, and what kind of tools do you need to set up and spin up your environment? It's not enough maybe to just have Xcode installed. Maybe you want to have an account on GitHub or Bitbucket or wherever you want to host your code, right? So obviously feel free to skip the beginning if this is not relevant for you, if you already have a basis, and you're just curious about this specific coding language. But I really liked the fact that it really walks you through everything that you need. So following this book gave me a very good hold of the theory. And while it's specifically on Swift, the principles of programming remain the same for most of the languages, right? So they can really be applied for other languages and other tools. But what I got excited about is that at the end of every chapter, it had this little exercise. So from the beginning, you know, just create a UI frame, and then at the end of it, it was completing an app, right? So that gave me a lot of satisfaction. So what I learned through my months of Xcode study, squares are hard. Particularly, a square is never just a square. So what I mean by that is that what users deem to be a very small, simple thing, actually might have a very complex engineering design underneath. So for example, like one of my aha moments, or my dread moments, was when I actually had to set margins, set margins to a little square, I think it was a weather app or something. So it was hours of work. But in order to ensure that the little square I was adding there can look nice in any type of device. So regardless of the size of the screen, or of the device, regardless of what the user was clicking, I needed to make sure that that square is always there, right? So you needed to ensure that you follow accessibility principles on and so forth. So honestly, after that, I had newfound respect for the engineers that I was working with. So the second thing that's really important, that was really important for me was on QA. So how important it is to really test everything that you're that you're trying to deploy. And while in Cloudflare, we don't have a separate function for QA engineering. We make sure that all of the engineers actually are their own QA and they test their code before they deploy everything. So the last one is maybe a cliche, but I can really learn anything. I mean, following this kind of manual really proves to me that I can learn anything, even if it sounds really daunting and scary in the beginning. So I continue with a bit of Python, with a little JavaScript, only because I wanted to further understand, you know, what do our data scientists do and use every day? How do we build our API, so on and so forth, right? So while I don't work with Xcode every day of my life, I have the satisfaction that I did deploy some code that's out there in an app. It's a customer complaint form or customer feedback form. So I know it's there. And I know that I shared my experience, particularly reading cover to cover a manual on Swift. I want to stress out, it doesn't have to be that. It can be anything you want. But just I think the idea of dipping your toe into a new programming language and trying to understand what's the structure, how are problems solved, what is the approach that your engineering counterpart might take, really can help you come on the same level and actually have a constructive conversation about what they're trying to build, what you are trying to build together, actually. The next book is another one. It's another nonfiction. It's written by Mick Kirsten. You have his Twitter handle here as well. He actually built a business based off on this book, but I don't want to talk about that. I want to talk about what I learned from project to product. And this is probably one of the, yeah, it's published in early 2019. So it's a really early book, but it's one of the strongest ones on how to develop software delivery management into a function that spans your whole business. So it's not the silo between the tech team and then the business teams. No, no. Software delivery is a driver of value. So in Cloudflare, we're software product led. So we don't really feel that there is this huge, huge silo. However, I've encountered a lot of businesses where you have the IT or the tech team, which is struggling to really show relevant metrics to bring them a seat at the leadership table. So one of the most prominent challenges in software delivery organizations is communicating to the business, as I said. Yeah. So engineering teams typically talk about, you know, t-shirt sizes and we talk in story points. And sometimes we don't realize that maybe for the CFO, this doesn't mean much. So this is becoming more and more crucial and central to the business. The book proposes a unified language. So unified terms that can be mutually understandable by both business teams and tech teams. Right. So the important part of this is kind of the core flow framework that the book proposes. It really walks you through everything that is relevant. So how to measure, what are the elements? And one of the important learnings from this is the four different flow items. So you'll have features. So what are you delivering to the customers? You'll have defects. What kind of bugs do you really ship and do you address them? You'll have risks. So how are you securing your product? And obviously, Clouder always helps with that. And then the fourth one is debt. So I mentioned debt in Accelerate. But again, how are we paying back our debt? And are we doing it at a reasonable rate? And obviously, you see here, distribution is really important, because it's important to have a distribution between all of these four types of items. It's not enough to just pay your debt, because then you don't ship value. It's also not enough to just ship new shiny features. And then you have an increasing backlog of technical debt that will really overwhelm and, to be honest, will lead to burnout of your engineers and of your tech teams. So I really loved how the book was structured, how it offered this proper playbook and examples in order for you to be able to apply to tech and delivery operations. And to be honest, today, I really use the language in my everyday conversations with technical teams, with business counterparts, and I use these metrics to prove the results of the teams that I'm working with. Because again, this book stresses out the importance of this collaboration between business and tech. And a big part of my job is actually to be that bridge in between. Yeah. Right. So I see I have about 10 minutes left. So we have two more books to go through. And the next one is Life in Code. It's written by Ellen Ullman. So I think many of you might know Ellen Ullman from a different book that she has. So she wrote probably more than 20 years ago. In 1997, she wrote Closer to Machine. This became a cult classic. However, Life in Code is much earlier. I think it's about three years old. And it takes the shape of a memoir, of an autobiography. So I find it quite fascinating from two different perspectives. One, she talks a lot about the life as a programmer, starting with the 70s when she actually started her career. So definitely, that was a very different life than what software engineers actually have today. Her stories span from the 70s to the 2000s. And she's also, to be fair, one of the very few women in the field back then, by comparison with the amount of men that were shaping up the Silicon Valley culture as it is today. So her memoir is really interesting in noting these things. And she was very aware of what was happening, and she was trying to kind of balance it out. So the second piece that I like, so it's her personal history of technology, right? And it's structured, as I said, there's a series of essays that are actually key milestones in the evolution of technology. So the second piece that I learned, it's very funny, is the Y3K bug. Have you heard about that? So everybody probably heard of the Y2K bug. And the Y3K is the same issue. It's just they never fixed it. They found the workaround. And now, when the year 3000 comes, assuming that we will use similar technologies and a similar codebase, they will run into the same issue. But that's a problem for future us. Yeah. And the last thing that I really liked about this book is that this is a person who has a background in English literature and a minor in biology, if I'm not mistaken. And she became a tech legend. So it again stresses out the fact that she is self-taught, that she managed to navigate in this world of technology and of new technologies coming up all the time. And she managed to kind of keep on track and keep on top of it, always managing to bring value. And the last book that I wanted to talk to you about, remember I mentioned that we'll have a novel? Actually, this is it. It's super geeky fiction. It's published by Jin Kim. So he's also one of the collaborators of Accelerate that we mentioned in the beginning. It's called The Unicorn Project. I have it here. I really recommend that you, I typically read on Kindle, but this one, I got it right when it was published. So the Kindle version wasn't yet available. Now it probably is. So this is a really, really funny story. I don't think I've ever read a book like that because I'm used to reading business books in a very specific format. And this one is, this is a story, this is a fiction story. So it's actually a novel that centered around the main character. So her name is Maxine. She's a senior developer. So she's an individual contributor, a senior developer in this inefficient, very big company. She has to navigate through all of this corporate structure, so much bureaucratic processes, through political games and everything. So it talks a lot about the gap between what we assume to be how mature we are in our digital transformation and what we actually are, or at least that part unlimited company is. And obviously this digital transformation is still a journey for a lot of people. However, I realized that this book is so relevant because this journey hasn't even started for a lot of companies. The second book that I, the second piece that I really like is the fact that this is about an individual contributor. So a senior developer, she knows a lot. She's very driven and it's such an important parallel with real life situations because a lot of people have to navigate process for the sake of process, you know, being blocked by other teams for such menial reasons that sometimes you don't understand, but that's just how we've always done it. Right. So this is a person who has a mission, who really wants to make things better. She likes her company. She likes her team. She likes her job. So her first thought isn't, oh, I'm just going to go someplace else. No, she actually decides that she wants to change it. Right. Even if she's not, you know, a leader, she's not, she doesn't have a lot of authority around how other teams do things, but she genuinely tries to, to improve, to, to, to improve things. So the author really explains the five ideas and it's references so many business frameworks in the format of a novel. And I really, really love that. So the third thing that's important to note here is how complex problems have different angles. And this is what Maxine does throughout her journey in the book. She, she tries to understand things from her team's perspective. So from the back end engineering, then from the QA perspective, then from sales, then from finance, so that she can put together all the pieces before she can make, she can take a stand and really propose a solution to the problem. And actually what's even greater about this book, if you're like me and you really like to read, and if you love a book, you want to see the sequel or something else that happened in that universe. This book comes with a bonus. So actually the Unicorn Project is a second publication. It's a mirror, a mirror of another book, which was called the Phoenix Project. The Phoenix Project was actually a collaboration between, between multiple authors, one of them being Jin Kim. And what stayed with me from, from this one was, was one, one part of it. So it was the, one of the characters, he, he was really, really curious about what does the CFO get measured against? So this, this wasn't a very transparent organization, as you can imagine. And I don't know if a lot of us actually actively ask, okay, what does my colleague get measured against? What are their KPIs? What's important for them? Or what's important for their manager to deem them good at their job, right? So actually have this open conversation. And for me, maybe for many of you won't be because maybe this is something that you do, but it really made me think, wow, it's true. I understand what my objectives are, what my immediate team's objectives are, but maybe I don't always understand what's behind a question or an action that a different team member is doing. So now I actually incorporate this in my, in my day-to-day job. And whenever I meet somebody new, whenever I talk to them, I really try to understand, okay, what are you measured against? What's important for you? How can I bring value to your, to your job, right? So these, these were the five, the five sessions. So as I mentioned, I know we have a couple of minutes left. So as I mentioned, feel free to ask any questions at the live studios at Cloudflare.tv. So I'm just going to check now if there are any questions. One second. Okay. So while there are no questions right now, I am then very glad that I decided to prepare something else. And maybe this is, this can be the start of a different, of a different section that I will be doing, but I wanted to quickly talk to you about the importance of really understanding your product counterparts. So this is a different facet of the, of the job of the delivery manager that I'm doing right now. So even if I'm part of the engineering organization, my biggest stakeholder remains products, product managers, product directors, the whole of the product organization. So when, when I, when I came into, into, when I decided to actually have this career, I, I found it crucial to really understand what is product management, how our products build, what the product, product management managers care about, how they take decisions on and so forth. So I did take a course because, you know, I'm geeky. So I decided to learn, but also actually two of the most, more important books were, were these two that you see here. So the first one I read was product leadership, which is a collaboration between Richard Banfield, Nate Walkinshaw and Martin Erickson. So it's important to know that it's three different subject matter experts. And this really helped me because I used to work in a delivery management role in a B2C company and I had to quickly catch up, you know, how do we build products for end users? So I, I did that. And then a couple of years into the job, I read the lean product playbook, the one by Dan Olson here, because I wanted to kind of complete my knowledge with new research, new structures and frameworks that could also be used for, for B2B. And I definitely recommend these two because they outlined a strong collaboration between tech and product teams. They focus on working cross-functionally and delivering products in squads, or, you know, you might call them in your team pods or value stream teams. And this is actually the same message that we talked about when we covered accelerate and project to product, if you remember. So actually on Cloudflare TV, you will see a lot of sessions on the schedule that are led by our product leads, product directors explaining things from their perspective. So how do we build products at Cloudflare? So I really recommend if you're, if you're curious about this and how do, how do we build our products, just follow those, those sessions, make sure that you ask questions or otherwise you can, you can always find other resources. So again, if there are no more, no more questions, I wonder, yeah, we, we actually have only a few seconds left. So I wanted to thank you so much for joining me today. I hope that you've enjoyed this talk and feel free to tweet at me if you have any other book recommendations. Or if you have any other thoughts about this, I'll read anything that's recommended to me. Even if I don't like it, at least there's always a reason to, to love a book. So thank you so much. And I hope you enjoy the next session on Cloudflare TV. Thank you.