What models of resilience?

0:01 Bonjour à toutes et à tous, merci d'écouter ce nouvel épisode du podcast Tech.Rocks. Aujourd'hui, j'ai envie de vous parler d'un événement que vous ne voudrez pas manquer, qui est le Tech.Rocks Summit 2024. Et de les 3 décembre, on se retrouve donc pour deux jours intenses de conférences inspirantes, de discussions passionnantes et d'expériences qui sortent de l'ordinaire. Ce sera l'occasion parfaite de découvrir des idées neuves, d'échanger avec des leaders de secteur et de se plonger dans le thème de la résilience dans la tech. Ça va être un moment vraiment unique. Donc, si vous avez envie de vous enrichir, de networker ou juste de vous inspirer, eh bien, on vous attend. Le lien est en description de l'épisode de ce podcast. J'espère qu'on vous y verra nombreux et nombreux et on a hâte de vous retrouver. À très bientôt! When I look back and think about the things that I think were most impactful for me, it's not experiences, it's the people. If I think about the thing at the moment from a work angle that motivates me the most, it's actually the writing process. I always had a career goal of writing a book.

1:05 When I think about resiliency, that's what it's about. It's not about saying, I'm never going to go down because that's irrational. And if you base your whole model around never falling over in the first place, you're not prepared for when it does happen. You don't want to get knocked down, but it's probably going to happen. So are you prepared for it? And once you do get knocked down, how quickly can you get back up and running? Hi everyone, I'm Philippe Ensarguet, VP Software Engineering at Orange. But today, it's as a member of the Tech.Rocks content team and co-chair of the 2024 summit that I'm here with you. Today, I'm delighted to welcome for this Tech.Rocks podcast, Sam Newman. Thank you so much for having me. Tech.Rocks will run the eighth episode of the Tech.Rocks Summit on December 2nd and 3rd at the Théâtre de Paris, an incredible place for our speakers and audience, mainly CTOs, VP and head of technology. After a 2022 session focused on scale, a 2023 session focused on efficiency, we decided this year to focus on the topic of resilience ecosystem in motion.

2:16 The summit is a very important moment because it will bring our community together for inspiration and reflection. And it will be also the perfect opportunity to network and to meet new contacts to strengthen our practices and learn together. We are so, so pleased to have Sam with us on Monday, 2nd of December, as keynoter to bootstrap the first afternoon of the Tech.Rocks Summit for a session called Models for Resilience. So let's jump in. First, Sam, I'm sure that our audience would love to better know who you are. That's a very deep philosophical question you've asked there. I would say I'm a half developer, half... office administrator who's latterly become a tech writer and a presenter. I started at a very boring career path. I loved computers as a kid. I went to university to study computing and goodness, what are we now? 20 something odd years later, I'm still doing the same job, but being through I've worked in engineering, done stuff at the European Space Agency.

3:21 I've been in three startups that have all failed. I was in a consultancy for a long time, which was really fun. And now I'm working for myself. You already had an amazing journey that drove you from full-time work to an independent consultant, like you mentioned, and a speaker. You created also the well-known XP legal game, and you are a tech hits writer, and in particular for O'Reilly. I have all your books just behind me. All those topics are really connected to cloud, continuous delivery, and complex, massively distributed systems. What could you share with our French tech leaders community as best transforming experiences? When I look back and think about the things that I think were most impactful for me, it's not experiences, it's the people. So I was fortunate enough to, in virtually every situation, to not be the smartest person in the room. And I like being around people that I can learn from. And so. It's been sort of individuals along the way that have really helped me. That's always been my goal.

4:23 I want to be in a place where I don't know enough. That's what I always want to be. Where do I not know anything? Let's go stick my nose in there. I think I'm quite fortunate that I have a, it's a blessing and a curse. I have quite a short attention span. But once I get interested in something, I get very interested in something. So always looking for the new place to go and learn. I also realized in hindsight that early on in my career, I just was much, was quite open to just trying things that were often outside of my comfort zone. So the studies as being a developer, but I fell into being a sysadmin just because no one else wanted to do it on the project. I was on. But that really led me into kind of exploring the space that became kind of continuous delivery. And that was only there because it needs to be done. I was wanting to learn a bit more and I threw myself into it. So I'd say never try and be the smartest person in the room. Always try and learn. And that's pretty much. How I continue my life. And certainly in my family, I'm not the smartest person. So that continues to this day.

