Podcasts about phoenix project devops helping business

Welcome to Episode 237 of “Playing With Perspective - The Suspended Animation Podcast!”

גיבוי הוא מסוג הדברים שאף פעם לא עומדים בראש סדר העדיפויות. אבל כמו בסרטי אימה, מה שהתעלמנו ממנו עלול לצוץ ולרדוף אותנו, בדיוק ברגע הכי לא מתאים. איך מונעים מראש את הקטסטרופה שכולנו חוששים ממנה? איך מוודאים שכל מה ששמרנו דיגיטלית, לא יעלם?לרן בר-זיק יש הרבה מה לומר על גיבויים, גם ברמה המקצועית, כמפתח וארכיטקט, וגם ברמה האישית, כעיתונאי, כאדם פרטי וכאיש משפחה. שוחחנו על סיפורי אסונות בז'אנר הגיבויים, על האחריות של בוני אתרים ביחס לגיבוי, על מה זה Disaster Recovery, על גיבוי קר ועל גיבוי חם, על פרוטוקול הגיבוי האישי אצל בר-זיק בבית, על מה לא לגבות ואפילו לבער ולהשמיד, ועל למה כדאי לכתוב דוקומנטציה רק אחרי שאוכלים ארוחת צהריים.האזנה נעימה,בועז לביאלספר The Phoenix Project:https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592פוסט של ערן שפירא על חיסכון בגיבוי:https://medium.com/@lxeran/how-we-decreased-our-monthly-aws-costs-from-10-000-to-1-500-f926f1fd4eef

In this episode of the Identity at the Center podcast, hosts Jeff and Jim return from Identiverse 2024 and share their experiences from the conference held in Las Vegas. They discuss notable moments, including unique conference swag and memorable interactions. Special guest Adam Michael, CISO and adjunct professor at Texas A&M University, joins the conversation to discuss the evolution of identity management to identity security at the university. Adam delves into the complexities of managing identity in a higher education environment and shares insights on implementing DevOps practices. The episode covers topics like AI's impact on teaching, infrastructure as code, ROI of identity security projects, and the challenges and benefits of centralizing IT services. Connect with Adam: https://www.linkedin.com/in/amikeal/ The Phoenix Project (book): https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592 Attending Identity Week in Europe, America, or Asia? Use our discount code IDAC30 for 30% off your registration fee! Learn more at: Europe: https://www.terrapinn.com/exhibition/identity-week/ America: https://www.terrapinn.com/exhibition/identity-week-america Asia: https://www.terrapinn.com/exhibition/identity-week-asia/ Connect with us on LinkedIn: Jim McDonald: https://www.linkedin.com/in/jimmcdonaldpmp/ Jeff Steadman: https://www.linkedin.com/in/jeffsteadman/ Visit the show on the web at idacpodcast.com and follow @IDACPodcast on Twitter.

Guest Bio: Mark Schwartz joined AWS as an Enterprise Strategist and Evangelist in July 2017. In this role, Mark works with enterprise technology executives to share experiences and strategies for how the cloud can help them increase speed and agility while devoting more of their resources to their customers. Mark has extensive experience as an IT leader in the government, private sector, and the nonprofit world, and with organizations ranging from startup to large. Prior to joining AWS, he was CIO of US Citizenship and Immigration Services (in the Department of Homeland Security), where he led a large digital transformation effort, moving the agency to the cloud, introducing and refining DevOps and Agile techniques, and adopting user-centric design approaches. From his work at USCIS, he developed a reputation for leading transformation in organizations that are resistant to change, obsessed with security, subject to considerable regulation and oversight, and deeply bureaucratic. Before USCIS, Mark was CIO of Intrax Cultural Exchange, a leader in global youth exchange programs, and CEO of a software company. Mark is the author of The Art of Business Value , A Seat at the Table: IT Leadership in the Age of Agility, War, Peace and IT and The Delicate Art of Bureaucracy. Mark speaks at conferences internationally on such subjects as DevOps, Leading Change, Driving Innovation in IT, and Managing Agility in Bureaucratic Organizations. He has been recognized as a Computerworld Premier IT Leader and received awards for Leadership in Technology Innovation, the Federal 100 IT Leaders, and a CIO Magazine 100 award. Mark has both a BS and MA degree from Yale University, and an MBA from Wharton.   Social Media/ Website: Mark's LinkedIn Profile: https://www.linkedin.com/in/innovativecio Mark's AWS Executive Insights page with links to all his blogs posts and books https://aws.amazon.com/ar/executive-insights/enterprise-strategists/mark-schwartz/  Books/ Resources: The Delicate Art of Bureaucracy: Digital Transformation with the Monkey, the Razor and the Sumo Wrestler by Mark Schwartz https://www.amazon.co.uk/Delicate-Art-Bureaucracy-Transformation-Wrestler-ebook/dp/B086XM4WCK/ The Art of Business Value by Mark Schwartz https://www.amazon.co.uk/Art-Business-Value-Mark-Schwartz/dp/1942788045 A Seat at the Table: IT Leadership in the Age of Agility by Mark Schwartz https://www.amazon.co.uk/Seat-Table-Leadership-Age-Agility/dp/1942788118/ War, Peace and IT: Business Leadership, Technology, and Success in the Digital Age by Mark Schwartz https://www.amazon.co.uk/War-Peace-Business-Leadership-Technology/dp/1942788711 Reaching Cloud Velocity: A Leader's Guide to Success in the AWS Cloud by Jonathan Allen et al https://www.amazon.co.uk/Reaching-Cloud-Velocity-Leaders-Success/dp/B086PTDP51 Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT by Stephen Orban https://www.amazon.co.uk/Ahead-Cloud-Practices-Navigating-Enterprise-ebook/dp/B07BYQTGJ7 Engineers of Victory: The Problem Solvers Who Turned the Tide in the Second World War by Paul Kennedy https://www.amazon.co.uk/Engineers-Victory-Problem-Solvers-Turned-ebook/dp/B00ADNPCC0 The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim https://www.amazon.co.uk/Phoenix-Project-Devops-Helping-Business/dp/1942788290/ The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data by Gene Kim https://www.amazon.co.uk/Unicorn-Project-Disruption-Redshirts-Overthrowing/dp/1942788762   Interview Transcript Ula Ojiaku:  Mark, thank you so much for making the time for this conversation. Mark Schwartz: Thank you, my pleasure. Ula Ojiaku: Great. Now let's start with you know, the question I usually ask my guests: who's Mark? What makes him tick? Mark Schwartz:  And they can answer that question. It's not a hard one. where to start? Um, you know, I always enjoy my work. That's a thing about me. I like to think that people have fun working with me because I tend to laugh a lot. And even you know, when the work is boring, I find ways to make it interesting. I just enjoy doing things and accomplishing things. I think if we're going to talk about my books, and some of the things I've done later, an important thing to realize is that, I started out, you know, when I went, when I was in high school, when I went to college, I was pretty sure I wanted to study computer science and get involved with these computer things. But when I was actually studying, I realized there were all these other interesting areas, I'm just, you know, endlessly curious. And so, I wound up studying all kinds of other things, in addition. And the result was that when I finished college, I decided to go to graduate school in philosophy. And I spent a few years getting a master's degree in philosophy. And the fact that I'm curious about so many things and read so many different things, I think it enters into a lot of what I do. I like to pull analogies from non-IT related fields and, and, and I'll call upon all the things I've learned in all sorts of different areas, as I'm writing and speaking and working. Ula Ojiaku:  It shines through in your book, definitely. Mark Schwartz:  Yes, I think it does. That's partly an explanation for what you see in my books. I think, um, you know, I sometimes say that I have trouble reading business books generally. Because I kind of find them boring. They tend to make the same point over and over again, and to be very just so one directional, you know, just on the same subject, and it's a little bit odd because in every other subject, the books tend to refer to other books in other fields and there's this extra dimension and that helps you understand what the author is getting at. But in business books, they, you know, aside from having a quote now and then from a famous leader or something, they don't tend to do that, they don't, they don't sort of call upon the whole history of literature and writing. And so, I have a little bit of fun in writing my books in trying to see if I can add an extra dimension just by reference and by bringing in other things that are a little bit orthogonal to the subject matter. Ula Ojiaku:  And that kind of, you know, brings home the point that life isn't black and white. It's actually a complex or a complex kind of, you know, maze and of different disciplines, different ideologies and different viewpoints that make it what it is really. Mark Schwartz:  Yeah well, of course, that was part of the fun of my recent book on Bureaucracy. You know, because I know we all, we want to throw up when we encounter bureaucracy, you know, it disturbs us in so many ways. And one of the things I wanted to say in the book is, well, actually bureaucracy is all around you all the time in unexpected places and it usually doesn't drive you crazy, actually. Yeah... Ula Ojiaku:  Well, I have a lot of questions for you on your book, The Delicate Art of Bureaucracy, which is a catchy, catchy title on its own, very clever. But before we get to that, what do you do when you're not working? I know, you said you love work and you've also said that you're curious about so many things, which means that you read broadly - that's my interpretation. So, what do you do when you're not ‘working'? Mark Schwartz:  Yes, I read broadly, is one thing. In the past, I played the guitar a lot. And I don't quite as much lately. I don't know why, you know, I'll start doing it again. I'm sure at some point. But while I was living in San Francisco, I was actually playing in bars and coffee shops, I have a singer, who I performed with. Ula Ojiaku: Really? Wow! Mark Schwartz: And that was really fun. And then the other thing I do is travel, I've really traveled a lot. And, yeah, there was one period in my life where for about five years, I was bumming around the world with a backpack with you know, occasional returns to the States to work a little bit and make some money and then go traveling again. So, one of the joys of my current job is that, I get to do a lot of traveling to interesting places. Ula Ojiaku:  So, where would you say is your ideal getaway destination? Mark Schwartz:  Oh, let's see. I'm a big fan of Brazil. That, I have good friends there and it's really nice to see them and the atmosphere is always kind of fun there. Ula Ojiaku: Okay. Mark Schwartz: I don't know what I've discovered so many places around the world that I've really loved being. I lived in Japan for a year and that is a place that I love to go to, especially for the food. Yeah, I like good food. But I don't know I've found so many places that made me feel like I'd like to spend more time there. And of course, you can't really spend more time everywhere. Ula Ojiaku:  Interesting. So, let's, let's go to your book, “The Art of Delicate Bureaucracy”. What was the inspiration behind that book? Mark Schwartz:  Well, for all of my books, before I wrote, before I wrote them, I was thinking, ‘why hasn't anybody else written a book on this topic?' People don't write books on bureaucracy, at least not, you know, popular books, there are academic books on bureaucracy. And the same thing happened to me with my first book, “The Art of Business Value”, where I said to myself, we keep talking about business value in the IT world, like, is it obvious what it means? You know, what, why isn't anybody writing a book about what business value means? So, bureaucracy is one of those things. I have a lot of experience with it first of all, I was a CIO in a government agency. But it turns out, it's not just the government, whenever I tell people about my government experience, when I speak at a conference, people come up to me afterwards and say, ‘Oh, my company's just like that. I work for a financial services company; we have lots of bureaucracy'. And I work with a lot of people who are trying to pull off some sort of digital transformation, which is change on a big scale, that's changing traditional organizations on a big scale. And bureaucracy is always in their way because bureaucracy tends to resist change; it strongly tends to resist change. So, if you're doing a big change, then you're probably going to come up against it. So, I thought maybe with my experience as a bureaucrat, or at least experience in the big bureaucracy, I could give some pointers to people who are trying to cause big change, and yet are facing bureaucratic obstacles. And I can't imagine that there's any organization, at least any large organization that does not have bureaucratic obstacles to digital transformation. So, that got me started on it. And then as I started to think about bureaucracy and research it, I realized this is actually a really interesting topic. Ula Ojiaku:  You had an interesting introduction to the book. You said, “we are bureaucrats all.” Why that claim, you actually were saying, everyone is a bureaucrat, and I know you made a statement that's similar to that earlier on in this conversation - why? Mark Schwartz:  Well, of course, I have to define in the book, what I mean by bureaucracy and all that. And I follow the generally what's accepted as the academic definition. It mostly comes from the sociologist Max Vabre, who is writing around 1920. And, and he talks a lot about bureaucracy, and it's fairly complicated, but I simplify it in the book. Basically, what it comes down to is a bureaucracy is a way of organizing socially, that has rigid formal roles for people and rigid formal rules. And that's the essence of it. You know, bureaucracy, there are rules and they have to be applied uniformly to everybody. And there's a division of labor and you know, a hierarchy. So, it has rigid roles of people who have to sign off on things and approve things. So, with that is the definition. I think it, it connects with the very human tendency to try to structure things and constantly improve them and optimize them. So, if you find a good way of doing something, you tend to turn it into a rule, you know, this is the way it should be done from now on. Ula Ojiaku: Best practice! Mark Schwartz: It's the best practice. Yeah, yeah, exactly. And also, we, in, social organization, we'd like people to be accountable or responsible for things. And we know that you can't hold somebody accountable unless they have authority to perform their role. So, when you put those things together, it's very natural for us to set up these organizational systems, where we assign roles to people, and give them authority, and we make rules that encapsulate the best way to do things. And, essentially, that's bureaucracy. So, bureaucracy, I find, is everywhere around us in one form or another. But it doesn't drive us crazy most of the time, so we don't notice it. Ula Ojiaku:  Maybe if it's serving us, then we wouldn't notice it. But… Mark Schwartz:  It does serve. And if you look at the cases where it does drive us crazy, they have certain things in common. And in the book, I say there are three characteristics that bureaucracies often take on which they don't need to, it's not part of the definition of bureaucracy, but they often take on these characteristics. And it's those three characteristics that are what drive us crazy. And so, the goal, ultimately is to eliminate those three characteristics or turn them into something else. Ula Ojiaku: I know that the listeners would be curious to know what the three characteristics of bureaucracy that drive us crazy are? Is that so or should I just tell them go buy the book? Mark Schwartz: Yeah, go buy the book! Well, let me tell you the three characteristics, and also their opposite, which is what we really want. So, the first characteristic that drives us crazy, I think, is that bureaucracies tend to be bloated instead of lean, that would be the opposite in my view. There's no reason why a bureaucracy has to be bloated and wasteful. It could be lean, but it's one of those things that bureaucracy tends to become. So that's the first one. The second one is that bureaucracies tend to petrify, as opposed to learning. So, when I say petrifies, I mean that the rules and the bureaucracy don't change, or don't change as often as they should, or don't change continuously, which is really what rules should do. Now, that's not necessarily a characteristic of bureaucracy, but the definition, the definition says the rules have to be applied rigorously. You know, once you have a rule, everybody has to follow it. But it doesn't say that the rules have to stay the same forever, they can change. The opposite of a petrified bureaucracy is a learning bureaucracy, where the rules are constantly adjusted, based on what the people in the organization learn. And there are plenty of good examples of learning bureaucracies out there. And your goal is to transform the one into the other, the petrified into the learning. The third is, bureaucracies tend to be coercive, rather than enabling. Coercive, meaning that they're there to control employee behavior, to force employees to behave in ways that otherwise they wouldn't want to. They tend to be ‘no' saying, they say ‘no', a lot. Your bureaucracy for your expense reporting policy in your company probably says, ‘no that expense is no good because X Y and Z.' There are plenty of examples of enabling bureaucracies, where the point is not to stop you from doing things or force you to do something you don't want to. But the bureaucracy provides a support structure, provide best practices, as you said, that help you do your job well. And there's no reason why bureaucracies can't do that. So, the three bad characteristics are bloat, coercion, and petrify. Ula Ojiaku: Okay, nice. So, it sounds like the way you've described bureaucracy, when you look at it from a positive slant, would it be the same thing as guardrails, putting guardrails in place, or giving people the right degree of freedom? Mark Schwartz: Yeah, that's exactly the idea. What I find is that guardrails and automation are ways of implementing bureaucracy, that lead to those three good characteristics rather than the bad ones. Let's say in software development, in DevOps, for example, it's a good idea to put guardrails, security guardrails, for example, around what people can do, and automated security tests and things like that. Because then the developers or the DevOps teams, they can go charging ahead full speed, knowing that they can't do anything wrong, you know, because the guardrails are there. And they get immediate feedback, if they do something that's going to put them outside the guardrails and they can just immediately fix it. So, it's very empowering for them, lets them move fast. And it also gets rid of that coercive element of you know, I write some code and then somebody comes in afterwards and says, ‘no, you can't deploy that'. That's annoying. Instead, I can run the security tests myself, as a developer, see if there's anything that's problematic, fix it right away if I want to, so it's all under my control. But the end result is still the same. The bureaucracy is still there. It's just automated and implemented as guardrails. Ula Ojiaku:  It's enabling, like you said before, instead of hindering. Mark Schwartz:  And it's lean, because it's very inefficient and wasteful, if you write some code, and then at the very end of the development process, somebody finds a security flaw. And now you have to remember what you were doing. And, you know, go back and relearn your code and make changes then, so that's wasteful, as opposed to lean. It's coercive, as opposed to enabling. And if you're good at doing these things, then you keep updating your guardrails and your security tests based on new security threats you learn about or new policies or whatever. So, you make a learning bureaucracy as well. Ula Ojiaku:  Interesting. In the book as well, you said you want us to be calm, chaos monkeys, knights of Ockham, lean sumo wrestlers, very interesting oxymoron there. And you know, black belt experts, could you tell us more about those terms? Why did you use those terms? Mark Schwartz:  Because they made me laugh of course. Ula Ojiaku: Well, they made me laugh too. Mark Schwartz: So, I thought about what I learned about coping with bureaucracy, especially in my government job, but also from reading and from talking to other people. And I realized I had about, you know, 30 techniques for coping with bureaucracy, I call them plays. And I just grabbed those 30 techniques, but I thought about it, and I realized they divided into three. And the three, I could sort of associate with a personality, almost. You know, that these 10 plays are associated with this personality, these 10 plays are associated with this one. And I came up with these three personalities that I thought describe those plays. And the three personalities are the monkey, and the razor, and the sumo wrestler. And, you know, I think, I could stop right there, because it's probably obvious why I associate those with these plays, but I will go a little further. Ula Ojiaku: Please… Mark Schwartz: So, I realized that some of the things we did, the ones that I call the plays of the monkey, the way of the monkey, those things had to do with provoking. You know, monkeys are mischievous, provocative, and sometimes annoying. And a bunch of the techniques had to do with trying to be provocative. And the razor and I'll give you some examples in a minute. The razor, to me is all about being lean. It's about trimming away waste. And it also refers to the philosophical principle of Ockham's razor. Ockham was a medieval philosopher, right, William of Ockham. And he's generally credited with an idea that something like if you have a choice between a simple explanation, and a complicated explanation, you should prefer the simple one. That's not really what he said. But that's, that's what most people associated with him. That's the principle of Ockham's razor. And, and so it's called a principle of ontological parsimony, meaning, you shouldn't presuppose the existence of more things than you need to, in order to explain something. So, you know, don't make up nymphs. And you know, I don't know, water dryads and whatever's to explain something that you can equally just explain through simple physical laws. Ula Ojiaku:  Just saying, 'keep it simple...' Mark Schwartz:  Yeah, keep it simple, in a way, right? So that's called the principle of ontological parsimony. And I said, there's a similar principle of bureaucratic parsimony, which says that if you're trying to implement a control, and you can do it in a simple way, or you could do it in a really complicated way, do it a simple way. And so, it's a principle of leanness because I find that bureaucracies, when they get bloated, they have these really complicated wasteful ways of doing something that they could they could accomplish exactly the same thing, but in a simpler way. So that's the razor. And then a sumo wrestler. Well, Sumo is the sport where, you know, two massive people sort of bang into each other, right? And the goal is you want to push your opponent out of the ring, or you want to make them fall and touch the ground with something other than their feet. And if you can do either of those things, you win. So, if you're a big massive person and you're trying to accomplish those things, you might think that the best thing to do is charge your opponent and push really hard. But if your opponent then just either dodges or just is soft and lets you push, well, you're probably going to go flying out of the ring, right? So, one of the principles in Sumo is you want to use your opponent's strength against them. And if they push hard, now, go ahead, give them a little pull. And, you know, let them push even harder. And I realized that some of these techniques for overcoming bureaucracy have to do with using bureaucracy actually, on your side, you know, the using the strength of bureaucracy against it. So that's why the sumo wrestler. So, I'll give you examples now on each one, now that I've described my three personalities. So, the monkey does what is sometimes referred to as provoking and inspecting or provoking and observing, in parallel with the Agile principle of inspect and adapt. So, provoke and observe, what the monkey does is try something that's probably outside the rules, or at least is, you know, a borderline and watches what happens. So, an example where we use this is that we have these rules in Homeland Security that essentially said, if you were going to do an IT project, you have to produce 87 documents. And each document had a template, and you have to fill in each section of the template. And these documents would run to hundreds of pages. And so, using the persona of the monkey, let's say, we started to turn in these documents. But in each section of the template, we just wrote a one sentence, one sentence answer, you know, we're very short answer instead of writing pages and pages. And we wanted to see what would happen if we did that, because there was no rule that said, it had to be a really long answer. And eventually, we started to provoke even more, we just left out sections that we thought didn't make any sense for what we were doing. And all of this was unprecedented, you know, it caused a lot of fear. It turned out, and this sometimes happens, that the enforcers of this policy, they were happy when they said, “We've never wanted anybody to write these really long answers to these things, we have to read them. And you know, the intention wasn't to slow people down. As long as you're giving us the right information. That's all we need.” So, in this case, provoking just it turned out that we could defeat a bunch of bureaucracy there, we could, we could make things a lot leaner because nobody objected. But sometimes people do object. And if they do, then you learn exactly what the resistance is, who it is, is resisting, and that gives you valuable information, when you're trying to figure out how to overcome it. So that's the monkey. You know, let's try something a little playful and mischievous, and see what happens. The razor, well, that one follows also on my 87 documents, because we then set up an alternative way of doing things that had only 15 documents. And where there had been 13 gate reviews required for each project. We reduced it to two. And so, all we did, you know, we just used our little razor to trim away all the excess stuff that was in the bureaucratic requirements. And then we showed people that those 15 documents and those two gate reviews accomplished exactly the same thing as the 87 documents and the 13 gate reviews. That's the principle of the razor, that's how the razor works. The sumo wrestler, also a favorite of mine. So, we were trying to convince the bureaucracy to let us do DevOps and to be agile, and it was resisting. And people kept pointing to a policy that said, you can't do these things. And so, we wrote our own policy. And it was a very good bureaucratic policy looked exactly like every bureaucratic document out there. But it essentially said you must use DevOps and you must be agile on it, you know, it set up a perfect bureaucracy around that it's set up ways of checking to make sure everybody was using DevOps. And the theory behind it was the auditors when they came to audit us and said we were being naughty because we were doing DevOps. Their argument was we looked at the policy and we looked at what you're doing, and they were different. And that's the way auditing works. That was the, you know, GAO, the Government Accountability Office, and the Inspector General and all that. So, we figured if we had a policy that said you must do DevOps, and they audited us, well, they would actually be enforcing the policy, you know, they'd be criticizing any part of the organization that was not using DevOps and I thought that's great. So, this is how you use the strength of the bureaucracy against the bureaucracy or not really, against even, you know, it's perfectly good, perfect… Ula Ojiaku:  To help the bureaucracy yeah, to help them to improve, improve the organization. But thinking about the monkey though, being provocative and mischievous, do you think that there has to be an element of you know, relationship and trust in place first, before… you can't just you know… you're new, and you've just gotten through the door and you start being a monkey… you probably will be taken back to wherever you came from! What do you think? Mark Schwartz:  Well, it helps if you're giggling while you do it. But you know, I think the goal here is to figure out the right levers that are going to move things. And sometimes you do have to push a little bit hard, you know, you do need to take people out of their comfort zone. Usually, you want to do these things in a way that takes into account people's feelings, and you know, is likely to move them in the right direction, rather than making them dig in their heels. But I'll give you a couple of examples of Monkey tactics that are less comfortable for people. One is simply, you know, there's a status quo bias. It's a known, well-known cognitive bias; people tend to prefer the status quo or look the other way about it's failings and stuff. So often, when you're trying to make a change, people say, we're fine the way we are, you know, everything's okay. So, one of the things the monkey tries to do is, is to make it clear that the status quo is not acceptable, you know, to show people that it actually if they think about it, it's no good. And so, for example, when we decided to move to the cloud, instead of working in our DHS data center, people said - of course at the time it was a big concern, ‘was the cloud secure enough?' And in the persona of the monkey, the right response is, ‘are we secure enough now?' You know, ‘don't you realize that we're not happy with our security posture today?' ‘It's not like, the cloud has proved itself. I mean, we have to compare our security in the cloud versus our security in the data center. And yes, I'm very sure it'll be better in the cloud and here's why…' But you can't start from the assumption that you are fine right now. In general, when we're talking about the cloud, that's the situation. Companies are using their own data centers. And it's like, you know, we have to teach them that they can do better in the cloud. But the truth is that they're not happy in their own data centers, if they think about it, right? There are security issues, there are performance issues, there are cost issues. And they're aware of those issues, right, they just look the other way. And because they're comfortable with the status quo, so the monkey has to sort of shake people up and say, ‘It's not okay, what you're doing now!' Another example, and this is really harsh, and I wouldn't use it in most cases. But let's say that this was in Homeland Security. Let's say that Homeland Security is enforcing a very bureaucratic process that results in IT projects, taking five years instead of six months. And let's say, you know, the process is there on paper, the rules say, ‘Do this', the people are interpreting the rules in a way that makes things take five years. Sometimes, the monkey has to go to somebody who's in their way and say, ‘We are in the Department of Homeland Security, this IT project is going to make people more secure in the homeland. Are you comfortable with the fact that you are preventing people from being more secure for the next four and a half years, when we could…' You know, it's a matter of personalizing it. And that sometimes is what's necessary to get people to start thinking creatively about how they can change the bureaucracy. You know, ‘I hate to say it, but you're a murderer', you know, essentially is the message. It's a monkey message. And like I said, you know, it's not the preferred way to go about doing things. But if you have to, I mean, the lives of people are at stake, and you've got to find a way to get there. Ula Ojiaku:  So how can leaders because your book, The Art of Business Value, in your book, you said that “leaders create the language of the organization, and they set up incentives and define value in a way that elicits desired outcomes.” So, in essence, I understand that statement to mean that leaders set the tone, and you know, kind of create the environment for things to happen. So, how can leaders implement or apply bureaucracy in a way that enables an organization where, before it was seen as a hindrance, how can they do this? Mark Schwartz:  My thought process was, if we all agree, we're gonna try to maximize business value? How do we know what we mean by it? And I realized, a lot of Agile people, you know, people in our Agile and DevOps community, were being a little bit lazy. You know, they were thinking, ‘Oh, business value, you know, it's returns on investment, or, you know, it's up to the business (to define) what's business value.' The tech people just, you know, do the work of providing a solution. And to me, that's too lazy. If you're going to be agile, be it you have to be more proactive about making sure you're delivering business value. So, you have to understand what it means. You have to actually do the work of, you know, figuring out what it means. And what it means is not at all obvious. And, you know, you might think it has something to do with return on investment or shareholder value or something like that. But when you really closely examine it, that is not the right way to define it, when it comes to deciding what its efforts to prioritize and all that that's, you know, the case that the book makes, and I explain why that's true. Instead, I say you have to think of business value within the context of the business's strategy and its objectives as a business. There's no like, abstract, this has more business value than this because we calculated an ROI or something like that, that doesn't work reprioritizing. It's always asked within the context of a particular business strategy. And the business strategy is a direction from leadership. There might be input from everybody else, but ultimately, you have leaders in the organization who are deciding what the strategic objectives are. So, for example, if you are a traditional bank, or traditional financial services company, and you look around you and you see there are all these new FinTech companies that are disrupting the industry, and you're worried, well there are a lot of different ways you can respond to those disruptive FinTechs. And how you're going to choose to respond depends on your preferences, it depends on the situation of your company, in the industry, the history of your company, all of those things. But of the many ways you can respond to that disruption, you're going to choose one as the leader of your enterprise. Well, what adds business value is whatever supports that direction you choose to go. You can't think of business value outside of that direction, you know. That's the case that I make. So, leaders don't just set the tone and the culture there, they're actually setting strategic direction that determines what has business value. And then the people who are executing the agile teams have to take it upon themselves to make sure that whatever they're doing is going to add business value in that sense.   So, the role of leadership then becomes direction setting and visioning for the future and communicating the vision to the people who are working and providing feedback, you know, on whether things are actually adding business value or not . And that's the key responsibility. Now, in order to do that, in order to motivate people to deliver according to that idea of business value, there are certain techniques as a leader that you have to keep in mind, there are ways that you get people, you get a big organization to sort of follow you. And one of the ones that's become most important to me to think about after talking to a lot of leaders about how they're running their organizations, and what's working, is using middle management as a lever for accomplishing those things. So often, I'll talk to leaders of a business, and they'll say, our problem is the frozen middle, middle management is, you know, they're just not changing the way we want, we want to, we want to cause a big transformation, but middle management is getting in the way. And I tell them, ‘that's pretty much a myth.' You know, ‘that's not actually what's happening, let's look more closely at your organization.' Almost always, middle management is still trying to do the best they can, given the situation that they're in. And the way that you get them to align themselves behind the change is, you change their incentives or their role definition, or how you tell them what you're expecting from them, you don't say “change”, you know, and start doing X and Y, you change what success looks like for their position. And then they adapt to it by becoming engaged and finding ways to get there. So, there's almost always a leadership problem when you have that frozen middle effect. And, and I've seen it work really well that, you know, all of a sudden, you get this big leverage, because you just do a little bit of tweaking of role definitions, and bring everybody into solving the problem. And actually, there's an example, I love to talk about a history book, like I said before, I like to bring in other things, right? It's called the Engineers of Victory. And it's about World War Two, the Allies realized that they had to solve a set of problems, I think there was six or so problems. One of them was how do you land troops on a beach that's heavily defended? They realize they were just not going to be able to win the war until they could do that. But nobody knew how to do it. Because, you know, obviously, the bad guys are there on the beach, they're dug in, they put barbed wire everywhere, and mines, and you know, all this stuff. And it's just going to be a slaughter if you try to land on the beach. So, this book, Engineers of Victory, makes the case that what really won the war, was figuring out those solutions. And who was responsible for figuring out those solutions? It was middle management, basically. It was the, you know, within the structure of the army, it was the people not at the top who had big authority, you know, the generals, and it was not the troops themselves, because they weren't in a position to figure out these things. It was middle management that could see across different parts of the organization that could try things and see whether they worked or not, that, you know, essentially could run their own mini skunkworks projects. And eventually, they came up with the solutions to these problems. So, I think that's very encouraging for the role of middle management, you know, that a lot of problems have to be solved at that layer in order to pull off a transformation. And it really can be done. And this is a beautiful example of it. Ula Ojiaku:  It reminds me of, you know, my experience in a few transformation initiatives. So, the middle, the people who are termed to be in the frozen middle, are, like you said, they want to do what's best for the company, and they show up wanting to do their best work, but it's really about finding out, ‘Where do I fit in, (with) all this change that's happening?' You know, ‘if my role is going away, if the teams are going to be more empowered, that means I'm not telling them what to do, but then what do I do now?' So, the clarity of what the ‘New World' means for them, and what's in it for them, would help, you know, make them more effective. Mark Schwartz: And the mistake that's often made is to say to them, ‘start doing DevOps' or, you know, ‘start doing agile or something.' Because if you don't change the definition of success, or you don't change the incentives that, you know, then it's just, make work and they're going to resist it. You know, if you say your incentive is to get really fast feedback or you know, one of the other goals of DevOps, because of the following reasons, it helps the business this way, so let's try to reduce cycle time as much as possible for producing software. Okay, that's a change in the incentive, or the, you know, the definition of success, rather than just telling somebody you have to do DevOps, you know, read a book and figure it out. Ula Ojiaku:  So, what other books because you mentioned the Engineers of Victory, are there any other books you would recommend for the listener to go check out if they wanted to learn more about what we've talked about today? Mark Schwartz:  Well, I think, you know, obviously, my books referred to War and Peace by Tolstoy, Moby Dick, another great one. You know, you probably need to read my books to figure out why those are the right books to read and Engineers of Victory. As I said, I think that one's a great one. Within the field, there are some DevOps books that that I like a lot, of course, Gene Kim's books, The Phoenix Project, and now The Unicorn Project, the sequel to that. Because those are books that give you a feel for the motivation behind all the things that we do. The Mechanics of Things, there are plenty of books out there that help you learn the mechanics of how to do continuous integration and continuous delivery. And then the cloud is I think it's really transformative. You know, it's the cloud itself is a tremendous enabler. I work at AWS, of course but I'm not saying this because I work at AWS, it's more than I work at AWS because I believe these things. And my teammates have written some good books on the cloud. Reaching Cloud Velocity, for example, by Jonathan Allen and Thomas Blood is a great one for reading up on how the cloud can be transformative. But my other teammates, Gregor Hope, has written a number of books that are really good, Stephen Orban did A Head in the Cloud. So, I think those are all… should be at the top of people's reading lists. And then, of course, I recommend my books, because they make me laugh, and they might make you laugh, too. Ula Ojiaku:  Definitely made me laugh, but they've also given me things to think about from a new perspective. So, I totally agree. And so, where can people find you if they want to reach out to you? Mark Schwartz:  Yeah, LinkedIn is a great place to find me. If you're with a company that is an AWS customer, feel free to talk to your account manager, the sales team from AWS and ask them to put you in touch with me, is another easy way. LinkedIn is kind of where I organize my world from so find me there. Ula Ojiaku:  Okay. Sounds great. And any final words for the audience or for the listeners. Mark Schwartz:  Um, I, I have found that these things that you want to do to take advantage of the digital world, and I think we're all sort of pointing ourselves in that direction, there are these amazing things you can do in the digital world. They're sometimes challenging to get there, but it's very possible to get there. And one thing I've learned a lot at Amazon is the idea of working backwards, you know, you get that picture in your head for where you want to be and then you say to yourself, ‘I can get there. Let me work backwards and figure out what I have to do in order to get there.' And you might be wrong, you know, you should test hypotheses, you start moving in the right direction, and of course, correct as you need to. But you can do it with confidence that others are doing it and you can too no matter what your organization is, no matter how much you think you're a snowflake and you know different from every other organization. You can still do it. And with just some good intention and good thinking you can figure out how to how to get there. Ula Ojiaku:  Thank you so much, Mark. That was a great close for this conversation and again, I really appreciate your making the time for this interview. Thank you. Mark Schwartz: Thanks for having me. Ula Ojiaku: You're welcome.  