5:24 And on a complementary angle, Sam, I would be very curious about what drives you and gets you up in the morning. What are your daily inspirations? Coffee. I mean, I purposely, we did think about having a coffee machine in the bedroom, but I realized I would just lean over. So honestly, that's what I need to get up. I'm a little bit older than I once was. If I think about the thing at the moment from a work angle that motivates me the most, it's actually the writing process. I always had a career goal of writing a book. Partly because it was sort of one of the things you would do and just becoming kind of more impactful. And that was always my goal was always to have impact, I think. But once I started writing, I realized I really enjoy the process of writing. So I know for some people, they find it a slog. I'm really fortunate that I don't. So anything that keeps me away from writing, I find at the moment anyway, I find to be a pain. And so right now what gets me up is a day that I've got clear, which is just sitting down and working on a writing project. And, you know, at the moment, that's the next book.

6:26 My last question before jumping to the next session where we talk about Your keynote. I would really want to understand how you are learning and how you are organizing your watch when you have, I would say, so much skills on the menu. Do you have some daily routines our audience could learn from? I'm very curious about this one. Yeah, I think because I have challenges around my attention span, I've gone through every organizing system there is, and I don't stick, none of them have stuck with me. I found that finding out what motivates you as an individual, it can be very personal. So I'm happy to talk about what I do, but I don't necessarily transfer. I think the key thing for me is I live off my calendar. I spent many years working in an international company, working with people all over the world. My calendar is everything to me because time zones just get dealt with there and everything else. So I have a mix of client work. I do training for some clients. I do consulting for others.

7:27 I do a lot of online training with O'Reilly. I've got to write as well. It took me about a book and a half to realize that when I want to write, I need a whole day. And ideally, I want two or three of those days running together, especially when I'm writing the first draft. And so now my wife, who also runs the business with me, she helps organize my calendar. So we know we've got these traders coming up, so we protect these days. In those days, I don't do any admin work. They're just writing time. That's all I do. And then when it comes to admin, calls for prospective clients, the... consulting I do, I will do those. I can easily mix like two or three bits of client work on the same day and the context switch for me is fine. But the flow state I need for writing means I have to keep those sorts of things separate. So you look at my calendar, you'll see blocks for holiday. You'll see blocks for writing. And then you'll see any advanced training tends to get blocked out in advance as well. And then that's it, really. And then everything else that falls in, I just do what my calendar tells me. And that is what works for me.

8:29 I also learned things like about the writing process. Like if I try and if I check my email before I start writing in the morning, there's a real big danger that I'm now gone off in some different area. So for me, I have to I do all my writing first. I don't even open my email client until it's done. When I finish about two, if I finish at three o'clock in the afternoon, that's been a great day writing wise. Sometimes it will be 12. Sometimes it'll be five. But you get to a point, you run out of steam. At that point, I'll pick up bookkeeping and stuff like that. But it took me two, I'd say two books to get to that point. And I'm kind of working on my fourth now. So I'm sure I've still got more things to learn. Sam, just before jumping into the keynote side, I would love to ask you a bonus question about the last answer that you shared with us. Is there a room for generative AI right now to help you in your work or in your, I would say, daily activities to better get organized? Or is it...

9:30 Absolutely outside or mainly outside of what you are using? It's not something I'm interested in. I think if I think about my writing, my voice is quite important. So how I communicate when I write, it's not just about the content. It's also about how that content is phrased. And that's quite important to me. That isn't to say that a generative AI model couldn't get to the point of, you know, sort of interpreting my own tone at some point. But that's just not something I'm exploring right now. By definition, I couldn't have an AI model learn from me and then write a book that I haven't written because by looking at my corpus of content, the stuff I'm writing hasn't been written by me. So it's not really in that space. In terms of the organizing space, it's just too personal a time. Those things, I've tried all kinds of very different models from time to time. Not really something that's on my horizon at the moment. So let's jump into your keynote.

10:31 Like I said in the intro, the focus of the Tech.Rocks Summit 2024 will be on resilience. And I think our audience is really keen to hear basically what it means to you, how it resonates. Every now and then I ask on Twitter, don't ask on Twitter anymore, but there'll be a term that I think has got lots of definitions and I'll just throw it out there. What do you think this means? And I did this years ago for talking about why asynchronous means. I did the same for resiliency. And I got, as I expected, lots of my friends and colleagues and experts and just random people in the street had very different definitions. And then an old friend of mine, Bruce, who I met through the London closure community, he just came back with one word. He said, chumbawamba. And of course, what he was referring to is a song by Chumbawamba, a band called Tub Thumping. And in it, there were the lyrics, I get knocked down, but I get up again. You are never going to keep me down. Right. That's that's the famous sort of chorus in that song. And so when I think about resiliency, that's what it's about.