Will Larson is Chief Technology Officer at Carta. Prior to joining Carta, he was the CTO at Calm and held engineering leadership roles at Stripe, Uber, and Digg. He is the author of two foundational engineering career books, An Elegant Puzzle and Staff Engineer, and The Engineering Executive's Primer, which will be released in February. In our conversation, we discuss:• Systems thinking: what it is and how to apply it• Advice for product managers on fostering productive relationships with engineering managers• Why companies should treat engineers like adults• How to best measure developer productivity• Writing and its impact on his career• How to balance writing with a demanding job• How to develop your company values—Brought to you by DX—A platform for measuring and improving developer productivity | OneSchema—Import CSV data 10x faster | Vanta—Automate compliance. Simplify security.—Find the transcript for this episode and all past episodes at: https://www.lennyspodcast.com/episodes/. Today's transcript will be live by 8 a.m. PT.—Where to find Will Larson:• X: https://twitter.com/Lethain• LinkedIn: https://www.linkedin.com/in/will-larson-a44b543/• Website: https://lethain.com/—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Will's background(04:12) Changes in the field of engineering(06:27) We need to stop treating engineers like children(08:32) Systems thinking(13:23) Implementing systems thinking in hiring(16:32) Engineering strategy(20:21) Examples of engineering strategies(25:08) How to get good at strategy(26:48) The importance of writing about things that excite you(32:40) The biggest risk to content creation is quitting too soon(35:24) How to make time for writing(37:41) Tips for aspiring writers(41:18) Building productive relationships between product managers and engineers(43:45) Giving the same performance rating to EMs and PMs(48:24) Measuring engineering productivity(55:53) Defining company values(01:02:10) Failure corner: the Digg rewrite(01:11:05) Will's upcoming book, The Engineering Executive's Primer(01:12:04) Lightning round—Referenced:• The end of the “free money” era: https://www.theguardian.com/technology/2023/apr/11/techscape-zirp-tech-boom• Work on what matters: https://lethain.com/work-on-what-matters/• Sheryl Sandberg to Harvard Biz Grads: “Find a Rocket Ship”: https://www.forbes.com/sites/kashmirhill/2012/05/24/sheryl-sandberg-to-harvard-biz-grads-find-a-rocket-ship/?sh=708c9a93b37a• What Is Systems Thinking?: https://www.snhu.edu/about-us/newsroom/business/what-is-systems-thinking• Introduction to systems thinking: https://lethain.com/systems-thinking/• Thinking in Systems: https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557• Silent Spring: https://www.amazon.com/Silent-Spring-Rachel-Carson/dp/0618249060• Writing an engineering strategy: https://lethain.com/eng-strategies/• Carta: https://carta.com/• Eric Vogl on LinkedIn: https://www.linkedin.com/in/ericvogl/• Good Strategy/Bad Strategy: The difference and why it matters: https://www.amazon.com/Good-Strategy-Bad-difference-matters/dp/1781256179• The Crux: How Leaders Become Strategists: https://www.amazon.com/Crux-How-Leaders-Become-Strategists/dp/1541701240/• How Big Things Get Done: The Surprising Factors That Determine the Fate of Every Project, from Home Renovations to Space Exploration and Everything in Between: https://www.amazon.com/How-Big-Things-Get-Done/dp/0593239512/• Technology Strategy Patterns: Architecture as Strategy: https://www.amazon.com/Technology-Strategy-Patterns-Architecture/dp/1492040878/• The Value Flywheel Effect: Power the Future and Accelerate Your Organization to the Modern Cloud: https://www.amazon.com/Value-Flywheel-Effect-Accelerate-Organization/dp/1950508579• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290• The Engineering Executive's Primer: Impactful Technical Leadership: https://www.amazon.com/Engineering-Executives-Primer-Impactful-Leadership/dp/1098149483• An Elegant Puzzle: Systems of Engineering Management: https://press.stripe.com/an-elegant-puzzle• Staff Engineer: Leadership beyond the management track: https://www.amazon.com/Staff-Engineer-Leadership-beyond-management-ebook/dp/B08RMSHYGG• Gergely Orosz's newsletter: https://blog.pragmaticengineer.com/author/gergely/• Leaving big tech to build the #1 technology newsletter | Gergely Orosz (The Pragmatic Engineer): https://www.lennyspodcast.com/videos/leaving-big-tech-to-build-the-1-technology-newsletter-gergely-orosz-the-pragmatic-engineer/• The art of product management | Shreyas Doshi (Stripe, Twitter, Google, Yahoo): https://www.lennyspodcast.com/videos/the-art-of-product-management-shreyas-doshi-stripe-twitter-google-yahoo/• Henry Ward on LinkedIn: https://www.linkedin.com/in/heward/• Vrushali Paunikar on LinkedIn: https://www.linkedin.com/in/vrushali-paunikar/• Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339• How to measure and improve developer productivity | Nicole Forsgren (Microsoft Research, GitHub, Google): https://www.lennyspodcast.com/how-to-measure-and-improve-developer-productivity-nicole-forsgren-microsoft-research-github-goo/• DORA: https://dora.dev/• Setting engineering org values: https://lethain.com/setting-engineering-org-values/• Digg: https://digg.com/• Kevin Rose on LinkedIn: https://www.linkedin.com/in/kevinrose/• Digg's v4 launch: an optimism born of necessity: https://lethain.com/digg-v4/• Dash Gopinath on LinkedIn: https://www.linkedin.com/in/dashgopinath/• Rich Schumacher on LinkedIn: https://www.linkedin.com/in/richschumacher/• The ALL NEW Don't Think of an Elephant!: Know Your Values and Frame the Debate: https://www.amazon.com/ALL-NEW-Dont-Think-Elephant-ebook/dp/B00NP9LHFA• Top Chef on Peacock: https://www.peacocktv.com/watch-online/tv/top-chef/5172289448907967112• Hard to work with: https://lethain.com/hard-to-work-with/—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

Don't miss out on the next #womenintech podcast episode, get notified by signing up here http://womenintechshow.com.Be featured in the Women in Tech Community by creating your profile here http://womenintechvip.com/“Tulika Biswas of Avid, The Power of Persistence”        #womenintech Show is a WeAreTech.fm production.To support the Women in Tech podcast go to https://www.patreon.com/womenintechTo be featured on the podcast go to http://womenintechshow.com/featureGuest Host,Felice LaZaehttps://www.linkedin.com/in/felicelazae/Guest,Tulika Biswashttps://www.linkedin.com/in/tulika-biswas-pmp-csm-sa-lpm-63b24492/Listener Spotlight,Ulviyya Jafarli https://www.linkedin.com/in/ulviyya-jafarli-924453156/In LA? Here's some awesome resources for you to become immersed in the LA Tech scene -For a calendar of all LA Startup events go to, http://WeAreLATech.comGet Podcast Listeners, http://getpodcastlisteners.com/Resources Mentioned:Avid, https://www.avid.comPro Tools, https://www.avid.com/pro-toolsPride and Prejudice, https://www.amazon.com/Pride-Prejudice-Jane-Austen/dp/1503290565The Phoenix Project, https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592Smartless, https://podcasts.apple.com/us/podcast/smartless/id1521578868Serial, https://serialpodcast.orgTechcrunch, https://techcrunch.comMIT Tech Review, https://www.technologyreview.comHBR, https://hbr.orgOffice Ladies, https://officeladies.comCredits:Produced and Hosted by Espree Devora, http://espreedevora.comStory Produced, Edited and Mastered by Cory Jennings, https://www.coryjennings.com/Production and Voiceover by Adam Carroll, http://www.ariacreative.ca/Team support by Janice GeronimoMusic by Jay Huffman, https://soundcloud.com/jayhuffmanShort Title: Tulika Biswas

Direct .mp3 file download. We talk with Ryan Price about how to start a new Drupal project the right way, including development environment setup, code base setup, initial modules, Git setup, and common newbie mistakes. URLs mentioned Docksal DDEV drupal/recommended-project Composer template Admin Toolbar Devel phpcs, phpcbf Pathauto Redirect Metatag Webform The Phoenix Project The Unicorn Project DrupalEasy News Professional module development - 15 weeks, 90 hours, live, online course. Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course. Audio transcript We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode. Subscribe Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher. If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

About GeneGene Kim is a multiple award-winning CTO, researcher and author, and has been studying high-performing technology organizations since 1999. He was founder and CTO of Tripwire for 13 years. He has written six books, including The Unicorn Project (2019), The Phoenix Project (2013), The DevOps Handbook (2016), the Shingo Publication Award winning Accelerate (2018), and The Visible Ops Handbook (2004-2006) series. Since 2014, he has been the founder and organizer of DevOps Enterprise Summit, studying the technology transformations of large, complex organizations.Links: The Phoenix Project: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/ The Unicorn Project: https://www.amazon.com/Unicorn-Project-Developers-Disruption-Thriving/dp/B0812C82T9 The DevOps Enterprise Summit: https://events.itrevolution.com/ @RealGeneKim TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: If you asked me to rank which cloud provider has the best developer experience, I'd be hard-pressed to choose a platform that isn't Google Cloud. Their developer experience is unparalleled and, in the early stages of building something great, that translates directly into velocity. Try it yourself with the Google for Startups Cloud Program over at cloud.google.com/startup. It'll give you up to $100k a year for each of the first two years in Google Cloud credits for companies that range from bootstrapped all the way on up to Series A. Go build something, and then tell me about it. My thanks to Google Cloud for sponsoring this ridiculous podcast.Corey: This episode is brought to us by our friends at Pinecone. They believe that all anyone really wants is to be understood, and that includes your users. AI models combined with the Pinecone vector database let your applications understand and act on what your users want… without making them spell it out. Make your search application find results by meaning instead of just keywords, your personalization system make picks based on relevance instead of just tags, and your security applications match threats by resemblance instead of just regular expressions. Pinecone provides the cloud infrastructure that makes this easy, fast, and scalable. Thanks to my friends at Pinecone for sponsoring this episode. Visit Pinecone.io to understand more.Corey Quinn: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by a man who needs no introduction but gets one anyway. Gene Kim, most famously known for writing The Phoenix Project, but now the Wall Street Journal best-selling author of The Unicorn Project, six years later. Gene, welcome to the show.Gene Kim: Corey so great to be on. I was just mentioning before how delightful it is to be on the other side of the podcast. And it's so much smaller in here than I had thought it would be.Corey Quinn: Excellent. It's always nice to wind up finally meeting people whose work was seminal and foundational. Once upon a time, when I was a young, angry Unix systems administrator—because it's not like there's a second type of Unix administrator—[laughing] The Phoenix Project was one of those texts that was transformational, as far as changing the way I tended to view a lot of what I was working on and gave a glimpse into what could have been a realistic outcome for the world, or the company I was at, but somehow was simultaneously uplifting and incredibly depressing all at the same time. Now, The Unicorn Project does that exact same thing only aimed at developers instead of traditional crusty ops folks.Gene Kim: [laughing] Yeah, yeah. Very much so. Yeah, The Phoenix Project was very much aimed at ops leadership. So, Bill Palmer, the protagonist of that book was the VP of Operations at Parts Unlimited, and the protagonist in The Unicorn Project is Maxine Chambers, Senior Architect, and Developer, and I love the fact that it's told in the same timeline as The Phoenix Project, and in the first scene, she is unfairly blamed for causing the payroll outage and is exiled to The Phoenix Project, where she recoils in existential horror and then finds that she can't do anything herself. She can't do a build, she can't run her own tests. She can't, God forbid, do her own deploys. And I just love the opening third of the book where it really does paint that tundra that many developers find themselves in where they're just caught in decades of built-up technical debt, unable to do even the simplest things independently, let alone be able to independently develop tests or create value for customers. So, it was fun, very much fun, to revisit the Parts Unlimited universe.Corey Quinn: What I found that was fun about—there are few things in there I want to unpack. The first is that it really was the, shall we say, retelling of the same story in, quote/unquote, “the same timeframe”, but these books were written six years apart.Gene Kim: Yeah, and by the way, I want to first acknowledge all the help that you gave me during the editing process. Some of your comments are just so spot on with exactly the feedback I needed at the time and led to the most significant lift to jam a whole bunch of changes in it right before it got turned over to production. Yeah, so The Phoenix Project is told, quote, “in the present day,” and in the same way, The Unicorn Project is also told—takes place in the present day. In fact, they even start, plus or minus, on the same day. And there is a little bit of suspension of disbelief needed, just because there are certain things that are in the common vernacular, very much in zeitgeist now, that weren't six years ago, like “digital disruption”, even things like Uber and Lyft that feature prominently in the book that were just never mentioned in The Phoenix Project, but yeah, I think it was the story very much told in the same vein as like Ender's Shadow, where it takes place in the same timeline, but from a different perspective.Corey Quinn: So, something else that—again, I understand it's an allegory, and trying to tell an allegorical story while also working it into the form of a fictional work is incredibly complicated. That's something that I don't think people can really appreciate until they've tried to do something like it. But I still found myself, at various times, reading through the book and wondering, asking myself questions that, I guess, say more about me than they do about anyone else. But it's, “Wow, she's at a company that is pretty much scapegoating her and blaming her for all of us. Why isn't she quitting? Why isn't she screaming at people? Why isn't she punching the boss right in their stupid, condescending face and storming out of the office?” And I'm wondering how much of that is my own challenges as far as how life goes, as well as how much of it is just there for, I guess, narrative devices. It needed to wind up being someone who would not storm out when push came to shove.Gene Kim: But yeah, I think she actually does the last of the third thing that you mentioned where she does slam the sheet of paper down and say, “Man, you said the outage is caused by a technical failure and a human error, and now you're telling me I'm the human error?” And just cannot believe that she's been put in that position. Yeah, so thanks to your feedback and the others, she actually does shop her resume around. And starts putting out feelers, because this is no longer feeling like the great place to work that attracted her, eight years prior. The reality is for most people, is that it's sometimes difficult to get a new job overnight, even if you want to. But I think that Maxine stays because she believes in the mission. She takes a great deal of pride of what she's created over the years, and I think like most great brands, they do create a sense of mission and there's a deep sense of the customers they serve. And, there's something very satisfying about the work to her. And yeah, I think she is very much, for a couple of weeks, very much always thinking about, she won't be here for long, one way or another, but by the time she stumbles into the rebellion, the crazy group of misfits, the ragtag bunch of misfits, who are trying to find better ways of working and willing to break whatever rules it takes to take over the very ancient powerful order, she falls in love with a group. She found a group of kindred spirits who very much, like her, believe that developer productivity is one of the most important things that we can do as an organization. So, by the time that she looks up with that group, I mean, I think she's all thoughts of leaving are gone.Corey Quinn: Right. And the idea of, if you stick around, you can theoretically change things for the better is extraordinarily compelling. The challenge I've seen is that as I navigate the world, I've met a number of very gifted employees who, frankly wind up demonstrating that same level of loyalty and same kind of loyalty to companies that are absolutely not worthy of them. So my question has always been, when do I stick around versus when do I leave? I'm very far on the bailout as early as humanly possible side of that spectrum. It's why I'm a great consultant but an absolutely terrible employee.Gene Kim: [laughing] Well, so we were honored to have you at the DevOps Enterprise Summit. And you've probably seen that The Unicorn Project book is really dedicated to the achievements of the DevOps Enterprise community. It's certainly inspired by and dedicated to their efforts. And I think what was so inspirational to me were all these courageous leaders who are—they know what the mission is. I mean, they viscerally understand what the mission is and understand that the ways of working aren't working so well and are doing whatever they can to create better ways of working that are safer, faster, and happier. And I think what is so magnificent about so many of their journeys is that their organization in response says, “Thank you. That's amazing. Can we put you in a position of even more authority that will allow you to even make a more material, more impactful contribution to the organization?” And so it's been my observation, having run the conference for, now, six years, going on seven years is that this is a population that is being out promoted—has been promoted at a rate far higher than the population at large. And so for me, that's just an incredible story of grit and determination. And so yeah, where does grit and determination becomes sort of blind loyalty? That's ultimately self-punishing? That's a deep question that I've never really studied. But I certainly do understand that there is a time when no amount of perseverance and grit will get from here to there, and that's a fact.Corey Quinn: I think that it's a really interesting narrative, just to see it, how it tends to evolve, but also, I guess, for lack of a better term, and please don't hold this against me, it seems in many ways to speak to a very academic perspective, and I don't mean that as an insult. Now, the real interesting question is why I would think, well—why would accusing someone of being academic ever be considered as an insult, but my academic career was fascinating. It feels like it aligns very well with The Five Ideals, which is something that you have been talking about significantly for a long time. And in an academic setting that seems to make sense, but I don't see it thought of or spoken of in the same way on the ground. So first, can you start off by giving us an intro to what The Five Ideals are, and I guess maybe disambiguate the theory from the practice?Gene Kim: Oh for sure, yeah. So The Five Ideals are— oh, let's go back one step. So The Phoenix Project had The Three Ways, which were the principles for which you can derive all the observed DevOps practices from and The Four Types of Work. And so in The Five Ideals I used the concept of The Five Ideals and they are—the first—Corey Quinn: And the next version of The Nine whatever you call them at that point, I'm sure. It's a geometric progression.Gene Kim: Right or actually, isn't it the pri—oh, no. four isn't, four isn't prime. Yeah, yeah, I don't know. So, The Five Ideals is a nice small number and it was just really meant to verbalize things that I thought were very important, things I just gravitate towards. One is Locality and Simplicity. And briefly, that's just, to what degree can teams do what they need to do independently without having to coordinate, communicate, prioritize, sequence, marshal, deconflict, with scores of other teams. The Second Ideal is what I think the outcomes are when you have that, which is Focus, Flow and Joy. And so, Dr. Mihaly Csikszentmihalyi, he describes flow as a state when we are so engrossed in the work we love that we lose track of time and even sense of self. And that's been very much my experience, coding ever since I learned Clojure, this functional programming language. Third Ideal is Improvement of Daily Work, which shows up in The Phoenix Project to say that improvement daily work is even more important than daily work itself. Fourth Ideal is Psychological Safety, which shows up in the State of DevOps Report, but showed up prominently in Google's Project Oxygen, and even in the Toyota production process where clearly it has to be—in order for someone to pull the andon cord that potentially stops the assembly line, you have to have an environment where it's psychologically safe to do so. And then Fifth Ideal is Customer Focus, really focus on core competencies that create enduring, durable business value that customers are willing to pay for, versus context, which is everything else. And yeah, to answer your question, Where did it come from? Why do I think it is important? Why do I focus on that? For me, it's really coming from the State of DevOps Report, that I did with Dr. Nicole Forsgren and Jez Humble. And so, beyond all the numbers and the metrics and the technical practices and the architectural practices and the cultural norms, for me, what that really tells the story of is of The Five Ideals, as to what one of them is very much a need for architecture that allows teams to work independently, having a higher predictor of even, continuous delivery. I love that. And that from the individual perspective, the ideal being, that allows us to focus on the work we want to do to help achieve the mission with a sense of flow and joy. And then really elevating the notion that greatness isn't free, we need to improve daily work, we have to make it psychologically safe to talk about problems. And then the last one really being, can we really unflinchingly look at the work we do on an everyday basis and ask, what the customers care about it? And if customers don't care about it, can we question whether that work really should be done or not. So that's where for me, it's really meant to speak to some more visceral emotions that were concretized and validated through the State of DevOps Report. But these notions I am just very attracted to.Corey Quinn: I like the idea of it. The question, of course, is always how to put these into daily practice. How do you take these from an idealized—well, let's not call it a textbook, but something very similar to that—and apply it to the I guess, uncontrolled chaos that is the day-to-day life of an awful lot of people in their daily jobs.Gene Kim: Yeah. Right. So, the protagonist is Maxine and her role in the story, in the beginning, is just to recognize what not great looks like. She's lived and created greatness for all of her career. And then she gets exiled to this terrible Phoenix project that chews up developers and spits them out and they leave these husks of people they used to be. And so, she's not doing a lot of problem-solving. Instead, it's this recoiling from the inability for people to do builds or do their own tests or be able to do work without having to open up 20 different tickets or not being able to do their own deploys. She just recoil from this spending five days watching people do code merges, and for me, I'm hoping that what this will do, and after people read the book, will see this all around them, hopefully, will have a similar kind of recoiling reaction where they say, “Oh my gosh, this is terrible. I should feel as bad about this as Maxine does, and then maybe even find my fellow rebels and see if we can create a pocket of greatness that can become like the sublimation event in Dr. Thomas Kuhn's book, The Structure of Scientific Revolutions.” Create that kernel of greatness, of which then greatness then finds itself surrounded by even more greatness.Corey Quinn: What I always found to be fascinating about your work is how you wind up tying so many different concepts together in ways you wouldn't necessarily expect. For example, when I was reviewing one of your manuscripts before this went to print, you did reject one of my suggestions, which was just, retitle the entire thing. Instead of calling it The Unicorn Project. Instead, call it Gene Kim's Love Letter to Functional Programming. So what is up with that?Gene Kim: Yeah, to put that into context, for 25 years or more, I've self-identified as an ops person. The Phoenix Project was really an ops book. And that was despite getting my graduate degree in compiler design and high-speed networking in 1995. And the reason why I gravitated towards ops, because that was my observation, that that's where the saves were made. It was ops who saved the customer from horrendous, terrible developers who just kept on putting things into production that would then blow up and take everyone with it. It was ops protecting us from the bad adversaries who were trying to steal data because security people were so ineffective. But four years ago, I learned a functional programming language called Clojure and, without a doubt, it reintroduced the joy of coding back into my life and now, in a good month, I spend half the time—in the ideal—writing, half the time hanging out with the best in the game, of which I would consider this to be a part of, and then 20% of time coding. And I find for the first time in my career, in over 30 years of coding, I can write something for years on end, without it collapsing in on itself, like a house of cards. And that is an amazing feeling, to say that maybe it wasn't my inability, or my lack of experience, or my lack of sensibilities, but maybe it was just that I was sort of using the wrong tool to think with. That comes from the French philosopher Claude Lévi-Strauss. He said of certain things, “Is it a good tool to think with?” And I just find functional programming is such a better tool to think with, that notions like composability, like immutability, what I find so exciting is that these things aren't just for programming languages. And some other programming languages that follow the same vein are, OCaml, Lisp, ML, Elixir, Haskell. These all languages that are sort of popularizing functional programming, but what I find so exciting is that we see it in infrastructure and operations, too. So Docker is fundamentally immutable. So if you want to change a container, we have to make a new one. Kubernetes composes these containers together at the level of system of systems. Kafka is amazing because it usually reveals the desire to have this immutable data model where you can't change the past. Version control is immutable. So, I think it's no surprise that as our systems get more and more complex and distributed, we're relying on things like immutability, just to make it so that we can reason about them. So, it is something I love addressing in the book, and it's something I decided to double down on after you mentioned it. I'm just saying, all kidding aside is this a book for—Corey Quinn: Oh good, I got to make it worse. Always excited when that happens.Gene Kim: Yeah, I mean, your suggestion really brought to the forefront a very critical decision, which was, is this a book for technology leaders, or even business leaders, or is this a book developers? And, after a lot of soul searching, I decided no, this is a book for developers, because I think the sensibilities that we need to instill and the awareness we need to create these things around are the developers and then you just hope and pray that the book will be good enough that if enough engineers like it, then engineering leaders will like it. And if enough engineering leaders like it, then maybe some business leaders will read it as well. So that's something I'm eagerly seeing what will happen as the weeks, months, and years go by. Corey Quinn: This episode is sponsored in part by DataStax. The NoSQL event of the year is DataStax Accelerate in San Diego this May from the 11th through the 13th. I've given a talk previously called the myth of multi-cloud, and it's time for me to revisit that with... A sequel! Which is funny given that it's a NoSQL conference, but there you have it. To learn more, visit datastax.com that's D-A-T-A-S-T-A-X.com and I hope to see you in San Diego. This May.Corey Quinn: One thing that I always admired about your writing is that you can start off trying to make a point about one particular aspect of things. And along the way you tie in so many different things, and the functional programming is just one aspect of this. At some point, by the end of it, I half expected you to just pick a fight over vi versus Emacs, just for the sheer joy you get in effectively drawing interesting and, I guess, shall we say, the right level of conflict into it, where it seems very clear that what you're talking about is something thing that has the potential to be transformative and by throwing things like that in you're, on some level, roping people in who otherwise wouldn't weigh in at all. But it's really neat to watch once you have people's attention, just almost in spite of what they want, you teach them something. I don't know if that's a fair accusation or not, but it's very much I'm left with the sense that what you're doing has definite impact and reverberations throughout larger industries.Gene Kim: Yeah, I hope so. In fact, just to reveal this kind of insecurity is, there's an author I've read a lot of and she actually read this blog post that she wrote about the worst novel to write, and she called it The Yeomans Tour of the Starship Enterprise. And she says, “The book begins like this: it's a Yeoman on the Starship Enterprise, and all he does is admire the dilithium crystals, and the phaser, and talk about the specifications of the engine room.” And I sometimes worry that that's what I've done in The Unicorn Project, but hopefully—I did want to have that technical detail there and share some things that I love about technology and the things I hate about technology, like YAML files, and integrate that into the narrative because I think it is important. And I would like to think that people reading it appreciate things like our mutual distaste of YAML files, that we've all struggled trying to escape spaces and file names inside of make files. I mean, these are the things that are puzzles we have to solve, but they're so far removed from the business problem we're trying to solve that really, the purpose of that was trying to show the mistake of solving puzzles in our daily work instead of solving real problems.Corey Quinn: One thing that I found was really a one-two punch, for me at least, was first I read and give feedback on the book and then relatively quickly thereafter, I found myself at my first DevOps Enterprise Summit, and I feel like on some level, I may have been misinterpreted when I was doing my live-tweeting/shitposting-with-style during a lot of the opening keynotes, and the rest, where I was focusing on how different of a conference it was. Unlike a typical DevOps Days or big cloud event, it wasn't a whole bunch of relatively recent software startups. There were serious institutions coming out to have conversations. We're talking USAA, we're talking to US Air Force, we're talking large banks, we're talking companies that have a 200-year history, where you don't get to just throw everything away and start over. These are companies that by and large, have, in many ways, felt excluded to some extent, from the modern discussions of, well, we're going to write some stuff late at night, and by the following morning, it's in production. You don't get to do that when you're a 200-year-old insurance company. And I feel like that was on some level interpreted as me making fun of startups for quote/unquote, “not being serious,” which was never my intention. It's just this was a different conversation series for a different audience who has vastly different constraints. And I found it incredibly compelling and I intend to go back.Gene Kim: Well, that's wonderful. And, in fact, we have plans for you, Mr. Quinn.Corey Quinn: Uh-oh.Gene Kim: Yeah. I think when I say I admire the DevOps Enterprise community. I mean that I'm just so many different dimensions. The fact that these, leaders and—it's not leaders just in terms of seniority on the organization chart—these are people who are leading technology efforts to survive and win in the marketplace. In organizations that have been around sometimes for centuries, Barclays Bank was founded in the year 1634. That predates the invention of paper cash. HMRC, the UK version of the IRS was founded in the year 1200. And, so there's probably no code that goes that far back, but there's certainly values and—Corey Quinn: Well, you'd like to hope not. Gene Kim: Yeah, right. You never know. But there are certainly values and traditions and maybe even processes that go back centuries. And so that's what's helped these organizations be successful. And here are a next generation of leaders, trying to make sure that these organizations see another century of greatness. So I think that's, in my mind, deeply admirable.Corey Quinn: Very much so. And my only concern was, I was just hoping that people didn't misinterpret my snark and sarcasm as aimed at, “Oh, look at these crappy—these companies are real companies and all those crappy SAS companies are just flashes in the pan.” No, I don't believe that members of the Fortune 500 are flash in the pan companies, with a couple notable exceptions who I will not name now, because I might want some of them on this podcast someday. The concern that I have is that everyone's work is valuable. Everyone's work is important. And what I'm seeing historically, and something that you've nailed, is a certain lack of stories that apply to some of those organizations that are, for lack of a better term, ossified into their current process model, where they there's no clear path for them to break into, quote/unquote, “doing the DevOps.”Gene Kim: Yeah. And the business frame and the imperative for it is incredible. Tesla is now offering auto insurance bundled into the car. Banks are now having to compete with Apple. I mean, it is just breathtaking to see how competitive the marketplaces and the need to understand the customer and deliver value to them quickly and to be able to experiment and innovate and out-innovate the competition. I don't think there's any business leader on the planet who doesn't understand that software is eating the world and they have to that any level of investment they do involves software at some level. And so the question is, for them, is how do they get educated enough to invest and manage and lead competently? So, to me it really is like the sleeping giant awakening. And it's my genuine belief is that the next 50 years, as much value as the tech giants have created: Facebook, Amazon, Netflix, Google, Microsoft, they've generated trillions of dollars of economic value. When we can get eighteen million developers, as productive as an engineer at a tech giant is, that will generate tens of trillions of dollars of economic value per year. And so, when you generate that much economic activity, all problems become solvable, you look at climate change, you take a look at the disparity between rich and poor. All things can be fixed when you significantly change the economic economy in this way. So, I'm extremely hopeful and I know that the need for things like DevOps are urgent and important.Corey Quinn: I guess that that's probably the best way of framing this. So you wrote one version that was aimed at operators back in 2013, this one was aimed at developers, and effectively retails and clarifies an awful lot of the same points. As a historical ops person, I didn't feel left behind by The Unicorn Project, despite not being its target market. So I guess the question on everyone's mind, are you planning on doing a third iteration, and if so, for what demographic?Gene Kim: Yeah, nothing at this point, but there is one thing that I'm interested in which is the role of business leaders. And Sarah is an interesting villain. One of my favorite pieces of feedback during the review process was, “I didn't think I could ever hate Sarah more. And yet, I did find her even to be more loathsome than before.” She's actually based on a real person, someone that I worked with.Corey Quinn: That's the best part, is these characters are relatable enough that everyone can map people they know onto various aspects of them, but can't ever disclose the entire list in public because that apparently has career consequences.Gene Kim: That's right. Yes, I will not say who the character is based on but there's, in the last scene of the book that went to print, Sarah has an interesting interaction with Maxine, where they meet for lunch. And, I think the line was, “And it wasn't what Maxine had thought, and she's actually looking forward to the next meeting.” I think that leaves room for it. So one of the things I want to do with some friends and colleagues is just understand, why does Sarah act the way she does? I think we've all worked with someone like her. And there are some that are genuinely bad actors, but I think a lot of them are doing something, based on genuine, real motives. And it would be fun, I thought, to do something with Elizabeth Henderson, who we decided to start having a conversation like, what does she read? What is her background? What is she good at? What does her resume look like? And what caused her to—who in technology treated her so badly that she treats technology so badly? And why does she behave the way she does? And so I think she reads a lot of strategy books. I think she is not a great people manager, I think she maybe has come from the mergers and acquisition route that viewed people as fungible. And yeah, I think she is definitely a creature of economics, was lured by an external investor, about how good it can be if you can extract value out of the company, squeeze every bit of—sweat every asset and sell the company for parts. So I would just love to have a better understanding of, when people say they work with someone like a Sarah, is there a commonality to that? And can we better understand Sarah so that we can both work with her and also, compete better against her, in our own organizations?Corey Quinn: I think that's probably a question best left for people to figure out on their own, in a circumstance where I can't possibly be blamed for it.Gene Kim: [laughing].That can be arranged, Mr. Quinn.Corey Quinn: All right. Well, if people want to learn more about your thoughts, ideas, feelings around these things, or of course to buy the book, where can they find you?Gene Kim: If you're interested in the ideas that are in The Unicorn Project, I would point you to all of the freely available videos on YouTube. Just Google DevOps Enterprise Summit and anything that's on the plenary stage are specifically chosen stories that very much informed The Unicorn Project. And the best way to reach me is probably on Twitter. I'm @RealGeneKim on Twitter, and feel free to just @ mention me, or DM me. Happy to be reached out in whatever way you can find me. Corey Quinn: You know where the hate mail goes then. Gene, thank you so much for taking the time to speak with me, I appreciate it.Gene Kim: And Corey, likewise, and again, thank you so much for your unflinching feedback on the book and I hope you see your fingerprints all over it and I'm just so delighted with the way it came out. So thanks to you, Corey. Corey Quinn: As soon as my signed copy shows up, you'll be the first to know.Gene Kim: Consider it done. Corey Quinn: Excellent, excellent. That's the trick, is to ask people for something in a scenario in which they cannot possibly say no. Gene Kim, multiple award-winning CTO, researcher, and author. Pick up his new book, The Wall Street Journal best-selling The Unicorn Project. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. If you hated this podcast, please leave a five-star review on Apple Podcasts and leave a compelling comment.Announcer: This has been this week's episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com or wherever fine snark is sold.This has been a HumblePod production. Stay humble.