11:33 It's not about saying, I'm never going to go down because that's irrational. And if you base your whole model around never falling over in the first place, you're not prepared for when it does happen. You don't want to get knocked down, but it's probably going to happen. So are you prepared for it? And once you do get knocked down, how quickly can you get back up and running? And what can you do to make sure you're not kept down? And that for me is, that's what resiliency is about. It's, you know, you could get sort of more philosophical. It's the difference between cast iron and grass, right? Cast iron snaps, grass bends. So that's the difference, right? How do we make things that are, we've got a bend, we can recover. And that's kind of what resiliency is to me. If possible, without any spoiler alerts, how could you pitch your keynote topic, that is models for resilience? And for those who are already following you, what will they learn new? I think given that sort of how I view resiliency as the whole, which now is viewed entirely through the lens of Chumbawamba, it's getting a bit more specific about things for sort of technologists to think about and the sphere of resilience.

12:45 There's lots of work being done in this space. Woods'work in the broader space of resiliency engineering, for example, is quite interesting, but it's quite academic. And so trying to take his models of his four concepts of resiliency and make those. maybe more applicable to a general audience. So he talks about resiliency in terms of robustness, which is being able to kind of ignore known problems, right? So a machine crashing, will you expect that? How can you ignore that? He talks about it as rebounding. How do you jump, come back after a traumatic event? But also how well do you handle the unexpected? How do you continually learn? So the concepts are there are interesting, but a lot of the way it's phrased is quite, I find, academic. So it's taking those ideas, also taking ideas from sort of wider studies into socio-technical systems as well, and trying to take these ideas and distill them down a little bit and make them I think a little bit more intuitive so that people can go back to their own place of work and spot these patterns and understand how these models might be useful for them in their own day-to-day work.

13:52 I would love for the next question, understanding according to your experience, what are the most important architectural patterns every tech leader should have in his bag to ensure basically what you described, robustness, stability, resilience of the system they are building? Where do they need to focus first? We can come at this from kind of, I would say, almost two different angles. And I think maybe I'll frame it in terms of the technical and the people, the social side of it, because you do have to address both if you want to build something truly resilient right now. A software-based system is technology and people working together. Maybe the first thing. You can't just look at the technology and think that's going to make a system resilient. It's about how the people and the technology work together. So that's the first thing. Right. So the second is on the technical side, it's recognizing the fundamental nature of our computer based systems. You can't beam information instantaneously between two points. That's not something that you can do with our computers. It takes time.

14:53 And secondly, sometimes the thing you want to talk to, you can't talk to. It's not there, right? That's the fundamentals. So from a technology point of view, if you're talking about making systems more robust, more stable. The logical conclusion from that is, well, you need to know about timeouts, retries, idempotency, and rate limiting. Probably in that order, although you should probably do idempotency and retries at the same time. So the technical side, recognize things aren't instantaneous. Sometimes things are not available. Timeouts, retries, idempotency, rate limiting, that's in your bag, right? On the people and process side of things, if you want to build a resilient system, It comes down to creating an environment where there's a high degree of psychological safety, where people feel that they're able to speak up and alert you to things that don't look right, where you don't have a blame culture. So if a mistake is made, because human beings make mistakes, we're good at that, right? A lot of creativity comes through making mistakes. So creating an environment where you learn from this. Because when a bad thing happens, if you have an environment in which you are blaming people for things, you will not learn from what happened.

16:00 And ergo, you will continue to create mistakes of the past. So on the people side, I would say it starts with creating an environment of psychological safety where people can learn and share ideas freely. And that's the most important thing, I think, from a resilience standpoint. I mean, obviously, there are a whole lot of other benefits that would flow from your organization if you embrace those ideas. I really love your answer. If it's like basically you don't want to the technical side and you also. promote all of the aspects of the resiliency topic. So you name about people, organization, but also communication in what you just answered. So is resilience a tech and social holistic topic for you? Yeah, absolutely. I think once you look at, but even though my work has been about software architecture, and that is fundamentally a socio-technical endeavor. If you're an architect and you don't think about people, How's that going to work?

17:01 Have you heard of Conway's law? Right. So already we have this idea that from software architecture as a whole, we have to have an understanding about how these two things are related. So for me, just from that broader sense is and absolutely it is when you start looking in the area of resiliency. I mean, the very fact we have to talk about human error as being claimed as a causative factor in software failures or any type of failure really makes it very clear that you have to see both sides. So the work I'm doing at the moment, although I'm much more of an expert on the technical side of things rather than the people side of things, just as when I wrote my previous books, I try to talk about people and culture and organizational design aspects. Like in my new book, the book's got two halves. The first half is going to be the technical. The second half is going to be kind of the more sociological. Because if you only focus on the technical, you are probably looking at less than half the picture. It's when you get both those things working together that I think you can build truly resilient. systems. Sam, because we are in the part of your keynote session of our conversation,

18:07 could you share, for instance, with the audience, what kind of material the participants will be able to take home and what basically will be learned? I'll be honest and say that there's a potential that my central pivot point for the talk may change between now and December. I mentioned Woods'models for resiliency, which are quite well known, but I have actually discovered, I think, some other models for sort of measuring resiliency that might replace it as being kind of the central pivot point. But I think it's like a practical model for thinking about how do I make my system resilient, right? That's the core of it. I'm also going to be sharing some a bit more detailed models around socio-technical systems. Some of my research for the book, I've discovered some really interesting analysis into socio-technical systems in the context of failures. So how do you break down that socio-technical into smaller pieces where you as a technology leader can say, have we got coverage in all these areas, rather than just thinking this is too big and too airy? So I think more concrete models for thinking about what resiliency is, how to measure it, and probably a list of things to be looking at and observing to make sure you're heading in the right direction.

19:17 Sam, before jumping to the next session, the last one on your keynote presentation, I'd be curious to know if during basically your talk preparation, even if it's not 100% done, like you said, Did you learn something new or unexpected? The weirdest thing I learned was when diving into the whole socio-technical stuff is that that work was pioneered by a group called the Tavistock Institute in the UK. And the Tavistock Institute are cited in a bunch of conspiracy theories, mostly coming out of the US, including one where the Tavistock Institute was cited as being part of a shadowy global cabal that created the Beatles. To control and bring down Western democracy. Now, I think the jury might still be out. Maybe the Beatles are sort of running a very long game on this whole thing. But I was like, it's also given where the world we're in operating in now, it's good to know that really crazy conspiracies have been around for a long time. I don't think it's going to get mentioned in the keynote, but I was like, huh.

20:20 Really? Okay. So yeah, that was a kind of a rabbit hole I went down at one point. But if you type in Tavistock and Beatles, and you will find some really odd blog posts out there. Amazing. So now, Sam, jump on the next session that is basically around your agenda. I guess that you are spending parts of your day and nights on your coming book called Building Resilient Distributed System. And it's a perfect echo to our event. And even if you, I would say, already wrote several books that are bestseller in tech, and even if you already brought some of them, what were your initial motivations while starting this new one? And what did you choose to tackle? I mean, the reality is I like writing. And so for me, it wasn't, am I going to write another book? It's what am I going to write another book about? And I did explore some other topics before I got to this one. There were a couple of other things I could have gone deeper into. I first learned about those ideas like 10 or 15 years ago.

21:24 And was struggling to understand them. And so every year or so, I'd come back and re-engage and hit my head against them and bounce off and hit my head and bounce off. And so after I'd finished the second edition of building microservices, I had a bit of a break. I played some computer games. I thought, okay, now I'm ready to write my next book. What's it going to be? And really it was about, well, what have I got that's still in my brain that's interesting enough for me to work on? I typically would do like a workshop. Or like a half day workshop or something before I write it, do any writing anyway. So I get to explore the spaces. And that was the material that I just created a class for, for O'Reilly. And it was like, that was really interesting. And there's loads more I wanted to explore. So I wanted to write. I had that in my mind and that's kind of where I went to. I mean, Obviously, you can see writing a book is a broader thing for me. I work independently. So for me, it works kind of as marketing and everything else. So there's obviously the motivations from that point of view. But if all I wanted to do was market myself and build my brand, there are cheaper and easier ways of doing it than writing a book.