The links referenced in this episode are:The PS Professional Certification: https://apmg-international.com/product/ps-professionalAPMG-International Website: https://apmg-international.com/The Company Doctor Podcast, and this is the most popular episode: https://podcasts.apple.com/gb/podcast/the-company-doctor/id1534721046?i=1000522983894The German speaking DevOps podcast "Auf die Ohren und ins Hirn”: https://podcasts.apple.com/de/podcast/devops-auf-die-ohren-und-ins-hirn/id1343760019FitSM Training: https://fitsm.onlineThe Phoenix Project (book): https://www.amazon.com.au/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

Andreas Creten is a software engineer and an entrepreneur who loves developing apps and building teams. He's the CEO of madewithlove, an app development company that helps startups and established companies turn ideas into applications by offering development, consulting and ad interim management services, building both products and teams. They have been CTO in over 60 companies, mainly operating as CTO ad interim. You can regularly find Andreas working on open-source projects and speaking at conferences around the world. in this episode we cover: 00:00 - https://byldd.com/ (Byldd - MVP Development Agency Based in New York) 01:12 - Intro 02:19 - Introducing Legacy Code 04:16 - Top Red Flags On The Due Diligence Process 08:50 - What Is Technical Debt And How They Work It 11:40 - Balancing Technical Debt & Product Development 15:24 - Scenarios Where Refactoring The Code Can Work 17:25 - Tools That Madewithlove Use To Ensure Code Quality 20:20 - Building The Perfect Engineering Team 23:24 - The App Development Process With madewithlove 28:35 - Madewithlove in Terms of Size Today 30:07 - Andreas' Favorite Activity To Get Into a Flow State 31:13 - Andreas' Piece of Advice for His 25 Years Old Self 32:51 - Andreas' Biggest Challenges at Madewithlove 34:06 - Instrumental Resources for Andreas' Success 36:54 - What Does Success Means for Andreas Today 38:07 - Get In Touch With Andreas Get In Touch With Andreas: https://www.linkedin.com/in/andreascreten/ (Andreas' LinkedIn) Mentions: https://basecamp.com/about/story (Jason Fried from Basecamp) Books: https://www.amazon.com.br/Getting-Real-Smarter-Successful-Application/dp/0578012812 (Getting Real by Jason Fried) https://www.amazon.com.br/Phoenix-Project-DevOps-Helping-Business/dp/1942788290 (The Phoenix Project by Gene Kim & Kevin Behr) Tag Us & Follow: https://www.facebook.com/SaaSDistrictPodcast/ (Facebook) https://www.linkedin.com/company/horizen-capital (LinkedIn) https://www.instagram.com/saasdistrict/ (Instagram) More About Akeel: https://twitter.com/AkeelJabber (Twitter) https://linkedin.com/in/akeel-jabbar (LinkedIn) https://horizencapital.com/saas-podcast/ (More SaaS Podcast Episodes) https://horizencapital.com/saas-consulting-services/ (SaaS Consultants) https://horizencapital.com/how-to-value-saas-business/ (Learn How to Value a SaaS Company)

The three reading recommendations referenced in today's episode were:Google: https://sre.google/booksThe Phoenix Project: https://www.amazon.com.au/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B09JWVXFNG/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=How Complex Systems Fail: https://how.complexsystems.fail/

Guest Bio: Mark Schwartz joined AWS as an Enterprise Strategist and Evangelist in July 2017. In this role, Mark works with enterprise technology executives to share experiences and strategies for how the cloud can help them increase speed and agility while devoting more of their resources to their customers. Mark has extensive experience as an IT leader in the government, private sector, and the nonprofit world, and with organizations ranging from startup to large. Prior to joining AWS, he was CIO of US Citizenship and Immigration Services (in the Department of Homeland Security), where he led a large digital transformation effort, moving the agency to the cloud, introducing and refining DevOps and Agile techniques, and adopting user-centric design approaches. From his work at USCIS, he developed a reputation for leading transformation in organizations that are resistant to change, obsessed with security, subject to considerable regulation and oversight, and deeply bureaucratic. Before USCIS, Mark was CIO of Intrax Cultural Exchange, a leader in global youth exchange programs, and CEO of a software company. Mark is the author of The Art of Business Value , A Seat at the Table: IT Leadership in the Age of Agility, War, Peace and IT and The Delicate Art of Bureaucracy. Mark speaks at conferences internationally on such subjects as DevOps, Leading Change, Driving Innovation in IT, and Managing Agility in Bureaucratic Organizations. He has been recognized as a Computerworld Premier IT Leader and received awards for Leadership in Technology Innovation, the Federal 100 IT Leaders, and a CIO Magazine 100 award. Mark has both a BS and MA degree from Yale University, and an MBA from Wharton.   Social Media/ Website: Mark's LinkedIn Profile: https://www.linkedin.com/in/innovativecio Mark's AWS Executive Insights page with links to all his blogs posts and books https://aws.amazon.com/ar/executive-insights/enterprise-strategists/mark-schwartz/  Books/ Resources: The Delicate Art of Bureaucracy: Digital Transformation with the Monkey, the Razor and the Sumo Wrestler by Mark Schwartz https://www.amazon.co.uk/Delicate-Art-Bureaucracy-Transformation-Wrestler-ebook/dp/B086XM4WCK/ The Art of Business Value by Mark Schwartz https://www.amazon.co.uk/Art-Business-Value-Mark-Schwartz/dp/1942788045 A Seat at the Table: IT Leadership in the Age of Agility by Mark Schwartz https://www.amazon.co.uk/Seat-Table-Leadership-Age-Agility/dp/1942788118/ War, Peace and IT: Business Leadership, Technology, and Success in the Digital Age by Mark Schwartz https://www.amazon.co.uk/War-Peace-Business-Leadership-Technology/dp/1942788711 Reaching Cloud Velocity: A Leader's Guide to Success in the AWS Cloud by Jonathan Allen et al https://www.amazon.co.uk/Reaching-Cloud-Velocity-Leaders-Success/dp/B086PTDP51 Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT by Stephen Orban https://www.amazon.co.uk/Ahead-Cloud-Practices-Navigating-Enterprise-ebook/dp/B07BYQTGJ7 Engineers of Victory: The Problem Solvers Who Turned the Tide in the Second World War by Paul Kennedy https://www.amazon.co.uk/Engineers-Victory-Problem-Solvers-Turned-ebook/dp/B00ADNPCC0 The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim https://www.amazon.co.uk/Phoenix-Project-Devops-Helping-Business/dp/1942788290/ The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data by Gene Kim https://www.amazon.co.uk/Unicorn-Project-Disruption-Redshirts-Overthrowing/dp/1942788762   Interview Transcript Ula Ojiaku:  Mark, thank you so much for making the time for this conversation. Mark Schwartz: Thank you, my pleasure. Ula Ojiaku: Great. Now let's start with you know, the question I usually ask my guests: who's Mark? What makes him tick? Mark Schwartz:  And they can answer that question. It's not a hard one. where to start? Um, you know, I always enjoy my work. That's a thing about me. I like to think that people have fun working with me because I tend to laugh a lot. And even you know, when the work is boring, I find ways to make it interesting. I just enjoy doing things and accomplishing things. I think if we're going to talk about my books, and some of the things I've done later, an important thing to realize is that, I started out, you know, when I went, when I was in high school, when I went to college, I was pretty sure I wanted to study computer science and get involved with these computer things. But when I was actually studying, I realized there were all these other interesting areas, I'm just, you know, endlessly curious. And so, I wound up studying all kinds of other things, in addition. And the result was that when I finished college, I decided to go to graduate school in philosophy. And I spent a few years getting a master's degree in philosophy. And the fact that I'm curious about so many things and read so many different things, I think it enters into a lot of what I do. I like to pull analogies from non-IT related fields and, and, and I'll call upon all the things I've learned in all sorts of different areas, as I'm writing and speaking and working. Ula Ojiaku:  It shines through in your book, definitely. Mark Schwartz:  Yes, I think it does. That's partly an explanation for what you see in my books. I think, um, you know, I sometimes say that I have trouble reading business books generally. Because I kind of find them boring. They tend to make the same point over and over again, and to be very just so one directional, you know, just on the same subject, and it's a little bit odd because in every other subject, the books tend to refer to other books in other fields and there's this extra dimension and that helps you understand what the author is getting at. But in business books, they, you know, aside from having a quote now and then from a famous leader or something, they don't tend to do that, they don't, they don't sort of call upon the whole history of literature and writing. And so, I have a little bit of fun in writing my books in trying to see if I can add an extra dimension just by reference and by bringing in other things that are a little bit orthogonal to the subject matter. Ula Ojiaku:  And that kind of, you know, brings home the point that life isn't black and white. It's actually a complex or a complex kind of, you know, maze and of different disciplines, different ideologies and different viewpoints that make it what it is really. Mark Schwartz:  Yeah well, of course, that was part of the fun of my recent book on Bureaucracy. You know, because I know we all, we want to throw up when we encounter bureaucracy, you know, it disturbs us in so many ways. And one of the things I wanted to say in the book is, well, actually bureaucracy is all around you all the time in unexpected places and it usually doesn't drive you crazy, actually. Yeah... Ula Ojiaku:  Well, I have a lot of questions for you on your book, The Delicate Art of Bureaucracy, which is a catchy, catchy title on its own, very clever. But before we get to that, what do you do when you're not working? I know, you said you love work and you've also said that you're curious about so many things, which means that you read broadly - that's my interpretation. So, what do you do when you're not ‘working'? Mark Schwartz:  Yes, I read broadly, is one thing. In the past, I played the guitar a lot. And I don't quite as much lately. I don't know why, you know, I'll start doing it again. I'm sure at some point. But while I was living in San Francisco, I was actually playing in bars and coffee shops, I have a singer, who I performed with. Ula Ojiaku: Really? Wow! Mark Schwartz: And that was really fun. And then the other thing I do is travel, I've really traveled a lot. And, yeah, there was one period in my life where for about five years, I was bumming around the world with a backpack with you know, occasional returns to the States to work a little bit and make some money and then go traveling again. So, one of the joys of my current job is that, I get to do a lot of traveling to interesting places. Ula Ojiaku:  So, where would you say is your ideal getaway destination? Mark Schwartz:  Oh, let's see. I'm a big fan of Brazil. That, I have good friends there and it's really nice to see them and the atmosphere is always kind of fun there. Ula Ojiaku: Okay. Mark Schwartz: I don't know what I've discovered so many places around the world that I've really loved being. I lived in Japan for a year and that is a place that I love to go to, especially for the food. Yeah, I like good food. But I don't know I've found so many places that made me feel like I'd like to spend more time there. And of course, you can't really spend more time everywhere. Ula Ojiaku:  Interesting. So, let's, let's go to your book, “The Art of Delicate Bureaucracy”. What was the inspiration behind that book? Mark Schwartz:  Well, for all of my books, before I wrote, before I wrote them, I was thinking, ‘why hasn't anybody else written a book on this topic?' People don't write books on bureaucracy, at least not, you know, popular books, there are academic books on bureaucracy. And the same thing happened to me with my first book, “The Art of Business Value”, where I said to myself, we keep talking about business value in the IT world, like, is it obvious what it means? You know, what, why isn't anybody writing a book about what business value means? So, bureaucracy is one of those things. I have a lot of experience with it first of all, I was a CIO in a government agency. But it turns out, it's not just the government, whenever I tell people about my government experience, when I speak at a conference, people come up to me afterwards and say, ‘Oh, my company's just like that. I work for a financial services company; we have lots of bureaucracy'. And I work with a lot of people who are trying to pull off some sort of digital transformation, which is change on a big scale, that's changing traditional organizations on a big scale. And bureaucracy is always in their way because bureaucracy tends to resist change; it strongly tends to resist change. So, if you're doing a big change, then you're probably going to come up against it. So, I thought maybe with my experience as a bureaucrat, or at least experience in the big bureaucracy, I could give some pointers to people who are trying to cause big change, and yet are facing bureaucratic obstacles. And I can't imagine that there's any organization, at least any large organization that does not have bureaucratic obstacles to digital transformation. So, that got me started on it. And then as I started to think about bureaucracy and research it, I realized this is actually a really interesting topic. Ula Ojiaku:  You had an interesting introduction to the book. You said, “we are bureaucrats all.” Why that claim, you actually were saying, everyone is a bureaucrat, and I know you made a statement that's similar to that earlier on in this conversation - why? Mark Schwartz:  Well, of course, I have to define in the book, what I mean by bureaucracy and all that. And I follow the generally what's accepted as the academic definition. It mostly comes from the sociologist Max Vabre, who is writing around 1920. And, and he talks a lot about bureaucracy, and it's fairly complicated, but I simplify it in the book. Basically, what it comes down to is a bureaucracy is a way of organizing socially, that has rigid formal roles for people and rigid formal rules. And that's the essence of it. You know, bureaucracy, there are rules and they have to be applied uniformly to everybody. And there's a division of labor and you know, a hierarchy. So, it has rigid roles of people who have to sign off on things and approve things. So, with that is the definition. I think it, it connects with the very human tendency to try to structure things and constantly improve them and optimize them. So, if you find a good way of doing something, you tend to turn it into a rule, you know, this is the way it should be done from now on. Ula Ojiaku: Best practice! Mark Schwartz: It's the best practice. Yeah, yeah, exactly. And also, we, in, social organization, we'd like people to be accountable or responsible for things. And we know that you can't hold somebody accountable unless they have authority to perform their role. So, when you put those things together, it's very natural for us to set up these organizational systems, where we assign roles to people, and give them authority, and we make rules that encapsulate the best way to do things. And, essentially, that's bureaucracy. So, bureaucracy, I find, is everywhere around us in one form or another. But it doesn't drive us crazy most of the time, so we don't notice it. Ula Ojiaku:  Maybe if it's serving us, then we wouldn't notice it. But… Mark Schwartz:  It does serve. And if you look at the cases where it does drive us crazy, they have certain things in common. And in the book, I say there are three characteristics that bureaucracies often take on which they don't need to, it's not part of the definition of bureaucracy, but they often take on these characteristics. And it's those three characteristics that are what drive us crazy. And so, the goal, ultimately is to eliminate those three characteristics or turn them into something else. Ula Ojiaku: I know that the listeners would be curious to know what the three characteristics of bureaucracy that drive us crazy are? Is that so or should I just tell them go buy the book? Mark Schwartz: Yeah, go buy the book! Well, let me tell you the three characteristics, and also their opposite, which is what we really want. So, the first characteristic that drives us crazy, I think, is that bureaucracies tend to be bloated instead of lean, that would be the opposite in my view. There's no reason why a bureaucracy has to be bloated and wasteful. It could be lean, but it's one of those things that bureaucracy tends to become. So that's the first one. The second one is that bureaucracies tend to petrify, as opposed to learning. So, when I say petrifies, I mean that the rules and the bureaucracy don't change, or don't change as often as they should, or don't change continuously, which is really what rules should do. Now, that's not necessarily a characteristic of bureaucracy, but the definition, the definition says the rules have to be applied rigorously. You know, once you have a rule, everybody has to follow it. But it doesn't say that the rules have to stay the same forever, they can change. The opposite of a petrified bureaucracy is a learning bureaucracy, where the rules are constantly adjusted, based on what the people in the organization learn. And there are plenty of good examples of learning bureaucracies out there. And your goal is to transform the one into the other, the petrified into the learning. The third is, bureaucracies tend to be coercive, rather than enabling. Coercive, meaning that they're there to control employee behavior, to force employees to behave in ways that otherwise they wouldn't want to. They tend to be ‘no' saying, they say ‘no', a lot. Your bureaucracy for your expense reporting policy in your company probably says, ‘no that expense is no good because X Y and Z.' There are plenty of examples of enabling bureaucracies, where the point is not to stop you from doing things or force you to do something you don't want to. But the bureaucracy provides a support structure, provide best practices, as you said, that help you do your job well. And there's no reason why bureaucracies can't do that. So, the three bad characteristics are bloat, coercion, and petrify. Ula Ojiaku: Okay, nice. So, it sounds like the way you've described bureaucracy, when you look at it from a positive slant, would it be the same thing as guardrails, putting guardrails in place, or giving people the right degree of freedom? Mark Schwartz: Yeah, that's exactly the idea. What I find is that guardrails and automation are ways of implementing bureaucracy, that lead to those three good characteristics rather than the bad ones. Let's say in software development, in DevOps, for example, it's a good idea to put guardrails, security guardrails, for example, around what people can do, and automated security tests and things like that. Because then the developers or the DevOps teams, they can go charging ahead full speed, knowing that they can't do anything wrong, you know, because the guardrails are there. And they get immediate feedback, if they do something that's going to put them outside the guardrails and they can just immediately fix it. So, it's very empowering for them, lets them move fast. And it also gets rid of that coercive element of you know, I write some code and then somebody comes in afterwards and says, ‘no, you can't deploy that'. That's annoying. Instead, I can run the security tests myself, as a developer, see if there's anything that's problematic, fix it right away if I want to, so it's all under my control. But the end result is still the same. The bureaucracy is still there. It's just automated and implemented as guardrails. Ula Ojiaku:  It's enabling, like you said before, instead of hindering. Mark Schwartz:  And it's lean, because it's very inefficient and wasteful, if you write some code, and then at the very end of the development process, somebody finds a security flaw. And now you have to remember what you were doing. And, you know, go back and relearn your code and make changes then, so that's wasteful, as opposed to lean. It's coercive, as opposed to enabling. And if you're good at doing these things, then you keep updating your guardrails and your security tests based on new security threats you learn about or new policies or whatever. So, you make a learning bureaucracy as well. Ula Ojiaku:  Interesting. In the book as well, you said you want us to be calm, chaos monkeys, knights of Ockham, lean sumo wrestlers, very interesting oxymoron there. And you know, black belt experts, could you tell us more about those terms? Why did you use those terms? Mark Schwartz:  Because they made me laugh of course. Ula Ojiaku: Well, they made me laugh too. Mark Schwartz: So, I thought about what I learned about coping with bureaucracy, especially in my government job, but also from reading and from talking to other people. And I realized I had about, you know, 30 techniques for coping with bureaucracy, I call them plays. And I just grabbed those 30 techniques, but I thought about it, and I realized they divided into three. And the three, I could sort of associate with a personality, almost. You know, that these 10 plays are associated with this personality, these 10 plays are associated with this one. And I came up with these three personalities that I thought describe those plays. And the three personalities are the monkey, and the razor, and the sumo wrestler. And, you know, I think, I could stop right there, because it's probably obvious why I associate those with these plays, but I will go a little further. Ula Ojiaku: Please… Mark Schwartz: So, I realized that some of the things we did, the ones that I call the plays of the monkey, the way of the monkey, those things had to do with provoking. You know, monkeys are mischievous, provocative, and sometimes annoying. And a bunch of the techniques had to do with trying to be provocative. And the razor and I'll give you some examples in a minute. The razor, to me is all about being lean. It's about trimming away waste. And it also refers to the philosophical principle of Ockham's razor. Ockham was a medieval philosopher, right, William of Ockham. And he's generally credited with an idea that something like if you have a choice between a simple explanation, and a complicated explanation, you should prefer the simple one. That's not really what he said. But that's, that's what most people associated with him. That's the principle of Ockham's razor. And, and so it's called a principle of ontological parsimony, meaning, you shouldn't presuppose the existence of more things than you need to, in order to explain something. So, you know, don't make up nymphs. And you know, I don't know, water dryads and whatever's to explain something that you can equally just explain through simple physical laws. Ula Ojiaku:  Just saying, 'keep it simple...' Mark Schwartz:  Yeah, keep it simple, in a way, right? So that's called the principle of ontological parsimony. And I said, there's a similar principle of bureaucratic parsimony, which says that if you're trying to implement a control, and you can do it in a simple way, or you could do it in a really complicated way, do it a simple way. And so, it's a principle of leanness because I find that bureaucracies, when they get bloated, they have these really complicated wasteful ways of doing something that they could they could accomplish exactly the same thing, but in a simpler way. So that's the razor. And then a sumo wrestler. Well, Sumo is the sport where, you know, two massive people sort of bang into each other, right? And the goal is you want to push your opponent out of the ring, or you want to make them fall and touch the ground with something other than their feet. And if you can do either of those things, you win. So, if you're a big massive person and you're trying to accomplish those things, you might think that the best thing to do is charge your opponent and push really hard. But if your opponent then just either dodges or just is soft and lets you push, well, you're probably going to go flying out of the ring, right? So, one of the principles in Sumo is you want to use your opponent's strength against them. And if they push hard, now, go ahead, give them a little pull. And, you know, let them push even harder. And I realized that some of these techniques for overcoming bureaucracy have to do with using bureaucracy actually, on your side, you know, the using the strength of bureaucracy against it. So that's why the sumo wrestler. So, I'll give you examples now on each one, now that I've described my three personalities. So, the monkey does what is sometimes referred to as provoking and inspecting or provoking and observing, in parallel with the Agile principle of inspect and adapt. So, provoke and observe, what the monkey does is try something that's probably outside the rules, or at least is, you know, a borderline and watches what happens. So, an example where we use this is that we have these rules in Homeland Security that essentially said, if you were going to do an IT project, you have to produce 87 documents. And each document had a template, and you have to fill in each section of the template. And these documents would run to hundreds of pages. And so, using the persona of the monkey, let's say, we started to turn in these documents. But in each section of the template, we just wrote a one sentence, one sentence answer, you know, we're very short answer instead of writing pages and pages. And we wanted to see what would happen if we did that, because there was no rule that said, it had to be a really long answer. And eventually, we started to provoke even more, we just left out sections that we thought didn't make any sense for what we were doing. And all of this was unprecedented, you know, it caused a lot of fear. It turned out, and this sometimes happens, that the enforcers of this policy, they were happy when they said, “We've never wanted anybody to write these really long answers to these things, we have to read them. And you know, the intention wasn't to slow people down. As long as you're giving us the right information. That's all we need.” So, in this case, provoking just it turned out that we could defeat a bunch of bureaucracy there, we could, we could make things a lot leaner because nobody objected. But sometimes people do object. And if they do, then you learn exactly what the resistance is, who it is, is resisting, and that gives you valuable information, when you're trying to figure out how to overcome it. So that's the monkey. You know, let's try something a little playful and mischievous, and see what happens. The razor, well, that one follows also on my 87 documents, because we then set up an alternative way of doing things that had only 15 documents. And where there had been 13 gate reviews required for each project. We reduced it to two. And so, all we did, you know, we just used our little razor to trim away all the excess stuff that was in the bureaucratic requirements. And then we showed people that those 15 documents and those two gate reviews accomplished exactly the same thing as the 87 documents and the 13 gate reviews. That's the principle of the razor, that's how the razor works. The sumo wrestler, also a favorite of mine. So, we were trying to convince the bureaucracy to let us do DevOps and to be agile, and it was resisting. And people kept pointing to a policy that said, you can't do these things. And so, we wrote our own policy. And it was a very good bureaucratic policy looked exactly like every bureaucratic document out there. But it essentially said you must use DevOps and you must be agile on it, you know, it set up a perfect bureaucracy around that it's set up ways of checking to make sure everybody was using DevOps. And the theory behind it was the auditors when they came to audit us and said we were being naughty because we were doing DevOps. Their argument was we looked at the policy and we looked at what you're doing, and they were different. And that's the way auditing works. That was the, you know, GAO, the Government Accountability Office, and the Inspector General and all that. So, we figured if we had a policy that said you must do DevOps, and they audited us, well, they would actually be enforcing the policy, you know, they'd be criticizing any part of the organization that was not using DevOps and I thought that's great. So, this is how you use the strength of the bureaucracy against the bureaucracy or not really, against even, you know, it's perfectly good, perfect… Ula Ojiaku:  To help the bureaucracy yeah, to help them to improve, improve the organization. But thinking about the monkey though, being provocative and mischievous, do you think that there has to be an element of you know, relationship and trust in place first, before… you can't just you know… you're new, and you've just gotten through the door and you start being a monkey… you probably will be taken back to wherever you came from! What do you think? Mark Schwartz:  Well, it helps if you're giggling while you do it. But you know, I think the goal here is to figure out the right levers that are going to move things. And sometimes you do have to push a little bit hard, you know, you do need to take people out of their comfort zone. Usually, you want to do these things in a way that takes into account people's feelings, and you know, is likely to move them in the right direction, rather than making them dig in their heels. But I'll give you a couple of examples of Monkey tactics that are less comfortable for people. One is simply, you know, there's a status quo bias. It's a known, well-known cognitive bias; people tend to prefer the status quo or look the other way about it's failings and stuff. So often, when you're trying to make a change, people say, we're fine the way we are, you know, everything's okay. So, one of the things the monkey tries to do is, is to make it clear that the status quo is not acceptable, you know, to show people that it actually if they think about it, it's no good. And so, for example, when we decided to move to the cloud, instead of working in our DHS data center, people said - of course at the time it was a big concern, ‘was the cloud secure enough?' And in the persona of the monkey, the right response is, ‘are we secure enough now?' You know, ‘don't you realize that we're not happy with our security posture today?' ‘It's not like, the cloud has proved itself. I mean, we have to compare our security in the cloud versus our security in the data center. And yes, I'm very sure it'll be better in the cloud and here's why…' But you can't start from the assumption that you are fine right now. In general, when we're talking about the cloud, that's the situation. Companies are using their own data centers. And it's like, you know, we have to teach them that they can do better in the cloud. But the truth is that they're not happy in their own data centers, if they think about it, right? There are security issues, there are performance issues, there are cost issues. And they're aware of those issues, right, they just look the other way. And because they're comfortable with the status quo, so the monkey has to sort of shake people up and say, ‘It's not okay, what you're doing now!' Another example, and this is really harsh, and I wouldn't use it in most cases. But let's say that this was in Homeland Security. Let's say that Homeland Security is enforcing a very bureaucratic process that results in IT projects, taking five years instead of six months. And let's say, you know, the process is there on paper, the rules say, ‘Do this', the people are interpreting the rules in a way that makes things take five years. Sometimes, the monkey has to go to somebody who's in their way and say, ‘We are in the Department of Homeland Security, this IT project is going to make people more secure in the homeland. Are you comfortable with the fact that you are preventing people from being more secure for the next four and a half years, when we could…' You know, it's a matter of personalizing it. And that sometimes is what's necessary to get people to start thinking creatively about how they can change the bureaucracy. You know, ‘I hate to say it, but you're a murderer', you know, essentially is the message. It's a monkey message. And like I said, you know, it's not the preferred way to go about doing things. But if you have to, I mean, the lives of people are at stake, and you've got to find a way to get there. Ula Ojiaku:  So how can leaders because your book, The Art of Business Value, in your book, you said that “leaders create the language of the organization, and they set up incentives and define value in a way that elicits desired outcomes.” So, in essence, I understand that statement to mean that leaders set the tone, and you know, kind of create the environment for things to happen. So, how can leaders implement or apply bureaucracy in a way that enables an organization where, before it was seen as a hindrance, how can they do this? Mark Schwartz:  My thought process was, if we all agree, we're gonna try to maximize business value? How do we know what we mean by it? And I realized, a lot of Agile people, you know, people in our Agile and DevOps community, were being a little bit lazy. You know, they were thinking, ‘Oh, business value, you know, it's returns on investment, or, you know, it's up to the business (to define) what's business value.' The tech people just, you know, do the work of providing a solution. And to me, that's too lazy. If you're going to be agile, be it you have to be more proactive about making sure you're delivering business value. So, you have to understand what it means. You have to actually do the work of, you know, figuring out what it means. And what it means is not at all obvious. And, you know, you might think it has something to do with return on investment or shareholder value or something like that. But when you really closely examine it, that is not the right way to define it, when it comes to deciding what its efforts to prioritize and all that that's, you know, the case that the book makes, and I explain why that's true. Instead, I say you have to think of business value within the context of the business's strategy and its objectives as a business. There's no like, abstract, this has more business value than this because we calculated an ROI or something like that, that doesn't work reprioritizing. It's always asked within the context of a particular business strategy. And the business strategy is a direction from leadership. There might be input from everybody else, but ultimately, you have leaders in the organization who are deciding what the strategic objectives are. So, for example, if you are a traditional bank, or traditional financial services company, and you look around you and you see there are all these new FinTech companies that are disrupting the industry, and you're worried, well there are a lot of different ways you can respond to those disruptive FinTechs. And how you're going to choose to respond depends on your preferences, it depends on the situation of your company, in the industry, the history of your company, all of those things. But of the many ways you can respond to that disruption, you're going to choose one as the leader of your enterprise. Well, what adds business value is whatever supports that direction you choose to go. You can't think of business value outside of that direction, you know. That's the case that I make. So, leaders don't just set the tone and the culture there, they're actually setting strategic direction that determines what has business value. And then the people who are executing the agile teams have to take it upon themselves to make sure that whatever they're doing is going to add business value in that sense.   So, the role of leadership then becomes direction setting and visioning for the future and communicating the vision to the people who are working and providing feedback, you know, on whether things are actually adding business value or not . And that's the key responsibility. Now, in order to do that, in order to motivate people to deliver according to that idea of business value, there are certain techniques as a leader that you have to keep in mind, there are ways that you get people, you get a big organization to sort of follow you. And one of the ones that's become most important to me to think about after talking to a lot of leaders about how they're running their organizations, and what's working, is using middle management as a lever for accomplishing those things. So often, I'll talk to leaders of a business, and they'll say, our problem is the frozen middle, middle management is, you know, they're just not changing the way we want, we want to, we want to cause a big transformation, but middle management is getting in the way. And I tell them, ‘that's pretty much a myth.' You know, ‘that's not actually what's happening, let's look more closely at your organization.' Almost always, middle management is still trying to do the best they can, given the situation that they're in. And the way that you get them to align themselves behind the change is, you change their incentives or their role definition, or how you tell them what you're expecting from them, you don't say “change”, you know, and start doing X and Y, you change what success looks like for their position. And then they adapt to it by becoming engaged and finding ways to get there. So, there's almost always a leadership problem when you have that frozen middle effect. And, and I've seen it work really well that, you know, all of a sudden, you get this big leverage, because you just do a little bit of tweaking of role definitions, and bring everybody into solving the problem. And actually, there's an example, I love to talk about a history book, like I said before, I like to bring in other things, right? It's called the Engineers of Victory. And it's about World War Two, the Allies realized that they had to solve a set of problems, I think there was six or so problems. One of them was how do you land troops on a beach that's heavily defended? They realize they were just not going to be able to win the war until they could do that. But nobody knew how to do it. Because, you know, obviously, the bad guys are there on the beach, they're dug in, they put barbed wire everywhere, and mines, and you know, all this stuff. And it's just going to be a slaughter if you try to land on the beach. So, this book, Engineers of Victory, makes the case that what really won the war, was figuring out those solutions. And who was responsible for figuring out those solutions? It was middle management, basically. It was the, you know, within the structure of the army, it was the people not at the top who had big authority, you know, the generals, and it was not the troops themselves, because they weren't in a position to figure out these things. It was middle management that could see across different parts of the organization that could try things and see whether they worked or not, that, you know, essentially could run their own mini skunkworks projects. And eventually, they came up with the solutions to these problems. So, I think that's very encouraging for the role of middle management, you know, that a lot of problems have to be solved at that layer in order to pull off a transformation. And it really can be done. And this is a beautiful example of it. Ula Ojiaku:  It reminds me of, you know, my experience in a few transformation initiatives. So, the middle, the people who are termed to be in the frozen middle, are, like you said, they want to do what's best for the company, and they show up wanting to do their best work, but it's really about finding out, ‘Where do I fit in, (with) all this change that's happening?' You know, ‘if my role is going away, if the teams are going to be more empowered, that means I'm not telling them what to do, but then what do I do now?' So, the clarity of what the ‘New World' means for them, and what's in it for them, would help, you know, make them more effective. Mark Schwartz: And the mistake that's often made is to say to them, ‘start doing DevOps' or, you know, ‘start doing agile or something.' Because if you don't change the definition of success, or you don't change the incentives that, you know, then it's just, make work and they're going to resist it. You know, if you say your incentive is to get really fast feedback or you know, one of the other goals of DevOps, because of the following reasons, it helps the business this way, so let's try to reduce cycle time as much as possible for producing software. Okay, that's a change in the incentive, or the, you know, the definition of success, rather than just telling somebody you have to do DevOps, you know, read a book and figure it out. Ula Ojiaku:  So, what other books because you mentioned the Engineers of Victory, are there any other books you would recommend for the listener to go check out if they wanted to learn more about what we've talked about today? Mark Schwartz:  Well, I think, you know, obviously, my books referred to War and Peace by Tolstoy, Moby Dick, another great one. You know, you probably need to read my books to figure out why those are the right books to read and Engineers of Victory. As I said, I think that one's a great one. Within the field, there are some DevOps books that that I like a lot, of course, Gene Kim's books, The Phoenix Project, and now The Unicorn Project, the sequel to that. Because those are books that give you a feel for the motivation behind all the things that we do. The Mechanics of Things, there are plenty of books out there that help you learn the mechanics of how to do continuous integration and continuous delivery. And then the cloud is I think it's really transformative. You know, it's the cloud itself is a tremendous enabler. I work at AWS, of course but I'm not saying this because I work at AWS, it's more than I work at AWS because I believe these things. And my teammates have written some good books on the cloud. Reaching Cloud Velocity, for example, by Jonathan Allen and Thomas Blood is a great one for reading up on how the cloud can be transformative. But my other teammates, Gregor Hope, has written a number of books that are really good, Stephen Orban did A Head in the Cloud. So, I think those are all… should be at the top of people's reading lists. And then, of course, I recommend my books, because they make me laugh, and they might make you laugh, too. Ula Ojiaku:  Definitely made me laugh, but they've also given me things to think about from a new perspective. So, I totally agree. And so, where can people find you if they want to reach out to you? Mark Schwartz:  Yeah, LinkedIn is a great place to find me. If you're with a company that is an AWS customer, feel free to talk to your account manager, the sales team from AWS and ask them to put you in touch with me, is another easy way. LinkedIn is kind of where I organize my world from so find me there. Ula Ojiaku:  Okay. Sounds great. And any final words for the audience or for the listeners. Mark Schwartz:  Um, I, I have found that these things that you want to do to take advantage of the digital world, and I think we're all sort of pointing ourselves in that direction, there are these amazing things you can do in the digital world. They're sometimes challenging to get there, but it's very possible to get there. And one thing I've learned a lot at Amazon is the idea of working backwards, you know, you get that picture in your head for where you want to be and then you say to yourself, ‘I can get there. Let me work backwards and figure out what I have to do in order to get there.' And you might be wrong, you know, you should test hypotheses, you start moving in the right direction, and of course, correct as you need to. But you can do it with confidence that others are doing it and you can too no matter what your organization is, no matter how much you think you're a snowflake and you know different from every other organization. You can still do it. And with just some good intention and good thinking you can figure out how to how to get there. Ula Ojiaku:  Thank you so much, Mark. That was a great close for this conversation and again, I really appreciate your making the time for this interview. Thank you. Mark Schwartz: Thanks for having me. Ula Ojiaku: You're welcome.