22:30 I write because I enjoy it. And that's also a thing I speak to lots of people. They say, oh, we want to write a book. Now, OK, OK. So they ask me for advice and say, so have you written anything like a blog post? Oh, no, no, no, no. But I want to write a book. OK, go write a blog post, then come back and talk to me, because it's like if you don't enjoy the process of writing. Writing a book is a terrible thing to do. There are other ways you can share your stuff. You can do podcasts. You can do YouTube videos, whatever else. I write because I enjoy it, and therefore I look. For something to write about. Sam, a bonus question on this one. When do you know that it's done for the book? I have a bit of a pattern for what works for me. And it's also I've got a really good editor. And one of the reasons I don't self-publish is because I actually quite like working with O'Reilly. And I've got a great editor, Virginia O'Reilly, who's fantastic to work with. So for me, I come up with a rough pitch. I sit down with colleagues at O'Reilly and Melissa, who I work with a lot there. She helps me sharpen that up a bit. And then I just start the process of writing.

23:32 And then I get tech reviewers in and I write a chapter or two and I send it to the tech reviewers and I get their feedback. And I iterate on that a bit. And I just kind of write chapter by chapter by chapter. And I get to the end and the first draft, hoping the first draft will be done in sort of, I don't know, like about April or May next year. And then it's like the reviewers are one of the biggest impacts for me in terms of giving me great feedback in terms of, am I missing something? Am I misstating something? Do I need some different structure? So I've got some great reviewers, Sarah Wells and Venkat Subramanian, who are both people who have written books. And so Geth will give great feedback, but also good subject matter experts. I've also got an old colleague of mine, Halvert, who's an expert in distributed systems, works at Google. So he comes in and tells me things I'm getting them technically wrong. I'm adding a couple more tech reviews at the moment. And that, for me, is the most important feedback. I won't lie to you, there's also another aspect to this, which is that it is a lot of work and it does occupy by a big chunk of my brain, I can only hold onto it for so long.

24:33 And so I do need it to finish within a two year period, really. So I also have to cut my cloth accordingly. And one of the hardest things I would find early on was I was writing too much, it wasn't gonna fit. So I had to write like an orphan, I have an orphan GitHub and I just put content there. I'm not deleting the content, it's just going over there for now. And then there's also the reality that a book is, the book is done, but the book is about getting ideas out there and the ideas. are never done. So by putting the book out there, I will get to enter into a dialogue with a whole bunch of other people that I've spoken to before. I'll learn new things after the book is out there. Right. That's also what I love as well. You know, that's partly why I came back into the second edition of Building Microservices, right? Enough time had passed. It was worth it. So I don't, the ideas are never done, but you do have to finish a book for your own sanity. Cool. Thanks for your answer. Very, very, very and really insightful. We also probably get to have you for the Tech Rock Summit, but I'm pretty sure you have also other a lot of conferences on your calendar.

25:36 Where could our audience listen to you? I've cut back a bit this year, partly because I'm writing the book and partly because I like staying at home. So the next conference I've got is IT Arena, which is going to be in Lviv in the Ukraine. So it's just on the western. No, I need to get my compass points right. That's over the Polish border in the Ukraine. So I'm going to be there the weekend of the 28th or 29th doing a talk and a half day workshop. And then aside from obviously Tech Rocks, the only other sort of standard conference I'm doing is going to be NDC Porto, which is going to be in October in Porto. It's a great five day conference, two days of workshops and a workshop there and then three days of kind of conferences. And then later in November, I'm just doing a one off two day workshop for Trifork in Amsterdam. I think it's the week, in fact, before Tech.Rocks. So I've actually only got. of three conferences left this year. And I'm going to finish, obviously, with the best one in Paris for Tech.Rocks, which is actually going to be the end of my, I sort of stopped doing any external work at the beginning of December.

26:46 So that will effectively be the last anything public I do of the year. And that's going to be, I'm looking forward to that event. I'm sure we could put links to those things in the show notes. Exactly, exactly. Sam, we are reaching the end of our podcast, and I would love to ask you one last question. Echoing basically our event to come, and it may be something like, for you, what does it mean to be a leader in tech with resiliency in mind? What could be a good advice from you? I would say creating a safe environment in which everybody can learn. If I have to distill it down, that's it. It's all about the environment where people can learn from what happens. That's the one thing I'd go with. Perfect. Sam, the time spent in your company has gone very, very, very fast. It was captivating and exciting at the same time. Sam, thank you very, very much. Thank you so much, Philippe, and I look forward to seeing you in Paris later this year.