In this episode, Richard talks to Scott Riley, founder of Cloud Nexus. They're a UK based consultancy that provides advice and strategy on technology solutions for small and medium sized businesses.  They chat about what Cloud Nexus offers, why they decided to niche down into providing Office 365 and Azure solutions, and how the business has had exceptional growth in the last two years. They talk about the Cloud Nexus sales process and the mistakes MSPs (managed service providers) make when selling their services. Scott explains the power of niching and the benefits of collaborating, and the future of RMM and of vendors.  They also explore why MSPs should give away helpful information for free, how to use social media to generate leads and why YouTube is a great resource to tap into. And Scott reveals the industries where cloud storage isn't the answer.  Scott also shares the people who've influenced him, from authors and content marketers to other IT experts and business coaches. And he explains why having an apprentice allowed him to grow Cloud Nexus and be consistent with content creation. Mentioned in This Episode Pax8 https://www.youtube.com/watch?v=NVSw5ZYgQzw (video tour) with Tom Welton Book: Bob Burg – https://www.amazon.co.uk/Go-Giver-Little-Story-Powerful-Business/dp/0241976278/ref=sr_1_2?dchild=1&keywords=bob+burg&qid=1626799176&s=books&sr=1-2 (The Go Giver) Podcast interview with https://www.tubblog.co.uk/podcasts/how-an-msp-can-thrive-in-the-security-niche-tubbtalk-33/ (Norb Doeberlein) of Netzbahn IT Business Coach https://www.petematheson.co.uk/ (Pete Matheson) Soft skills training: https://helpdeskhabits.com/ (Helpdesk Habits) Book: Michael E Gerber: https://www.amazon.co.uk/Myth-Revisited-Small-Businesses-About-ebook/dp/B000RO9VJK/ref=sr_1_1?dchild=1&keywords=the+emyth&qid=1626799296&s=books&sr=1-1 (The Emyth Revisited) Book: Gene Kim: https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B078Y98RG8/ref=sr_1_1?crid=2DTI96AMARBI6&dchild=1&keywords=the+phoenix+project&qid=1626799318&s=books&sprefix=the+phoenix%2Cstripbooks%2C257&sr=1-1 (The Phoenix Project) Book: Marcus Sheridan: https://www.amazon.co.uk/They-Ask-You-Answer-Revolutionary-ebook/dp/B07VVH94ZF/ref=sr_1_1?crid=1QC3I5ED7ZMIT&dchild=1&keywords=marcus+sheridan+they+ask+you+answer+book&qid=1626799347&s=books&sprefix=marcus+sheridan%2Cstripbooks%2C205&sr=1-1 (They Ask , You Answer) Personal inspiration: Ade Cheatham at https://cooperparry.com/ (Cooper Parry) Accountants Visit the Cloud Nexus website or email Scott directly: scottr@cloudnexus.co.uk You can also find the https://www.linkedin.com/company/cloudnexus/ (business )and Scott on LinkedIn. And you can also check out the videos on YouTube.

In this show I get to talk with Jessica about the breaking down of tribal knowledge through chaos engineering,  her favourite tools, culture change and I discover that kubernetes and cloud native infused gardening might soon be a "thing".  About Jessica CherrySRE IIEvangelist of silo prevention in the IT space, the importance of information sharing with all teams. Believer in educating all and open source development. Lover of all things tech.Follow Jessica Cherry on Twitter @alynderthered1Important links----https://www.oreilly.com/library/view/seeking-sre/9781491978856/https://github.com/dastergon/awesome-chaos-engineeringhttps://opensource.com/users/cherrybombhttps://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHOSlide deck: https://docs.google.com/presentation/d/15JmmOx9KneE79md2WMRn3uS5spRft3iNzw3xcvvirwc/edit?usp=sharingTools!Chaoskube: https://github.com/linki/chaoskubelitmus: https://litmuschaos.io/kubeinvaders: https://github.com/lucky-sideburn/KubeInvaderschaosmesh: https://chaos-mesh.org/ 

Caterpillar Financial Services Corporation Chief Information Security Officer Ross Young shares his learnings from a career in both the public and private sectors, like how to develop shared goals and alignment within a security organization, why soft skills and people skills are essential for building relationships, and how managers can use introspection to become great leaders. Follow Ross on LinkedIn at https://www.linkedin.com/in/mrrossyoung/  Learn more about Caterpillar Financial at https://www.cat.com/en_US/support/financing-protection.html  Nightfall is the industry's first cloud-native DLP platform that discovers, classifies, and protects data via machine learning. Nightfall is designed to work with popular SaaS applications like Slack & GitHub as well as IaaS platforms like AWS. Learn more about Nightfall AI on our website: https://nightfall.ai/about/  Listen and subscribe on Apple Podcasts or your favourite podcast player for free! And leave us a review if you're enjoying the show. This podcast is created and sponsored by Nightfall AI. Please share your questions and feedback with us at marketing@nightfall.ai. Follow us on social media:Facebook https://www.facebook.com/NightfallAI Twitter https://twitter.com/NightfallAI LinkedIn https://www.linkedin.com/company/nightfall-ai Instagram https://www.instagram.com/nightfall_ai/  Follow CISO Insider managing producer and host Chris Martinez on LinkedIn https://www.linkedin.com/in/chris-martinez-communications/  Follow Ross' new podcast CISO Tradecraft, a guide to the adventure of becoming a CISO https://www.cisotradecraft.com/  Here are a few of the podcasts, books, and other resources Ross mentioned in today's episode: SANS https://www.sans.org CISO-Security Vendor Relationship podcast https://podcasts.apple.com/us/podcast/ciso-security-vendor-relationship-podcast/id1391337832   Defense in Depth podcast https://podcasts.apple.com/us/podcast/defense-in-depth/id1450197741 The Phoenix Project by Gene Kim https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290  Special thanks to Wendel Topper for podcast production support. Follow Wendel's work at https://createk.us/  Thanks for listening!

Making things cheaper, faster, and better is the key to gaining competitive advantage. If you can gain a competitive advantage in cyber, then you will reduce risk to the business and protect key revenue streams. This episode discusses the three ways of DevOps and how you can use them to improve information security. The three ways of DevOps consist of:The First Way: Principles of FlowThe Second Way: Principles of FeedbackThe Third Way: Principles of Continuous LearningIf you would like to learn more about the three ways of DevOps, G Mark Hardy and Ross Young invite you to read The Phoenix Project by Gene Kimhttps://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

In this week’s episode we are talking about event organizer teams. What do they look like and how can oragnisers prepare for their return, but we also look at what skills, across departments, you could learn to help you thrive in the future. We are in conversation with CTO of Easyfairs, Stephan Forseilles. Stephan migrated from the telecom industry to exhibitions 15 years ago and has a passion for all things digital. He is currently Head of Technology and Digital Transformation (CTO) but is also active across many industry initiatives including UFI’s Digital Innovation Working Group and The Exhibitions Think Tank. He is passionate about helping the industry to get in better shape and to be more customer orientated for the future. In our conversation, you may be surprised to hear, given my guests specialty, we’re not focusing on tech teams but all parts of organizations that should be working together to drive customer experience. We were previously a very transactional led industry, however now, we should be looking at how we enthuse, engage, educate and inspire experiences of the future. We talk about:Being more agile and what that really meansBeing open to change and more so, have the willingness to changeBeing ready to learnWe then dive into a number of departments across an organisers business:Product Management –learn the skills of taking risk but being data driven and not to assume anything. Tech Teams – retraining how to be more agile and that it’s ok to not be live with the final product. Build, launch, test, refine. Finance – not one you typically see on panels or podcasts, but these teams need to work in partnership with teams and to work with a level of uncertainty when budgeting, that they’ve never had to work with before. Marketing – have to truly understand the industry they are serving if they’re to really connect with audiences year round. It’s not just about attracting visitors to three days of a show anymore. Sales –There is a greater catalogue of products available to sell, so really understanding the opportunities available in a hybrid world will set sales teams apart in 2021. Management – Already versed in how to bring people together, management teams will need to support greater cross team collaboration to drive success of the future. No more silos, breaking down barriers, making things happen. Let us know what you think? Is your team changing for the hybrid year? This week, we also launch something special. Wanting to share the success of people or businesses that have launched something through this pandemic or supported the industry through this time. We’re excited to share the news from avid listener Noel Reeves and Rocket-Exhibitions. Check them out at www.rocket-exhibitions.com For reference, the book that Stephan mentioned in this episode is called the Phoenix Project and available here: https://www.amazon.co.uk/Phoenix-Project-Devops-Helping-Business/dp/1942788290/ref=sr_1_1?dchild=1&keywords=phoenix+project&qid=1605005120&quartzVehicle=774-1178&replacementKeywords=project&sr=8-1 Support the show (https://www.buymeacoffee.com/wavespodcast)

Brandon interviews Drew Firment from A Cloud Guru. (https://acloudguru.com/) They discuss Drew's career, how Capital One embraced the cloud and A Cloud Guru's mission to teach the world to cloud. Plus, Drew offers advice on deciding which cloud certifications to get first. Show links The Phoenix Project (https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592) Hygieia (https://www.capitalone.com/tech/solutions/hygieia/) The cloud resume challenge (https://forrestbrazeal.com/2020/04/23/the-cloud-resume-challenge/) Contact Drew A Cloud Guru (https://acloudguru.com/) Drew's LinkedIn (https://www.linkedin.com/in/drewfirment/) Twitter: @drewfirment (https://twitter.com/drewfirment) Photo Credit (https://unsplash.com/photos/a96M-pnoUQA) Special Guest: Drew Firment.

Devs Like Us Episode 10 | The DevOps Mindset Summary: Terrence, JB, and Clarence discuss DevOps. DevOps Books: The Unicorn Project https://www.amazon.com/Unicorn-Project-Developers-Disruption-Thriving/dp/1942788762/ref=sr_1_1?dchild=1&keywords=the+unicorn+project&qid=1602774667&sr=8-1 The DevOps Handbook https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002/ref=sr_1_3?dchild=1&keywords=the+devops+handbook&qid=1602774707&sr=8-3 The Phoenix Project https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/ref=sr_1_2?crid=3J6UBRGA3S7GY&dchild=1&keywords=the+phoenix+project&qid=1602774742&sprefix=The+ph%2Caps%2C145&sr=8-2 YouTube: https://www.youtube.com/channel/UCOQaCm4q93rCUtTMI-YsaLg Website: https://devslike.us Instagram: https://www.instagram.com/devslike.us/ --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/devslikeus/message Support this podcast: https://anchor.fm/devslikeus/support

The three ways of DevOps comes from the Phoenix Project, a famous book in DevOps circle. This episode covers how to use the three ways to progress in your digital transformation initiatives.   Sources: https://www.businessinsider.com/how-changing-one-habit-quintupled-alcoas-income-2014-4?r=US&IR=T https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592 https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations-ebook/dp/B01M9ASFQ3/ref=sr_1_1?crid=316RJMM06NH59&dchild=1&keywords=the+devops+handbook&qid=1600774333&s=books&sprefix=The+devops+h%2Cstripbooks-intl-ship%2C235&sr=1-1 Transcript: My first introduction to the principles behind DevOps came from reading The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. In this seminal book, that blew my mind we follow Bill as he transforms Parts Unlimited through salvaging The Phoenix Project. An IT project that went so wrong, it could almost have been a project in the public sector. Through Bills journey to DevOps, we discover and experience the Three Ways of DevOps. In this episode, I cover the three ways of DevOps and how they can be applied in a Transformation. This is the DevOps Dojo #6, I am Johan Abildskov, join me in the dojo to learn. In the DevOps world, few books have had the impact of The Phoenix Project. If you have not read it yet, it has my whole-hearted recommendation. It is tragically comic in its recognizability and frustratingly true. In it, we experience the three ways of DevOps. The three ways of DevOps are Principles of Flow, principles of feedback and principles of continuous learning.  While each of these areas support each other and has some overlap, we can also use them as a vague roadmap towards DevOps capabilities. The First Way of Flow addresses our ability to execute. The second way of Feedback concerns our ability to build quality in and notice defects early. The Third way of Continuous Learning focuses on pushing our organizations to ever higher peaks through experimentation. The first way of DevOps is called the principles of flow. The first way of DevOps is called the principles of flow. The foundational realization of the first way is that we need to consider the full flow from ideation until we provide value to the customer. This is also a a clash with the chronic conflict of DevOps with siloed Dev and Ops teams. It doesn't matter whether you feel like you did your part or not, as long as we the collective are not providing value to end-users. If you feel you are waiting a lot, try to pick up the adjacent skills so you can help where needed. We also focus on not passing defects on and automating the delivery mechanisms such that we have a quick delivery pipeline. Using Kanban boards or similar to visualize how work flows through our organization can help make the intangible work we do visible. A small action with high leverage is WIP limits. Simply limiting the amount of concurrent tasks that can move through the system at any point in time can have massive impact. Another valuable exercise to do is a Value Stream Map where you look at the flow from aha-moment to ka-ching moment. This can be a learning situation for all involved members as well as the organization around them. Looking at the full end to end flow and having optimized that we can move on to the second way of DevOps.   The second way of DevOps is the Principles of Feedback The first way of DevOps enables us to act on information, so the second way focuses on generating that information through feedback loops, and shortening those feedback loops to be able to act on learning while it is cheapest and has the highest impact. Activities in the Second Way can be shifting left on security by adding vulnerability scans in our pipelines. It can be decomposing our test suites such that we get the most valuable feedback as soon as is possible. We can also invite QA, InfoSec and other specialist competences into our cycles early to help architect for requirements, making manual approvals and reviews less like to reject a change. Design systems are a powerful way to shift left as we can provide development teams with template projects, pipelines and deployments that adhere to desired guidelines. This enables autonomous teams to be compliant by default. The second way is also about embedding knowledge where it is needed. This is a special case of shortening feedback loops. This can both be subject matter expert knowledge embedded on full stack teams, but it can also be transparency into downstream processes to better allow teams to predict outcomes of review and compliance activities. A fantastic way of shifting left on code reviews, and improve knowledge sharing in the team is Mob Programming. Solving problems together as a team on a single computer. We can even invite people that are external to the team to our sessions to help knowledge sharing and to draw on architects or other key knowledge banks. Now that we have focused on our ability to create flow and feedback we can move on to the third and final way of DevOps. The principles of continuous learning.   The first and second way of DevOps provide most of the technical capabilities for continuous learning and experimentation - so the hard work in the third way of DevOps is primarily cultural. Which makes it that much more difficult to do. A small step could be to start talking about hypotheses that we want to test rather than tasks we want to do. We have a tendency to state things as fact and put them into our backlogs. This creates an unfortunate mental model and Taylorist Command and Control culture. Language shape our thoughts so let's start phrasing our backlog items as hypothesis. Rather than saying "Make Button A Blue", say "We believe making Button A Blue will increase clickthrough rate by 10%." While the previous step can be useful the big theme in the third way is psychological safety. Making it safe to learn and experiment must be a priority if we want to have a healthy culture. We must make diversity a focus area, especially in the tech business we have a notoriously toxic culture. We can measure Westrum Culture as described in a previous episode, and seek to address any shortcoming. Learning, Diversity and Psychological safety must come from a leadership level exemplifying the virtues that the members of the organization must live. Otherwise, there will be no resilience and any benefits will be temporary. The impressive transformation of Alcoa embodies this perfectly. Another simple, but difficult practice is to drive down the size of the work items you are working on. This will make it easier to create small self-contained experiments. This will of course put stress on your software and organizational architecture.If you want to finish with a concrete technical practice look into Chaos Engineering as described in a previous Episode. Chaos Engineer will help build resilience into your organization and is a structured approach to create more learning. As such it can bring some safer sandbox to practice learning and experimentation. This can be beneficial if the organization is quite far from psychologically safe. The three ways of DevOps: Flow, Feedback and Learning are a meaningful definition of DevOps and it even hints at a roadmap for DevOps Transformations. Use the three ways and the activities I have described here as an inspiration to kickstart or accelerate your DevOps transformation!   This has been the DevOpsDojo. You can follow me on twitter @randomsort. If you have any questions, feedback or just want to reach out and suggest a topic, do not hesitate. You can find show notes with transcripts, links and more at dojo.fm. Support the show by leaving a review, sharing this episode with a friend or colleague or subscribing to the DevOpsDojo on your favourite podcast platform. Thank you for listening, keep learning.  

Developer Operations is a data driven endeavor, but how do you avoid drowning in noise? In this episode of Adventures in DevOps, the panelists discuss the metrics that matter, how we approach separating information from noise, and when a simple number fails to tell the whole story. Panelists Jeff Groman Henry Jewkes Scott Nixon Sponsors CacheFly Links CodePipeline Dashboard DevOps 043: Testing in Production with Talia Nassi SlIs, SLOs, SLAs, oh my! The Unicorn Project The Phoenix Project Accelerate: The Sciene of Lean Software and DevOps Picks Scott Nixon: Alone Follow on Social Media: Facebook: Adventures in DevOps Twitter: @DevOpsPodcast

Developer Operations is a data driven endeavor, but how do you avoid drowning in noise? In this episode of Adventures in DevOps, the panelists discuss the metrics that matter, how we approach separating information from noise, and when a simple number fails to tell the whole story. Panelists Jeff Groman Henry Jewkes Scott Nixon Sponsors CacheFly Links CodePipeline Dashboard DevOps 043: Testing in Production with Talia Nassi SlIs, SLOs, SLAs, oh my! The Unicorn Project The Phoenix Project Accelerate: The Sciene of Lean Software and DevOps Picks Scott Nixon: Alone Follow on Social Media: Facebook: Adventures in DevOps Twitter: @DevOpsPodcast

For Love Of Code Episode #8 - Is 10x Developer a Myth Chris and Tim discuss the Sony PS5 announcement and how that will impact how games are developed in the future. Chris shares the only reason he owned a PS was for the Blu-ray player. The guys also discussed the first super computer built by Virginia Tech using Apple. There was also a conversation about the current movement to create a "Right to Repair" laws for electronics. The main topic is the idea of the 10x developer and does it really exist. Tim insists he's definitely one...Chris is not a believer. ~ Articles and books discussed ~ Sony says the PlayStation 5’s SSD will completely change next-gen level design https://www.theverge.com/2020/3/18/21185356/sony-ps5-playstation-5-ssd-load-times-mark-cerny-developer-gdc The Past and Future of the Head-up Display, the Original Augmented Reality https://nymag.com/intelligencer/2019/01/the-past-and-future-of-the-head-up-display.html Tesla now disables Supercharging in salvaged vehicles https://electrek.co/2020/02/12/tesla-disables-supercharging-salvaged-vehicles/ Sonos Criticised For Bricking Old Speakers https://www.silicon.co.uk/e-innovation/green-it/sonos-bricking-old-speakers-326187 Rich Rebuilds - We hacked the Tesla model 3s and it's true potential is INSANE https://www.youtube.com/watch?v=pivzUIOB-gw Right to Repair Is Less Complicated and More Important Than You Might Think https://gizmodo.com/right-to-repair-is-less-complicated-and-more-important-1834672055 The myth of developer productivity https://nortal.com/us/blog/the-myth-of-developer-productivity/ The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290 The Pragmatic Programmer: 20th Anniversary Edition, 2nd Edition: Your Journey to Mastery https://www.amazon.com/Pragmatic-Programmer-Anniversary-Journey-Mastery/dp/B0833FBNHV ~ Social Media ~ https://twitter.com/forloveofcode https://www.instagram.com/forloveofcode/ https://www.linkedin.com/company/forloveofcode https://www.facebook.com/forloveofcode #ForLoveOfCode #Prime3Software

Nan Epizòd sa Luther ak Jude fè yon ti chita pale ak yon envite speysal Gael ki se yon enfòmatisyen. Gael gen yon platfòm ki rele kozetek. Kòm yon ayisyen natif natal, Gael eksplike wout li pase pou li rive isi e kòman li te rive jwen pozisyon li ye kounye a ozetazini. Li eksplike tou kòman lew jwen travay la pou ou ka bay bon sèvis ak kliyantè/itilizatè (customer service) pou ka jwenn plis moun an kontank avè yon antanke travayè. Gael eksplike diferans ki genyen nan moun kap kode, moun kap entèaji ak kilyan, e moun kap bay sipò ak sistèm. Nan peripesi Gael pase anvan li vin jwenn yon travay, Gael rive devlope 10 etap bagay pou fè pouw ka rive jwen yon travay. Koute epizòd sa pou w tande 10 konsèy kritik ke Gael bay pou avanse e jwenn travay nan yon fason jeneral. Links: https://www.uopeople.edu/ http://www.github.com https://www.kozeteknoloji.com/ Social Media: https://www.kozeteknoloji.com/ https://www.youtube.com/user/beauboeufg Books: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592

In this episode of Adventures in DevOps the pane interviews Adam Nowak. Adam is a part of the DevOps team at Netguru. He joins the panel today to share his DevOps transformation story. Adam starts by explaining the title he chose for today’s episode. He also shares his definition of DevOps. Adam explains the age-old story of a misunderstood DevOps team that was overworked and underappreciated. The organization grew but the DevOps team didn’t scale with it, leaving them with piles of tickets and everyone else wondering what was taking so long. The panel commiserates with Adam and shares some of their own similar stories.  Reaching out to others to help solve the problem, Adam found that many DevOps teams had and are experiencing the same problem. He found help from others in the DevOps space and recommended books. His team started by making their work more visible. To do this they streamlined their communication and published documentation.  Next, they made more focused goals. Instead of trying to do everything and never meeting their goals they chose a couple things to work on and focused on that. Another change they made was to diversify their meetings, projects, and initiatives; they brought in people from all the teams to collaborate, making the projects even better.  The panel discusses the importance of empathy in the workplace and in life. Most people are trying their best and probably have a reason for doing the things that they are doing. Instead of treating others as if they are incompetent, talk them and discuss the reasons behind their actions and decisions.  Panelists Nell Shamrell-Harrington Charles Max Wood Guest Adam Nowak Sponsors CacheFly Links How we killed DevOps by creating a dedicated DevOps team | Adam Nowak The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win  Making Work Visible: Exposing Time Theft to Optimize Work & Flow  The Goal: A Process of Ongoing Improvement   The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations  Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs  Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations  Switch: How to Change Things When Change Is Hard  https://www.facebook.com/Adventures-in-DevOps-345350773046268/ Picks Charles Max Wood: Holiday Inn  White Christmas  The MaxCoders Guide To Finding Your Dream Developer Job  Nell Shamrell-Harrington: The Mandalorian Rust in Motion  Adam Nowak: Why We Sleep: Unlocking the Power of Sleep and Dreams Jabra Elite 85h Wireless Noise-Canceling Headphones

In this episode of Adventures in DevOps the pane interviews Adam Nowak. Adam is a part of the DevOps team at Netguru. He joins the panel today to share his DevOps transformation story. Adam starts by explaining the title he chose for today’s episode. He also shares his definition of DevOps. Adam explains the age-old story of a misunderstood DevOps team that was overworked and underappreciated. The organization grew but the DevOps team didn’t scale with it, leaving them with piles of tickets and everyone else wondering what was taking so long. The panel commiserates with Adam and shares some of their own similar stories.  Reaching out to others to help solve the problem, Adam found that many DevOps teams had and are experiencing the same problem. He found help from others in the DevOps space and recommended books. His team started by making their work more visible. To do this they streamlined their communication and published documentation.  Next, they made more focused goals. Instead of trying to do everything and never meeting their goals they chose a couple things to work on and focused on that. Another change they made was to diversify their meetings, projects, and initiatives; they brought in people from all the teams to collaborate, making the projects even better.  The panel discusses the importance of empathy in the workplace and in life. Most people are trying their best and probably have a reason for doing the things that they are doing. Instead of treating others as if they are incompetent, talk them and discuss the reasons behind their actions and decisions.  Panelists Nell Shamrell-Harrington Charles Max Wood Guest Adam Nowak Sponsors CacheFly Links How we killed DevOps by creating a dedicated DevOps team | Adam Nowak The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win  Making Work Visible: Exposing Time Theft to Optimize Work & Flow  The Goal: A Process of Ongoing Improvement   The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations  Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs  Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations  Switch: How to Change Things When Change Is Hard  https://www.facebook.com/Adventures-in-DevOps-345350773046268/ Picks Charles Max Wood: Holiday Inn  White Christmas  The MaxCoders Guide To Finding Your Dream Developer Job  Nell Shamrell-Harrington: The Mandalorian Rust in Motion  Adam Nowak: Why We Sleep: Unlocking the Power of Sleep and Dreams Jabra Elite 85h Wireless Noise-Canceling Headphones

Luca Mezzalira is an Italian developer. He is the VP of architecture at DAZN, a multi-country live streaming platform for sports, Google developer expert, and London JavaScript community manager. Luca got his start in programming 16 years ago when a friend told him about it and gave him a book. He was very intrigued and went on to learn multiple languages and travel the world for his job. For the last 4-5 years he’s been working in architecture, and is now the leader on thoughts on micro-frontends.  Luca first defines what he means by a micro-frontend. He advises that when designing a new application one should consider how to make it scalable from the beginning. His passion for micro-frontends came from working with DAZN, where they need to enable hundreds of people to work on the same project in different time zones and locations. This problem was solved by microservices.A microservice is a self contained, autonomous, independent service that can be deployed inside a system responding to an API you can consume. It only does one job, and when you have a backend that has multiple microservices you can move away from the old monolith, and scale one API at a time and apply an independent release of a service. Microservices are often applied to the backend, but Luca talks about how the same principles can be applied to the frontend. This is similar to the way that Netflix works. His advice is to think about how you can slice your frontend into individual pieces. Micro-frontends can work with both regular and micro-backends. Luca talks about how DAZN has developed, from a monolith front and back to utilizing microservices. He has found that using microservices has decreased the amount of code they release, increased their speed because decisions happen locally and independently from the rest of the program, and enables teams to work in parallel. Using microservices on both the front and backend has given this large organization greater agility overall.   Luca addresses some risks with using micro-frontends. It is important to identify your business model before implementing a micro-frontend. They are more effective when you know where your site traffic goes and you can slice your frontend properly. When applied correctly, microservices can enable your app to get more elaborate because it will only load the code that it needs.  Ari Clark wonders if having a micro-frontend helps you create autonomous teams with expertise that benefit your company or if the specialization affects your operational readiness if something goes wrong. One of the main challenges DAZN has had is knowledge sharing between teams, and he shares practices the company has implemented to help spread the information around to keep people from feeling isolated. He talks about how developer teams are set up in his company, with some temporary roles and some people in rotation. Developers are encouraged to change their team if they want to try another challenge. Luca has found that this set up causes people to stick around longer, but notes that it is important that your location be pretty stable in the number of people there before implementing this method. He also talks about how people other than developers are divided in the company.  Luca talks about some of the challenges they’ve had with this organization and the tools they’ve employed that are conducive to this business structure. Some of their management methods are working in small iterations, creating bridges between teams, and centralizing some teams. They are currently working on creating a structure where developers at any stage can chip in. The panel discusses the value of this business setup.  The panel asks Luca his feelings on code reuse. He believes it to be important, but not essential. He talks about how resing code is implemented in his company and how they are working on a way to make it better. Luca notes that if you have a unique framework you’re using, you need to have try to have multiple libraries of the same framework for different versions. He also talks about situations where he found duplicating code helpful. The show finishes with the panel discussing his article on micro-frontends on Medium.  Panelists Ari Clark Chris Fritz Elizabeth Fine Ben Hong With special guest: Luca Mezzalira Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan Elixir Mix Links DAZN Microservice  Amazon style dictionary I Don't Understand Micro Frontends by Luca Mezzalira Follow DevChatTV on Facebook and Twitter Picks Ari Clark: What We Do in the Shadows on Netflix and Hulu Chris Fritz: VoiceAttack Lover by Taylor Swift Elizabeth Fine: CookBook app Ben Hong: Exhalation by Ted Chang Perplexus Epic Luca Mezzalira: The Phoenix Project Building Micro-Frontends Webinar September 30, 2019 Follow Luca @lucamezzalira and at https://lucamezzalira.com

Luca Mezzalira is an Italian developer. He is the VP of architecture at DAZN, a multi-country live streaming platform for sports, Google developer expert, and London JavaScript community manager. Luca got his start in programming 16 years ago when a friend told him about it and gave him a book. He was very intrigued and went on to learn multiple languages and travel the world for his job. For the last 4-5 years he’s been working in architecture, and is now the leader on thoughts on micro-frontends.  Luca first defines what he means by a micro-frontend. He advises that when designing a new application one should consider how to make it scalable from the beginning. His passion for micro-frontends came from working with DAZN, where they need to enable hundreds of people to work on the same project in different time zones and locations. This problem was solved by microservices.A microservice is a self contained, autonomous, independent service that can be deployed inside a system responding to an API you can consume. It only does one job, and when you have a backend that has multiple microservices you can move away from the old monolith, and scale one API at a time and apply an independent release of a service. Microservices are often applied to the backend, but Luca talks about how the same principles can be applied to the frontend. This is similar to the way that Netflix works. His advice is to think about how you can slice your frontend into individual pieces. Micro-frontends can work with both regular and micro-backends. Luca talks about how DAZN has developed, from a monolith front and back to utilizing microservices. He has found that using microservices has decreased the amount of code they release, increased their speed because decisions happen locally and independently from the rest of the program, and enables teams to work in parallel. Using microservices on both the front and backend has given this large organization greater agility overall.   Luca addresses some risks with using micro-frontends. It is important to identify your business model before implementing a micro-frontend. They are more effective when you know where your site traffic goes and you can slice your frontend properly. When applied correctly, microservices can enable your app to get more elaborate because it will only load the code that it needs.  Ari Clark wonders if having a micro-frontend helps you create autonomous teams with expertise that benefit your company or if the specialization affects your operational readiness if something goes wrong. One of the main challenges DAZN has had is knowledge sharing between teams, and he shares practices the company has implemented to help spread the information around to keep people from feeling isolated. He talks about how developer teams are set up in his company, with some temporary roles and some people in rotation. Developers are encouraged to change their team if they want to try another challenge. Luca has found that this set up causes people to stick around longer, but notes that it is important that your location be pretty stable in the number of people there before implementing this method. He also talks about how people other than developers are divided in the company.  Luca talks about some of the challenges they’ve had with this organization and the tools they’ve employed that are conducive to this business structure. Some of their management methods are working in small iterations, creating bridges between teams, and centralizing some teams. They are currently working on creating a structure where developers at any stage can chip in. The panel discusses the value of this business setup.  The panel asks Luca his feelings on code reuse. He believes it to be important, but not essential. He talks about how resing code is implemented in his company and how they are working on a way to make it better. Luca notes that if you have a unique framework you’re using, you need to have try to have multiple libraries of the same framework for different versions. He also talks about situations where he found duplicating code helpful. The show finishes with the panel discussing his article on micro-frontends on Medium.  Panelists Ari Clark Chris Fritz Elizabeth Fine Ben Hong With special guest: Luca Mezzalira Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan Elixir Mix Links DAZN Microservice  Amazon style dictionary I Don't Understand Micro Frontends by Luca Mezzalira Follow DevChatTV on Facebook and Twitter Picks Ari Clark: What We Do in the Shadows on Netflix and Hulu Chris Fritz: VoiceAttack Lover by Taylor Swift Elizabeth Fine: CookBook app Ben Hong: Exhalation by Ted Chang Perplexus Epic Luca Mezzalira: The Phoenix Project Building Micro-Frontends Webinar September 30, 2019 Follow Luca @lucamezzalira and at https://lucamezzalira.com

פרק מספר 61 של באמפרס (377 למניין רברס עם פלטפורמה) - רן, אלון, ודותן מתאוששים מהבחירות (שוב) עם סקירה של טכנלוגיות ודברים מעניינים בשוק התוכנה הלוהט מהזמן האחרון, לפחות עד שיפורסמו התוצאות הרשמיות (ממשלת אחדות של React ו-Rust?! שמעתם את זה לראשונה כאן)רן - בלוג-פוסט מעניין שמגיע מ - Palo Alto Networks (שאחד ממייסדיה ישראלי) - השוואה של Security Features עבור Containers שונים - An Overview of Sandboxed Container Technologiesצעד אחורה לפני הצלילה - דוגמא נפוצה ל - Containers Technology זו Docker: טכנולוגיה שנחשבת פחות בטוחה מוירטואליזציה מלאה כיוון שכל ה-  Containers משתמשים באותו Kernel, ואעפ”י שננקטים הרבה צעדים על מנת לבודד בין ה - Containers השונים, הבידוד אף פעם לא מוחלט ותמיד יש חשש מזליגה של מידע או השפעה מאחד לשני - בעיה קיימת, שרירה וידועה בעולם ה - Containers נכון להיום, וכל הזמן מחפשים עבורה פתרונות שונים.הבלוג-פוסט המדובר מציג את מה שנחשב כ - state of the art נכון להיום: מה הן ה  -Containers Technologies הקיימות היום ואיזו רמה של בידוד נלקחת על מנת לספק רמה גבוהה יותר של Securityה - trade-off הקלאסי הוא Performance vs. Security.יש כאן תיאור של Use-cases שונים וגם תיאור הנדסי של איך כל טכנולוגיה עובדת, וזה מאוד מעניין.סקירה קצרה של מה שמתואר (אמ;לק) - לא טכנולוגית Containers (בתור התחלה . . . ) אבל נותנת מענה ל Use Case דומה - UniKernel: מעיין מערכת הפעלה שיש בה תוכנית אחת, למעשה - מערכת הפעלה שלמה שכל מה שהיא עושה זה להריץ את התוכנית שלכם (אם Zaphod Beeblebrox היה מתכנת וכו’); כיוון שכך - היא מאוד מוקשחת (כוללת רק את מה שהתוכנית שלכם צריכה - ולא יותר). כאמור - לא באמת Container אבל Use Case דומה - עם startup time מאוד קצר, מבנה מינימליסטי וכו’.מ-IBM מגיעה Container Technology בשם IBM Nabla - גם אם לא שמעתם על זה קודם (כאילו יש משהו של IBM שהוא לא AS400, Mainframe או משהו מהשכבה הגיאולוגית הזו כן שמעתם עליו), זה קיים - וברשימה.טכנולוגיה של Google בשם gVisor - טכנולוגיה שמשמשת את Google פנימית (וגם עבור App Engine לפני הרבה זמן), היום היא כבר מופיעה כקוד פתוח, ומהווה ברירת מחדל או משהו בסגנון עבור Kubernetes; מה שמעניין כאן הוא השימוש ב User-level Kernel - יש Kernel אבל ב - User level, כך שהוא לא משותף - אלא הרבה Kernels קטנים.יש את Amazon Firecracker - שעליו כבר דיברנו כמה פעמים (וגם כאן וכאן).וגם את OpenStack Kata - שגם עליו לא שמענו קודם (זאת אומרת - על OpenStack כן, Kata פחות - המושג עצמו מוסבר יפה ב - Phoenix Project).בסופו של דבר - סקירה מאוד יפה ומעמיקה מומלץ.אז בכל זאת TL;DR לאמ;לק? חלק מהטכנולוגיות ברמת בשלות גבוהה וחלק פחות; וכל אחת מהן לוקחת איזשהו Trade-off בין Performance ל - Security, וכל אחד צריך למצוא את המקום הנכון בשבילו - אין פתרון קסם אחד.יש גם טבלת סיכום בסוף המאמר, עם Features שונים כמו הפעלה דומה ל - Docker, האם הקוד פתוח (כן, כולם), וכו’ - יכול לעזור לבחור.בשורה התחתונה - אנחנו יודעים ש - Docker הכי פופלארי אם אתם בעניין של מיינסטרים (אפילו לא מופיע בסקירה . . . ), אבל גם סביר להניח שהוא הכי פחות בטוח (Secured), אז אם חשוב לכם Security כי למשל את מריצים workloads מגורמים שהם Un-trusted ואתם חייבים לשים לב; אם כל ה - workload שלכם פנימית אז הסכנה אולי פחות גדולה ועדיין מומלץ לשים לב ולמנוע מבעייה באחד ה - Containers לזלוג לאחרים.שורה תחתונה, שוב: ה - trade-off הקלאסי של Performance vs. Security, עם רמות בשלות שונות של הפלטפורמות השונות: gVisor ו - Firecracker ברמת בשלות גבוהה יחסית והשתיים האחרות פחות, אבל אף אחת לא פופלארית ברמה של Docker למשל.צריך לקחת בחשבון שלפעמים בענייני Security הדברים הכי פופלאריים הם גם הכי מסוכנים - אם מישהו מנסה Brut-force ויודע שרוב הסיכויים הם לנחות על Docker אז אולי ישקיע בזה יותר וזה סיכון.מצד אחד - אולי ככל שהפלטרפרומה יותר פופלארית כך היא תהווה מטרה יותר גדולה ל Hackers, ומצד שני  - יותר עיניים יסתכלו עליה כך שיותר באגים ימצאו ואולי כך היא תהפוך ליותר קשיחה. מאזן אימה . . .הבוטים באים! AWS Chatbot: ChatOps for AWSאיפה נועםר?אז AWS פרסמו פלטרפורמה בשם AWS Chatbot, שיכולה להוות נדבך משמעותי ב - Chat-Ops על AWS.רגע - ChatOps?מדובר ביכולת לנהל סביבת Production דרך צ’אט - אם זה Deployment או Provisioning למכונות, Scale up או Scale down, ניטור (Monitoring) . . . הכל דרך צ’אט.שיטה מקובלת בכל מיני חברות, אחת המפורסמות היא GitHub.יתרונות - שקיפות: אף פעם לא עושים SSH לאיזשהו Server, הכל דרך צ’אט אז כולם רואים מה קורה, וגם יכולים ללמוד איך לעשות את זה בפעם הבאה לבד.ובחזרה לאייטם - AWS Chatbot, מאפשרת לממש ChatOps על AWS.רן השתמש (בקטנה) לצרכי עבודה - פונקציות Lambda שמדווחות על Events ב-AWS, או כאלה ש”מאזינות לצ’אט” ועושות פעולות על AWS, ויש גם דברים אחרים.זו פלטפורמה קצת יותר הוליסטית, שיכולה להוות נקודת התחלה די טובה, בהנחה שאתם עובדים תחת AWS ורוצים ChatOps.אז עכשיו רק חסר להוסיף את זה עם פקודות קוליות ל Alexa . . . רק לחבר לשירות Text to Speech שלהם (Polly) וזהו?תכל’ס - מה הסיכוי שזה כבר קיים? כל ה-Echo Devices גם ככה מקשיבים כל הזמן, אז אפשר להתחיל להרים מכונות כבר כשמתמעורר הדיון בפינת הקפה, ואז כשסוף כל סוף מגיעה הפקודה זה מוכן ממש מהר. נשאר רק לממש Delay קטן כדי למנוע חשדות ולהפחית Creepiness .  . . אין על SkyNet.האם אפשר לשדר את כל הפקודות הקוליות בתדר שרק מכונות “שומעות”, ואז לעשות Hacking לכולם? בטח גם זה כבר קיים . . . מסביר מלא דברים.וברצינות (יחסית) - זה עובד רק על AWS או שניתן לבצע אינטגרציה עם מערכות אחרות?מה שהם מממשים עובד רק על AWS, עם ה - Backend של AWS - למשל EC2, ELB ,S3 וכאלה, אבל אפשר לקחת Design דומה, וקונספטואלית לעשות משהו דומה עבור פלטפורמה אחרת - וזה גם קיים -אחד הראשונים היה HUBOT של GitHub, והוא עדיין די פופלארי (על אף הרבה re-writes, במקור זה היה ב CoffeeScript, אבל יש מצב שיש כיום בעולם יותר מפתחי Cobol מ-CoffeeScript…)יש גם פלטפורמה חדשה שנכתבה ב-Go, עם השם הקליט joe…טרנד אחר שמתכתב עם זה הוא GitOps, אבל זה אולי לפעם אחרת.הכרזה של AWS על POP חדש בישראל - AWS CloudFront launches a POP in Israelלא פופ כזה . . . Point Of Presence - למעשה מדובר ב”קצה של ה-CDN” שנמצא בישראלגרם להתרגשות גדולה בקרב קהילת המפתחים בישראל (אלון בהדגמה חיה, פחות עובר בטקסט, דמיינו התרגשות).בסופו של דבר זה בסך הכל POP, ויכול קצת לזרז את הגישה ל-CDN של AWS, ואולי גם חישוביות במובן של Lambda@Edge, אבל כנראה שלא יותר מזה (חישוביות מוגבלת).ב-POP סטנדרטי של AWS יש CloudFront ו - Lambda@Edge (לא בכולם, כאן נראה שכן) - ודי זהו בגדול.מה הסיכוי שזה מתואם עם ההשקה של Amazon.com בישראל? אולי, אבל יש מצב שיותר קשור למכרזים ממשלתיים ש-AWS מתעניינת בהם (מול GCP ו-Azure בעיקר), ושכוללים בין השאר דרישה לתשתיות פיזיות בארץ, כך שאולי זה קשור כהכנה או משהו.אבל זה רק POP . . . פקידי הממשלה - שלא יעבדו עליכם! שוב . . . זה לא Storage וזה לא Compute - זו עדיין לא נוכחות “אמיתית”, אבל לפחות אנחנו על המפה ואנחנו נשארים במפה. הנה.בתיאוריה - יש את Lambda@Edge, אז ברמה התיאורטית אפשר “לעשות הכל” . . . זאת אומרת - רק דברים ש Lambda@Edge יכולה לעשות. יש מגבלות לעומת Lambda רגילה - שלחו גלויה אם אתם יודעים מה הן בדיוק (או בדקו ב Stack Overflow). בין הפותרים נכונה יוגרל פותר שלא ענה נכונה. או גלויה נוספת.ואם ב-AWS עסקינן - עוד הכרזה קטנה על Improved VPC networking for AWS Lambda functionsלמי שהתעסק על Functions ו-VPC יודע שהייתה בעיה בחיבור של Lambda עם VPC - כשה-Cold start עולה משמעותית יותר לאט (עד כדי 8-10 שניות, לעומת סדר גודל של עד שנייה אחת).יש לזה הרבה “תירוצים” של חיבורים ותשתיות וכו’עכשיו - נפתרה הבעיה, ובחיבור של Lambda עם VPC לא אמור להיות שינוי משמעותי ב-Cold start, שזה די מגניב כי זה הפריע לשימוש ב-Lambda במקרים מסויימים, למשל אם היה צריך להתחבר ל-Database שמאחורי VPC.האייטם הבא - GitHub: בהמשך להכרזה מלפני לא מעט זמן על GitHub Actions, אז GitHub Actions now supports CI/CD, free for public repositoriesהכרזה על Workflows, שזה בעצם CI/CD - בחינם עבור פרויקטים פומביים (Public).למעשה ניתן להשתמש עכשיו ב GitHub Actions על מנת להריץ CI, באותו אופן שבו יכולתם להריץ למשל CircleCI או Travis-CI וכו’.בכל מקרה - עכשיו זה מובנה בתוך GitHub וזה די נחמדרן כבר השתמש בזה בפרויקט (טיזר להמשך . . . )ה-Feature כולו עדיין ב-Beta, אבל אתם יכולים להגיש בקשה להתקבל ל-Beta (רן התקבל, רק אומרים).אז

Episode Summary In this episode of the Adventures in DevOps podcast, the panelists talk about getting started with DevOps and learning its principles and technologies. Lee and Scott mention that they share a similar journey, initially starting as system administrators and working their way into DevOps. Nell says that she was a Ruby and .NET developer before learning cloud technologies such as Heroku, Chef, and Docker. To someone with a programming background wanting to get into DevOps, Lee highly recommends three books - The Practice of System and Network Administration, The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services - Volume 2, and Time Management for System Administrators. He mentions that they are technology-agnostic and help in understanding what is really going on in the system. Scott stresses on the importance of understanding basic networking, linux systems and commands, bash scripting and knowing the core fundamentals and interactions of the underlying systems. He suggests going for online resources, tutorials and boot camps which are plenty nowadays and easily accessible as well. Nell advises listeners to pick a cloud provider such as Digital Ocean and learn the basics by working with it, which can later be applied to any other cloud provider. She also recommends learning programming languages to get a good software development foundation. The panelists talk about working on specific projects and getting hands dirty rather than traditional learning, to enhance their DevOps skills. Nell explains how they implement the 'learning by doing' concept at work. She mentions that understanding how virtual machines and physical servers work is crucial before moving on to learning about containers. Lee suggests Vagrant - a tool for building and managing virtual machine environments, as a good resource for the same. They caution that while it is important to learn things during our time off, self-care and setting healthy boundaries is paramount. It is ok to take longer to learn something given that DevOps as a whole can be extremely complex, and working in a non-pressure environment can be very beneficial. They recommend Ops School for beginners which is a comprehensive program aimed at people who want to get into operations engineering. They then share their insights on monitoring and how to get started with it. Lee recommends the book Practical Monitoring, and Sensu - a monitoring event pipeline, as good starting points. DevOps can be considered as a technical as well as a cultural movement. To that effect, they discuss where should people start learning the associated cultural elements. Nell recommends reading the books - Effective DevOps, and The Phoenix Project and Crucial Conversations. Lee advocates going old school with the writings of Richard Stallman, and books of the 80s and 90s such as The Art of C Programming. They mention that conversational skills and dealing with people are critical skills in today's work environments. Scott recommends Google's Site Reliability Engineering books which have a lot of great stuff to build a solid foundation and are also free to read online. Finally, they talk about how to keep learning and expanding knowledge. Some effective suggestions discussed include extensive practicing, working professionally, solving business problems, building expertise in programming, and attending DevOps Days events and Linux Users groups. They end the episode with picks. Panel Nell Shamrell-Harrington Lee Whalen Scott Nixon Sponsors iPhreaks - Devchat.tv The Dev Rev - Devchat.tv React Round Up - Devchat.tv CacheFly Links A Cloud Guru Digital Ocean Linux Academy The League of Professional System Administrators Vagrant Ops School Curriculum Practical Monitoring Sensu Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale The Phoenix Project The Art of C Programming Crucial Conversations Site Reliability Engineering - Google DevOps Days Picks Nell Shamrell-Harrington: Fresh Tarragon Lee Whalen: The Practice of System and Network Administration The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2 Time Management for System Administrators Scott Nixon: How to Stay Motivated: Developing the Qualities of Success

Episode Summary In this episode of the Adventures in DevOps podcast, the panelists talk about getting started with DevOps and learning its principles and technologies. Lee and Scott mention that they share a similar journey, initially starting as system administrators and working their way into DevOps. Nell says that she was a Ruby and .NET developer before learning cloud technologies such as Heroku, Chef, and Docker. To someone with a programming background wanting to get into DevOps, Lee highly recommends three books - The Practice of System and Network Administration, The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services - Volume 2, and Time Management for System Administrators. He mentions that they are technology-agnostic and help in understanding what is really going on in the system. Scott stresses on the importance of understanding basic networking, linux systems and commands, bash scripting and knowing the core fundamentals and interactions of the underlying systems. He suggests going for online resources, tutorials and boot camps which are plenty nowadays and easily accessible as well. Nell advises listeners to pick a cloud provider such as Digital Ocean and learn the basics by working with it, which can later be applied to any other cloud provider. She also recommends learning programming languages to get a good software development foundation. The panelists talk about working on specific projects and getting hands dirty rather than traditional learning, to enhance their DevOps skills. Nell explains how they implement the 'learning by doing' concept at work. She mentions that understanding how virtual machines and physical servers work is crucial before moving on to learning about containers. Lee suggests Vagrant - a tool for building and managing virtual machine environments, as a good resource for the same. They caution that while it is important to learn things during our time off, self-care and setting healthy boundaries is paramount. It is ok to take longer to learn something given that DevOps as a whole can be extremely complex, and working in a non-pressure environment can be very beneficial. They recommend Ops School for beginners which is a comprehensive program aimed at people who want to get into operations engineering. They then share their insights on monitoring and how to get started with it. Lee recommends the book Practical Monitoring, and Sensu - a monitoring event pipeline, as good starting points. DevOps can be considered as a technical as well as a cultural movement. To that effect, they discuss where should people start learning the associated cultural elements. Nell recommends reading the books - Effective DevOps, and The Phoenix Project and Crucial Conversations. Lee advocates going old school with the writings of Richard Stallman, and books of the 80s and 90s such as The Art of C Programming. They mention that conversational skills and dealing with people are critical skills in today's work environments. Scott recommends Google's Site Reliability Engineering books which have a lot of great stuff to build a solid foundation and are also free to read online. Finally, they talk about how to keep learning and expanding knowledge. Some effective suggestions discussed include extensive practicing, working professionally, solving business problems, building expertise in programming, and attending DevOps Days events and Linux Users groups. They end the episode with picks. Panel Nell Shamrell-Harrington Lee Whalen Scott Nixon Sponsors iPhreaks - Devchat.tv The Dev Rev - Devchat.tv React Round Up - Devchat.tv CacheFly Links A Cloud Guru Digital Ocean Linux Academy The League of Professional System Administrators Vagrant Ops School Curriculum Practical Monitoring Sensu Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale The Phoenix Project The Art of C Programming Crucial Conversations Site Reliability Engineering - Google DevOps Days Picks Nell Shamrell-Harrington: Fresh Tarragon Lee Whalen: The Practice of System and Network Administration The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2 Time Management for System Administrators Scott Nixon: How to Stay Motivated: Developing the Qualities of Success

Dennis Stepp is prioritizing tests based on risk. This episode is not sponsored! Want to be a sponsor? You can contact me or check out my sponsorship gig on Fiverr Show Notes: Mind Mapping The four factors of risk based analytis: Domain, risks, impact, likelihood I threw out the term systemic risk Books: Clean Code by Robert C. Martin The Phoenix Project by Jean Kim A Seat at the Table by Mark Schwartz Making Work Visible by Dominica Degrandis Working Effectively with Legacy Code by Michael Feathers Dennis-Stepp.com Dennis is on Twitter Want to be on the next episode? You can! All you need is the willingness to talk about something technical.

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit CacheFly Panel AJ O’Neal Charles Max Wood Joined by Special Guest: Anatoliy Zaslavskiy Summary Anatoliy Zaslavskiy introduces pickle.js and answers the panels questions about using it. The panel discusses the automated testing culture and employee retention. The panel discusses job satisfaction and why there is so much turn over in development jobs. Charles Max Wood reveals some of the reasons that he left past development jobs and the panel considers how the impact of work environments and projects effect developers. Ways to choose the right job for you and how to better a work situation is discussed. Anatoliy finishes by advocating for junior developers and explaining the value they bring to a company. Links https://github.com/storybooks/storybook https://www.picklejs.com/docs/getting-started https://opencv.org/ https://itunes.apple.com/us/app/snapcrap/id1436238261 https://tolicodes.com/ https://www.facebook.com/tolicodes https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber Picks AJ O’Neal The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim How to Diagnose and Fix Everything Electronic, Second Edition by Michael Jay Geier   Charles Max Wood https://andyfrisella.com/blogs/mfceo-project-podcast https://www.garyvaynerchuk.com/the-askgaryvee-show-podcast/ The 1-Page Marketing Plan: Get New Customers, Make More Money, And Stand out From The Crowd by Allan Dib Skyward by Brandon Sanderson Anatoliy Zaslavskiy Acro yoga http://www.cuddleparty.com/  

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit CacheFly Panel AJ O’Neal Charles Max Wood Joined by Special Guest: Anatoliy Zaslavskiy Summary Anatoliy Zaslavskiy introduces pickle.js and answers the panels questions about using it. The panel discusses the automated testing culture and employee retention. The panel discusses job satisfaction and why there is so much turn over in development jobs. Charles Max Wood reveals some of the reasons that he left past development jobs and the panel considers how the impact of work environments and projects effect developers. Ways to choose the right job for you and how to better a work situation is discussed. Anatoliy finishes by advocating for junior developers and explaining the value they bring to a company. Links https://github.com/storybooks/storybook https://www.picklejs.com/docs/getting-started https://opencv.org/ https://itunes.apple.com/us/app/snapcrap/id1436238261 https://tolicodes.com/ https://www.facebook.com/tolicodes https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber Picks AJ O’Neal The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim How to Diagnose and Fix Everything Electronic, Second Edition by Michael Jay Geier   Charles Max Wood https://andyfrisella.com/blogs/mfceo-project-podcast https://www.garyvaynerchuk.com/the-askgaryvee-show-podcast/ The 1-Page Marketing Plan: Get New Customers, Make More Money, And Stand out From The Crowd by Allan Dib Skyward by Brandon Sanderson Anatoliy Zaslavskiy Acro yoga http://www.cuddleparty.com/  

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit CacheFly Panel AJ O’Neal Charles Max Wood Joined by Special Guest: Anatoliy Zaslavskiy Summary Anatoliy Zaslavskiy introduces pickle.js and answers the panels questions about using it. The panel discusses the automated testing culture and employee retention. The panel discusses job satisfaction and why there is so much turn over in development jobs. Charles Max Wood reveals some of the reasons that he left past development jobs and the panel considers how the impact of work environments and projects effect developers. Ways to choose the right job for you and how to better a work situation is discussed. Anatoliy finishes by advocating for junior developers and explaining the value they bring to a company. Links https://github.com/storybooks/storybook https://www.picklejs.com/docs/getting-started https://opencv.org/ https://itunes.apple.com/us/app/snapcrap/id1436238261 https://tolicodes.com/ https://www.facebook.com/tolicodes https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber Picks AJ O’Neal The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim How to Diagnose and Fix Everything Electronic, Second Edition by Michael Jay Geier   Charles Max Wood https://andyfrisella.com/blogs/mfceo-project-podcast https://www.garyvaynerchuk.com/the-askgaryvee-show-podcast/ The 1-Page Marketing Plan: Get New Customers, Make More Money, And Stand out From The Crowd by Allan Dib Skyward by Brandon Sanderson Anatoliy Zaslavskiy Acro yoga http://www.cuddleparty.com/  

Designers, developers, marketers, operations and finance are just a sampling of the parties that are coming together to make digital products for enterprises. As you can imagine (and have probably experienced), getting these often separate groups of people to march in the same direction can be difficult. On this episode, we talk with Director of Product Design, Christy Ennis-Kloote & Connected Products & Data Analytics Practice Lead, Aaron Kamphuis about the pitfalls some digital teams face as they attempt to organize and make something great. From team size and deadlines to communication and agile process, Christy & Aaron break down these common issues and suggest some alternative ways to assemble and work toward a common goal. Christy & Aaron mention a few recommended books in this episode, including: The 5 Dysfunctions of a Team https://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756 If videos are more your thing, the author has 40-minute talk that summarizes the content well. https://www.youtube.com/watch?v=wHpB1EBufFo The Trusted Advisor https://www.amazon.com/Trusted-Advisor-David-H-Maister/dp/0743212347 The Phoenix Project https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592 Enjoy!

Sponsors Sentry use the code "devchat" for $100 credit TripleByte Panel Dave Kimura Nate Hopkins Charles Max Wood Special Guest - Radoslav Stankov   In this episode, the panelists of Ruby Rogues speak with Radoslav Stankov about GraphQL and its implementation in depth. Radoslav is based out of Sofia, Bulgaria and is the head of the engineering team at Product Hunt. He is a full stack developer since 2002, working on JavaScript, Ruby on Rails, Elixir and GraphQL.   Show Notes: 0:00 – Charles introduces the panel and the special guest. 0:30 – Advertisement: Sentry - Use the code “devchat” to get two months free on Sentry’s small plan. 1:40   - Radoslav introduces himself and gives a short description about what he is working on. 2:20 - Charles asks him about the stack at Product Hunt and details about the company. Radoslav gives a brief historical background while explaining that they moved to GraphQL two years ago. He states that his team consists of about six full stack developers. He explains that GraphQL is their main API currently for communicating with the Rail backend and a React client in the front. He also mentions that they released a new iOS app recently. 5:12 - Charles asks if increasing number of websites are moving toward the mentioned model where Rails provides the backend API and rendering happens in the front. Radoslav agrees while saying Rails is faster but if the complexity increases, it starts becoming increasingly complex. He gives an example of views to explain his point. He interprets GraphQL as an update on REST API which is much cleaner and easier to work with.  7:08 - Dave agrees that GraphQL is interesting and compares it to SOAP interface while explaining the comparison in detail. He asks Radoslav the reason why GraphQL is used internally without a client facing API. Radoslav answers that he prefers GraphQL to be private and explains with an example using it internally is very flexible, hassle free and can be used for anything that the user wants to do in a simple manner.  11:30 - Dave asks does GraphQL handles versioning as the application matures. Radoslav elaborates on it by saying that versioning is similar to REST API and with GraphQL, the scheme is statically typed and it’s easy to identify information such as which field was requested frequently by the customer and which needs to be deprecated.  14:08 - Dave asks if GraphQL has a documentation API like Swagger. Radoslav talks about a tool called “graphical” which is an IDE for graphical queries that generates automatic documentation. 15:31 - Nate asks about the origin of the metric tracking in GraphQL. Radoslav says that it comes from certain tools, that all the libraries such JavaScript, Ruby, Elixir have instrumentation hooks and information is obtained by plugging into them.  16:22 - Nate then says that this is basically like hoisting SQL database to frontend layer and then goes on to ask how the database queries are optimized. Radoslav explains in detail that the optimization is done similar as normal Rails and explains the process of batching. He mentions that he has written two blog posts on the same topic - optimization for N+1 queries. 19:27 - Dave shares that GraphQL has a good feature where you can restrict the query based on what the user wants. Radoslav talks about the method of caching for optimization.  21:30 - Charles asks if building resolvers has gotten better than before. Radoslav answers in affirmative and talks about the usage of classes, methods and mutations that makes the procedure simple. He explains that one of his libraries has a GraphQL plugin where you have to define search queries and it exports those to GraphQL types and arguments that can be plugged into GraphQL schema. 24:20 - Nate asks about the implementation of GraphQL components. Radoslav says that it is separated into a single namespace, exposed to a controller, the GraphQL types are matched to REST serializers. The frontend has React component and the backend contains the controller, utility classes and the GraphQL logic. He then goes on to explain the structure in depth.   26:47 - Nate asks if this strategy has been blogged about to which Radoslav answers that he hasn’t but has given talks on it.   27:15 - Nate asks about the downsides of GraphQL. Radoslav shares his worries about making the API public as it should be made more bullet-proof as it could have performance issues on such a large scale and would involve much better monitoring. He says that authorization for resources would also be a problem. 29:17 - Nate mentions that in the end it is a tradeoff as it is with any software and asks at what point does it start to make sense to use GraphQL. Radoslav answers that it depends on the roadmap, the kind of the product is and gives some examples to elaborate further.   31:35 - Nate says that early planning could be needed for growing the team in a particular way. He also talks about the disadvantage of growing trends that break down solutions into smaller parts that it takes away the ability of small teams to build entire solutions. Radoslav says that while it is true, the developers in his team are full stack and capable of working with all kinds of tasks be it frontend or backend that come their way. 35:45 - Nate asks about the team’s hiring practices. Radoslav describes that they started with senior developers and later on hired interns and juniors as well. He states that interns and juniors ask better questions and work well with component driven design.   39:18 - Nate asks why Ruby is considered to be a good choice for GraphQL. Radoslav answers that the Ruby implementation of GraphQL is one of the best, used by big companies like Shopify, GitHub, Airbnb. It solves code scaling issues and integrates well with Rails.  42:45 - Dave says that it will be interesting to see what Facebook will come up next in the frontend framework. Radoslav agrees and says Facebook infrastructure team makes good tradeoffs and gives the example that each time there is React update, the team updates the whole codebase to the newest React version. 45:56 – Dave and Radoslav talk about the React team’s versioning being unusual. 46:23 – Advertisement - TripleByte - 1000$ signing bonus for listeners 47:20 – Picks! 54:50 – Radoslav mentions that he is available as rstankov on Twitter, GitHub and his website is www.rstankov.com. 55:25 – END – Advertisement – CacheFly!   Picks Dave Swing Cars - for kids Dewalt USB charger Nate Multipliers - How the Best Leaders Make Everyone Smarter Jimmy Buffet songs - A Pirate looks at Forty, Come Monday Charles For listeners - Tag devchat episodes on tv or github.com/cmaxw/devchat-eleventy. For every 5 episodes tagged (particularly Ruby, JavaScript, testing, new programmers, etc), one hour of coaching will be given. You can open an issue on GitHub for each episode you’re tagging so it does not get mixed up with other listeners. “How to Get a Job” - Book in progress. Radoslav Marc-Andre GraphQL Schema Design at GraphQL summit The Phoenix Project 

Sponsors Sentry use the code "devchat" for $100 credit TripleByte Panel Dave Kimura Nate Hopkins Charles Max Wood Special Guest - Radoslav Stankov   In this episode, the panelists of Ruby Rogues speak with Radoslav Stankov about GraphQL and its implementation in depth. Radoslav is based out of Sofia, Bulgaria and is the head of the engineering team at Product Hunt. He is a full stack developer since 2002, working on JavaScript, Ruby on Rails, Elixir and GraphQL.   Show Notes: 0:00 – Charles introduces the panel and the special guest. 0:30 – Advertisement: Sentry - Use the code “devchat” to get two months free on Sentry’s small plan. 1:40   - Radoslav introduces himself and gives a short description about what he is working on. 2:20 - Charles asks him about the stack at Product Hunt and details about the company. Radoslav gives a brief historical background while explaining that they moved to GraphQL two years ago. He states that his team consists of about six full stack developers. He explains that GraphQL is their main API currently for communicating with the Rail backend and a React client in the front. He also mentions that they released a new iOS app recently. 5:12 - Charles asks if increasing number of websites are moving toward the mentioned model where Rails provides the backend API and rendering happens in the front. Radoslav agrees while saying Rails is faster but if the complexity increases, it starts becoming increasingly complex. He gives an example of views to explain his point. He interprets GraphQL as an update on REST API which is much cleaner and easier to work with.  7:08 - Dave agrees that GraphQL is interesting and compares it to SOAP interface while explaining the comparison in detail. He asks Radoslav the reason why GraphQL is used internally without a client facing API. Radoslav answers that he prefers GraphQL to be private and explains with an example using it internally is very flexible, hassle free and can be used for anything that the user wants to do in a simple manner.  11:30 - Dave asks does GraphQL handles versioning as the application matures. Radoslav elaborates on it by saying that versioning is similar to REST API and with GraphQL, the scheme is statically typed and it’s easy to identify information such as which field was requested frequently by the customer and which needs to be deprecated.  14:08 - Dave asks if GraphQL has a documentation API like Swagger. Radoslav talks about a tool called “graphical” which is an IDE for graphical queries that generates automatic documentation. 15:31 - Nate asks about the origin of the metric tracking in GraphQL. Radoslav says that it comes from certain tools, that all the libraries such JavaScript, Ruby, Elixir have instrumentation hooks and information is obtained by plugging into them.  16:22 - Nate then says that this is basically like hoisting SQL database to frontend layer and then goes on to ask how the database queries are optimized. Radoslav explains in detail that the optimization is done similar as normal Rails and explains the process of batching. He mentions that he has written two blog posts on the same topic - optimization for N+1 queries. 19:27 - Dave shares that GraphQL has a good feature where you can restrict the query based on what the user wants. Radoslav talks about the method of caching for optimization.  21:30 - Charles asks if building resolvers has gotten better than before. Radoslav answers in affirmative and talks about the usage of classes, methods and mutations that makes the procedure simple. He explains that one of his libraries has a GraphQL plugin where you have to define search queries and it exports those to GraphQL types and arguments that can be plugged into GraphQL schema. 24:20 - Nate asks about the implementation of GraphQL components. Radoslav says that it is separated into a single namespace, exposed to a controller, the GraphQL types are matched to REST serializers. The frontend has React component and the backend contains the controller, utility classes and the GraphQL logic. He then goes on to explain the structure in depth.   26:47 - Nate asks if this strategy has been blogged about to which Radoslav answers that he hasn’t but has given talks on it.   27:15 - Nate asks about the downsides of GraphQL. Radoslav shares his worries about making the API public as it should be made more bullet-proof as it could have performance issues on such a large scale and would involve much better monitoring. He says that authorization for resources would also be a problem. 29:17 - Nate mentions that in the end it is a tradeoff as it is with any software and asks at what point does it start to make sense to use GraphQL. Radoslav answers that it depends on the roadmap, the kind of the product is and gives some examples to elaborate further.   31:35 - Nate says that early planning could be needed for growing the team in a particular way. He also talks about the disadvantage of growing trends that break down solutions into smaller parts that it takes away the ability of small teams to build entire solutions. Radoslav says that while it is true, the developers in his team are full stack and capable of working with all kinds of tasks be it frontend or backend that come their way. 35:45 - Nate asks about the team’s hiring practices. Radoslav describes that they started with senior developers and later on hired interns and juniors as well. He states that interns and juniors ask better questions and work well with component driven design.   39:18 - Nate asks why Ruby is considered to be a good choice for GraphQL. Radoslav answers that the Ruby implementation of GraphQL is one of the best, used by big companies like Shopify, GitHub, Airbnb. It solves code scaling issues and integrates well with Rails.  42:45 - Dave says that it will be interesting to see what Facebook will come up next in the frontend framework. Radoslav agrees and says Facebook infrastructure team makes good tradeoffs and gives the example that each time there is React update, the team updates the whole codebase to the newest React version. 45:56 – Dave and Radoslav talk about the React team’s versioning being unusual. 46:23 – Advertisement - TripleByte - 1000$ signing bonus for listeners 47:20 – Picks! 54:50 – Radoslav mentions that he is available as rstankov on Twitter, GitHub and his website is www.rstankov.com. 55:25 – END – Advertisement – CacheFly!   Picks Dave Swing Cars - for kids Dewalt USB charger Nate Multipliers - How the Best Leaders Make Everyone Smarter Jimmy Buffet songs - A Pirate looks at Forty, Come Monday Charles For listeners - Tag devchat episodes on tv or github.com/cmaxw/devchat-eleventy. For every 5 episodes tagged (particularly Ruby, JavaScript, testing, new programmers, etc), one hour of coaching will be given. You can open an issue on GitHub for each episode you’re tagging so it does not get mixed up with other listeners. “How to Get a Job” - Book in progress. Radoslav Marc-Andre GraphQL Schema Design at GraphQL summit The Phoenix Project 

Sponsors Sentry use the code "devchat" for $100 credit TripleByte Panel Dave Kimura Nate Hopkins Charles Max Wood Special Guest - Radoslav Stankov   In this episode, the panelists of Ruby Rogues speak with Radoslav Stankov about GraphQL and its implementation in depth. Radoslav is based out of Sofia, Bulgaria and is the head of the engineering team at Product Hunt. He is a full stack developer since 2002, working on JavaScript, Ruby on Rails, Elixir and GraphQL.   Show Notes: 0:00 – Charles introduces the panel and the special guest. 0:30 – Advertisement: Sentry - Use the code “devchat” to get two months free on Sentry’s small plan. 1:40   - Radoslav introduces himself and gives a short description about what he is working on. 2:20 - Charles asks him about the stack at Product Hunt and details about the company. Radoslav gives a brief historical background while explaining that they moved to GraphQL two years ago. He states that his team consists of about six full stack developers. He explains that GraphQL is their main API currently for communicating with the Rail backend and a React client in the front. He also mentions that they released a new iOS app recently. 5:12 - Charles asks if increasing number of websites are moving toward the mentioned model where Rails provides the backend API and rendering happens in the front. Radoslav agrees while saying Rails is faster but if the complexity increases, it starts becoming increasingly complex. He gives an example of views to explain his point. He interprets GraphQL as an update on REST API which is much cleaner and easier to work with.  7:08 - Dave agrees that GraphQL is interesting and compares it to SOAP interface while explaining the comparison in detail. He asks Radoslav the reason why GraphQL is used internally without a client facing API. Radoslav answers that he prefers GraphQL to be private and explains with an example using it internally is very flexible, hassle free and can be used for anything that the user wants to do in a simple manner.  11:30 - Dave asks does GraphQL handles versioning as the application matures. Radoslav elaborates on it by saying that versioning is similar to REST API and with GraphQL, the scheme is statically typed and it’s easy to identify information such as which field was requested frequently by the customer and which needs to be deprecated.  14:08 - Dave asks if GraphQL has a documentation API like Swagger. Radoslav talks about a tool called “graphical” which is an IDE for graphical queries that generates automatic documentation. 15:31 - Nate asks about the origin of the metric tracking in GraphQL. Radoslav says that it comes from certain tools, that all the libraries such JavaScript, Ruby, Elixir have instrumentation hooks and information is obtained by plugging into them.  16:22 - Nate then says that this is basically like hoisting SQL database to frontend layer and then goes on to ask how the database queries are optimized. Radoslav explains in detail that the optimization is done similar as normal Rails and explains the process of batching. He mentions that he has written two blog posts on the same topic - optimization for N+1 queries. 19:27 - Dave shares that GraphQL has a good feature where you can restrict the query based on what the user wants. Radoslav talks about the method of caching for optimization.  21:30 - Charles asks if building resolvers has gotten better than before. Radoslav answers in affirmative and talks about the usage of classes, methods and mutations that makes the procedure simple. He explains that one of his libraries has a GraphQL plugin where you have to define search queries and it exports those to GraphQL types and arguments that can be plugged into GraphQL schema. 24:20 - Nate asks about the implementation of GraphQL components. Radoslav says that it is separated into a single namespace, exposed to a controller, the GraphQL types are matched to REST serializers. The frontend has React component and the backend contains the controller, utility classes and the GraphQL logic. He then goes on to explain the structure in depth.   26:47 - Nate asks if this strategy has been blogged about to which Radoslav answers that he hasn’t but has given talks on it.   27:15 - Nate asks about the downsides of GraphQL. Radoslav shares his worries about making the API public as it should be made more bullet-proof as it could have performance issues on such a large scale and would involve much better monitoring. He says that authorization for resources would also be a problem. 29:17 - Nate mentions that in the end it is a tradeoff as it is with any software and asks at what point does it start to make sense to use GraphQL. Radoslav answers that it depends on the roadmap, the kind of the product is and gives some examples to elaborate further.   31:35 - Nate says that early planning could be needed for growing the team in a particular way. He also talks about the disadvantage of growing trends that break down solutions into smaller parts that it takes away the ability of small teams to build entire solutions. Radoslav says that while it is true, the developers in his team are full stack and capable of working with all kinds of tasks be it frontend or backend that come their way. 35:45 - Nate asks about the team’s hiring practices. Radoslav describes that they started with senior developers and later on hired interns and juniors as well. He states that interns and juniors ask better questions and work well with component driven design.   39:18 - Nate asks why Ruby is considered to be a good choice for GraphQL. Radoslav answers that the Ruby implementation of GraphQL is one of the best, used by big companies like Shopify, GitHub, Airbnb. It solves code scaling issues and integrates well with Rails.  42:45 - Dave says that it will be interesting to see what Facebook will come up next in the frontend framework. Radoslav agrees and says Facebook infrastructure team makes good tradeoffs and gives the example that each time there is React update, the team updates the whole codebase to the newest React version. 45:56 – Dave and Radoslav talk about the React team’s versioning being unusual. 46:23 – Advertisement - TripleByte - 1000$ signing bonus for listeners 47:20 – Picks! 54:50 – Radoslav mentions that he is available as rstankov on Twitter, GitHub and his website is www.rstankov.com. 55:25 – END – Advertisement – CacheFly!   Picks Dave Swing Cars - for kids Dewalt USB charger Nate Multipliers - How the Best Leaders Make Everyone Smarter Jimmy Buffet songs - A Pirate looks at Forty, Come Monday Charles For listeners - Tag devchat episodes on tv or github.com/cmaxw/devchat-eleventy. For every 5 episodes tagged (particularly Ruby, JavaScript, testing, new programmers, etc), one hour of coaching will be given. You can open an issue on GitHub for each episode you’re tagging so it does not get mixed up with other listeners. “How to Get a Job” - Book in progress. Radoslav Marc-Andre GraphQL Schema Design at GraphQL summit The Phoenix Project 

I recently read a book called “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win”. All in all, it is very inspiring book. So I would highly recommend you give it a read. https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/ 5 minutes of React - podcast about React hot topics and JavaScript ecosystem. https://5minreact.audio

Dan and James are joined by Jason Hoyt, who is the CEO and co-founder of PeerJ, an open access journal for the biological and medical sciences. Here's some of what they cover: PeerJ’s model and how it got started What goes into running a journal Impact factors vs. low-cost publishing When the journal user experience is too good Getting a quick reviewer turnaround The need scientists to change their practices (not publishers) PeerJ’s membership model Glamour journals Future plans for PeerJ Predatory journals Researchers don’t want cheap journals, only impact factors Links - PeerJ: https://peerj.com - The Phoenix project: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO - The Goal: https://www.amazon.com/Goal-Process-Ongoing-Improvement-ebook/dp/B002LHRM2O/ref=pdsim3512?encoding=UTF8&psc=1&refRID=EMTE1M9W2XW5Q24X4GE8 Music credits: Lee Rosevere freemusicarchive.org/music/Lee_Rosevere/ Special Guest: Jason Hoyt.

Colin McNamara is the Founder and Principle Consultant at Farkley, where he helps Companies, Communities and Individuals succeed in a world be transformed by next generation technologies. In this episode Colin shares his secrets to success for the very first time with our listeners at the end of this episode!    Sponsor: www.zerotoEngineer.com - Level up and become a full stack network engineer!   Favorite Quote: The difficult we do immediately, the impossible just takes a little longer - U.S. Navy Seabees   My 2017 Experiment - What would happen if you applied the core principles of DevOps; Lean and Agile and applied them to every aspect of your life.   What would happen if you took the time do it right?  What would happen if you took that time to grow your self, your employees and your company? What would happen if you ran your own life like your business, and your business like your life?   Tech Topic of the Day: How IOT, Cognitive Compute, Robotics, Lean and Agile are are coming together with the 5G LTE refresh to change how we interact with the world around us.    Favorite Tool or Application? Trello Board   Favorite Book: Phoenix Project https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business

Episode 4 av BEKK Open Podcast handler om API-er og Tjenestedesign.Først får vi besøk av Mads Mobæk og Kristoffer Dyrkorn som har sett på API-revolusjonen som skjer blant norske bedrifter nå. Vi diskuterer hvilke muligheter dette gir, og hvordan man bør gå frem for å lage et godt API.Deretter får vi besøk av Hilde Johannessen som snakker om tjenestedesign og hvor viktig det er å fokusere på behov fremfor løsning.Til slutt er Thomas Gøytil på plass i sikkerhetsspalten og vi diskuterer hvordan Virginias valgmaskiner var sårbare for angrep fra alle kanter.Linker og slikt:The Phoenix Project: http://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business/dp/0988262509/I

Our annual list of the top 10 books we read this last year--fiction and non-fiction.Listen now: (download)Russ' top non-fiction:Antifragile: Things that Gain from Disorder (A Book Review)To Save Everything, Click Here: The Folly of Technological SolutionismThe Innovators (Book Review Episode)Dataclysm (Episode: The Intersection of Product Design and Big Data with Natasha Irizarry)The Idea FactoryBett's top non-fiction:The Phoenix ProjectScrum: The Art of Doing Twice the Work in Half the TimeThe Glass CageTo Save Everything, Click Here: The Folly of Technological SolutionismSeneca: Letters from a StoicRuss' top fictionThe Martian: A NovelDaemonCat's Cradle: A NovelWhite NoiseThe CircleBett's top fictionThe Martian: A NovelThe CircleHyperionAndroid's DreamDaemon