Podcast appearances and mentions of Simon Wardley

Strategic tools can help you navigate organisational and market complexities. But how do you even begin to make sense of it all?In this episode, Simon Wardley, the creator of Wardley Mapping and one of the most profound thinkers and influencers in strategy, explains the power of mapping complex ecosystems. He speaks on how building resilient organisations goes beyond clever tactics and requires a deep understanding of the landscapes you're navigating. He highlights how most organisations still struggle to truly understand their customers, and emphasises why it's crucial to realign strategies, foster a shared language, and enable cohesiveness to create true “value.”For leaders, this conversation serves as a call to rethink how you approach both organisational structures and the strategies needed to stay adaptable in a constantly changing landscape.Simon brings a wealth of experiential knowledge in strategy, having contributed to the growth of some of the biggest organisations worldwide. In this podcast, he delves into the evolution of technology, organisational structures, and strategy, with a particular focus on the impact of AI. He challenges our fear of rapid technological advancement by sharing how tech's true development follows a more gradual process, ultimately leading to sudden bursts of change - a more nonlinear growth.He also explores other critical themes like - the evolution of organisational structures, referencing his explorers-villagers-town planners model, the need to have strong guiding principles, and also shares why the engineer is the true architect of a technology.So, for anyone seeking a roadmap to navigate complexity correctly, this conversation is a must-listen. Tune in. Key Highlights

In this episode, Simon Wardley, together with Carola Lilienthal, Tsvetelina Plummer, Markus Harrer, and Eberhard Wolff, discusses how the visual strategic thinking tool Wardley Maps can help software architects make better decisions. After a brief introduction to Wardley Mapping, you'll hear about several ideas and patterns that can be useful when developing large-scale software systems. Links Simon's keynote at Agile meets Architecture

(05:57) Brought to you by Swimm.io.⁠⁠⁠⁠Start modernizing your mainframe faster with Swimm.Understand the what, why, and how of your mainframe code.Use AI to uncover critical code insights for seamless migration, refactoring, or system replacement.Are we looking at software engineering the wrong way?What if it's less about writing code and more about making better decisions in an ever-changing system?Learn a revolutionary approach to understanding complex software systems in my conversation with Tudor Girba, the CEO of feenk. We explore “Moldable Development,” a groundbreaking concept that challenges traditional views of software engineering. Learn why treating development as a decision-making process, supported by custom tools, is crucial for tackling today's software challenges, especially when dealing with legacy systems.Key topics discussed:Software Engineering as Decision-Making: Why software development is fundamentally about making informed decisions rather than just constructing systems.The Inefficiency of Reading Code: Developers spend over 50% of their time reading code, yet this activity remains unoptimized.Moldable Development: Learn how creating custom tools tailored to specific problems can revolutionize your workflow and decision-making process.Legacy Systems as Opportunities: Reframe legacy systems as value-creation opportunities instead of burdens.Glamorous Toolkit: Discover the innovative development environment enabling thousands of micro-tools for better system understanding.The Future of Development Environments: Explore how AI, moldable development, and tools like Glamorous Toolkit can coexist to solve diverse class of problems.This conversation will completely transform how you think about software development!  Timestamps:(00:01:57) Career Turning Points(00:08:29) Understanding How We Read Code(00:10:43) Software Engineering is a Decision-Making Activity(00:13:19) Reading Code is a Suboptimal Activity(00:16:44) Moldable Development(00:22:47) The Challenges with Legacy Systems(00:30:17) Moldable Development Workflow(00:46:02) Glamorous Toolkit(00:54:15) IDE, AI, and Glamorous Toolkit(01:00:36) Writing with Simon Wardley(01:03:01) 1 Tech Lead Wisdom_____Tudor Girba's BioTudor Girba is the CEO of feenk, a company focused on modernizing legacy systems. They do that through Moldable Development, a way of programming through contextual tools. They build Glamorous Toolkit, a free and open-source moldable development environment, to show how working through thousands of contextual tools per system can be practical. In 2014, Tudor received the prestigious Dahl-Nygaard Junior Prize for his work on modeling and visualisation of evolution and interplay of large numbers of objects.Follow Tudor:LinkedIn – linkedin.com/in/girbaBluesky – bsky.app/profile/tudorgirba.comX – x.com/girbafeenk – feenk.comGlamorous Toolkit – gtoolkit.com

In this compelling episode, Bryon Kroger, founder and CEO of Rise8 and the former COO of the U.S. Air Force's groundbreaking Kessel Run program, reflects on his journey from intelligence officer to software innovator and leader of transformative change. Bryon shares candid lessons learned from catalyzing digital transformation within one of the largest bureaucracies in the world and offers a nuanced perspective on the interplay between rebellion and revolution in creating lasting impact.A central theme of the conversation is the distinction Bryon draws between rebels and revolutionaries. While rebels may succeed in challenging the status quo, revolutionaries think long-term, building alliances and maintaining patience to achieve sustainable change. Bryon shares his own experiences navigating this balance, reflecting on moments where his rebellious instincts needed to give way to the humility and strategy of a true revolutionary. His insights provide a framework for leaders aiming to drive progress without alienating stakeholders.Drawing on Simon Wardley's Pioneer, Settler, Planner model, Bryon illustrates how Catalysts serve as vital bridges between visionary pioneers and methodical planners to drive organizational change. He unpacks the delicate balance of maintaining strategic patience while acting with tactical urgency, emphasizing the importance of vision, humility, and active listening to inspire others to embrace change.As an executive, Bryon underscores the critical need to "create other Catalysts," explaining how scaling leadership through cultural transformation and skill development fosters sustainable growth. Reflecting on his transition from government to private sector leadership, Bryon shares his evolving approach to navigating resistance and offers powerful advice for knowing when to persevere or walk away from a battle to win the broader war.Original music by ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Lynz Floren⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠.

This interview was recorded for GOTO Unscripted.https://gotopia.techRead the full transcription of this interview hereSusanne Kaiser - Independent Tech Consultant & Author of "Architecture for Flow"Michaela Greiler - Code Reviews Expert, Trainer & ConsultantAdele Carpenter - Software Engineer at TriforkDaniel Terhorst-North - Originator of Behavior Driven Development (BDD) & Principal at Dan North & AssociatesSimon Wardley - Thought Lord, Mapper, Mostly GoodRESOURCESSusannehttps://mastodon.social/@suksrhttps://susannekaiser.netMichaelahttps://twitter.com/mgreilerhttps://michaelagreiler.comAdelehttps://bsky.app/profile/97adele.bsky.socialDanielhttps://bsky.app/profile/suksr.bsky.socialhttp://dannorth.net/blogSimonhttps://bsky.app/profile/swardley.bsky.socialhttp://blog.gardeviance.orgDESCRIPTIONExplore the rich tapestry of what it truly means to support developers.The conversation took a forward-looking turn as they examined the role of AI, not as a looming replacement, but as a powerful ally that enhances human creativity, much like past innovations that revolutionized workflows. They showcased how intuitive design—exemplified by tools like IntelliJ—can make a developer's experience seamless and enjoyable.RECOMMENDED BOOKSSusanne Kaiser • Adaptive Systems With Domain-Driven Design, Wardley Mapping & Team TopologiesSimon Wardley • Wardley MapsSimon Wardley • Wardley Mapping, The KnowledgeMatthew Casperson • DevEx as a ServiceChristian Clausen • Five Lines of CodeDavid Anderson, Marck McCann & Michael O'Reilly • TBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Have you ever had to do a leadership hand-off? Welcome to part one of my series on Crossroads. My hope for this series is to give you the clarity, confidence and courage you need at the crossroads of life. For this first conversation, I speak with the "Business Transition Sherpa", Laurie Barkman about how she helps business owners transition out of their roles and hand off their leadership to others. Which leads to a rich discussion about growth during transitions, how emotional intelligence plays a big part, and what it looks like to move forward with trust instead of fear. Let's dive in! Free ResourceIn the show I reference an analogy I love from Simon Wardley's Pioneers, Settlers, and Town Planners model. My team put together a helpful PDF for you to get a great visual and more info on the analogy.Download the free Pioneers, Settlers, and Town Planners PDFEnjoy!Step into The Life You're Made For, I'm cheering you on!heatherpenny.com@heatherpennyphdMusic by Jason SquiresProduction by Cody Vermillion

Subscribe to The Beautiful Mess Podcast in your favorite podcast platform using this RSS URL: https://api.substack.com/feed/podcast/24711.rssIntroductionIn today's episode of The Beautiful Mess Podcast, I am talking to Chris Butler. Chris is currently a staff product operations manager at GitHub.During his career, he's worked at companies like Google, Facebook, Cognizant, Kayak, and Waze, as well as founding the Uncertainty Project. Chris embraces the mess like few people I've met. Defying categorization in his career path, inventing models and techniques for collaboration and sense-making, he's well versed in engineering, design and product, and figuring out how to challenge the status quo in big companies.Somehow he manages to be a mad scientist in terms of ways of working, and have a day job. In this episode we talk about being a change agent, introducing new ways of working, embracing a persona external to your day job, and interesting stories about the Google culture and define career categorizations.Enjoy.Transcript[00:00:00] John Cutler: Hi Chris, welcome to the It Depends podcast. How are you doing?[00:01:07] Chris Butler: Good. Thank you for having me. I'm excited to say it depends as many times as possible during this podcast.[00:01:13] John Cutler: You will not be judged for saying it depends in this podcast.[00:01:17] Chris Butler: I have the it depends jar over here that I have to keep putting, you know, a dollar in every single time I say it on other places. So it's, it's good that this is an open space.[00:01:25] John Cutler: And it depends safe space for sure. One thing I wanted to start out with is that typically there's things about our personal experience or how we grew up or maybe the jobs we've had, our personal context, which is our own personal It Depends. When you think about your personal experience, what are some things that stood out that have shaped how you view situations?[00:01:44] Chris Butler: I really hate the question, at a barbecue, "Like, what do you do?" It requires me to simplify down what I am and kind of my experience around what I do down to a place that is you know, maybe not helpful.[00:01:58] In high school I would help teach the C programming course because I was taught by another student and the teachers there didn't know how to do C programming. So I basically taught that course. I was a senior class vice president, but I ran on the anarchist ticket, mostly about how we would get like better pencil machines in the hallways.[00:02:16] And then I was, you know, a team captain on a football team, three time All League, Honorable Mention of my Empire. And I also built red boxes and ran bulletin board systems that were like, Warez Bulletin Boards back in the day.[00:02:30] I try not to require my identity to become one thing. Rather than like a T shaped career or whatever those other things are, like an octopus career. And the reason why I like that is because, you know, the octopus is like a very interesting neural kind of, system where it has one brain, but it also has like brains in all of its arms.[00:02:49] I guess I've just started to allow myself to be more comfortable with having a bunch of different things that maybe unify in certain cases. And I get paid for those things or it's part of my daily job. But I think I've just always followed my interests.[00:03:01] The anarchist kind of thread in my background or the fact that I was building red boxes or doing warez boards kind of says to me a little bit that I also have a problem with doing things within the rules sometimes. I don't think this is fair, right? Like just to be very clear, I don't think this is fair, but I feel like I have a natural distrust for leaders. I realized that there are also people, right. And there was a great post that came out a little while ago that was basically like, you will never fully love your manager no matter what, because of just the way, the way that these systems work.[00:03:29] That's maybe something that has really formed the way I think about all of this stuff and the work that I do on a regular basis is really, it's, it's a lot about how are we pushing back on just the way things are. That's where I would say, you know, I've kind of come from and maybe that's, that's the reason why I am the way I'm today.[00:03:46] John Cutler: I'm curious, when you start a new job do you know you've found your fellow Anarchist, you know, football captain, you know, cause certainly you could run into the football captain in the hall and say, Hey, welcome, welcome to the Anarchy Club, you were in the Anarcy Club too. And they, they might not be too happy with that statement.[00:04:04] John Cutler: How do you know that you found your tribe when you're in a company?[00:04:08] Chris Butler: Joining very large companies is interesting because I guess I see part of what my benefit is to people is building connections between maybe topics that don't make sense together, but also connecting and creating networks within the organization I'm in .[00:04:23] For example, there's a group called Flux and Gale, and it was started by someone internal to Google that was all about people that are model thinkers, system thinkers, like that type of stuff.[00:04:35] You kind of have to pretend to just be a regular person at first. I guess. When you find your other community, it's not because you want to just like be the same as everybody else. It's that you want your thinking challenged in this domain and they have the tools, the terminology, the language and the background to be able to then push you.[00:04:54] I've been doing a lot of stuff with something called design fiction, which is really about this idea of like prototyping some future artifact. And then how do we use that in a bunch of different ways? Like I I've given a talk about like product management is product management, fiction, right? Which like everything we write as product managers is fiction at first. It just happens to be really boring fiction, unfortunately. And so like, how do we do a better job of that?[00:05:15] But me going into like an intranet site and looking up things like design fiction, I started to find groups of people that were, you know, interested in these topic areas. And from there, I'm just have a natural like networking kind of ability that I then just reach out to people and say, Hey, I did this cool thing over here. I think you might be interested in it.[00:05:33] So that's, that's how I ended up like finding those people is really based on topic areas, but it's not always, it's not always possible. The intranet site that runs something like GitHub is different than the intranet sites that were inside of Google.[00:05:45] It's hard, but if you allow for that iterative exploration, you'll find the next person that is like this and, and maybe pushes you in a way that that would be helpful.[00:05:55] John Cutler: I knew you do a fair amount of speaking external to the companies you work at. curious how the desire to express yourself externally from your companies Is that a balancing act for you so that you can balance the need to project that everywhere internally as well.[00:06:10] Chris Butler: It's more of like an escape valve because I think like whenever we're at an organization, there are cultural expectations. There's the Overton window of what is acceptable or not. I've had previous leaders say we're kind of cutesy or like too smart or something like that. I have to try to gauge what is the Overton window for process change inside of this organization, and how do I push them a little bit so I can do more of this stuff? I think I've started to come to the conclusion, and I think a lot of people in the Wardley Mapping community also think about this, is that like, I can't use the terminology, I can't call it this thing anymore.[00:06:42] I was talking to someone at the product ops summit in New York like a month or two ago. And they were an agile coach that had gone into product operations, which feels like a natural progression, honestly, based on the terminology of today. She was saying that if she then tries to do something like hold a retrospective for the team, especially with her current team, they would be like, no, we're not, we don't do that type of thing. We don't get in a room and just like whine at each other about how bad things are. Right. But when she says like, we just had this launch and the launch went well in a lot of ways, but not in all ways, so why don't we get in a room and let's talk about like what went right, what went wrong and what we could do better next time.[00:07:17] I need a place to be able to experiment with these concepts. And so I use the external speaking as a place to do that. Would say that the values that I really care about personally end up being connection, right? Ends up being how do we actually discover new ways of doing things and then how do I personally learn about things. And so that type of drive for me means that these are going to be topic areas where I think they're on the edge of what is acceptability or considered to be normal or regular for these teams.[00:07:44] And that's what drives me is it's that escape valve.[00:07:46] Now, what's cool though, is that like when people that are part of my work come and see me talk about this stuff. They want to do more of it internally. The problem is how do we do it in a way that still allows leaders to kind of feel the culture that they have is appropriate and it's not too much of an assault on that.[00:08:02] So I think that's the, that's the problem I ended up coming up against is that I want to do these things internally. Right. But it's not always going to be considered to be a good thing if I didn't.[00:08:11] John Cutler: don't know if you have any, an example of something within the Wardley Mapping community, for example, that if you went down a rabbit hole, it would be the best three hours that had ever had. within Google or GitHub or whatever, if you went down that same rabbit hole in the same way, in that, in a different culture, it would not go over well. Maybe to give people like a very tangible, sense of how that would go down.[00:08:33] Chris Butler: Well so like with Wardley Mapping, right? Created by Simon Wardley, there's a bunch of different people that, that are kind of in this community of practice around essentially how do we create value chains and then understand the evolution of them over time, right? That's the simplest way I would put it.[00:08:46] I did a workshop as part of one of the Wardley Mapping online conferences about how you use Wardley Maps as a game board for doing strategic rehearsal or wargaming.[00:08:54] That's the type of thing where those people are like, "Oh, wow, this is actually a very interesting way to use this map to then talk about evolution."[00:09:00] When I did that, by the way, I did that inside of Google as part of our summit. And it was interesting because we did two different exercises as part of this. We did scenario planning where we would create basically critical uncertainty--so a two by two of like two different uncertainties, and it creates four worlds that we want to like talk about.[00:09:16] And the people that were user researchers, designers, they really got that. They, they did a great job inside of Google to do that. The PMs inside of Google had a really hard time thinking about like uncertainty about the future. But then like we, we changed it around and I had people build their Wardley Maps and then we would have random events that would happen and then they would have to like figure out what does that mean.[00:09:36] I think the thing that I do in a lot of these types of workshops or in these discussions, it ends up being that there's a surprise that they need to realize on their own. And so inside of this, I had felt like our strategy was not as like, well formulated as it could have been and was not communicated out in the way it could have been. And so whenever I asked for reflection at the end of this process of using a Wardley Map, people were like, you know, I was like, how did the strategy work out for you? And they were like, we are incredibly reactive.[00:10:03] I think it's things like that where you have to sometimes just not use exactly the type of terminology you want to use, but you want to still get people to some type of transformation or realization. And so, that to me is like, maybe looking at those two different communities, like, that type of wargaming thing could have gone on for actually more hours after that with the Wardley Mapping community. Within my community, It was like a little bit like pulling teeth to get people to think about this, like uncertainty and have an imperfect map. Inside the Wardley Mapping community all these maps are disposable. You create a map and then you will throw it away essentially.[00:10:34] Every time that I've ever done a workshop inside of Google where there's like post it notes, someone's like, "Who's going to write down all these post it notes?" And I'm like, no, we're not. We're just going to throw them all away, like, or recycle them ideally. But like, we don't need to have every single idea captured. It was about the lived experience of everybody inside this workshop that was actually meaningful.[00:10:52] So it's like stances on what is considered to be expertise or great at something, like how certain or uncertain people are. I think it's those kinds of things inside the communities that end up being I think it's very different.[00:11:04] John Cutler: Without necessarily revealing privacy stuff or whatever, what, what is it about the the Google culture that predisposes it to how are we going to write up all the stickies?[00:11:15] Chris Butler: There's a lot of smart people inside of Google, right? For a very long time, the culture was around academic excellence, right? I actually, I interviewed at Google like four times before I got offered a job. And I think it was the first couple of times I got rejected because my high school GPA wasn't that high.[00:11:28] There's like a real academic kind of smartness type of thing that's there. And so what that means is like, for people that are very smart in a particular domain, they tend to think that if they just think hard enough about something, they will come up with the perfect answer.[00:11:40] That's not true in my opinion.[00:11:42] This also is then related to like consensus driven decision making, which I think Google suffers from an awful lot. Where because everybody's like the other part of the culture is kind of like everybody's kind of nice to each other as well. It means that we all have to agree to be able to move forward. Because we're all super smart people, that means all of our opinions are equally weighted. And we have to converge all of them before we can move forward on anything.[00:12:02] And so that's, those are two things I think from the culture. And again, there are benefits to those types of cultures.[00:12:07] I would say that in the face of uncertainty, that's why we have to write down and take notes about every idea that came up because we don't want to miss a good idea that was there, when the reality is like, this was really just more of a workshop to get people to talk to each other in a particular way. And, and so I think that's, that's like a key difference, I think, and the reason why actually it's like that inside of places like Google.[00:12:28] John Cutler: When you think about the Wardley Mapping community. So that's the flip side. Like, what's the first thing that jumps out to you?[00:12:34] riverside_john_cutler_raw-audio_john_cutler's studio_0002: It's[00:12:34] John Cutler: seems like it's a honeypot for a certain type of thinking or need. what, what, what about that context sort of is the flip side for that? Um, cause it attracts a certain type thinker, uh, almost by definition of the visualization.[00:12:53] Chris Butler: I've met a lot of people inside the Wardley Mapping community that, you know, I mean, they're, they're fairly analytical when it comes to trying to understand this because some people are trying to take it into the direction where it's like, we're going to now use this map. Right. And, and you, you know, Double Loop right? Like I think Double Loop is a great example of that type of thing. They are actually trying to, in some way, mechanize these types of strategies. The honeypot of Wardley Mapping is trying to understand what is going on and then making choices about that.[00:13:19] The antithesis to that is that we actually have to make choices together and we want to make sure that everybody's happy. How much of your organization needs to agree to a strategic direction or not?[00:13:29] And I used to think it was like high, like you want to get everybody to agree. Then I was kind of like, Oh, well, maybe it's like 51%. You just need like most people. And then now I'm, now I'm actually of the mind that like, if you have a leader that you trust, it's actually only one person needs to actually believe in that strategy and everybody else can like decide whether they want to stay on that train or not. Basically. Right. Culture is another one. Like, yeah, you can try to change culture. It takes a lot of work to change culture, but if this culture is just not right for you, you just shouldn't be there.[00:13:59] Ideally, right? I think there's issues with like, you know, the fact that compensation and we all have to take care of families and that type of thing that I think ends up muddying this thing. But I think that's the ideal, right? We want to make hard decisions. And I think most of the time making hard decisions is a better strategic value, but that doesn't work inside of consensus driven cultures.[00:14:20] Like, like a Google. If we were to say to our leaders a lot of the time, like, should we do this or that? They'd say, do both. And it was because we also had unlimited resources almost, right? Search and ads are just printing money. So like all these other things we should be able to just like build whatever we want, but maybe the thing that, that Google has done really well that I loved about Google was that they don't feel bad about killing products if they feel like it's not in line. That's great.[00:14:44] And then there was like an internal site called Meme Gen which is known publicly, but it's like a meme site for Googlers. And it's usually very scathing of the leadership. And I thought this was probably one of the most interesting cultural things inside of Google.[00:14:58] If I wanted to understand what was actually going on with the people inside of Google, and it could be negative, a little bit negative sometimes. If I go to Meme Gen, I will understand what most of Google is thinking about, like in reality, not what we're actually talking about when it comes to, like the polished press releases and stuff like that.[00:15:12] John Cutler: I wonder what it is about that culture that would let that type of thing emerge.[00:15:19] it that, well, people are doing pretty well from a financial perspective and they're not going to get fired for saying something scathing? Or maybe that's changed now. Maybe you're like, yeah.[00:15:28] Chris Butler: it's, it is changing. I mean, I think there's always a struggle within organizations about how to allow for people to have, say, political discussions internally. And so that is something. There's an article that just came out recently about how they're removing downvotes because of some of the memes that came out about like the, you know, Israel, Palestine, conflict, right.[00:15:47] So there's things like that, that I think they're still figuring out. Now, there has been a belief that, that Googlers think that like management is trying to slowly kill Meme Gen because they don't like it.[00:15:58] Maybe from the beginning though, too. It's like, if, if you have a lot of really smart people. That are doing their own thing. That means that you allow for this type of like hacker culture. Like that's, that's, that's the truth is, is what's going on here. And so I think as like an organization like Google that's trying to become more of like a shareholder holder value type of organization, rather than an engineering driven organization, I think that's where you start to see that change.[00:16:22] Whereas for me, like it, it actually is very much like an engineer driven way of being is that you just build something because you felt like it was funny, right? That's where, that's where I think Meme Gen comes from, right? And there's lots of stuff like that internally that I thought was like, again, I think is, is an important part of like the culture there, but it's changing over time.[00:16:41] John Cutler: When you see people forming strategies do you have any example of of some contextual factor that they tend to think that matters that doesn't really matter in the grand scheme?[00:16:49] Chris Butler: One of the things I see pretty often is that people think about the plan, not about the strategy. And so we end up getting tied around the axle on like the stack ranking priority of this thing over this thing, rather than what are the rules that we're actually trying to kind of think about from this?[00:17:07] If you look at something like your roadmap or the next projects that are being funded, look at like how many headcount, any of those things are, that is your strategy at that point. And I call it the starter strategy and kind of a, you know, it's fine. Like that's, that's the way most leaders they'll come in. They'll create this like thing, which is a roadmap. That is the strategy, quote unquote, but it's really just like a plan.[00:17:26] That's actually something that leaders shouldn't be doing. Product leaders should not micromanage as much.[00:17:30] And I've definitely heard this concept that people should get into the weeds and worry about it. When the reality is like, If you're a product leader, if you're there to talk about the strategy, then maybe you need to know something about how the execution will take place. And I don't want to create this false dichotomy between strategy and execution. Like every execution includes a strategy of some type. But what I really get annoyed with is like, your job is actually to build culture now or to build the team or to create incentives for practicing in a way that you want people to practice. And that to me is less about like you're helping make these little tiny decisions and it's more about like broader things.[00:18:06] All the decisions then start being like, like led from just the leader rather than being distributed through the team, which is what we really want. That's why you should have a great strategy is because you should make the really hard decisions that people are constantly struggling with very easy. Because here's the strategy that says that we're going to do these things.[00:18:22] When we have things like escalations happening from the people that are at the ground level or at like the practicing level where they're talking with customers and they're building things for customers. If a whole bunch of escalations happen because of this theme, it sounds like that's actually a problem your team is struggling with, and they want guidance, right?[00:18:38] But it shouldn't be on a piece by piece basis. It should be that probably those five different things that are in the same theme, that's a strategy. And that's actually something that's really pertinent to today in making decision making, in doing decisions. We don't have enough where people are looking at the escalations to see how that modifies the strategy.[00:18:55] And then the third kind of last thing I think happens a lot for leaders is that they don't provide the context to their organization as often as they should. We don't have as much, at least I don't see it in a way that really, I think impacts people's day to day is here's kind of the headwinds and tailwinds that I see, like over the last month that I think you should actually know because I have a different context than you. Here's what I think you need to know more about in this world. And I feel like a lot of the time when we do strategy, like reviews, it's just pushing information up in a document or a slide deck or something like that, but there's very little, like, there's no, like, what is the person that's reviewing? What are they going to provide inside this meeting other than just like saying yes or no? Like they should actually be preparing things as well about like what they think is going on with the organization. That that's what I would argue.[00:19:43] John Cutler: When you think about the last couple of years why are we seeing this increase in people saying leaders should get into the details. Why are we saying this so often? Why is Brian Chesky saying this on an interview and, and every day on LinkedIn, someone's saying or have to be more hands on than you thought you were like, what's going on.[00:20:06] Chris Butler: I'm sure that there are leaders that are domain experts, right? Like I, I don't, I, I totally believe that's true. Right. And, and I've, I've often gotten in trouble both internally with my teams or externally on Tik TOK about saying, I don't think product managers should be very technical.[00:20:20] You can be a domain expert as a leader, and you can have good judgment and taste and kind of belief around things. But if you're not actually building teams that are able to be the domain experts. Right. I think that's a failure of leadership or, or a failure of building a team at the very least.[00:20:39] Because I want to make sure that there's like, there's a difference between like being great at hiring and talent development versus leadership in a certain area versus the management mechanisms and politics and all those different things that like are balled into a manager or a senior leader type of position. I want to make sure that that's clear that like, there's a lot of different ways to be a great senior leader. I think the moment that some moment that your job is there to catch all of the failures of your team. That's probably not a very healthy relationship.[00:21:08] That's why, like when, when managers complain that they don't get any like feedback from people, it's because that's the way that they usually are interacted with is like, you're there to make the most perfect presentation possible and any, any failure, like, you know, I've, I've heard about certain leaders that if anybody ever fails for any reason, they're suddenly unlucky and they should not be trusted with anything else. And that just sounds insane to me. You've got to be incredibly lucky. And that's like survivorship bias. Right. So then make it to that point. And maybe that's just the way that they think is the right view of the world. But I think, I don't think it is, I think it's bad for the organizations that they're building[00:21:43] John Cutler: What are some tips to make those sessions more effective?[00:21:46] Chris Butler: Derek Sivers has like a post that's like a two cents and it's all about the fact that a leader's two cents can be taken way out of context when the reality is it was like, just like a throwaway comment. And now someone's spun up a work stream to like figure out what this like two cent comment meant basically.[00:22:02] Speak less. Like it's your, your job is, is there to enable teams and to help them, but not to be like the main speaker, right? Like that, that's what I would argue.[00:22:11] The last thing is to actually believe in the systems that allow for that type of peer feedback. PMs can learn an awful lot from the way that like does great design critiques work or great code reviews happen.[00:22:23] From those kinds of practices, you end up actually learning something much more from each other. And because there's other people there, you accelerate the learning because other people are dealing with other problems. Allowing for that type of thing and actually not only inspiring it, but actually pushing to have those things inside of your teams. I think that is what great leaders should do is they want to create as many opportunities for feedback, between their team members as possible. And they're not always going to be the right ones to do the feedback because again, there's power dynamics. There's the fear of like losing your job because you screwed up, right? Like these are things that are really visceral for people. I don't think that the leader can always do that. What they can do though is they can push for systems that allow for that type of thing and do a better job of that.[00:23:03] I've heard this from a leader specifically that they thought that retrospectives were just whining sessions. And then they sent me a couple of articles about how HBR thought that retrospectives were bad. I get it. Like you need a good facilitator for those things sometimes, right? Like people will rat hole or they'll just want to complain or whatever. But I think overall, like having the team talk in a structured way about things is better than not doing it. Is what I would argue.[00:23:27] And I think this is why leaders, what they should be doing more of, is actually telling people on their team why they made a particular decision. And what was the process by which they did that. And if it's just intuition, Like, I just have tons of experience in this industry and so I'm making a decision based on this. That I think is the part that we, we need senior leaders to describe more.[00:23:44] And this is why like things like forward looking case studies, like decision forcing cases I think are so interesting is that you get everybody in a room from both junior to senior people and I would run these inside of Google. We get L3s to L7s inside of this room. They have to create a slide that is going to be for this offsite. It's very, it's a very PM activity. Right. Um, they, they have five minutes to create a slide that is going to basically frame this conversation that needs to take place.[00:24:09] And it's really interesting because like the L3 people, they, they are like very much, okay, well, here's the traffic light grid of options and characteristics and like red, yellow, green, everything like that, the L7s they would just be like, I have two questions for this audience. It's just like question one, question two. And it's like, the discussion is what matters in that case.[00:24:27] And what's really cool is just seeing the way that those senior leaders think about that in comparison to the junior ones. And they're not wrong or right. They're just like two different ways of looking at it.[00:24:37] I think this is why like strategic rehearsal thing I was talking about for wildly mapping, like. Those senior leaders should not go off and do email during those summits and just have their people do these activities. They should be there actually describing how they would do this. We need leaders to present more of their expertise as well inside these things to be able to describe this.[00:24:55] So that's why, I tend to want to have these types of containers for conversations that rather than the weekly, you know hand down of here's what's going to happen. I want the leader to be part of a game that talks about different decisions and see how different people in that room would do it because you learn about everybody's decision making capability.[00:25:15] That's what I would say. I think those things are more helpful. I've been starting to read this, this book about LARPing live action role playing, but there's this idea of a conceit where I'm going to play this role. It's not really who I am. Right. But I may be a jerk right now or like six hats is a great example of that, right? Like one of those hats is a jerk and it's okay because that's just the way six hats work. Right. So I think like allowing for those types of things that are more exploratory, I think, actually help the entire team learn from each other.[00:25:40] John Cutler: Back in the beginning of the podcast you talked about how you were okay with the flexibility in these particular environments. Right? Now I understand better about how you might be okay with like, uh, this is going to be improv slash, uh, we're going to do a two by two and improv and you're going to make slides and, and going to be fine with, uh, we're going to throw it all away afterwards.[00:26:05] Chris Butler: Right. That's right.[00:26:06] Dave Snowden. We call it acceptation. I think it's this idea of like meta or interdisciplinary thinking. I think we, we can gain an awful lot from that. And, and that's, that's what I love about this work.[00:26:16] John Cutler: One thing I like about how you're describing this though, is that you seem. to like the theory side of it, but then you seem to like manifesting it in an actually very visceral, hands on, out in the world type way. And one thing I've noticed Is that often that duality is not something that people immediately understand, right?[00:26:37] Do you ever get pigeonholed as being very theoretical and academic and you're like you have to raise your hand and say actually "Do you want to do an improv, uh role playing session with me? Like let's LARP. We're gonna go LARPing now." How do you communicate that duality that you seem to have to folks? ,[00:26:55] Chris Butler: I've been definitely called very academic, like very theoretical. But what's funny too is that like with a lot of the people that if I like be coaching someone or trying to mentor them, you know, I'm asking a lot of questions because I'm trying to understand what is the context of what's going on.[00:27:10] And, and people have said like, you know, I'll have a conversation with Chris and it's like the first 55 minutes are just like meandering. I have no idea where they're going. And then he gives me like three things to do with the 55 minute work. And it's like exactly what I needed, basically. You're absolutely right.[00:27:24] I think like part of the product manager's job is to be a toolbox of like methodologies and frameworks, right? It's like shu ha ri from the agile world is, is what we're trying to do.[00:27:32] I think once you get to that point where you're doing your own way. It's usually just a combination of things that have worked. I mean, I think you've said this too, about the fact that like frameworks are usually just an experts encodification of what they usually do. Right. And it worked in that moment, in that place, in that time. And it's trying to now turn it into something that anybody can pick up as a tool. But the reality is like, there's pieces of it that won't exactly work in every context.[00:27:54] Rather than assuming that there's this process that just has to work this exact way, how do we build something that is appropriate and fit for this. And I think maybe dropping another kind of like honeypot name is probably Christopher Alexander and pattern libraries and stuff like that. The way he thinks about things is that we're going to create a beautiful place that is going to be a place for someone to live, that is situated in the environment and gives them the things that they want, like the ability to have like a great breakfast with a beautiful view or something like that.[00:28:24] He really railed against the idea of kind of establishment of licensing for architects, the way that like architecture started to become something that was all about like the perfect way of doing something.[00:28:34] And if it's going to be for people, you have to build things in a very special way. And that's why I think like. We need all these tools and then we have like a team, which is a bunch of just people together and we need to figure out how they work and what they, what they want to work like. And that's why those things are, but it's, it's very hard.[00:28:49] I definitely try to do that. Usually it's just through workshops, right? It's like, that's the simplest way. Let's get in a room and we're going to format this conversation where it's not one person talking the whole time. It's all of us talking in this particular way.[00:29:00] And so that's kind of a, just for me, that's the brass tacks of this is like conversations.[00:29:06] John Cutler: Awesome. Well, I think that's a good way to end, actually. That's like a nice way of wrapping this up. This was a lot of fun and. I think I'm supposed to ask, you know, where are people supposed to find you? Although I think people are generally fairly findable now at the moment.[00:29:23] Chris Butler: Yeah. I mean, I'm on LinkedIn. If people want to connect and I'd love to hear if you try anything that I've talked about, I'd love to hear how it works for you and whether it does or doesn't. The Uncertainty Project is a community of like decision makers and strategists that I think is interesting.[00:29:36] And there's like, that's where I've been doing some, some more interesting writing about this. But yeah, just in general, just always excited to hear how people are doing their job.[00:29:44] John Cutler: Great. All right. Thank you so much, Chris.[00:29:46] Chris Butler: You're welcome. Thank you. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit cutlefish.substack.com

Chris Adams is joined by Ines Akrap from Cognizant to talk all-things sustainable web design. Together, they delve into the nuances of designing energy-efficient websites and the challenges of green coding in frontend development. Ines shares valuable insights from her experiences at the Linux Energy Foundation Summit and the SDIA Green Coding Summit. The episode also explores common mistakes in optimizing sites for carbon efficiency and discusses exciting projects in the field of green software that are generating buzz. Resources like Website Carbon, Ecograder, and Lighthouse are highlighted, alongside discussions on the Software Carbon Intensity Specification and the CarbonAware SDK. This episode is a must-listen for anyone interested in the intersection of web development and sustainability, offering practical tips and exploring new research horizons in the quest to decarbonize the digital world.

Aaron Delp and Brian Gracely discuss the possibility of another major cloud provider emerging as the economy changes and new application workloads begin to take shape. SHOW: 757CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT - "CLOUDCAST BASICS"SHOW SPONSORS:Find "Breaking Analysis Podcast with Dave Vellante" on Apple, Google and SpotifyKeep up to data with Enterprise Tech with theCUBEReduce the complexities of protecting your workloads and applications in a multi-cloud environment. Panoptica provides comprehensive cloud workload protection integrated with API security to protect the entire application lifecycle.  Learn more about Panoptica at panoptica.appSHOW NOTES:Microsoft hiring to build small reactors near data centersThe economic case for Generative AI (a16z)AWS invests (up to) $4B in AnthropicNVIDIA DGX CloudNVIDIA's new computing model (Acquired podcast)Topic 1 - Do you remember back when AWS was starting to take off, and Simon Wardley used to talk about how IBM or HP or Cisco or EMC/VMware should have been the ones building the utility cloud services? Topic 2 - We're now at a stage when all anyone can talk about is AI (Generative AI, LLMs, etc.) and GPUs. So which one is more powerful, the Models/Data or the Infrastructure?Topic 3 - Is it possible that NVIDIA could start building their own cloud? Do they potentially want to own a more vertical experience? Topic 4 - Obviously the buildout costs are enormous, but are they that much different from what the Big 3 are trying to do in retrofitting existing data centers, or hiring to build their own mini-Nuclear reactors?Topic 5 - Who could potentially be a partner to NVIDIA in building out this type of cloud in the near-term? (Equinix, national governments, cities-of-the-future, sovereign wealth funds, etc.)FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

Bringing mapping to your org. We are doing a wee series on Wardley Mapping, with some practical items. The last two episodes were: 'Wardley Mapping 101' and 'Can Wardley Maps Predict the Future?'. So I thought it would be good to answer a common question: 'That's a cool technique, but how would I do that in my work?'. If you follow Simon Wardley, on Twitter, and you've started experimenting with Wardley Mapping, we tell you how you to bring Wardley Mapping to your place of work. We talk about using the Northstar exercise to facilitate mapping. And about finding like-minded people to sit and practice with. There is a way of talking about mapping. You're better to start with the outcomes. And then see if people are interested to get back into the map, as a way of sensemaking complicated areas. It's great to make sense of something and share that thinking with peers. And once you get into that language, you open up a common way of thinking and the idea of evolution to access things you want to talk about it. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

Adam & Dax discuss the SVB collapse and how the government stepped in to prevent catastrophe. (00:41) - What happened at Silicon Valley Bank? (03:09) - What could've the impact been? (08:13) - Why are people upset about bailing out a bank? (11:26) - Individual bank accounts weren't affected (12:44) - VC chatter (16:22) - Simon Wardley's Twitter thread (19:07) - Hearing the end of the 2008 crash (19:57) - How do you stay on top of things?

What is strategy, and is it useful for business? Business schools want you think it is the critical factor in competitive success or failure. They teach structured markets, divided up by market share, with boundaries and external and internal forces to be assessed and countered. “Where to play and how to win.” They see strategy through their lens of financialization and utilize fictitious economic calculations like discounted future cash flows and market capitalization. There's very little Austrian flavor in their view — no acknowledgement of subjective value and the qualitative drivers of value, customer sovereignty, empathy, constantly changing customer preferences, no role for the entrepreneur in helping customers learn what they can want in an evolving world. Our guest Erik Schön provides us with an entirely different view of strategy, which he arrives at via a synthesis of three great strategists: Sun Tzu, John Boyd, and Simon Wardley. Knowledge Capsule Strategy is how to survive and thrive and, for a business, the key tool is harmonization. Sun Tzu identified Purpose as the fundamental factor that keeps people united: customers, producers, suppliers, partners, owners, executives, employees, supporting each other without fear through success and failure. In Sun Tzu, there are four more fundamental factors: Landscape — your business environment.Climate: the forces acting on the environment.Doctrine: ways of operating.Leadership: actions, decisions, choices, and gameplays. Master all five to succeed, or else fail. John Boyd added the dynamics of continuously changing intentions within the pursuit of the realization of purpose. (We find reflections here of Mises' concept of constant flux — everything changing all the time.) Boyd's definition of strategy Is a mental tapestry of changing intentions for harmonizing our efforts to realize purpose in a world that can be bewildering. The purpose of strategy is to improve our ability to adapt: a vision that magnifies the strength and commitment of its adherents, and a grand ideal or noble philosophy providing a binding paradigm for all. Boyd's famous framing of the learning process to develop the ability to adapt is the OODA Loop. [[{"fid":"138778","view_mode":"image_no_caption","fields":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"John Boyd's OODA Loop","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""},"type":"media","field_deltas":{"1":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"John Boyd's OODA Loop","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""}},"attributes":{"alt":"John Boyd's OODA Loop","class":"media-element file-image-no-caption media-wysiwyg-align-center","data-delta":"1"}}]] For Wardley, strategy is the art of moving in and manipulating an environment using tools such as positioning and technological innovation. Wardley's major contribution is to visualize strategy in the form of a map where the X-axis is movement in the environment in predictable steps: Genesis: a new technology or solution or brand is introduced; it's unique.Custom built: a company identifies ways to serve customers with constructed products and services from the new origin.Product: move from custom built to standardization, including sourcing standard parts from suppliersCommodity: there's nothing left that's unique, many companies can be producers.Evolution: a new genesis emerges. The automobile industry provides an example. Genesis: the first internal combustion engine.Custom built: the first car brands, often from craftsmen and small workshops.Product: Many suppliers, competitive differentiation (Ford versus GM).Commodity: ICE automobiles produced in many countries (Japan, South Korea, China, Italy, etc.) with limited customer differentiation.Evolution: the beginning of the EV era. Wardley's approach is that all markets exhibit this evolution. It's important to know the current landscape and predict the future landscape, moving through it with “the why of purpose” (to survive and thrive) and “the why of movement” (taking a particular action that moves you through the landscape). Everything evolves through supply and demand competition. [[{"fid":"138779","view_mode":"image_no_caption","fields":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"Climatic Pattern","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""},"type":"media","field_deltas":{"2":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"Climatic Pattern","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""}},"attributes":{"alt":"Climatic Pattern","class":"media-element file-image-no-caption media-wysiwyg-align-center","data-delta":"2"}}]] The Sun Tzu, Boyd and Wardley approaches to strategy can be combined in the concept of the Strategy Cycle, Strategists move continually through the phases and components. [[{"fid":"138780","view_mode":"image_no_caption","fields":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"the Strategy Cycle","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""},"type":"media","field_deltas":{"3":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"the Strategy Cycle","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""}},"attributes":{"alt":"the Strategy Cycle","class":"media-element file-image-no-caption media-wysiwyg-align-center","data-delta":"3"}}]] The reference to these strategy masters enables businesses to move beyond business school strategy. Move beyond strategy as wars, battles and combat for market share, towards strategy as individuals, teams and organizations fulfilling their shared purpose. Move beyond strategy for survival in competitive environments to sustainably thriving in a world with a high rate of change. Move beyond strategy development as planning, metrics and data towards strategy development for a harmonized direction based on regular assessment of needs (especially customers' needs) and the organization's purpose. Move beyond strategy development as execution and chasing targets to decisions and actions in a harmonized direction by everyone everywhere in the organization based on high situational awareness. Move beyond business as maximizing shareholder value to business as succeeding together with customers and other stakeholders. Move beyond leadership for managers and people in hierarchical leader roles to leadership as a service provided by all people in the organization. Move beyond practices and principles for optimizing parts to harmonizing the whole. The art of strategy is to succeed by securing harmony among stakeholders, and keeping competition off-balance through evolving better capabilities to influence, adapt and map. The three strategists offer complementary views of strategic success. Sun Tzu: Unite society rather than divide.Unite the organization rather than divide.Unite the team rather than divide.Make the organization resilient by cultivating purpose and doctrine. Boyd: A grand ideal, overarching theme, or noble philosophy that individuals can shape and adapt to unfolding circumstances. Wardley: Know your user — know your customers and know how to create value through meeting their needs.Set exceptional standards.Be resilient to cope with a wide variety of extremes and changes by rapidly adapting. The great obstacle to adaptiveness in strategy is inertia in its various forms. Success breeds inertia, and inertia kills. It's rarely a lack of innovation that kills companies, but rather inertia caused by pre-existing business models. Any past success with any component or element will tend to create a resistance to change. Inertia is a loss of capital — whether physical, human, social, or financial. Strategists look to identify different categories of inertia and devise ways to counter them. Category of inertiaCounterpointPeople resist disruption of past normsPast has evolved / lead the charge Write down cost of legacy, run more efficiently Building future agility Already happening in the market, falling behind Fear of transition to the newLet's build new skills internally Develop capabilities in-house Develop relationships with new suppliers Work on adapting practices, not scrapping them Are we sure we can make the new work? Don't seek certainty, seek learning Develop new standards, use open source Use multiple vendors, use brokers Improve supplier relationships Changing business models is hard Avoid death spiral; new approaches e.g., ecosystem Risk mitigation; spin off the old Use rewards, education, training Perfect telling the new story Leading without pressure and control. Erik uses the gardening analogy to illustrate the Sun Tzu style of leading without pressure and control. The gardener tends the garden gently, tilling and planting and watering ahead of time, and the flowers grow. Today we might call this style “self-organization”. The three strategists are very consistent with the action-focused approach to entrepreneurship from Austrian economics. Action is learning. The path is made by walking. Try things out. Draw some Wardley maps as a trial. They'll take you a long way. Additional Resources The Art of Strategy: Steps Towards Business Agility by Erik Schön: Mises.org/E4B_207_Book1 The Art Of Leadership: Purpose and Integrity for Sustainable Success by Erik Schön: Mises.org/E4B_207_Book2 Erik Schön on LinkedIn: Mises.org/E4B_207_LinkedIn A Collection of Wardley Maps: Mises.org/E4B_207_Maps1 A Wardley Map of the Automobile Industry: Mises.org/E4B_207_Maps2

What is strategy, and is it useful for business? Business schools want you think it is the critical factor in competitive success or failure. They teach structured markets, divided up by market share, with boundaries and external and internal forces to be assessed and countered. “Where to play and how to win.” They see strategy through their lens of financialization and utilize fictitious economic calculations like discounted future cash flows and market capitalization. There's very little Austrian flavor in their view — no acknowledgement of subjective value and the qualitative drivers of value, customer sovereignty, empathy, constantly changing customer preferences, no role for the entrepreneur in helping customers learn what they can want in an evolving world. Our guest Erik Schön provides us with an entirely different view of strategy, which he arrives at via a synthesis of three great strategists: Sun Tzu, John Boyd, and Simon Wardley. Knowledge Capsule Strategy is how to survive and thrive and, for a business, the key tool is harmonization. Sun Tzu identified Purpose as the fundamental factor that keeps people united: customers, producers, suppliers, partners, owners, executives, employees, supporting each other without fear through success and failure. In Sun Tzu, there are four more fundamental factors: Landscape — your business environment.Climate: the forces acting on the environment.Doctrine: ways of operating.Leadership: actions, decisions, choices, and gameplays. Master all five to succeed, or else fail. John Boyd added the dynamics of continuously changing intentions within the pursuit of the realization of purpose. (We find reflections here of Mises' concept of constant flux — everything changing all the time.) Boyd's definition of strategy Is a mental tapestry of changing intentions for harmonizing our efforts to realize purpose in a world that can be bewildering. The purpose of strategy is to improve our ability to adapt: a vision that magnifies the strength and commitment of its adherents, and a grand ideal or noble philosophy providing a binding paradigm for all. Boyd's famous framing of the learning process to develop the ability to adapt is the OODA Loop. [[{"fid":"138778","view_mode":"image_no_caption","fields":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"John Boyd's OODA Loop","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""},"type":"media","field_deltas":{"1":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"John Boyd's OODA Loop","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""}},"attributes":{"alt":"John Boyd's OODA Loop","class":"media-element file-image-no-caption media-wysiwyg-align-center","data-delta":"1"}}]] For Wardley, strategy is the art of moving in and manipulating an environment using tools such as positioning and technological innovation. Wardley's major contribution is to visualize strategy in the form of a map where the X-axis is movement in the environment in predictable steps: Genesis: a new technology or solution or brand is introduced; it's unique.Custom built: a company identifies ways to serve customers with constructed products and services from the new origin.Product: move from custom built to standardization, including sourcing standard parts from suppliersCommodity: there's nothing left that's unique, many companies can be producers.Evolution: a new genesis emerges. The automobile industry provides an example. Genesis: the first internal combustion engine.Custom built: the first car brands, often from craftsmen and small workshops.Product: Many suppliers, competitive differentiation (Ford versus GM).Commodity: ICE automobiles produced in many countries (Japan, South Korea, China, Italy, etc.) with limited customer differentiation.Evolution: the beginning of the EV era. Wardley's approach is that all markets exhibit this evolution. It's important to know the current landscape and predict the future landscape, moving through it with “the why of purpose” (to survive and thrive) and “the why of movement” (taking a particular action that moves you through the landscape). Everything evolves through supply and demand competition. [[{"fid":"138779","view_mode":"image_no_caption","fields":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"Climatic Pattern","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""},"type":"media","field_deltas":{"2":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"Climatic Pattern","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""}},"attributes":{"alt":"Climatic Pattern","class":"media-element file-image-no-caption media-wysiwyg-align-center","data-delta":"2"}}]] The Sun Tzu, Boyd and Wardley approaches to strategy can be combined in the concept of the Strategy Cycle, Strategists move continually through the phases and components. [[{"fid":"138780","view_mode":"image_no_caption","fields":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"the Strategy Cycle","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""},"type":"media","field_deltas":{"3":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"the Strategy Cycle","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""}},"attributes":{"alt":"the Strategy Cycle","class":"media-element file-image-no-caption media-wysiwyg-align-center","data-delta":"3"}}]] The reference to these strategy masters enables businesses to move beyond business school strategy. Move beyond strategy as wars, battles and combat for market share, towards strategy as individuals, teams and organizations fulfilling their shared purpose. Move beyond strategy for survival in competitive environments to sustainably thriving in a world with a high rate of change. Move beyond strategy development as planning, metrics and data towards strategy development for a harmonized direction based on regular assessment of needs (especially customers' needs) and the organization's purpose. Move beyond strategy development as execution and chasing targets to decisions and actions in a harmonized direction by everyone everywhere in the organization based on high situational awareness. Move beyond business as maximizing shareholder value to business as succeeding together with customers and other stakeholders. Move beyond leadership for managers and people in hierarchical leader roles to leadership as a service provided by all people in the organization. Move beyond practices and principles for optimizing parts to harmonizing the whole. The art of strategy is to succeed by securing harmony among stakeholders, and keeping competition off-balance through evolving better capabilities to influence, adapt and map. The three strategists offer complementary views of strategic success. Sun Tzu: Unite society rather than divide.Unite the organization rather than divide.Unite the team rather than divide.Make the organization resilient by cultivating purpose and doctrine. Boyd: A grand ideal, overarching theme, or noble philosophy that individuals can shape and adapt to unfolding circumstances. Wardley: Know your user — know your customers and know how to create value through meeting their needs.Set exceptional standards.Be resilient to cope with a wide variety of extremes and changes by rapidly adapting. The great obstacle to adaptiveness in strategy is inertia in its various forms. Success breeds inertia, and inertia kills. It's rarely a lack of innovation that kills companies, but rather inertia caused by pre-existing business models. Any past success with any component or element will tend to create a resistance to change. Inertia is a loss of capital — whether physical, human, social, or financial. Strategists look to identify different categories of inertia and devise ways to counter them. Category of inertiaCounterpointPeople resist disruption of past normsPast has evolved / lead the charge Write down cost of legacy, run more efficiently Building future agility Already happening in the market, falling behind Fear of transition to the newLet's build new skills internally Develop capabilities in-house Develop relationships with new suppliers Work on adapting practices, not scrapping them Are we sure we can make the new work? Don't seek certainty, seek learning Develop new standards, use open source Use multiple vendors, use brokers Improve supplier relationships Changing business models is hard Avoid death spiral; new approaches e.g., ecosystem Risk mitigation; spin off the old Use rewards, education, training Perfect telling the new story Leading without pressure and control. Erik uses the gardening analogy to illustrate the Sun Tzu style of leading without pressure and control. The gardener tends the garden gently, tilling and planting and watering ahead of time, and the flowers grow. Today we might call this style “self-organization”. The three strategists are very consistent with the action-focused approach to entrepreneurship from Austrian economics. Action is learning. The path is made by walking. Try things out. Draw some Wardley maps as a trial. They'll take you a long way. Additional Resources The Art of Strategy: Steps Towards Business Agility by Erik Schön: Mises.org/E4B_207_Book1 The Art Of Leadership: Purpose and Integrity for Sustainable Success by Erik Schön: Mises.org/E4B_207_Book2 Erik Schön on LinkedIn: Mises.org/E4B_207_LinkedIn A Collection of Wardley Maps: Mises.org/E4B_207_Maps1 A Wardley Map of the Automobile Industry: Mises.org/E4B_207_Maps2

What is strategy, and is it useful for business? Business schools want you think it is the critical factor in competitive success or failure. They teach structured markets, divided up by market share, with boundaries and external and internal forces to be assessed and countered. “Where to play and how to win.” They see strategy through their lens of financialization and utilize fictitious economic calculations like discounted future cash flows and market capitalization. There's very little Austrian flavor in their view — no acknowledgement of subjective value and the qualitative drivers of value, customer sovereignty, empathy, constantly changing customer preferences, no role for the entrepreneur in helping customers learn what they can want in an evolving world. Our guest Erik Schön provides us with an entirely different view of strategy, which he arrives at via a synthesis of three great strategists: Sun Tzu, John Boyd, and Simon Wardley. Knowledge Capsule Strategy is how to survive and thrive and, for a business, the key tool is harmonization. Sun Tzu identified Purpose as the fundamental factor that keeps people united: customers, producers, suppliers, partners, owners, executives, employees, supporting each other without fear through success and failure. In Sun Tzu, there are four more fundamental factors: Landscape — your business environment.Climate: the forces acting on the environment.Doctrine: ways of operating.Leadership: actions, decisions, choices, and gameplays. Master all five to succeed, or else fail. John Boyd added the dynamics of continuously changing intentions within the pursuit of the realization of purpose. (We find reflections here of Mises' concept of constant flux — everything changing all the time.) Boyd's definition of strategy Is a mental tapestry of changing intentions for harmonizing our efforts to realize purpose in a world that can be bewildering. The purpose of strategy is to improve our ability to adapt: a vision that magnifies the strength and commitment of its adherents, and a grand ideal or noble philosophy providing a binding paradigm for all. Boyd's famous framing of the learning process to develop the ability to adapt is the OODA Loop. [[{"fid":"138778","view_mode":"image_no_caption","fields":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"John Boyd's OODA Loop","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""},"type":"media","field_deltas":{"1":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"John Boyd's OODA Loop","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""}},"attributes":{"alt":"John Boyd's OODA Loop","class":"media-element file-image-no-caption media-wysiwyg-align-center","data-delta":"1"}}]] For Wardley, strategy is the art of moving in and manipulating an environment using tools such as positioning and technological innovation. Wardley's major contribution is to visualize strategy in the form of a map where the X-axis is movement in the environment in predictable steps: Genesis: a new technology or solution or brand is introduced; it's unique.Custom built: a company identifies ways to serve customers with constructed products and services from the new origin.Product: move from custom built to standardization, including sourcing standard parts from suppliersCommodity: there's nothing left that's unique, many companies can be producers.Evolution: a new genesis emerges. The automobile industry provides an example. Genesis: the first internal combustion engine.Custom built: the first car brands, often from craftsmen and small workshops.Product: Many suppliers, competitive differentiation (Ford versus GM).Commodity: ICE automobiles produced in many countries (Japan, South Korea, China, Italy, etc.) with limited customer differentiation.Evolution: the beginning of the EV era. Wardley's approach is that all markets exhibit this evolution. It's important to know the current landscape and predict the future landscape, moving through it with “the why of purpose” (to survive and thrive) and “the why of movement” (taking a particular action that moves you through the landscape). Everything evolves through supply and demand competition. [[{"fid":"138779","view_mode":"image_no_caption","fields":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"Climatic Pattern","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""},"type":"media","field_deltas":{"2":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"Climatic Pattern","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""}},"attributes":{"alt":"Climatic Pattern","class":"media-element file-image-no-caption media-wysiwyg-align-center","data-delta":"2"}}]] The Sun Tzu, Boyd and Wardley approaches to strategy can be combined in the concept of the Strategy Cycle, Strategists move continually through the phases and components. [[{"fid":"138780","view_mode":"image_no_caption","fields":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"the Strategy Cycle","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""},"type":"media","field_deltas":{"3":{"format":"image_no_caption","alignment":"center","field_file_image_alt_text[und][0][value]":"the Strategy Cycle","field_file_image_title_text[und][0][value]":false,"field_caption_text[und][0][value]":"","field_image_file_link[und][0][value]":""}},"attributes":{"alt":"the Strategy Cycle","class":"media-element file-image-no-caption media-wysiwyg-align-center","data-delta":"3"}}]] The reference to these strategy masters enables businesses to move beyond business school strategy. Move beyond strategy as wars, battles and combat for market share, towards strategy as individuals, teams and organizations fulfilling their shared purpose. Move beyond strategy for survival in competitive environments to sustainably thriving in a world with a high rate of change. Move beyond strategy development as planning, metrics and data towards strategy development for a harmonized direction based on regular assessment of needs (especially customers' needs) and the organization's purpose. Move beyond strategy development as execution and chasing targets to decisions and actions in a harmonized direction by everyone everywhere in the organization based on high situational awareness. Move beyond business as maximizing shareholder value to business as succeeding together with customers and other stakeholders. Move beyond leadership for managers and people in hierarchical leader roles to leadership as a service provided by all people in the organization. Move beyond practices and principles for optimizing parts to harmonizing the whole. The art of strategy is to succeed by securing harmony among stakeholders, and keeping competition off-balance through evolving better capabilities to influence, adapt and map. The three strategists offer complementary views of strategic success. Sun Tzu: Unite society rather than divide.Unite the organization rather than divide.Unite the team rather than divide.Make the organization resilient by cultivating purpose and doctrine. Boyd: A grand ideal, overarching theme, or noble philosophy that individuals can shape and adapt to unfolding circumstances. Wardley: Know your user — know your customers and know how to create value through meeting their needs.Set exceptional standards.Be resilient to cope with a wide variety of extremes and changes by rapidly adapting. The great obstacle to adaptiveness in strategy is inertia in its various forms. Success breeds inertia, and inertia kills. It's rarely a lack of innovation that kills companies, but rather inertia caused by pre-existing business models. Any past success with any component or element will tend to create a resistance to change. Inertia is a loss of capital — whether physical, human, social, or financial. Strategists look to identify different categories of inertia and devise ways to counter them. Category of inertiaCounterpointPeople resist disruption of past normsPast has evolved / lead the charge Write down cost of legacy, run more efficiently Building future agility Already happening in the market, falling behind Fear of transition to the newLet's build new skills internally Develop capabilities in-house Develop relationships with new suppliers Work on adapting practices, not scrapping them Are we sure we can make the new work? Don't seek certainty, seek learning Develop new standards, use open source Use multiple vendors, use brokers Improve supplier relationships Changing business models is hard Avoid death spiral; new approaches e.g., ecosystem Risk mitigation; spin off the old Use rewards, education, training Perfect telling the new story Leading without pressure and control. Erik uses the gardening analogy to illustrate the Sun Tzu style of leading without pressure and control. The gardener tends the garden gently, tilling and planting and watering ahead of time, and the flowers grow. Today we might call this style “self-organization”. The three strategists are very consistent with the action-focused approach to entrepreneurship from Austrian economics. Action is learning. The path is made by walking. Try things out. Draw some Wardley maps as a trial. They'll take you a long way. Additional Resources The Art of Strategy: Steps Towards Business Agility by Erik Schön: Mises.org/E4B_207_Book1 The Art Of Leadership: Purpose and Integrity for Sustainable Success by Erik Schön: Mises.org/E4B_207_Book2 Erik Schön on LinkedIn: Mises.org/E4B_207_LinkedIn A Collection of Wardley Maps: Mises.org/E4B_207_Maps1 A Wardley Map of the Automobile Industry: Mises.org/E4B_207_Maps2

About AerinAerin is a Cloud Sustainability Advocate and neurodiverse founder in tech on a mission to help developers understand the real impact that cloud computing has on the world and reduce their carbon emissions in the cloud. Did you know that internet and cloud computing contribute over 4% of annual carbon emissions? Twice that of the airline industry!Aerin also hosts "Public Cloud for Public Good," a podcast targeted towards developers and senior leaders in tech. Every episode, they also donate £500 to charities and highlight organisations that are working towards a better future. Listen and learn how you can contribute towards making the world a better place through the use of public cloud services.Links Referenced: Twitter: https://twitter.com/aerincloud LinkedIn: https://www.linkedin.com/in/aerinb/ Public Cloud for Public Good: https://publicgood.cloud/ duckbillgroup.com: https://duckbillgroup.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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: This episode is sponsored in part by our friends at Uptycs, because they believe that many of you are looking to bolster your security posture with CNAPP and XDR solutions. They offer both cloud and endpoint security in a single UI and data model. Listeners can get Uptycs for up to 1,000 assets through the end of 2023 (that is next year) for $1. But this offer is only available for a limited time on UptycsSecretMenu.com. That's U-P-T-Y-C-S Secret Menu dot com.Corey: Cloud native just means you've got more components or microservices than anyone (even a mythical 10x engineer) can keep track of. With OpsLevel, you can build a catalog in minutes and forget needing that mythical 10x engineer. Now, you'll have a 10x service catalog to accompany your 10x service count. Visit OpsLevel.com to learn how easy it is to build and manage your service catalog. Connect to your git provider and you're off to the races with service import, repo ownership, tech docs, and more. Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn and I am joined what feels like roughly a year later by a returning guest, Aerin Booth. How long have you been?Aerin: I've been really great. You know, it's been a journey of a year, I think, since we sort of did this podcast even, like, you know, a year and a bit since we met, and, like, I'm doing so much and I think it's doing, like, a big difference. And yeah, I can't wait for everything else. It's just yeah, a lot of work right now, but I'm really enjoying it. So, I'm really well, thank you.Corey: Normally, I like to introduce people by giving their job title and the company in which they work because again, that's a big deal for an awful lot of people. But a year ago, you were independent. And now you still are. And back when I was doing my own consulting independently, it felt very weird to do that, so I'm just going to call you the Ted Lasso of cloud at this point.Aerin: [laugh].Corey: You've got the mustache, you've got the, I would say, obnoxiously sunny disposition. It's really, there's a certain affinity right there. So, there we go. I feel like that is the best descriptor for what you have become.Aerin: I—do know what, I only just watched Ted Lasso over Christmas and I really found it so motivational in some ways because wow, like, it's not just who we'd want to be in a lot of ways? And I think, you know, for the work that I do, which is focused on sustainability, like, I want to present a positive future, I want to encourage people to achieve more and collaborate, and yeah, basically work on all these problems that we need to be worked on. And yeah, I think that's [laugh] [crosstalk 00:02:02]—Corey: One of the challenges of talking to you sometimes is you talk about these depressing things, but there's such a—you take such an upbeat, positive approach to it that I, by comparison, invariably come away from our conversations during, like, I'm Surly McBastard over here.Aerin: [laugh]. Yeah, you can be the bad cop of cloud computing and I'll try and be the good cop. Do you know, you say that the stuff I talk about is depressing, and it is true and people do worry about climate change. Like I did an online conference recently, it's focused on FinOps, and we had a survey, “Do you worry about climate change?” 70% of the people that responded said they worry about it.So, we all know, it's something we worry about and we care about. And, you know, I guess what I'm really trying to do is encourage people to care a bit more and start taking action and look after yourself. Because you know, when you do start taking action towards it, when you join those communities that are also working on it, it is good, it is helpful. And, you know, I've gone through some ups and downs and some of this, like, just do I throw in the towel because no one cares about it? Like, we spoke last year; I had attended re:Invent for the first time.This year, I was able to speak at re:Invent. So, I did a talk on being ethical in tech. And it was fun, it was good. I enjoyed what I delivered, but I had about 35 people sign up to that. I'm pretty sure if I talked about serverless or the next Web3 blockchain product, I would have got hundreds more. But what I'm starting to realize is that I think people just aren't ready to, sort of, want to do this yet. And yeah, I'm hoping that'll change.Corey: Let's first talk about, I guess, something that is more temporally pressing than some other things. Not that it is more important than climate change, mind you, but it feels like it's on a shorter timeline which is, relatively soon after this recording, there is a conference that you are kicking off called The State of Open. Ajar, Aerin. The State of Open is ajar. What is this conference? Is it in person? Is it virtual? Is it something where you and three friends are going to show up and basically talk to each other? How big? How small? What is it? What's it about? Tell me more, please. I'm riveted.Aerin: So, State of Open conference is a conference that's been in the works now for maybe about two weeks, a little bit longer in the planning, but the work we've been putting in over the last two weeks. It'll be on the seventh and eighth of February in London as a physical event in the QEII Conference Centre, but it will also be available online. And you know, when we talk about the State of Open, it's that question: what is the State of Open? The state of open-source, the state of open hardware, and the state of open data. And it is going to be probably the first and hopefully the biggest open-source conference in the UK.We already have over 100 confirmed guest speakers from Jimmy Wales, the co-founder of Wikipedia, to many of our great guests and headliners who haven't even announced yet for the plenary. So, I'm really excited. And the reason why I wanted to get involved with this is because one of the coolest things about this conference—compared to some others like re:Invent, for example—is that sustainability and diversity run through every single thing that we do. So, as the content director, I reviewed every single CFP for both of these things. I mean, you couldn't get a better person than someone like me, who's the queer person who won't shut up about sustainability to sort of do this thing.So, you know, I looked after those scorings for the CFPs in support of the CFP chairs. And now, as I'm working with those individual speakers on their content and making sure that diversity is included in the content. It's not just the diversity of the speaker, for example it's, who were the other people whose voice you're raising? What other people if you worked on this? Are there anyone that you've mentored, like, you know, actually, you know, let's have this as a wider conversation?Corey: Thank God. I thought you were about to say diversity of thought, and I was about to reach through the screen to strangle you.Aerin: [laugh]. No, no. I mean, we're doing really well, so of the announced speakers online, we are 40% non-male and about 18% non-white, which to be honest, for a fair sheer conference, when we didn't really do that much to specifically call this out, but I would probably raise this to Amanda Brock, who is the CEO of OpenUK, you know, she has built a community in the UK and around the world over the last few years which has been putting women forward and building these links. And that's why we've had such a great response for our first-year conferences, the work she's put in. It's hard.Like, this isn't easy. You know, we've had to do a lot of work to make sure that it is representative, at least better than other conferences, at least. So, I'm really excited. And like, there's so much, like, open-source is probably going to be the thing that saves the world. If we're going to end up looking at two different futures with monopolies and closed systems and all the money going towards cloud providers versus a fair and equitable society, open-source is the thing that's going to get us closer to that. So yeah, this conference will be a great event.Corey: Is it all in person? Is it being live-streamed as well? What is the deal here?Aerin: So, in person, we have loads of different things going on, but what will be streamed online if you sign up for virtual ticket is five different tracks. So, our platform engineering track, our security track, government law and policy, open data, and open hardware. And of course, the keynote and plenaries. But one of the things I'm also really proud about this conference is that we're really focusing on the developer experience, like, you know, what is your experience at the conference? So, we also have an unconference, we have a sub-conference run by Sustain OSS focused on workshops related to climate change and sustainability.We have loads of developer experience halls in the event itself. And throughout the day, over the two days, we have two one-hour blocks with no speaking content at all so that we can really make sure that people have that hardware track and are out there meeting each other and having a good time. And obviously, of course, like any good conference, the all-hands party on the first night. So, it really is a conference that's doing things differently from diversity to sustainability to that experience. So, it's awesome.Corey: One of the challenges that I've seen historically around things aiming at the idea of open conferences—and when we talk open-source, et cetera, et cetera—open' seems like it is a direction parallel to, we haven't any money, where it's, “Yes, we're a free software foundation,” and it turns out conferences themselves are not free. And you wind up with a whole bunch of folks showing up to it who are, in many cases, around the fringes of things. There are individual hobbyists who are very passionate about a thing but do not have the position in the corporate world. I'm looking through the lengthy list of speakers you have here and that is very much not this. These are serious people at serious companies. Not that there are not folks who are individual practitioners and passionate advocates and hobbyists than the rest. This is, by virtually any way you look at it, a remarkably diverse conference.Aerin: Mmm. You know, you are right about, like, that problem in open-source. It's like, you know, we look at open and whether we want to do open and we just go, “Well, it won't make me any money. I can't do that. I don't have the time. I need to bring in some money.”And one of the really unique things, again, about this conference is—I have not even mentioned it yet—we have an entrepreneurship room. So, we have 20 tables filled with entrepreneurs and CEOs and founders of open-source companies throughout the two days where you can book in time to sit at that table and have conversations with them. Ask them the questions that you want to ask about, whether it's something that you want to work on, or a company you want to found, and you'll be able to get that time. I had a very similar experience in some ways. It was re:Invent.I was a peer talk expert and you know, I had 15 or so conversations with some really interesting people just because they were able put that time in and they were able to find me on the website. So, that's something we are replicating to get those 20 also entrepreneurs and co-founders out to everyone else. They want to be able to help you and support you.Corey: That is an excellent segue if I do say so myself. Let's talk about re:Invent. It's the one time of the year you and I get to spend time in the same room. One thing that I got wrong is that I overbooked myself as I often do, and I didn't have time to do anything on their peer talk expert program, which is, you more or less a way that any rando can book time to sit down and chat with you. Now, in my case, I have assassination concerns because it turns out Amazon employees can read that thing too and some of them might work on billing. One wonders.So yeah, I have to be a little careful for personal reasons but for most people, it's a non-issue. I didn't get as much time as I wanted to talk to folks in the community. That is not going to repeat itself at the end of this year. But what was your take on re:Invent, because I was in meetings for most of them?Aerin: So, comparing this re:Invent to the re:Invent I went to, my first re:Invent when we met in 2021, you know, that was the re:Invent that inspired me to get into sustainability. They'd announced stuff to do with the shared responsibility model. A few months later, they released their carbon calculator, and I was like, “Yeah, this is the problem. This is the thing I want to work on and it will make me happy.” And a lot of that goes into, you know, finding a passion that keeps me motivated when things aren't that great.When maybe not a lot of money is coming in, at least I know, I'm doing everything I can to help save the world. So, re:Invent 2021 really inspired me to get involved with sustainability. When I look at re:Invent 2022, you might have Adam Selipsky on the main stage saying that sustainability is the problem of our generation, but that is just talk and bluster compared to what they were putting out in terms of content and their experience of, like, let's say the sustainability—I don't know what to call it—tiny little square in the back of the MGM Grand compared to the paid hall in the expo. Like, you know, that's the sort of thing where you can already see the prioritization of money. Let's put the biggest sponsors and all the money that we can bring it in the big hall where everyone is, and then put the thing we care about the most, apparently—sustainability—in the back of the MGM.And that in itself was annoying, but then you get there in the content, and it was like a massive Rivian van, like, an advert for, “Oh, Amazon has done all this to electrify Rivian and deliver you Prime.” But where was the people working on sustainability in the cloud? You know, we had a couple of teams who were talking about the customer carbon footprint tool, but there was just not much. And I spoke to a lot of people and they were saying similar things, like, “Where are the announcements? Where are the actual interesting things?” Rather than just—which is kind of what I'm starting to realize is that a lot of the conversations about sustainability is about selling yourself as sustainable.Use me rather than my competitors because we're 88% more, kind of, carbon neutral when it comes to traditional data centers, not because we are really going to solve these problems. And not to say that Amazon isn't doing innovative, amazing things that no one else can't do, because that is true, and cloud as part of the solution, but you know, sustainability shouldn't be about making more sales and growing your business, it should be about making the world a better place, not just in terms of carbon emissions, but you know, our life, the tech that we can access. Three billion people on this planet have never accessed the internet. And as we continue to grow all of our services like AI and machine learning and new Web3, bloody managed services come online, that's going to be more carbon, more compute power going towards the already rich and the already westernized people, rather than solving the problems we need to solve in the face of climate change.So, I was a little bit disappointed. And I did put a tweet thread out about it afterwards. And I just hope it can be different next year and I hope more people will start to ask for this. And that also what I'm starting to realize is that until more Amazon customers put this as their number one priority and say, “I'm not going to do business with you because of this issue,” or, you know, “This is what we really care about,” they're not going to make a change. Unless it starts to impact their bottom lines and people start to choose other cloud providers, they're not going to prioritize it.And I think up until this point, we're not seeing that from customers. We're kind of getting some people like me shouting about it, but across the board, sustainability isn't the number one priority right now. It's, like what Amazon says, security or resiliency or something else.Corey: And I think that, at least from where I set, the challenge is that if you asked me what I got out of re:Invent, and what the conversations I had—going into it, what are my expectations, and what do I hope to get and how's it going to end up, and then you ask you that same question—though maybe you are a poor example of this—and then you ask someone who works out as an engineer at a company that uses AWS and their two or three years into their career, why don't you talk to a manager or director or someone else? And the problem is if you start polling the entire audience, you'll find that this becomes—you're going to wind up with 20 different answers, at least. The conference doesn't seem like it has any idea of what it wants to be and to whom and in that vacuum, it tries to be all things to all people. And surprise, just like the shooting multifunction printer some of us have in our homes, it doesn't do well with any of those things because it's trying to stand in too many worlds at the same time.Aerin: You know, let's not, like, look at this from a way that you know, re:Invent is crap and, like, do all the work that everyone puts it is wasted because it is a really great event for a lot of different things for a lot of different people. And to be honest, the work that the Amazon staff put into it is pretty out of this world. I feel sorry though because you know, the rush for AWS sell more and do this massive event, they put people through the grinder. And I feel like, I don't know, we could see the cracks in some of that, the way that works. But, you know, there's so many people that I speak to who were like, “Yeah, I'm definitely not going again. I'm not even going to go anywhere near submitting a talk.”And, sort of, the thing is, like, I can imagine if the conference was something different; it was focused at sustainability at number one, it was about making the world a better place from everything that they do, it was about bringing diverse communities together. Like, you know, bringing these things up the list would make the whole thing a lot better. And to be honest, it would probably make it a lot more enjoyable [laugh] for the Amazon staff who end up talking at it. Because, you know, I guess it can feel a bit soulless over time is all you're doing is making money for someone else and selling more things. And, yeah, I think there's a lot more… different things we can do and a lot more things we can talk about if people just start to talk about, like you know, if you care about this as well and you work at Amazon, then start saying that as well.It'll really make a difference if you say we want re:Invent to look different. I mean, even Amazon staff, [laugh] and we've not even mentioned this one because I got Covid straight after re:Invent, nine days and staring at a wall in hotel room in Vegas was not my idea of a good time post-conference. So, that was a horrible, horrible experience. But, you know, I've had people call it re:Infect. Like, where are the Covid support?Like, there was hardly any conversation about that. It was sort of like, “Don't mention it because oh, s”—whatever else. But imagine if you just did something a little bit differently to look like you care about your customers. Just say, “We recommend people mask or take a test,” or even provide tests and masks. Like, even if it's not mandatory, they could have done a lot more to make it safer for everyone. Because, yeah, imagine having the reputation of re:Infect rather than re:Invent?Corey: I can only imagine how that would play out.Aerin: Only imagine.Corey: Yeah, it's it feels like we're all collectively decided to pretend that the pandemic is over. Because yeah, that's a bummer. I don't want to think about it. You know, kind of like we approach climate change.Aerin: Yeah. At the end of the day, like, and I keep coming across this more and more, you know, my thinking has changed over the last year because, like, you know, initially it was like a hyperactive puppy. Why are we caring about this? Like, yeah, if I say it, people will come, but the reality is, we have to blinker ourselves in order to deal with a lot of this stuff. We can't always worry about all of this stuff all of the time. And that's fine. That's acceptable. We do that in so many different parts of our life.But there comes to a point when you kind of think, “How much do I care about this?” And for a lot of people, it's because they have kids. Like, anyone who has kids right now must have to think, “Wow, what's the future going to look like?” And if you worry about what the future is going to look like, make sure you're taking steps to make the world a better place and make it the future you want it to look like. You know, I made the decision a long time ago not to have kids because I don't think I'd want to bring anyone into the world on what it might actually end up being, but you know, when I speak to people who are older in the 60s and they're like, “Oh, you've got 100 years. You don't need to worry about it.” Like, “Maybe you can say that because you're closer to dying than I am.” But yeah, I have to worry about this now because I'll still be eighty when all this shit is kicking off [laugh].Corey: This episode is sponsored in part by our friends at Strata. Are you struggling to keep up with the demands of managing and securing identity in your distributed enterprise IT environment? You're not alone, but you shouldn't let that hold you back. With Strata's Identity Orchestration Platform, you can secure all your apps on any cloud with any IDP, so your IT teams will never have to refactor for identity again. Imagine modernizing app identity in minutes instead of months, deploying passwordless on any tricky old app, and achieving business resilience with always-on identity, all from one lightweight and flexible platform.Want to see it in action? Share your identity challenge with them on a discovery call and they'll hook you up with a complimentary pair of AirPods Pro. Don't miss out, visit Strata.io/ScreamingCloud. That's Strata dot io slash ScreamingCloud.Corey: That I guess is one of the big fears I have—and I think it's somewhat unfounded—is that every year starts to look too much like the year before it. Because it's one of those ideas where we start to see the pace of innovation is slowing at AWS—and I'm not saying that to piss people at Amazon off and have them come after me with pitchforks and torches again—but they're not launching new services at the rate they once did, which is good for customers, but it starts to feel like oh, have we hit peak cloud this is what it's going to look like? Absolutely not. I don't get the sense that the world is like, “Well, everything's been invented. Time to shut down the patent office,” anytime soon.And in the short term, it feels like oh, there's not a lot exciting going on, but you look back the last five years even and look at how far we've come even in that period of time and—what is it? “The days are long, but the years are short.” It becomes a very macro thing of as things ebb and flow, you start to see the differences but the micro basis on a year-to-year perspective, it seems harder to detect. So longer term, I think we're going to see what the story looks like. And it's going to be satisfying one. Just right now, it's like, well, this wasn't as entertaining as I would have hoped, so I'm annoyed. Which I am because it wasn't, but that's not the biggest problem in the world.Aerin: It's not. And, you know, you look at okay, cool, there wasn't all these new flashy services. There was a few things are announced, I mean, hopefully that are going to contribute towards climate change. One of them is called AWS Supply Chain. And the irony of seeing sort of like AWS Supply Chain where a company that already has issues with data and conversations around competition, saying to everyone, “Hey, trust us and give all of your supply chain information and put it into one of our AWS products,” while at the same time their customer carbon footprint tool won't even show the full scope for their emissions of their own supply chain is not lost on me.And you do say, “Maybe we should start seeing things at a macro level,” but unless Amazon and other cloud hyperscalers start pulling the finger out and showing us how they have got a vision between now and 2040, and now in 2050, of how they're going to get there, it kind of just feels like they're saying, “It'll all be fine as long as we continue to grow, as long as we keep sucking up the market.” And, you know, an interesting thing that just kicked off in the UK back in November was the Competition and Markets Authority have started an investigation into the cloud providers on how they are basically sucking up all these markets, and how the growth of things that are not hyperscale is going. So, in the UK, the percentage of cloud has obviously gone up—more and more cloud spending has gone up—but kind of usage across non-hyperscalers has gone down over that same period. And they really are at risk of sucking up the world. Like, I have got involved in a lot of different things.I'm an AWS community builder; like, I do promote AWS. And, you know, the reason why I promote cloud, for example is serverless. We need serverless as the way we run our IT because that's the only way we'll do things like time shifting or demand shifting. So, when we look at renewable energy on the grid if that really high, the wind is blowing and the sun is shining, we want more workloads to be running then and when they're tiny, and they're [unintelligible 00:21:03], and what's the call it serverless generally, uh—Corey: Hype?Aerin: Function as a Code?Corey: Function—yeah, Function as a Service and all kinds of other nonsense. But I have to ask, when you're talking about serverless, in this context, is a necessary prerequisite of serverless that scale to zero when it's [unintelligible 00:21:19].Aerin: [laugh]. I kind of go back to marketing. What Amazon releasing these days when it relates to serverless that isn't just marketing and saying, “Oh, it's serverless.” Because yeah, there was a few products this year that is not scaled to zero is it? It's a 100-pound minimum. And when you're looking at number of accounts that you have, that can add up really quickly and it excludes people from using it.Corey: It's worse than that because it's not number of accounts. I consider DynamoDB to be serverless, by any definition of the term. Because it is. And what I like about it is I can have a separate table for every developer, for every service or microservice or project that they have, and in fact, each branch can have its own stuff like that. I look at some of the stuff that I build with multi-branch testing and whatnot, and, “Oh, wow. That would cost more than the engineer if they were to do that with some of the serverless offerings that AWS has put out.”Which makes that entire philosophy a complete non-starter, which means that invariably as soon as you start developing down that path, you are making significant trade-offs. That's just from a economics slash developer ergonomics slash best practices point of view. But there's a sustainability story to it as well.Aerin: Yeah. I mean, this sustainability thing is like, if you're not going to encourage this new way of working, like, if you're not going to move everyone to this point of view and this is how we need to do things, then you kind of just propagating the old world, putting it into your data center. For every managed service that VMware migrated piece of crap, just that land in the cloud, it's not making a real difference in the world because that's still going to exist. And we mentioned this just before the podcast and, you know, a lot of focus these days and for a lot of people is, “Okay, green energy is the problem. We need to solve green energy.”And Amazon is the biggest purchaser of power purchase agreements in renewable energy around the world, more than most governments. Or I think that the biggest corporate purchaser of it anyway. And that all might sound great, like, “Oh, the cloud is going to solve this problem for me and Amazon is going to solve it for me even better because they're bigger.” But at the end of the day, when we think about a data center, it exists in the real world.It's made of concrete. You know, when you pour concrete and when you make concrete, it releases CO2. It's got racks of servers that all are running. So, those individual servers had to be made by whoever it is in Asia or mined from rare earth metals and end up in the supply chain and then transported into the data centers in us-east-1. And then things go wrong. You have to repair you have to replace and you have to maintain them.Unless we get these circular economies going in a closed system, we can't just continue to grow like this. Because carbon emissions related to Scope 3, all those things I've just been talking about, basically anything that isn't the energy, is about 80 to 90% of all the carbon emissions. So, when Amazon says, “Oh, we're going to go green and get energy done by 2030”—which is seven years away—they've then got ten years to solve 90% of the problem. And we cannot all just continue to grow and think of tech as neutral and better for the world if we still got that 90% problem, which we do right now. And it really frustrates me when you look at the world and the way we've jumped on technology just go on, “Oh, it must be good.”Like Bitcoin, for example. Bitcoin has released 200 million metric tons of CO2 since its inception. And for something that is basically a glorified Ponzi scheme, I can't see how that is making the world a better place. So, when cloud providers are making managed services for Web3 and for blockchain, and they're selling more and more AI and machine learning, basically so they can keep on selling GPU access, I do worry about whether our path to infinite growth with all of these hyperscalers is probably the wrong way of looking at things. So, linking back to, you know, the conference, open-source and, you know, thinking about things differently is really important in tech right now.And not just for your own well-being and being able to sleep at night, but this is how we're going to solve our problems. When all companies on the planet want people to be sustainable and we have to start tackling this because there's a financial cost related to it, then you're going to be in the vogue. If you're really good developer, thinking about things differently can be efficient, then yeah, you're the developer that's going to win in the future. You might be assisted by ChatGPT three or whatever else, but yeah, sustainability and efficiency can really be the number one priority because it's a win, win, win. We save the world, we make ourselves better, we sleep better at night, and you just become a better developer.I keep monologuing at this point, but you know, when it comes to stuff like games design, we look at things like Quake and Pokemon and all these things when there's like, “How did they get these amazing games and these amazing experiences in such small sizes,” they had boundaries. They had boundaries to innovate within because they had to. They couldn't release the game if they couldn't fit into the cartridge, therefore, they made it work. When the cloud is sold as infinitely scalable and horizontally scalable and no one needs to worry about this stuff because you can get your credit card out, people stop caring about being innovative and being more efficient. So yeah, let's get some more boundaries in the cloud.Corey: What I find that is super helpful, has been, like, if I can, like, descri—like, Instagram is down. Describe your lunch to me style meme description, like, the epic handshake where you have two people clasping hands, and one side is labeled in this case, ‘sustainability advocates,' and the other side should be labeled ‘cloud economists,' and in the middle, it's, “Turn that shit off.” Because it's not burning carbon if it's not running, and it's not costing you anything—ideally—if it's not running, so it's one of those ideas where we meet in the middle. And that's important, not just because it makes both of us independently happy because it's both good for the world and you'll get companies on board with this because, “Wait. We can do this thing and it saves us money?” Suddenly, you're getting them aligned because that is their religion.If companies could be said to have a religion, it is money. That's the way it works. So, you have to make it worth money for them to do the right thing or you're always going to be swimming upstream like a depressed salmon.Aerin: I mean, look at why [unintelligible 00:27:11] security is near the top: because there's so many big fines related to security breaches. It will cost them money not to be secure. Right now, it doesn't cost companies money to be inefficient or to release all this carbon, so they get away with it or they choose to do it. And I think that's going to change. We see in regulations across you're coming out.So, you know, if you work for a big multinational that operates in Europe, by next year, you'll have to report on all of your Scope 3 carbon emissions. If you're a customer of AWS right now, you have no ability to do that. So, you know, this is going to be crunch time over the next 18 months to two years for a lot of big businesses, for Amazon and the other hyperscalers, to really start demonstrating that they can do this. And I guess that's my big push. And, you know, I want to work with anyone, and it's funny because I have been running this business for about, you know, a couple of years now, it's been going really well, I did my podcast, I'm on this path.But I did, last year, take some time, and I applied into AWS. And you know, I was like, “Okay, maybe I'll apply for this big tech company and help Amazon out.” And because I'll take that salary and I'll do something really good with it afterwards, I'll do my time for three years and attend re:Invent and deliver 12 talks and never sleep, but you know, at the end of it, I'll say, “Okay, I've done that and now I can do something really good.” Unfortunately, I didn't get the role—or fortunately—but you know, when I applied for that role, what I said to them is, “I really care about sustainability. I want to make the world a better place. I want to help your customers be more sustainable.”And they didn't want me to join. So, I'm just going to continue doing that but from the outside. And whether that means working with politicians or developers or anyone else to try and make the world better and to kind of help fight against climate change, then, yeah, that's definitely what I'm doing.Corey: So, one last question before we wind up calling it an episode. How do we get there? What is the best next step that folks can take? Because it's easy to look at this as a grand problem and realize it's too big to solve. Well, great. You don't need to solve the entire problem. You need take the first step. What is that first step?Aerin: Individuals, I would say it's just realizing that you do care about it and you want to take action. And you're going to say to yourself, “Even if I do little things, I'm going to move forward towards that point.” So, if that is being a more sustainable engineer or getting more conversations about climate change or even just doing other things in your community to make the world a better place than it is, taking that action. But one thing that I can definitely help about and talk a bit more of is that at the conference itself, I'll be running a panel with some great experts called the, “Next Generation of Cloud Education.” So, I really think we need to—like I said earlier in the podcast—to think differently about the cloud and IT.So, I am doing this panel and I'm bringing together someone like Simon Wardley to help people do Wardley Mapping. Like, that is a tool that allows you to see the landscape that you're operating in. You know, if you use that sort of tool to understand the real-world impact of what you're doing, then you can start caring about it a bit more. I'm bringing in somebody called Anne Currie, who is a tech ethicist and speaker and lecturer, and she's actually written some [laugh] really great nonfiction books, which I'd recommend everyone reads. It starts with Utopia Five.And that's about asking, “Well, is this ethical? Can we continue to do these things?” Can't—talks about things about sustainability. If it's not sustainable for everyone, it's not ethical. So, when I mentioned 3 billion people currently don't use the internet, it's like, can we continue to just keep on doing things the same way?And then John Booth, who is a data center expert, to help us really understand what the reality is on the ground. What are these data centers really look like? And then Amanda Brock, from OpenUK in the conference will joining as well to talk about, kind of, open-source and how we can make the world kind of a better place by getting involved in these communities. So, that'll be a really great panel.But what I'm also doing is releasing this as an online course. So, for people who want to get involved, it will be very intimate, about 15 seats on each core, so three weeks for you to actually work and talk directly with some of these experts and me to figure out what you want to do in the world of climate change and how you can take those first steps. So, it'll be a journey that even starts with an ecotherapist to help us deal with climate grief and wonder about the things we can do as individuals to feel better ourselves and be happier. So, I think that'd be a really great thing for a lot of people. And, yeah, not only that, but… it'll be great for you, but it also goes towards making the world a better place.So, 50% of the course fees will be donated, 25%, to charity, and 25% supporting open-source projects. So, I think it kind of just win, win, win. And that's the story of sustainability in general. It's a win, win, win for everyone. If you start seeing the world through a lens of sustainability, you'll save money, you'll sleep better at night, you'll get involved with some really great communities, and meet some really great people who care about this as well. And yeah, it'll be a brighter future.Corey: If people want to learn more, where can they find you?Aerin: So, if you want to learn more about what I'm up to, I'm on Twitter under @aerincloud, that A-E-R-I-N cloud. And then you can also find me on LinkedIn. But I also run my own podcast that was inspired by Corey, called Public Cloud for Public Good talking about cloud sustainability and how to make the world a better place for the use of public cloud services.Corey: And we will, of course, put a link to that in the [show notes 00:32:32]. Thank you so much for your time. I appreciate it, as always.Aerin: Thank you.Corey: Aerin Booth, the Ted Lasso of cloud. 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 your podcast platform of choice, whereas if you've hated this episode, please leave a five-star review on your podcast platform of choice, along with an angry and insulting comment that I will immediately scale to zero in true serverless fashion.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

The complexity of business and business processes can pull us away from the big picture. Internal documents, graphs, and other visual representations are there to aid us, but they might not be detailed enough, intuitive, or easy to read. In this regard, Wardley maps are business management tools that help organizations visualize their processes by plotting all their components topologically. In this episode, researcher Simon Wardley teaches us his mapping technique for making sense of how organizations work and reach their highest potential.Listen to the full episode or read the transcript at https://semaphoreci.com/blog/wardley-mapsLike this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

It began with the forging of the Great Maps and Simon Wardley We've been talking this week about Wardley mapping. Simon Wardley features in our book 'The Value Flywheel Effect'. Where did you first hear about Wardley Mapping?  I first heard Simon Wardley talking at cloud conferences about early cloud. I remember an open source conference and a 20 minute video. Simon was really funny, which actually helped. When he presented it came across as common sense. Like, why would you do anything else? The bigger question is why were we looking for this type of stuff? Or why did it resonate with us? I think we were at a certain point in our careers. We had been engineers for a while. And we thought there's got to be a bigger picture here that we're not quite grasping. Simon Wardley started writing his book in 2016. I went to Lean Agile Scotland in October 2016. And he did the talk in person. I had seen his talk a couple of times, but it didn't really click until I sat and watched it in real life. I've always liked the idea of a group of people drawing a diagram to understand something. I think that is really powerful. Remember, there was a time when we said we need to stop using PowerPoint! We need to get people into rooms to have conversations and working sessions. I refined and improved my ability to do Wardley Maps through teaching. There were people who hadn't experienced mapping. Or if we had visitors or customers in the building, you'd get them into the end room with the big white wall and just start talking. You would try to teach them what a map was. And what each position meant. Or even just have a conversation. There's another important step. You move from doing it yourself to doing it in a group environment. When you are looking at a map you are figuring it out. When you do it in a group environment, the group will ask about this and that. And that's when it really starts to click. For me, the two big things are: 1. Start with a customer need. I remember a team were stuck for six months because they didn't know who the customer was. 2. The four phases of evolution or access (Genesis, Custom Built, Product, Commodity). Get your head around that concept. One of the other pitfalls we fell into was mapping too much detail. We went too low level. And then someone came along and zoomed us out, by saying 'you don't need those five components. Here's just one!'. Practice, practice, practice is the big lesson here. We knew we were starting to get good when we were able to roll it out across multiple teams to map out the tech stack. They were getting value and getting excited about doing it. And we were getting lots of feedback on what did or didn't work. We were in offices and I would draw maps on the board. It was all very collaborative. But now we have the emergence of good online collaboration tools like Miro etc. Another important lesson is that senior people just want to hear what you are going to do. They don't want to know how you figured it out. If they say why are you doing that? You can go through the map in your head and say that you've thought about it. If you say this is what we are going to do and here's the outcome, you don't need to show them all your work. When we started mapping there wasn't much about apart from the odd presentation. Now there's lots of material out there. The community is growing. You can google and look up YouTube. And there's online conferences as well like Map Camp. Those videos are available soon as well. A lot of Simon Wardley's maps are readily available on GitHub. A lot of the work in UK.Gov carried out by Liam Maxwell and others still stands the test of time. If you look at the UK government's digital footprint, it's still in there on freely available materials. Their work is permeated with thinking about user needs, understanding value chains and situational awareness and mapping. For resources look at Simon Wardley on Twitter @swardley and his pinned tweet. Simon has a book: 'Wardley mapping'. He is on Medium at 'wardleymaps'. There's a whole bunch of stuff including free articles. They're fairly meaty but they're good. John Grant keeps a list of maps on GitHub, which is list.wardleymaps.com. Ben from @hiredthought is also at learnwardleymapping.com. And of course, our book, 'The Value Flywheel Effect' is coming to a store near you soon. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect book Follow us on Twitter @ServerlessEdge Transcribed by https://otter.ai

Join Murray Robinson and Shane Gibson in a conversation with Simon Wardley about Wardley maps. Wardely maps are a discussion tool that surfaces assumptions about competitive landscapes. Starting with the customer, we draw the value chain of components that we need to meet their goal and then identify what stage each component is in the evolutionary lifecycle. Is a component a custom build, a product or service or a commodity or utility. When there is a competitive market everything moves to become a high volume, low cost standardised commodity over time. Understanding this allows you to get ahead of the wave of market change and it allows you to identify enormous cost savings by using utility services like AWS instead of building your own data centre.   Listen to the podcast on your favourite podcast app: | Spotify | Apple Podcasts | Google Podcasts | iHeart Radio | PlayerFM | Amazon Music | Listen Notes | TuneIn | Audible | Podchaser |  Connect with Simon on LinkedIn Read Simons draft book for free at https://medium.com/wardleymaps Contact Murray via email or Shane in the Twitter-sphere  @shagility.   The No Nonsense Podcast is sponsored by: Simply Magical Data

In this talk from our Online Spring Conference in 2021, Simon Wardley walks us through how Wardley mapping helps you to understand where your business is, identify opportunities and threats to its existence, make plans for the future and, gameplay the routes to getting to where you want to be. It is a powerful tool to inform your strategy and monitor your progress. --- Send in a voice message: https://anchor.fm/business-of-software/message

Wardley Mapping

Wardley Mapping

MLOps Coffee Sessions #86 with Julien Bisconti, Building ML/Data Platform on Top of Kubernetes. // Abstract When building a platform, a good start would be to define the goals and features of that platform, knowing it will evolve. Kubernetes is established as the de facto standard for scalable platforms but it is not a fully-fledged data platform. Do ML engineers have to learn and use Kubernetes directly? They probably shouldn't. So it is up to the data engineering team to provide the tools and abstraction necessary to allow ML engineers to do their work. The time, effort, and knowledge it takes to build a data platform is already quite an achievement. When it is built, one has to maintain it, monitor it, train people to on-call rotation, implement escalation policies and disaster recovery, optimize for usage and costs, secure it and build a whole ecosystem of tools around it (front-end, CLI, dashboards). That cost might be too high and time-consuming for some companies to consider building their own ML platform as opposed to cloud offering alternatives. Note that cloud offerings still require some of those points but most of the work is already done. // Bio Julien is a software engineer turned Site Reliability Engineer. He is a Google developer expert, certified Data Engineer on Google Cloud and Kubernetes Administrator, mentor for Woman Developer Academy and Google For Startups program. He is working on building and maintaining data/ML platform. // Related Links https://portal.superwise.ai/ Crossing the River by Feeling the Stones • Simon Wardley • GOTO 2018: https://www.youtube.com/watch?v=2IW9L1uNMCs --------------- ✌️Connect With Us ✌️ ------------- Join our slack community: https://go.mlops.community/slack Follow us on Twitter: @mlopscommunity Sign up for the next meetup: https://go.mlops.community/register Catch all episodes, blogs, newsletter and more: https://mlops.community/ Connect with Demetrios on LinkedIn: https://www.linkedin.com/in/dpbrinkm/ Connect with Vishnu on LinkedIn: https://www.linkedin.com/in/vrachakonda/ Connect with Julien on LinkedIn: https://www.linkedin.com/in/julienbisconti/ Timestamps: [00:00] French intro by Julien [00:32] Introduction to Julien Bisconti [03:35] Arriving at the non-technical side process of MLOps [06:06] Envious of people with technological problems [07:27] People problem bandwidth conversation [11:04] Atomic decision making [14:20] Advice to developers either to buy or build in their career potential [18:23] Jobs board - https://mlops.pallet.xyz/jobs [21:28] Chaos engineering [26:33] Role of chaos engineering in building production machine learning systems [32:59] Core challenge of MLOps [37:04] Standardization on an industry level [40:30] Reconciliation of trade-offs using Vertex and Sagemaker [45:21] Crossing the River by Feeling the Stones talk by Simon Wardley [47:22] Wrap up

Dave, Mark and Mike discuss Dave's 'Adaptation - the Value Flywheel' talk at Map Camp 2021. In this episode they work through Wardley Mapping as a concept demonstrating an example that Simon Wardley uses when mapping serverless as a concept. They then move on to Dave's talk at Map Camp which develops the concept further through the use of the Value Flywheel.  This sets the context of how Wardley Mapping works in the practical implementation of ongoing technical strategy.   https://www.mapcamp.co.uk/ https://twitter.com/MapsAsCode https://onlinewardleymaps.com/ https://twitter.com/swardley/status/1436280981087047682  https://twitter.com/davidand393/status/1448260882350346242  https://architectelevator.com/  https://theserverlessedge.com New Book from David Anderson itrevolution.com Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

Simon Wardley is a researcher for the Leading Edge Forum focused on the intersection of IT strategy and new technologies. Simon is a seasoned executive who has spent the last 15 years defining future IT strategies for companies in the FMCG, retail, and IT industries—from Canon's early leadership in the cloud-computing space in 2005 to Ubuntu's recent dominance as the top cloud operating system. As a geneticist with a love of mathematics and a fascination for economics, Simon has always found himself dealing with complex systems, whether in behavioral patterns, the environmental risks of chemical pollution, developing novel computer systems, or managing companies. He is a passionate advocate and researcher in the fields of open source, commoditization, innovation, organizational structure, and cybernetics.Simon's most recent published research, “Clash of the Titans: Can China Dethrone Silicon Valley?,” assesses the high-tech challenge from China and what this means to the future of global technology industry competition. His previous research covers topics including the nature of technological and business change over the next 20 years, value chain mapping, strategies for an increasingly open economy, Web 2.0, and a lifecycle approach to cloud computing. Simon is a regular presenter at conferences worldwide and has been voted one of the UK's top 50 most influential people in IT in Computer Weekly's 2011 and 2012 polls.Twitter: https://twitter.com/swardleyMedium: https://swardley.medium.comBlog: https://blog.gardeviance.orgWardley Maps (free online book): https://medium.com/wardleymapsSimon's slides discussed during the podcast

This Episode Joekub tackles the elusive topic: STRATEGY Simon Wardley (inventor of Wardley Mapping) & Chris Daniel (Strategy guru) Join Jakub and Joe on the hunt for what a good strategy is, does, and looks like. They explore topics like: • Is a strategy just a few lines of text? • Do you even need a strategy? • Can anyone make a strategy? • How to use Wardley Maps to be excommunicated from your business (and also how not to) Jakub and Joe got so excited about this conversation that the podcast spills over to a video recorded event of Simon Wardley making a Wardley map of the Joekub Podcast. We go full on meta as we begin to feel the potential of Wardley Mapping in real time. The follow up video of Joe and Jakub mapping is available here: https://youtu.be/qdh5lA0Qz3I Join us for laughs, amazing stories and lots of insights. If you'd like to learn how to make your own Wardely Map, check out these resources: intro to Wardley Maps: https://aktiasolutions.com/introduction-to-wardley-maps/ make your own maps: https://onlinewardleymaps.com/ --- Send in a voice message: https://anchor.fm/joekub/message

The host of CFO Bookshelf bumped into Simon Wardley's writing on mapping strategy several years ago, and he couldn't put his content down.In this conversation, we talk about the strategy circle, the OODA loop, the 'why' of purpose, doctrine, and many other key concepts related to Wardley Mapping.

About Rebecca MarshburnRebecca's interested in the things that interest people—What's important to them? Why? And when did they first discover it to be so? She's also interested in sharing stories, elevating others' experiences, exploring the intersection of physical environments and human behavior, and crafting the perfect pun for every situation. Today, Rebecca is the Head of Content & Community at Common Room. Prior to Common Room, she led the AWS Serverless Heroes program, where she met the singular Jeremy Daly, and guided content and product experiences for fashion magazines, online blogs, AR/VR companies, education companies, and a little travel outfit called Airbnb.Twitter: @beccaodelayLinkedIn: Rebecca MarshburnCompany: www.commonroom.ioPersonal work (all proceeds go to the charity of the buyer's choice): www.letterstomyexlovers.comWatch this episode on YouTube: https://youtu.be/VVEtxgh6GKI This episode sponsored by CBT Nuggets and Lumigo.Transcript:Rebecca: What a day today is! It's not every day you turn 100 times old, and on this day we celebrate Serverless Chats 100th episode with the most special of guests. The gentleman whose voice you usually hear on this end of the microphone, doing the asking, but today he's going to be doing the telling, the one and only, Jeremy Daly, and me. I'm Rebecca Marshburn, and your guest host for Serverless Chats 100th episode, because it's quite difficult to interview yourself. Hey Jeremy!Jeremy: Hey Rebecca, thank you very much for doing this.Rebecca: Oh my gosh. I am super excited to be here, couldn't be more honored. I'll give your listeners, our listeners, today, the special day, a little bit of background about us. Jeremy and I met through the AWS Serverless Heroes program, where I used to be a coordinator for quite some time. We support each other in content, conferences, product requests, road mapping, community-building, and most importantly, I think we've supported each other in spirit, and now I'm the head of content and community at Common Room, and Jeremy's leading Serverless Cloud at Serverless, Inc., so it's even sweeter that we're back together to celebrate this Serverless Chats milestone with you all, the most important, important, important, important part of the podcast equation, the serverless community. So without further ado, let's begin.Jeremy: All right, hit me up with whatever questions you have. I'm here to answer anything.Rebecca: Jeremy, I'm going to ask you a few heavy hitters, so I hope you're ready.Jeremy: I'm ready to go.Rebecca: And the first one's going to ask you to step way, way, way, way, way back into your time machine, so if you've got the proper attire on, let's do it. If we're going to step into that time machine, let's peel the layers, before serverless, before containers, before cloud even, what is the origin story of Jeremy Daly, the man who usually asks the questions.Jeremy: That's tough. I don't think time machines go back that far, but it's funny, when I was in high school, I was involved with music, and plays, and all kinds of things like that. I was a very creative person. I loved creating things, that was one of the biggest sort of things, and whether it was music or whatever and I did a lot of work with video actually, back in the day. I was always volunteering at the local public access station. And when I graduated from high school, I had no idea what I wanted to do. I had used computers at the computer lab at the high school. I mean, this is going back a ways, so it wasn't everyone had their own computer in their house, but I went to college and then, my first, my freshman year in college, I ended up, there's a suite-mate that I had who showed me a website that he built on the university servers.And I saw that and I was immediately like, "Whoa, how do you do that"? Right, just this idea of creating something new and being able to build that out was super exciting to me, so I spent the next couple of weeks figuring out how to do HTML, and this was before, this was like when JavaScript was super, super early and we're talking like 1997, and everything was super early. I was using this, I eventually moved away from using FrontPage and started using this thing called HotDog. It was a software for HTML coding, but I started doing that, and I started building websites, and then after a while, I started figuring out what things like CGI-bins were, and how you could write Perl scripts, and how you could make interactions happen, and how you could capture FormData and serve up different things, and it was a lot of copying and pasting.My major at the time, I think was psychology, because it was like a default thing that I could do. But then I moved into computer science. I did computer science for about a year, and I felt that that was a little bit too narrow for what I was hoping to sort of do. I was starting to become more entrepreneurial. I had started selling websites to people. I had gone to a couple of local businesses and started building websites, so I actually expanded that and ended up doing sort of a major that straddled computer science and management, like business administration. So I ended up graduating with a degree in e-commerce and internet marketing, which is sort of very early, like before any of this stuff seemed to even exist. And then from there, I started a web development company, worked on that for 12 years, and then I ended up selling that off. Did a startup, failed the startup. Then from that startup, went to another startup, worked there for a couple of years, went to another startup, did a lot of consulting in between there, somewhere along the way I found serverless and AWS Cloud, and then now it's sort of led me to advocacy for building things with serverless and now I'm building sort of the, I think what I've been dreaming about building for the last several years in what I'm doing now at Serverless, Inc.Rebecca: Wow. All right. So this love story started in the 90s.Jeremy: The 90s, right.Rebecca: That's an incredible, era and welcome to 2021.Jeremy: Right. It's been a journey.Rebecca: Yeah, truly, that's literally a new millennium. So in a broad way of saying it, you've seen it all. You've started from the very HotDog of the world, to today, which is an incredible name, I'm going to have to look them up later. So then you said serverless came along somewhere in there, but let's go to the middle of your story here, so before Serverless Chats, before its predecessor, which is your weekly Off-by-none newsletter, and before, this is my favorite one, debates around, what the suffix "less" means when appended to server. When did you first hear about Serverless in that moment, or perhaps you don't remember the exact minute, but I do really want to know what struck you about it? What stood out about serverless rather than any of the other types of technologies that you could have been struck by and been having a podcast around?Jeremy: Right. And I think I gave you maybe too much of a surface level of what I've seen, because I talked mostly about software, but if we go back, I mean, hardware was one of those things where hardware, and installing software, and running servers, and doing networking, and all those sort of things, those were part of my early career as well. When I was running my web development company, we started by hosting on some hosting service somewhere, and then we ended up getting a dedicated server, and then we outgrew that, and then we ended up saying, "Well maybe we'll bring stuff in-house". So we did on-prem for quite some time, where we had our own servers in the T1 line, and then we moved to another building that had a T3 line, and if anybody doesn't know what that is, you probably don't need to anymore.But those are the things that we were doing, and then eventually we moved into a co-location facility where we rented space, and we rented electricity, and we rented all the utilities, the bandwidth, and so forth, but we had Blade servers and I was running VMware, and we were doing all this kind of stuff to manage the infrastructure, and then writing software on top of that, so it was a lot of work. I know I posted something on Twitter a few weeks ago, about how, when I was, when we were young, we used to have to carry a server on our back, uphill, both ways, to the data center, in the snow, with no shoes, and that's kind of how it felt, that you were doing a lot of these things.And then 2008, 2009, as I was kind of wrapping up my web development company, we were just in the process of actually saying it's too expensive at the colo. I think we were paying probably between like $5,000 and $7,000 a month between the ... we had leases on some of the servers, you're paying for electricity, you're paying for all these other things, and we were running a fair amount of services in there, so it seemed justifiable. We were making money on it, that wasn't the problem, but it just was a very expensive fixed cost for us, and when the cloud started coming along and I started actually building out the startup that I was working on, we were building all of that in the cloud, and as I was learning more about the cloud and how that works, I'm like, I should just move all this stuff that's in the co-location facility, move that over to the cloud and see what happens.And it took a couple of weeks to get that set up, and now, again, this is early, this is before ELB, this is before RDS, this is before, I mean, this was very, very early cloud. I mean, I think there was S3 and EC2. I think those were the two services that were available, with a few other things. I don't even think there were VPCs yet. But anyways, I moved everything over, took a couple of weeks to get that over, and essentially our bill to host all of our clients' sites and projects went from $5,000 to $7,000 a month, to $750 a month or something like that, and it's funny because had I done that earlier, I may not have sold off my web development company because it could have been much more profitable, so it was just an interesting move there.So we got into the cloud fairly early and started sort of leveraging that, and it was great to see all these things get added and all these specialty services, like RDS, and just taking the responsibility because I literally was installing Microsoft SQL server on an EC2 instance, which is not something that you want to do, you want to use RDS. It's just a much better way to do it, but anyways, so I was working for another startup, this was like startup number 17 or whatever it was I was working for, and we had this incident where we were using ... we had a pretty good setup. I mean, everything was on EC2 instances, but we were using DynamoDB to do some caching layers for certain things. We were using a sharded database, MySQL database, for product information, and so forth.So the system was pretty resilient, it was pretty, it handled all of the load testing we did and things like that, but then we actually got featured on Good Morning America, and they mentioned our app, it was the Power to Mobile app, and so we get mentioned on Good Morning America. I think it was Good Morning America. The Today Show? Good Morning America, I think it was. One of those morning shows, anyways, we got about 10,000 sign-ups in less than a minute, which was amazing, or it was just this huge spike in traffic, which was great. The problem was, is we had this really weak point in our system where we had to basically get a lock on the database in order to get an incremental-ID, and so essentially what happened is the database choked, and then as soon as the database choked, just to create user accounts, other users couldn't sign in and there was all kinds of problems, so we basically lost out on all of this capability.So I spent some time doing a lot of research and trying to figure out how do you scale that? How do you scale something that fast? How do you have that resilience in there? And there's all kinds of ways that we could have done it with traditional hardware, it's not like it wasn't possible to do with a slightly better strategy, but as I was digging around in AWS, I'm looking around at some different things, and we were, I was always in the console cause we were using Dynamo and some of those things, and I came across this thing that said "Lambda," with a little new thing next to it. I'm like, what the heck is this?So I click on that and I start reading about it, and I'm like, this is amazing. We don't have to spin up a server, we don't have to use Chef, or Puppet, or anything like that to spin up these machines. We can basically just say, when X happens, do Y, and it enlightened me, and this was early 2015, so this would have been right after Lambda went GA. Had never heard of Lambda as part of the preview, I mean, I wasn't sort of in that the re:Invent, I don't know, what would you call that? Vortex, maybe, is a good way to describe the event.Rebecca: Vortex sounds about right. That's about how it feels by the end.Jeremy: Right, exactly. So I wasn't really in that, I wasn't in that group yet, I wasn't part of that community, so I hadn't heard about it, and so as I started playing around with it, I immediately saw the value there, because, for me, as someone who again had managed servers, and it had built out really complex networking too. I think some of the things you don't think about when you move to an on-prem where you're managing your stuff, even what the cloud manages for you. I mean, we had firewalls, and we had to do all the firewall rules ourselves, right. I mean, I know you still have to do security groups and things like that in AWS, but just the level of complexity is a lot lower when you're in the cloud, and of course there's so many great services and systems that help you do that now.But just the idea of saying, "wait a minute, so if I have something happen, like a user signup, for example, and I don't have to worry about provisioning all the servers that I need in order to handle that," and again, it wasn't so much the server aspect of it as it was the database aspect of it, but one of the things that was sort of interesting about the idea of Serverless 2 was this asynchronous nature of it, this idea of being more event-driven, and that things don't have to happen immediately necessarily. So that just struck me as something where it seemed like it would reduce a lot, and again, this term has been overused, but the undifferentiated heavy-lifting, we use that term over and over again, but there is not a better term for that, right?Because there were just so many things that you have to do as a developer, as an ops person, somebody who is trying to straddle teams, or just a PM, or whatever you are, so many things that you have to do in order to get an application running, first of all, and then even more you have to do in order to keep it up and running, and then even more, if you start thinking about distributing it, or scaling it, or getting any of those things, disaster recovery. I mean, there's a million things you have to think about, and I saw serverless immediately as this opportunity to say, "Wait a minute, this could reduce a lot of that complexity and manage all of that for you," and then again, literally let you focus on the things that actually matter for your business.Rebecca: Okay. As someone who worked, how should I say this, in metatech, or the technology of technology in the serverless space, when you say that you were starting to build that without ELB even, or RDS, my level of anxiety is like, I really feel like I'm watching a slow horror film. I'm like, "No, no, no, no, no, you didn't, you didn't, you didn't have to do that, did you"?Jeremy: We did.Rebecca: So I applaud you for making it to the end of the film and still being with us.Jeremy: Well, the other thing ...Rebecca: Only one protagonist does that.Jeremy: Well, the other thing that's interesting too, about Serverless, and where it was in 2015, Lambda goes GA, this will give you some anxiety, there was no API gateway. So there was no way to actually trigger a Lambda function from a web request, right. There was no VPC access in Lambda functions, which meant you couldn't connect to a database. The only thing you do is connect via HDP, so you could connect to DynamoDB or things like that, but you could not connect directly to RDS, for example. So if you go back and you look at the timeline of when these things were released, I mean, if just from 2015, I mean, you literally feel like a caveman thinking about what you could do back then again, it's banging two sticks together versus where we are now, and the capabilities that are available to us.Rebecca: Yeah, you're sort of in Plato's cave, right, and you're looking up and you're like, "It's quite dark in here," and Lambda's up there, outside, sowing seeds, being like, "Come on out, it's dark in there". All right, so I imagine you discovering Lambda through the console is not a sentence you hear every day or general console discovery of a new product that will then sort of change the way that you build, and so I'm guessing maybe one of the reasons why you started your Off-by-none newsletter or Serverless Chats, right, is to be like, "How do I help tell others about this without them needing to discover it through the console"? But I'm curious what your why is. Why first the Off-by-none newsletter, which is one of my favorite things to receive every week, thank you for continuing to write such great content, and then why Serverless Chats? Why are we here today? Why are we at number 100? Which I'm so excited about every time I say it.Jeremy: And it's kind of crazy to think about all the people I've gotten a chance to talk to, but so, I think if you go back, I started writing blog posts maybe in 2015, so I haven't been doing it that long, and I certainly wasn't prolific. I wasn't consistent writing a blog post every week or every, two a week, like some people do now, which is kind of crazy. I don't know how that, I mean, it's hard enough writing the newsletter every week, never mind writing original content, but I started writing about Serverless. I think it wasn't until the beginning of 2018, maybe the end of 2017, and there was already a lot of great content out there. I mean, Ben Kehoe was very early into this and a lot of his stuff I read very early.I mean, there's just so many people that were very early in the space, I mean, Paul Johnson, I mean, just so many people, right, and I started reading what they were writing and I was like, "Oh, I've got some ideas too, I've been experimenting with some things, I feel like I've gotten to a point where what I could share could be potentially useful". So I started writing blog posts, and I think one of the earlier blog posts I wrote was, I want to say 2017, maybe it was 2018, early 2018, but was a post about serverless security, and what was great about that post was that actually got me connected with Ory Segal, who had started PureSec, and he and I became friends and that was the other great thing too, is just becoming part of this community was amazing.So many awesome people that I've met, but so I saw all this stuff people were writing and these things people were doing, and I got to maybe August of 2018, and I said to myself, I'm like, "Okay, I don't know if people are interested in what I'm writing". I wasn't writing a lot, but I was writing a little bit, but I wasn't sure people were overly interested in what I was writing, and again, that idea of the imposter syndrome, certainly everything was very early, so I felt a little bit more comfortable. I always felt like, well, maybe nobody knows what they're talking about here, so if I throw something into the fold it won't be too, too bad, but certainly, I was reading other things by other people that I was interested in, and I thought to myself, I'm like, "Okay, if I'm interested in this stuff, other people have to be interested in this stuff," but it wasn't easy to find, right.I mean, there was sort of a serverless Twitter, if you want to use that terminology, where a lot of people tweet about it and so forth, obviously it's gotten very noisy now because of people slapped that term on way too many things, but I don't want to have that discussion, but so I'm reading all this great stuff and I'm like, "I really want to share it," and I'm like, "Well, I guess the best way to do that would just be a newsletter."I had an email list for my own personal site that I had had a couple of hundred people on, and I'm like, "Well, let me just turn it into this thing, and I'll share these stories, and maybe people will find them interesting," and I know this is going to sound a little bit corny, but I have two teenage daughters, so I'm allowed to be sort of this dad-jokey type. I remember when I started writing the first version of this newsletter and I said to myself, I'm like, "I don't want this to be a newsletter." I was toying around with this idea of calling it an un-newsletter. I didn't want it to just be another list of links that you click on, and I know that's interesting to some people, but I felt like there was an opportunity to opine on it, to look at the individual links, and maybe even tell a story as part of all of the links that were shared that week, and I thought that that would be more interesting than just getting a list of links.And I'm sure you've seen over the last 140 issues, or however many we're at now, that there's been changes in the way that we formatted it, and we've tried new things, and things like that, but ultimately, and this goes back to the corny thing, I mean, one of the first things that I wanted to do was, I wanted to basically thank people for writing this stuff. I wanted to basically say, "Look, this is not just about you writing some content". This is big, this is important, and I appreciate it. I appreciate you for writing that content, and I wanted to make it more of a celebration really of the community and the people that were early contributors to that space, and that's one of the reasons why I did the Serverless Star thing.I thought, if somebody writes a really good article some week, and it's just, it really hits me, or somebody else says, "Hey, this person wrote a great article," or whatever. I wanted to sort of celebrate that person and call them out because that's one of the things too is writing blog posts or posting things on social media without a good following, or without the dopamine hit of people liking it, or re-tweeting it, and things like that, it can be a pretty lonely place. I mean, I know I feel that way sometimes when you put something out there, and you think it's important, or you think people might want to see it, and just not enough people see it.It's even worse, I mean, 240 characters, or whatever it is to write a tweet is one thing, or 280 characters, but if you're spending time putting together a tutorial or you put together a really good thought piece, or story, or use case, or something where you feel like this is worth sharing, because it could inspire somebody else, or it could help somebody else, could get them past a bump, it could make them think about something a different way, or get them over a hump, or whatever. I mean, that's just the kind of thing where I think people need that encouragement, and I think people deserve that encouragement for the work that they're doing, and that's what I wanted to do with Off-by-none, is make sure that I got that out there, and to just try to amplify those voices the best that I could. The other thing where it's sort of progressed, and I guess maybe I'm getting ahead of myself, but the other place where it's progressed and I thought was really interesting, was, finding people ...There's the heavy hitters in the serverless space, right? The ones we all know, and you can name them all, and they are great, and they produce amazing content, and they do amazing things, but they have pretty good engines to get their content out, right? I mean, some people who write for the AWS blog, they're on the AWS blog, right, so they're doing pretty well in terms of getting their things out there, right, and they've got pretty good engines.There's some good dev advocates too, that just have good Twitter followings and things like that. Then there's that guy who writes the story. I don't know, he's in India or he's in Poland or something like that. He writes this really good tutorial on how to do this odd edge-case for serverless. And you go and you look at their Medium and they've got two followers on Medium, five followers on Twitter or something like that. And that to me, just seems unfair, right? I mean, they've written a really good piece and it's worth sharing right? And it needs to get out there. I don't have a huge audience. I know that. I mean I've got a good following on Twitter. I feel like a lot of my Twitter followers, we can have good conversations, which is what you want on Twitter.The newsletter has continued to grow. We've got a good listener base for this show here. So, I don't have a huge audience, but if I can share that audience with other people and get other people to the forefront, then that's important to me. And I love finding those people and those ideas that other people might not see because they're not looking for them. So, if I can be part of that and help share that, that to me, it's not only a responsibility, it's just it's incredibly rewarding. So ...Rebecca: Yeah, I have to ... I mean, it is your 100th episode, so hopefully I can give you some kudos, but if celebrating others' work is one of your main tenets, you nail it every time. So ...Jeremy: I appreciate that.Rebecca: Just wanted you to know that. So, that's sort of the Genesis of course, of both of these, right?Jeremy: Right.Rebecca: That underpins the foundational how to share both works or how to share others' work through different channels. I'm wondering how it transformed, there's this newsletter and then of course it also has this other component, which is Serverless Chats. And that moment when you were like, "All right, this newsletter, this narrative that I'm telling behind serverless, highlighting all of these different authors from all these different global spaces, I'm going to start ... You know what else I want to do? I don't have enough to do, I'm going to start a podcast." How did we get here?Jeremy: Well, so the funny thing is now that I think about it, I think it just goes back to this tenet of fairness, this idea where I was fortunate, and I was able to go down to New York City and go to Serverless Days New York in late 2018. I was able to ... Tom McLaughlin actually got me connected with a bunch of great people in Boston. I live just outside of Boston. We got connected with a bunch of great people. And we started the Serverless Days Boston for 2019. And we were on that committee. I started traveling and I was going to conferences and I was meeting people. I went to re:Invent in 2018, which I know a lot of people just don't have the opportunity to do. And the interesting thing was, is that I was pulling aside brilliant people either in the hallway at a conference or more likely for a very long, deep discussion that we would have about something at a pub in Northern Ireland or something like that, right?I mean, these were opportunities that I was getting that I was privileged enough to get. And I'm like, these are amazing conversations. Just things that, for me, I know changed the way I think. And one of the biggest things that I try to do is evolve my thinking. What I thought a year ago is probably not what I think now. Maybe call it flip-flopping, whatever you want to call it. But I think that evolving your thinking is the most progressive thing that you can do and starting to understand as you gain new perspectives. And I was talking to people that I never would have talked to if I was just sitting here in my home office or at the time, I mean, I was at another office, but still, I wasn't getting that context. I wasn't getting that experience. And I wasn't getting those stories that literally changed my mind and made me think about things differently.And so, here I was in this privileged position, being able to talk to these amazing people and in some cases funny, because they're celebrities in their own right, right? I mean, these are the people where other people think of them and it's almost like they're a celebrity. And these people, I think they deserve fame. Don't get me wrong. But like as someone who has been on that side of it as well, it's ... I don't know, it's weird. It's weird to have fans in a sense. I love, again, you can be my friend, you don't have to be my fan. But that's how I felt about ...Rebecca: I'm a fan of my friends.Jeremy: So, a fan and my friend. So, having talked to these other people and having these really deep conversations on serverless and go beyond serverless to me. Actually I had quite a few conversations with some people that have nothing to do with serverless. Actually, Peter Sbarski and I, every time we get together, we only talk about the value of going to college for some reason. I don't know why. It has usually nothing to do with serverless. So, I'm having these great conversations with these people and I'm like, "Wow, I wish I could share these. I wish other people could have this experience," because I can tell you right now, there's people who can't travel, especially a lot of people outside of the United States. They ... it's hard to travel to the United States sometimes.So, these conversations are going on and I thought to myself, I'm like, "Wouldn't it be great if we could just have these conversations and let other people hear them, hopefully without bar glasses clinking in the background. And so I said, "You know what? Let's just try it. Let's see what happens. I'll do a couple of episodes. If it works, it works. If it doesn't, it doesn't. If people are interested, they're interested." But that was the genesis of that, I mean, it just goes back to this idea where I felt a little selfish having conversations and not being able to share them with other people.Rebecca: It's the very Jeremy Daly tenet slogan, right? You got to share it. You got to share it ...Jeremy: Got to share it, right?Rebecca: The more he shares it, it celebrates it. I love that. I think you do ... Yeah, you do a great job giving a megaphone so that more people can hear. So, in case you need a reminder, actually, I'll ask you, I know what the answer is to this, but do you know the answer? What was your very first episode of Serverless Chats? What was the name, and how long did it last?Jeremy: What was the name?Rebecca: Oh yeah. Oh yeah.Jeremy: Oh, well I know ... Oh, I remember now. Well, I know it was Alex DeBrie. I absolutely know that it was Alex DeBrie because ...Rebecca: Correct on that.Jeremy: If nobody, if you do not know Alex DeBrie, not only is he an AWS data hero, as well as the author of The DynamoDB Book, but he's also like the most likable person on the planet too. It is really hard if you've ever met Alex, that you wouldn't remember him. Alex and I started communicating, again, we met through the serverless space. I think actually he was working at Serverless Inc. at the time when we first met. And I think I met him in person, finally met him in person at re:Invent 2018. But he and I have collaborated on a number of things and so forth. So, let me think what the name of it was. "Serverless Purity Versus Practicality" or something like that. Is that close?Rebecca: That's exactly what it was.Jeremy: Oh, all right. I nailed it. Nailed it. Yes!Rebecca: Wow. Well, it's a great title. And I think ...Jeremy: Don't ask me what episode number 27 was though, because no way I could tell you that.Rebecca: And just for fun, it was 34 minutes long and you released it on June 17th, 2019. So, you've come a long way in a year and a half. That's some kind of wildness. So it makes sense, like, "THE," capital, all caps, bold, italic, author for databases, Alex DeBrie. Makes sense why you selected him as your guest. I'm wondering if you remember any of the ... What do you remember most about that episode? What was it like planning it? What was the reception of it? Anything funny happened recording it or releasing it?Jeremy: Yeah, well, I mean, so the funny thing is that I was incredibly nervous. I still am, actually a lot of guests that I have, I'm still incredibly nervous when I'm about to do the actual interview. And I think it's partially because I want to do justice to the content that they're presenting and to their expertise. And I feel like there's a responsibility to them, but I also feel like the guests that I've had on, some of them are just so smart, and the things they say, just I'm in awe of some of the things that come out of these people's mouths. And I'm like, "This is amazing and people need to hear this." And so, I feel like we've had really good episodes and we've had some okay episodes, but I feel like I want to try to keep that level up so that they owe that to my listener to make sure that there is high quality episode that, high quality information that they're going to get out of that.But going back to the planning of the initial episodes, so I actually had six episodes recorded before I even released the first one. And the reason why I did that was because I said, "All right, there's no way that I can record an episode and then wait a week and then record another episode and wait a week." And I thought batching them would be a good idea. And so, very early on, I had Alex and I had Nitzan Shapira and I had Ran Ribenzaft and I had Marcia Villalba and I had Erik Peterson from Cloud Zero. And so, I had a whole bunch of these episodes and I reached out to I think, eight or nine people. And I said, "I'm doing this thing, would you be interested in it?" Whatever, and we did planning sessions, still a thing that I do today, it's still part of the process.So, whenever I have a guest on, if you are listening to an episode and you're like, "Wow, how did they just like keep the thing going ..." It's not scripted. I don't want people to think it's scripted, but it is, we do review the outline and we go through some talking points to make sure that again, the high-quality episode and that the guest says all the things that the guest wants to say. A lot of it is spontaneous, right? I mean, the language is spontaneous, but we do, we do try to plan these episodes ahead of time so that we make sure that again, we get the content out and we talk about all the things we want to talk about. But with Alex, it was funny.He was actually the first of the six episodes that I recorded, though. And I wasn't sure who I was going to do first, but I hadn't quite picked it yet, but I recorded with Alex first. And it was an easy, easy conversation. And the reason why it was an easy conversation was because we had talked a number of times, right? It was that in a pub, talking or whatever, and having that friendly chat. So, that was a pretty easy conversation. And I remember the first several conversations I had, I knew Nitzan very well. I knew Ran very well. I knew Erik very well. Erik helped plan Serverless Days Boston with me. And I had known Marcia very well. Marcia actually had interviewed me when we were in Vegas for re:Invent 2018.So, those were very comfortable conversations. And so, it actually was a lot easier to do, which probably gave me a false sense of security. I was like, "Wow, this was ... These came out pretty well." The conversations worked pretty well. And also it was super easy because I was just doing audio. And once you add the video component into it, it gets a little bit more complex. But yeah, I mean, I don't know if there's anything funny that happened during it, other than the fact that I mean, I was incredibly nervous when we recorded those, because I just didn't know what to expect. If anybody wants to know, "Hey, how do you just jump right into podcasting?" I didn't. I actually was planning on how can I record my voice? How can I get comfortable behind a microphone? And so, one of the things that I did was I started creating audio versions of my blog posts and posting them on SoundCloud.So, I did that for a couple of ... I'm sorry, a couple of blog posts that I did. And that just helped make me feel a bit more comfortable about being able to record and getting a little bit more comfortable, even though I still can't stand the sound of my own voice, but hopefully that doesn't bother other people.Rebecca: That is an amazing ... I think we so often talk about ideas around you know where you want to go and you have this vision and that's your goal. And it's a constant reminder to be like, "How do I make incremental steps to actually get to that goal?" And I love that as a life hack, like, "Hey, start with something you already know that you wrote and feel comfortable in and say it out loud and say it out loud again and say it out loud again." And you may never love your voice, but you will at least feel comfortable saying things out loud on a podcast.Jeremy: Right, right, right. I'm still working on the, "Ums" and, "Ahs." I still do that. And I don't edit those out. That's another thing too, actually, that one of the things I do want people to know about this podcast is these are authentic conversations, right? I am probably like ... I feel like I'm, I mean, the most authentic person that I know. I just want authenticity. I want that out of the guests. The idea of putting together an outline is just so that we can put together a high quality episode, but everything is authentic. And that's what I want out of people. I just want that authenticity, and one of the things that I felt kept that, was leaving in, "Ums" and, "Ahs," you know what I mean? It's just, it's one of those things where I know a lot of podcasts will edit those out and it sounds really polished and finished.Again, I mean, I figured if we can get the clinking glasses out from the background of a bar and just at least have the conversation that that's what I'm trying to achieve. And we do very little editing. We do cut things out here and there, especially if somebody makes a mistake or they want to start something over again, we will cut that out because we want, again, high quality episodes. But yeah, but authenticity is deeply important to me.Rebecca: Yeah, I think it probably certainly helps that neither of us are robots because robots wouldn't say, "Um" so many times. As I say, "Uh." So, let's talk about, Alex DeBrie was your first guest, but there's been a hundred episodes, right? So, from, I might say the best guest, as a hundredth episode guests, which is our very own Jeremy Daly, but let's go back to ...Jeremy: I appreciate that.Rebecca: Your guests, one to 99. And I mean, you've chatted with some of the most thoughtful, talented, Serverless builders and architects in the industry, and across coincident spaces like ML and Voice Technology, Chaos Engineering, databases. So, you started with Alex DeBrie and databases, and then I'm going to list off some names here, but there's so many more, right? But there's the Gunnar Grosches, and the Alexandria Abbasses, and Ajay Nair, and Angela Timofte, James Beswick, Chris Munns, Forrest Brazeal, Aleksandar Simovic, and Slobodan Stojanovic. Like there are just so many more. And I'm wondering if across those hundred conversations, or 99 plus your own today, if you had to distill those into two or three lessons, what have you learned that sticks with you? If there are emerging patterns or themes across these very divergent and convergent thinkers in the serverless space?Jeremy: Oh, that's a tough question.Rebecca: You're welcome.Jeremy: So, yeah, put me on the spot here. So, yeah, I mean, I think one of the things that I've, I've seen, no matter what it's been, whether it's ML or it's Chaos Engineering, or it's any of those other observability and things like that. I think the common thing that threads all of it is trying to solve problems and make people's lives easier. That every one of those solutions is like, and we always talk about abstractions and, and higher-level abstractions, and we no longer have to write ones and zeros on punch cards or whatever. We can write languages that either compile or interpret it or whatever. And then the cloud comes along and there's things we don't have to do anymore, that just get taken care of for us.And you keep building these higher level of abstractions. And I think that's a lot of what ... You've got this underlying concept of letting somebody else handle things for you. And then you've got this whole group of people that are coming at it from a number of different angles and saying, "Well, how will that apply to my use case?" And I think a lot of those, a lot of those things are very, very specific. I think things like the voice technology where it's like the fact that serverless powers voice technology is only interesting in the fact as to say that, the voice technology is probably the more interesting part, the fact that serverless powers it is just the fact that it's a really simple vehicle to do that. And basically removes this whole idea of saying I'm building voice technology, or I'm building a voice app, why do I need to worry about setting up servers and all this kind of stuff?It just takes that away. It takes that out of the equation. And I think that's the perfect idea of saying, "How can you take your use case, fit serverless in there and apply it in a way that gets rid of all that extra overhead that you shouldn't have to worry about." And the same thing is true of machine learning. And I mean, and SageMaker, and things like that. Yeah, you're still running instances of it, or you still have to do some of these things, but now there's like SageMaker endpoints and some other things that are happening. So, it's moving in that direction as well. But then you have those really high level services like NLU API from IBM, which is the Watson Natural Language Processing.You've got AP recognition, you've got the vision API, you've got sentiment analysis through all these different things. So, you've got a lot of different services that are very specific to machine learning and solving a discrete problem there. But then basically relying on serverless or at least presenting it in a way that's serverless, where you don't have to worry about it, right? You don't have to run all of these Jupiter notebooks and things like that, to do machine learning for a lot of cases. This is one of the things I talk about with Alexandra Abbas, was that these higher level APIs are just taking a lot of that responsibility or a lot of that heavy lifting off of your plate and allowing you to really come down and focus on the things that you're doing.So, going back to that, I do think that serverless, that the common theme that I see is that this idea of worrying about servers and worrying about patching things and worrying about networking, all that stuff. For so many people now, that's just not even a concern. They didn't even think about it. And that's amazing to think of, compute ... Or data, or networking as a utility that is now just available to us, right? And I mean, again, going back to my roots, taking it for granted is something that I think a lot of people do, but I think that's also maybe a good thing, right? Just don't think about it. I mean, there are people who, they're still going to be engineers and people who are sitting in the data center somewhere and racking servers and doing it, that's going to be forever, right?But for the things that you're trying to build, that's unimportant to you. That is the furthest from your concern. You want to focus on the problem that you're trying to solve. And so I think that, that's a lot of what I've seen from talking to people is that they are literally trying to figure out, "Okay, how do I take what I'm doing, my use case, my problem, how do I take that to the next level, by being able to spend my cycles thinking about that as opposed to how I'm going to serve it up to people?"Rebecca: Yeah, I think it's the mantra, right, of simplify, simplify, simplify, or maybe even to credit Bruce Lee, be like water. You're like, "How do I be like water in this instance?" Well, it's not to be setting up servers, it's to be doing what I like to be doing. So, you've interviewed these incredible folks. Is there anyone left on your list? I'm sure there ... I mean, I know that you have a large list. Is there a few key folks where you're like, "If this is the moment I'm going to ask them, I'm going to say on the hundredth episode, 'Dear so-and-so, I would love to interview you for Serverless Chats.'" Who are you asking?Jeremy: So, this is something that, again, we have a stretch list of guests that we attempt to reach out to every once in a while just to say, "Hey, if we get them, we get them." But so, I have a long list of people that I would absolutely love to talk to. I think number one on my list is certainly Werner Vogels. I mean, I would love to talk to Dr. Vogels about a number of things, and maybe even beyond serverless, I'm just really interested. More so from a curiosity standpoint of like, "Just how do you keep that in your head?" That vision of where it's going. And I'd love to drill down more into the vision because I do feel like there's a marketing aspect of it, that's pushing on him of like, "Here's what we have to focus on because of market adoption and so forth. And even though the technology, you want to move into a certain way," I'd be really interesting to talk to him about that.And I'd love to talk to him more too about developer experience and so forth, because one of the things that I love about AWS is that it gives you so many primitives, but at the same time, the thing I hate about AWS is it gives you so many primitives. So, you have to think about 800 services, I know it's not that many, but like, what is it? 200 services, something like that, that all need to kind of connect together. And I love that there's that diversity in those capabilities, it's just from a developer standpoint, it's really hard to choose which ones you're supposed to use, especially when several services overlap. So, I'm just curious. I mean, I'd love to talk to him about that and see what the vision is in terms of, is that the idea, just to be a salad bar, to be the Golden Corral of cloud services, I guess, right?Where you can choose whatever you want and probably take too much and then not use a lot of it. But I don't know if that's part of the strategy, but I think there's some interesting questions, could dig in there. Another person from AWS that I actually want to talk to, and I haven't reached out to her yet just because, I don't know, I just haven't reached out to her yet, but is Brigid Johnson. She is like an IAM expert. And I saw her speak at re:Inforce 2019, it must have been 2019 in Boston. And it was like she was speaking a different language, but she knew IAM so well, and I am not a fan of IAM. I mean, I'm a fan of it in the sense that it's necessary and it's great, but I can't wrap my head around so many different things about it. It's such a ...It's an ongoing learning process and when it comes to things like being able to use tags to elevate permissions. Just crazy things like that. Anyways, I would love to have a conversation with her because I'd really like to dig down into sort of, what is the essence of IAM? What are the things that you really have to think about with least permission? Especially applying it to serverless services and so forth. And maybe have her help me figure out how to do some of the cross role IAM things that I'm trying to do. Certainly would love to speak to Jeff Barr. I did meet Jeff briefly. We talked for a minute, but I would love to chat with him.I think he sets a shining example of what a developer advocate is. Just the way that ... First of all, he's probably the only person alive who knows every service at AWS and has actually tried it because he writes all those blog posts about it. So that would just be great to pick his brain on that stuff. Also, Adrian Cockcroft would be another great person to talk to. Just this idea of what he's done with microservices and thinking about the role, his role with Netflix and some of those other things and how all that kind of came together, I think would be a really interesting conversation. I know I've seen this in so many of his presentations where he's talked about the objections, what were the objections of Lambda and how have you solved those objections? And here's the things that we've done.And again, the methodology of that would be really interesting to know. There's a couple of other people too. Oh, Sam Newman who wrote Building Microservices, that was my Bible for quite some time. I had it on my iPad and had a whole bunch of bookmarks and things like that. And if anybody wants to know, one of my most popular posts that I've ever written was the ... I think it was ... What is it? 16, 17 architectural patterns for serverless or serverless microservice patterns on AWS. Can't even remember the name of my own posts. But that post was very, very popular. And that even was ... I know Matt Coulter who did the CDK. He's done the whole CDK ... What the heck was that? The CDKpatterns.com. That was one of the things where he said that that was instrumental for him in seeing those patterns and being able to use those patterns and so forth.If anybody wants to know, a lot of those patterns and those ideas and those ... The sort of the confidence that I had with presenting those patterns, a lot of that came from Sam Newman's work in his Building Microservices book. So again, credit where credit is due. And I think that that would be a really fascinating conversation. And then Simon Wardley, I would love to talk to. I'd actually love to ... I actually talked to ... I met Lin Clark in Vegas as well. She was instrumental with the WebAssembly stuff, and I'd love to talk to her. Merritt Baer. There's just so many people. I'm probably just naming too many people now. But there are a lot of people that I would love to have a chat with and just pick their brain.And also, one of the things that I've been thinking about a lot on the show as well, is the term "serverless." Good or bad for some people. Some of the conversations we have go outside of serverless a little bit, right? There's sort of peripheral to it. I think that a lot of things are peripheral to serverless now. And there are a lot of conversations to be had. People who were building with serverless. Actually real-world examples.One of the things I love hearing was Yan Cui's "Real World Serverless" podcast where he actually talks to people who are building serverless things and building them in their organizations. That is super interesting to me. And I would actually love to have some of those conversations here as well. So if anyone's listening and you have a really interesting story to tell about serverless or something peripheral to serverless please reach out and send me a message and I'd be happy to talk to you.Rebecca: Well, good news is, it sounds like A, we have at least ... You've got at least another a hundred episodes planned out already.Jeremy: Most likely. Yeah.Rebecca: And B, what a testament to Sam Newman. That's pretty great when your work is referred to as the Bible by someone. As far as in terms of a tome, a treasure trove of perhaps learnings or parables or teachings. I ... And wow, what a list of other folks, especially AWS power ... Actually, not AWS powerhouses. Powerhouses who happened to work at AWS. And I think have paved the way for a ton of ways of thinking and even communicating. Right? So I think Jeff Barr, as far as setting the bar, raising the bar if you will. For how to teach others and not be so high-level, or high-level enough where you can follow along with him, right? Not so high-level where it feels like you can't achieve what he's showing other people how to do.Jeremy: Right. And I just want to comment on the Jeff Barr thing. Yeah.Rebecca: Of course.Jeremy: Because again, I actually ... That's my point. That's one of the reasons why I love what he does and he's so perfect for that position because he's relatable and he presents things in a way that isn't like, "Oh, well, yeah, of course, this is how you do this." I mean, it's not that way. It's always presented in a way to make it accessible. And even for services that I'm not interested in, that I know that I probably will never use, I generally will read Jeff's post because I feel it gives me a good overview, right?Rebecca: Right.Jeremy: It just gives me a good overview to understand whether or not that service is even worth looking at. And that's certainly something I don't get from reading the documentation.Rebecca: Right. He's inviting you to come with him and understanding this, which is so neat. So I think ... I bet we should ... I know that we can find all these twitter handles for these folks and put them in the show notes. And I'm especially ... I'm just going to say here that Werner Vogels's twitter handle is @Werner. So maybe for your hundredth, all the listeners, everyone listening to this, we can say, "Hey, @Werner, I heard that you're the number one guest that Jeremy Daly would like to interview." And I think if we get enough folks saying that to @Werner ... Did I say that @Werner, just @Werner?Jeremy: I think you did.Rebecca: Anyone if you can hear it.Jeremy: Now listen, he did retweet my serverless musical that I did. So ...Rebecca: That's right.Jeremy: I'm sort of on his radar maybe.Rebecca: Yeah. And honestly, he loves serverless, especially with the number of customers and the types of customers and ... that are doing incredible things with it. So I think we've got a chance, Jeremy. I really do. That's what I'm trying to say.Jeremy: That's good to know. You're welcome anytime. He's welcome anytime.Rebecca: Do we say that @Werner, you are welcome anytime. Right. So let's go back to the genesis, not necessarily the genesis of the concept, right? But the genesis of the technology that spurred all of these other technologies, which is AWS Lambda. And so what ... I don't think we'd be having these conversations, right, if AWS Lambda was not released in late 2014, and then when GA I believe in 2015.Jeremy: Right.Rebecca: And so subsequently the serverless paradigm was thrust into the spotlight. And that seems like eons ago, but also three minutes ago.Jeremy: Right.Rebecca: And so I'm wondering ... Let's talk about its evolution a bit and a bit of how if you've been following it for this long and building it for this long, you've covered topics from serverless CI/CD pipelines, observability. We already talked about how it's impacted voice technologies or how it's made it easy. You can build voice technology without having to care about what that technology is running on.Jeremy: Right.Rebecca: You've even talked about things like the future and climate change and how it relates to serverless. So some of those sort of related conversations that you were just talking about wanting to have or having had with previous guests. So as a host who thinks about these topics every day, I'm wondering if there's a topic that serverless hasn't touched yet or one that you hope it will soon. Those types of themes, those threads that you want to pull in the next 100 episodes.Jeremy: That's another tough question. Wow. You got good questions.Rebecca: That's what I said. Heavy hitters. I told you I'd be bringing it.Jeremy: All right. Well, I appreciate that. So that's actually a really good question. I think the evolution of serverless has seen its ups and downs. I think one of the nice things is you look at something like serverless that was so constrained when it first started. And it still has constraints, which are good. But it ... Those constraints get lifted. We just talked about Adrian's talks about how it's like, "Well, I can't do this, or I can't do that." And then like, "Okay, we'll add some feature that you can do that and you can do that." And I think that for the most part, and I won't call it anything specific, but I think for the most part that the evolution of serverless and the evolution of Lambda and what it can do has been thoughtful. And by that I mean that it was sort of like, how do we evolve this into a way that doesn't create too much complexity and still sort of holds true to the serverless ethos of sort of being fairly easy or just writing code.And then, but still evolve it to open up these other use cases and edge cases. And I think that for the most part, that it has held true to that, that it has been mostly, I guess, a smooth ride. There are several examples though, where it didn't. And I said I wasn't going to call anything out, but I'm going to call this out. I think RDS proxy wasn't great. I think it works really well, but I don't think that's the solution to the problem. And it's a band-aid. And it works really well, and congrats to the engineers who did it. I think there's a story about how two different teams were trying to build it at the same time actually. But either way, I look at that and I say, "That's a good solution to the problem, but it's not the solution to the problem."And so I think serverless has stumbled in a number of ways to do that. I also feel EFS integration is super helpful, but I'm not sure that's the ultimate goal to share ... The best way to share state. But regardless, there are a whole bunch of things that we still need to do with serverless. And a whole bunch of things that we still need to add and we need to build, and we need to figure out better ways to do maybe. But I think in terms of something that doesn't get talked about a lot, is the developer experience of serverless. And that is, again I'm not trying to pitch anything here. But that's literally what I'm trying to work on right now in my current role, is just that that developer experience of serverless, even though there was this thoughtful approach to adding things, to try to check those things off the list, to say that it can't do this, so we're going to make it be able to do that by adding X, Y, and Z.As amazing as that has been, that has added layers and layers of complexity. And I'll go back way, way back to 1997 in my dorm room. CGI-bins, if people are not familiar with those, essentially just running on a Linux server, it was a way that it would essentially run a Perl script or other types of scripts. And it was essentially like you're running PHP or you're running Node, or you're running Ruby or whatever it was. So it would run a programming language for you, run a script and then serve that information back. And of course, you had to actually know ins and outs, inputs and outputs. It was more complex than it is now.But anyways, the point is that back then though, once you had the script written. All you had to do is ... There's a thing called FTP, which I'm sure some people don't even know what that is anymore. File transfer protocol, where you would basically say, take this file from my local machine and put it on this server, which is a remote machine. And you would do that. And the second you did that, magically it was updated and you had this thing happening. And I remember there were a lot of jokes way back in the early, probably 2017, 2018, that serverless was like the new CGI-bin or something like that. But more as a criticism of it, right? Or it's just CGI-bins reborn, whatever. And I actually liked that comparison. I felt, you know what? I remember the days where I just wrote code and I just put it to some other server where somebody was dealing with it, and I didn't even have to think about that stuff.We're a long way from that now. But that's how serverless felt to me, one of the first times that I started interacting with it. And I felt there was something there, that was something special about it. And I also felt the constraints of serverless, especially the idea of not having state. People rely on things because they're there. But when you don't have something and you're forced to think differently and to make a change or find a way to work around it. Sometimes workarounds, turn into best practices. And that's one of the things that I saw with serverless. Where people were figuring out pretty quickly, how to build applications without state. And then I think the problem is that you had a lot of people who came along, who were maybe big customers of AWS. I don't know.I'm not going to say that you might be influenced by large customers. I know lots of places are. That said, "We need this." And maybe your ... The will gets bent, right. Because you just... you can only fight gravity for so long. And so those are the kinds of things where I feel some of the stuff has been patchwork and those patchwork things haven't ruined serverless. It's still amazing. It's still awesome what you can do within the course. We're still really just focusing on fast here, with everything else that's built. With all the APIs and so forth and everything else that's serverless in the full-service ecosystem. There's still a lot of amazing things there. But I do feel we've become so complex with building serverless applications, that you can't ... the Hello World is super easy, but if you're trying to build an actual application, it's a whole new mindset.You've got to learn a whole bunch of new things. And not only that, but you have to learn the cloud. You have to learn all the details of the cloud, right? You need to know all these different things. You need to know cloud formation or serverless framework or SAM or something like that, in order to get the stuff into the cloud. You need to understand the infrastructure that you're working with. You may not need to manage it, but you still have to understand it. You need to know what its limitations are. You need to know how it connects. You need to know what the failover states are like.There's so many things that you need to know. And to me, that's a burden. And that's adding new types of undifferentiated heavy-lifting that shouldn't be there. And that's the conversation that I would like to have continuing to move forward is, how do you go back to a developer experience where you're saying you're taking away all this stuff. And again, to call out Werner again, he constantly says serverless is about writing code, but ask anybody who builds serverless applications. You're doing a lot more than writing code right now. And I would love to see us bring the conversation back to how do we get back there?Rebecca: Yeah. I think it kind of goes back to ... You and I have talked about this notion of an ode to simplicity. And it's sort of what you want to write into your ode, right? If we're going to have an ode to simplicity, how do we make sure that we keep the simplicity inside of the ode?Jeremy: Right.Rebecca:So I've got ... I don't know if you've seen these.Jeremy: I don't know.Rebecca: But before I get to some wrap-up questions more from the brainwaves of Jeremy Daly, I don't want to forget to call out some long-time listener questions. And they wrote in a via Twitter and they wanted to perhaps pick your brain on a few things.Jeremy: Okay.Rebecca: So I don't know if you're ready for this.Jeremy: A-M-A. A-M-A.Rebecca: I don't know if you've seen these. Yeah, these are going to put you in the ...Jeremy: A-M-A-M. Wait, A-M-A-A? Asked me almost anything? No, go ahead. Ask me anything.Rebecca: A-M-A-A. A-M-J. No. Anyway, we got it. Ask Jeremy almost anything.Jeremy: There you go.Rebecca: So there's just three to tackle for today's episode that I'm going to lob at you. One is from Ken Collins. "What will it take to get you back to a relational database of Lambda?"Jeremy: Ooh, I'm going to tell you right now. And without a doubt, Aurora Serverless v2. I played around with that right after re:Invent 2000. What was it? 20. Yeah. Just came out, right? I'm trying to remember what year it is at this point.Rebecca: Yes. Indeed.Jeremy: When that just ... Right when that came out. And I had spent a lot of time with Aurora Serverless v1, I guess if you want to call it that. I spent a lot of time with it. I used it on a couple of different projects. I had a lot of really good success with it. I had the same pains as everybody else did when it came to scaling and just the slowness of the scaling and then ... And some of the step-downs and some of those things. There were certainly problems with it. But v2 just the early, early preview version of v2 was ... It was just a marvel of engineering. And the way that it worked was just ... It was absolutely fascinating.And I know it's getting ready or it's getting close, I think, to being GA. And when that becomes GA, I think I will have a new outlook on whether or not I can fit RDS into my applications. I will say though. Okay. I will say, I don't think that transactional applications should be using relational databases though. One of the things that was sort of a nice thing about moving to serverless, speak

About Gojko AdzicGojko Adzic is a partner at Neuri Consulting LLP. He one of the 2019 AWS Serverless Heroes, the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award. Gojko’s book Specification by Example won the Jolt Award for the best book of 2012, and his blog won the UK Agile Award for the best online publication in 2010.Gojko is a frequent speaker at software development conferences and one of the authors of MindMup and Narakeet.As a consultant, Gojko has helped companies around the world improve their software delivery, from some of the largest financial institutions to small innovative startups. Gojko specializes in agile and lean quality improvement, in particular impact mapping, agile testing, specification by example, and behavior driven development.Twitter: @gojkoadzicNarakeet: https://www.narakeet.comPersonal website: https://gojko.netWatch this video on YouTube: https://youtu.be/kCDDli7uzn8This episode is sponsored by CBT Nuggets: https://www.cbtnuggets.com/TranscriptJeremy: Hi everyone, I'm Jeremy Daly and this is Serverless Chats. Today my guest is Gojko Adzic. Hey Gojko, thanks for joining me.Gojko: Hey, thanks for inviting me.Jeremy: You are a partner at Neuri Consulting, you're an AWS Serverless Hero, you've written I think, what? I think 6,842 books or something like that about technology and serverless and all that kind of stuff. I'd love it if you could tell listeners a little bit about your background and what you've been working on lately.Gojko: I'm a developer. I started developing software when I was six and a half. My dad bought a Commodore 64 and I think my mom would have kicked him out of the house if he told her that he bought it for himself, so it was officially for me.Jeremy: Nice.Gojko: And I was the only kid in the neighborhood that had a computer, but didn't have any ways of loading games on it because he didn't buy it for games. I stayed up and copied and pasted PEEKs and POKEs in a book I couldn't even understand until I made the computer make weird sounds and print rubbish on the screen. And that's my background. Basically, ever since, I only wanted to build software really. I didn't have any other hobbies or anything like that. Currently, I'm building a product for helping tech people who are not video editing professionals create videos very easily. Previously, I've done a lot of work around consulting. I've built a lot of product that is used by millions of school children worldwide collaborate and brainstorm through mind-mapping. And since 2016, most of my development work has been on Lambda and on team stuff.Jeremy: That's awesome. I joke a little bit about the number of books that you wrote, but the ones that you have, one of them's called Running Serverless. I think that was maybe two years ago. That is an excellent book for people getting started with serverless. And then, one of my probably favorite books is Humans Vs Computers. I just love that collection of tales of all these things where humans just build really bad interfaces into software and just things go terribly.Gojko: Thank you very much. I enjoyed writing that book a lot. One of my passions is finding edge cases. I think people with a slight OCD like to find edge cases and in order to be a good developer, I think somebody really needs to have that kind of intent, and really look for edge cases everywhere. And I think collecting these things was my idea to help people first of all think about building better software, and to realize that stuff we might glance over like, nobody's ever going to do this, actually might cause hundreds of millions of dollars of damage ten years later. And thanks very much for liking the book.Jeremy: If people haven't read that book, I don't know, when did that come out? Maybe 2016? 2015?Gojko: Yeah, five or six years ago, I think.Jeremy: Yeah. It's still completely relevant now though and there's just so many great examples in there, and I don't want to spent the whole time talking about that book, but if you haven't read it, go check it out because it's these crazy things like police officers entering in no plates whenever they're giving parking tickets. And then, when somebody actually gets that, ends up with thousands of parking tickets, and it's just crazy stuff like that. Or, not using the middle initial or something like that for the name, or the birthdate or whatever it was, and people constantly getting just ... It's a fascinating book. Definitely check that out.But speaking of edge cases and just all this experience that you have just dealing with this idea of, I guess finding the problems with software. Or maybe even better, I guess a good way to put it is finding the limitations that we build into software mostly unknowingly. We do this unknowingly. And you and I were having a conversation the other day and we were talking about way, way back in the 1970s. I was born in the late '70s. I'm old but hopefully not that old. But way back then, time-sharing was a thing where we would basically have just a few large computers and we would have to borrow time against them. And there's a parallel there to what we were doing back then and I think what we're doing now with cloud computing. What are your thoughts on that?Gojko: Yeah, I think absolutely. We are I think going in a slightly cyclic way here. Maybe not cyclic, maybe spirals. We came to the same horizontal position but vertically, we're slightly better than we were. Again, I didn't start working then. I'm like you, I was born in late '70s. I wasn't there when people were doing punch cards and massive mainframes and time-sharing. My first experience came from home PC computers and later PCs. The whole serverless thing, people were disparaging about that when the marketing buzzword came around. I don't remember exactly when serverless became serverless because we were talking about microservices and Lambda was a way to run microservices and execute code on demand. And all of a sudden, I think the JAWS people realized that JAWS is a horrible marketing name, and decided to rename it to serverless. I think it most important, and it was probably 2017 or something like that. 2000 ...Jeremy: Something like that, yeah.Gojko: Something like that. And then, because it is a horrible marketing name, but it's catchy, it caught on and then people were complaining how it's not serverless, it's just somebody else's servers. And I think there's some truth to that, but actually, it's not even somebody else's servers. It really is somebody else's mainframe in a sense. You know in the '70s and early '80s, before the PC revolution, if you wanted to be a small software house or a small product operator, you probably were not running your own data center. What you would do is you would rent it based on paying for time to one of these massive, massive, massive operators. And in fact, we ended up with AWS being a massive data center. As far as you and I are concerned, it's just a blob. It's not a collection of computers, it's a data center we learn something from and Google is another one and then Microsoft is another one.And I remember reading a book about Andy Grove who was the CEO of Intel where they were thinking about the market for PC computers in the late '70s when somebody came to them with the idea that they could repurpose what became a 8080 processor. They were doing this I think for some Japanese calculator and then somebody said, "We can attach a screen to this and make this a universal computer and sell it." And they realized maybe there's a market for four or five computers in the world like that. And I think that that's ... You know, we ended up with four or five computers, it's just the definition of a computer changed.Jeremy: Right. I think that's a good point because you think about after the PC revolution, once the web started becoming really big, people started building data centers and collocation facilities like crazy. This is way before the cloud, and everybody was buying racks and Dell was getting really popular because people buying servers from Dell, and installing these in their data centers and doing this. And it just became this massive, whole industry built around doing that. And then you have these few companies that say, "Well, what if we just handled all that stuff for you? Rather than just racking stuff for you," but started just managing the software, and started managing the networking, and the backups, and all this stuff for you? And that's where the cloud was born.But I think you make a really good point where the cloud, whatever it is, Amazon or Google or whatever, you might as well just assume that that's just one big piece of processing that you're renting and you're renting some piece of that. And maybe we have. Maybe we've moved back to this idea where ... Even though everybody's got a massive computer in their pocket now, tons of compute power, in terms of the real business work that's being done, and the real global value, and the things that are powering global commerce and everything else like that, those are starting to move back to run in four, five, massive computers.Gojko: Again, there's a cyclic nature to all of this. I remember reading about the advent of power networks. Because before people had electric power, there were physical machines and movement through physical power, and there were water-powered plants and things like that. And these whole systems of shafts and belts and things like that powering factories. And you had this one kind of power load in a factory that was somewhere in the middle, and then from there, you actually have physical belts, rotating cogs in other buildings, and that was rotating some shafts that were rotating other cogs, and things like that.First of all, when people were able to package up electricity into something that's distributable, and they were running their own small electricity generators next to these big massive machines that were affecting early factories. And one of the first effects of that was they could reuse 30% of their factories better because it was up to 30% of the workspace in the factory that was taken up by all the belts and shafts. And all that movement was producing a lot of air movement and a lot of dust and people were getting sick. But now, you just plug a cable and you no longer have all this bad air and you don't have employees going sick and things like that. Things started changing quite a lot and then all of a sudden, you had this completely new revolution where you no longer had to operate your own electric generator. You could just plug in and get power from the network.And I think part of that is again, cyclic, what's happening in our industry now, where, as you said, we were getting machines. I used to make money as a Linux admin a long time ago and I could set up my own servers and things like that. I had a company in 2007 where we were operating our own gaming system, and we actually had physical servers in a physical server room with all the LEDs and lights, and bleeps, and things like that. Around that time, AWS really made it easy to get virtual machines on EC2 and I realized how stupid the whole, let's manage everything ourself is. But, we are getting to the point where people had to run their own generators, and now you can actually just plug into the electricity network. And of course, there is some standardization. Maybe U.S. still has 110 volts and Europe has 220, and we never really get global standardization there.But I assume before that, every factory could run their own voltage they wanted. It was difficult to manufacture for these things but now you have standardization, it's easier for everybody to plug into the ecosystem and then the whole ecosystem emerged. And I think that's partially what's happening now where things like S3 is an API or Lambda is an API. It's basically the electric socket in your wall.Jeremy: Right, and that's that whole Wardley maps idea, they become utilities. And that's the thing where if you look at that from an enterprise standpoint or from a small business standpoint if you're a startup right now and you are ordering servers to put into a data center somewhere unless you're doing something that's specifically for servers, that's just crazy. Use the cloud.Gojko: This product I mentioned that we built for mind mapping, there's only two of us in the whole company. We do everything from presales, to development testing supports, to everything. And we're competing with companies that have several orders of magnitude more employees, and we can actually compete and win because we can benefit from this ecosystem. And I think this is totally wonderful and amazing and for anybody thinking about starting a product, it's easier to start a product now than ever. And, another thing that's totally I think crazy about this whole serverless thing is how in effect we got a bookstore to offer that first.You mentioned the world utility. I remember I was the editor of a magazine in 2001 in Serbia, and we had licensing with IDG to translate some of their content. And I remember working on this kind of piece from I think PC World in the U.S. where they were interviewing Hewlett Packard people about utility computing. And people from Hewlett Packard back then were predicting that in a few years' time, companies would not operate their own stuff, they would use utility and things like that. And it's totally amazing that in order to reach us over there, that had to be something that was already evaluated and tested, and there was probably a prototype and things like that. And you had all these giants. Hewlett Packard in 2001 was an IT giant. Amazon was just up-and-coming then and they were a bookstore then. They were not even anything more than a bookstore. And you had, what? A decade later, the tables completely turned where HP's ... I don't know ...Jeremy: I think they bought Compaq at some point too.Gojko: You had all these giants, IBM completely missed it. IBM totally missed ...Jeremy: It really did.Gojko: ... the whole mobile and web and everything revolution. Oracle completely missed it. They're trying to catch up now but fat chance. Really, we are down to just a couple of massive clouds, or whatever that means, that we interact with as we're interacting with electricity sockets now.Jeremy: And going back to that utility comparison, or, not really a comparison. It is a utility now. Compute is offered as a utility. Yes, you can buy and generate compute yourself and you can still do that. And I know a lot of enterprises still will. I think cloud is like 4% of the total IT market or something. It's a fraction of it right now. But just from that utility aspect of it, from your experience, you mentioned you had two people and you built, is it MindMup.com?Gojko: MindMup, yeah.Jeremy: You built that with just two people and you've got tons of people using it. But just from your experience, especially coming from the world of being a Linux administrator, which again, I didn't administer ... Well, I guess I was. I did a lot of work in data centers in my younger days. But, coming from that idea and seeing how companies were building in the past and how companies are still building now, because not every company is still using the cloud, far from it. But not taking advantage of that utility, what are those major disadvantages? How badly do you think that's going to slow companies down that are trying to innovate?Gojko: I can give you a story about MindMup. You mentioned MindMup. When was it? 2018, there was the Intel processor vulnerabilities that were discovered.Jeremy: Right, yes.Gojko: I'm not entirely sure what the year was. A few years ago anyway. We got a email from a concerned university admin when the second one was discovered. The first one made all the news and a month later a second one was discovered. Now everybody knew that, they were in panic and things like that. After the second one was discovered, we got a email from a university admin. And universities are big users, they need to protect the data and things like that. And he was insisting that we tell him what our plan was for mitigating this thing because he knows we're on the cloud.I'm working on European time. The customer was in the U.S., probably somewhere U.S. Pacific because it arrived in the middle of the night. I woke up, I'm still trying to get my head around and drinking coffee and there's this whole sausage CV number that he sent me. I have no idea what it's about. I took that, pasted it into Google to figure out what's going on. The first result I got from Google was that AWS Lambda was already patched. Copy, paste, my day's done. And I assume lots and lots of other people were having a totally different conversation with their IT department that day. And that's why I said I think for products like the one I'm building with video and for the MindMup, being able to rent operations as a utility, but really totally rent ops as a utility, not have to worry about anything below my unique business level is really, really important.And yes, we can hire people to work on that it could even end up being slightly cheaper technically but in terms of my time and where my focus goes and my interruptions, I think deploying on a utility platform, whatever that utility platform is, as long as it's reliable, lets me focus on adding value where I can actually add value. That makes my product unique rather than the generic stuff.Jeremy: You mentioned the video product that you're working on too, and something that is really interesting I think too about taking advantage of the cloud is the scalability aspect of it. I remember, it was maybe 2002, maybe 2003, I was running my own little consulting company at the time, and my local high school always has a rivalry football game every Thanksgiving. And I thought it'd be really interesting if I was to stream the audio from the local AM radio station. I set up a server in my office with ReelCast Streaming or something running or whatever it was. And I remember thinking as long as we don't go over 140 subscribers, we'll be okay. Anything over that, it'll probably crash or the bandwidth won't be enough or whatever.Gojko: And that's just one of those things now, if you're doing any type of massive processing or you need bandwidth, bandwidth alone ... I remember T1 lines being great and then all of a sudden it was like, well, now you need a T3 line or something crazy in order to get the bandwidth that you need. Just from that aspect of it, the ability to scale quickly, that just seems like such a huge blocker for companies that need to order provision servers, maybe get a utility company to come in and install more bandwidth for them, and things like that. That's just stuff that's so far out of scope for building a business to me. At least building a software business or building any business. It's crazy.When I was doing consulting, I did a bit of work for what used to be one of the largest telecom companies in the world.Jeremy: Used to be.Gojko: I don't want to name names on a public chat. Somewhere around 2006, '07 let's say, we did a software project where they just needed to deploy it internally. And it took them seven months to provision a bunch of virtual machines to deploy it internally. Seven months.Jeremy: Wow.Gojko: Because of all the red tape and all the bureaucracy and all the wait for capacity and things like that. That's around the time where Amazon when EC2 became commercially available. I remember working with another client and they were waiting for some servers to arrive so they can install more capacity. And I remember just turning on the Amazon console. I didn't have anything useful to running it then but just being able to start up a virtual machine in about, I think it was less than half an hour, but that was totally fascinating back then. Here's a new Linux machine and in less than half an hour, you can use it. And it was totally crazy. Now we're getting to the point where Lambda will start up in less than 10 milliseconds or something like that. Waiting for that kind of capacity is just insane.With the video thing I'm building, because of Corona and all of this remote teaching stuff, for some reason, we ended up getting lots of teachers using the product. It was one of these half-baked experiments because I didn't have time to build the full user interface for everything, and I realized that lots of people are using PowerPoint to prepare that kind of video. I thought well, how about if I shorten that loop, so just take your PowerPoint and convert it into video. Just type up what you want in the speaker notes, and we'll use these neurometrics to generate audio and things like that. Teachers like it for one reason or the other.We had this influential blogger from Russia explain it on his video blog and then it got picked up, my best guess from what I could see from Google Translate, some virtual meeting of teachers of Russia where they recommended people to try it out. I woke up the next day, the metrics went totally crazy because a significant portion of teachers in Russia tried my tool overnight in a short space of time. Something like that, I couldn't predict it. It's lovely but as you said, as long as we don't go over a hundred subscribers, we're fine. If I was in a situation like that, the thing would completely crash because it's unexpected. We'd have a thing that's amazingly good for marketing that would be amazingly bad for business because it would crash all our capacity we had. Or we had to prepare for a lot more capacity than we needed, but because this is all running on Lambda, Fargate, and other auto-scaling things, it's just fine. No sweat at all. It was a lovely thing to see actually.Jeremy: You actually have two problems there. If you're not running in the cloud or not running on-demand compute, is the fact that one, you would've potentially failed, things would've fallen over and you would've lost all those potential customers, and you wouldn't have been able to grow.Gojko: Plus you've lost paying customers who are using your systems, who've paid you.Jeremy: Right, that's the other thing too. But, on the other side of that problem would be you can't necessarily anticipate some of those things. What do you do? Over-provision and just hope that maybe someday you'll get whatever? That's the crazy thing where the elasticity piece of the cloud to me, is such a no-brainer. Because I know people always talk about, well, if you have predictable workloads. Well yeah, I know we have predictable workloads for some things, but if you're a startup or you're a business that has like ... Maybe you'd pick up some press. I worked for a company that we picked up some press. We had 10,000 signups in a matter of like 30 seconds and it completely killed our backend, my SQL database. Those are hard to prepare for if you're hosting your own equipment.Gojko: Absolutely, not even if you're hosting your own.Jeremy: Also true, right.Gojko: Before moving to Lambda, the app was deployed to Heroku. That was basically, you need to predict how many virtual machines you need. Yes, it's in the cloud, but if you're running on EC2 and you have your 10, 50, 100 virtual machines, whatever running there, and all of a sudden you get a lot more traffic, will it scale or will it not scale? Have you designed it to scale like that? And one of the best things that I think Lambda brought as a constraint was forcing people to design this stuff in a way that scales.Jeremy: Yes.Gojko: I can deploy stuff in the cloud and make it all distributed monolith, so it doesn't really scale well, but with Lambda because it was so constrained when it launched, and this is one thing you mentioned, partially we're losing those constraints now, but it was so constrained when it launched, it was really forcing people to design things that were easy to scale. We had total isolation, there was no way of sharing things, there was no session stickiness and things like that. And then you have to come up with actually good ways of resolving that.I think one of the most challenging things about serverless is that even a Hello World is a distributed transaction processing system, and people don't get that. They think about, well, I had this DigitalOcean five-dollar-a-month server and it was running my, you know, Rails up correctly. I'm just going to use the same ideas to redesign it in Lambda. Yes, you can, but then you're not going to really get the benefits of all of this other stuff. And if you design it as a massively distributed transaction processing system from the start, then yes, it scales like crazy. And it scales up and down and it's lovely, but as Lambda's maturing, I have this slide deck that I've been using since 2016 to talk about Lambda at conferences. And every time I need to do another talk, I pull it out and adjust it a bit. And I have this whole Git history of it because I do markdown to slides and I keep the markdown in Git so I can go back. There's this slide about limitations where originally it's only ... I don't remember what was the time limitation, but something very short.Jeremy: Five minutes originally.Gojko: Yeah, something like that and then it was no PCI compliance and the retries are difficult, and all of this stuff basically became sold. And one of the last things that was there, there was don't even try to put it in a VPC, definitely, you can but it's going to take 10 minutes to start. Now that's reasonably okay as well. One thing that I remember as a really important design constraint was effectively it was a share nothing platform because you could not share data between two Lambdas running at the same time very easily in the same VM. Now that we can connect Lambdas to EFS, you effectively can do that as well. You can have two Lambdas, one writing into an EFS, the other reading the same EFS at the same time. No problem at all. You can pump it into a file and the other thing can just stay in a file and get the data out.As the platform is maturing, I think we're losing some of these design constraints, and sometimes constraints breed creativity. And yes, you still of course can design the system to be good, but it's going to be interesting to see. And this 15-minute limit that we have in Lamdba now is just an artificial number that somebody thought.Jeremy: Yeah, it's arbitrary.Gojko: And at some point when somebody who is important enough asks AWS to give them half-hour Lamdbas, they will get that. Or 24-hour Lambdas. It's going to be interesting to see if Lambda ends up as just another way of running EC2 and starting EC2 that's simpler because you don't have to manage the operating system. And I think the big difference we'll get between EC2 and Lambda is what percentage of ops your developers are responsible for, and what percentage of ops Amazon's developers are responsible for.Because if you look at all these different offerings that Amazon has like Lightsail and EC2 and Fargate and AWS Batch and CodeDeploy, and I don't know how many other things you can run code on in Lambda. The big difference with Lambda is really, at least until very recently was that apart from your application, Amazon is responsible for everything. But now, we're losing design constraints, you can put a Docker container in, you can be responsible for the OS image as well, which is a bit again, interesting to look at.Jeremy: Well, I also wonder too, if you took all those event sources that you can point at Lambda and you add those to Fargate, what's the difference? It seems like they're just merging into two very similar products.Gojko: For the video build platform, the last step runs in Fargate because people are uploading things that are massive, massive, massive for video processing, and just they don't finish in 15 minutes. I have to run to Fargate, and the big difference is the container I packaged up for Fargate takes about 40 seconds to actually deploy. A new event at the moment with the stuff I've packaged in Fargate takes about 40 seconds to deploy. I can optimize that, but I can't optimize it too much. Fargate is still order of magnitude of tens of seconds to process an event. I think as Fargate gets faster and as Lambda gets more of these capabilities, it's going to be very difficult to tell them apart I think.With Fargate, you're intended to manage the container image yourself. You're responsible for patching software, you're responsible for patching OS vulnerabilities and things like that. With Lambda, Amazon, unless you use a container image, Amazon is responsible for that. They come close. When looking at this video building for the first time, I was actually comparing code. I was considering using CodeBuild for that because CodeBuild is also a way to run things on demand and containers, and you actually can get quite decent machines with CodeBuild. And it's also event-driven, and Fargate is event-driven, AWS Batch is event-driven, and all of these things are converging to each other. And really, AWS is famous for having 10 products that do the same thing effectively and you can't tell them apart, and maybe that's where we'll end.Jeremy: And I'm wondering too, the thing that was great about Lambda, at least for me like you said, the shared nothing architecture where it was like, you almost didn't have to rely on anything other than the event that came in, and the processing of that Lambda function. And if you designed your systems well, you may have some bottleneck up front, but especially if you used distributed transactions and you used async invocations of downstream functions, where you could basically take some data that you needed to pass into it, and then you wouldn't necessarily need that to communicate with anything other than itself to process that data. The scale there was massive. You could just keep scaling and scaling and scaling. As you add things like EFS and that adds constraints in terms of the number of transactions and connections that, that can make and all those sort of things. Do these things, do they become less reliable? By allowing it to do more, are we building systems that are less reliable because we're not using some of those tried-and-true constraints that were there?Gojko: Possibly, but every time you add a new moving part, you create one more potential point of failure there. And I think for me, one of the big lessons when I was working on ... I spent a few years working on very high throughput transaction processing systems. That's why this whole thing rings a bell a lot. A lot of it really was how do you figure out what type of messages you send and where you send them. The craze of these messages and distributed transaction processing systems in early 2000s, created this whole craze of enterprise service buses later that came. We now have this... What is it called? It's not called enterprise service bus, it's called EventBridge, or something like that.Jeremy: EventBridge, yes.Gojko: That's effectively an enterprise service bus, it's just the enterprise is the Amazon cloud. The big challenge in designing things like that is decoupling. And it's realizing that when you have a complicated system like that, stuff is going to fail. And especially when we were operating around hardware, stuff is going to fail badly or occasionally, and you need to not bring the whole house down where some storage starts working a bit slower. You create circuit breakers, you create layers and layers of stuff that disconnect things. I remember when we were looking originally at Lambdas and trying to get the head around that and experimenting, should one Lambda call another? Or should one Lambda not call another? And things like that.I realized, let's say for now, until we realize we want to do something else, a Lambda should only ever talk to SNS and nothing else. Or SQS or something like that. When one Lambda completes, it's going to track a message somewhere and we need to design these messages to be good so that we can decouple different parts of the process. And so far, that helps too as a constraint. I think very, very few times we have one Lambda calling another. Mostly when we actually need a synchronized response back, and for security reasons, we wanted to isolate something to a single Lambda, but that's effectively just a black box security isolation. Since creating these isolation layers through messages, through queues, through topics, becomes a fundamental part of designing these systems.I remember speaking at the conference to somebody. I forgot the name of the person who was talking about airline. And he was presenting after me and he said, "Look, I can relate to a lot of what you said." And in the airline community basically they often talk about, apparently, I'm not an airline programmer, he told me that in the airline community, talk about designing the protocol being the biggest challenge. Once you design the protocol between your components, the message is who sends what where, you can recover from almost any other design flaw because it's decoupled so if you've made a mess in one Lambda, you can redesign that Lambda, throw it away, rewrite it, decouple things a different way. If the global protocol is good, you get all the flexibility. If you mess up the protocol for communication, then nothing's going to save you at the end.Now we have EFS and Lambda can talk to an EFS. Should this Lambda talk directly to an EFS or should this Lambda just send some messages to a topic, and then some other Lambdas that are maybe reserved, maybe more constrained talk to EFS? And again, the platform's evolved quite a lot over the last few years. One thing that is particularly useful in that regard is the SQS FIFO queues that came out last year I think. With Corona ...Jeremy: Yeah, whenever it was.Gojko: Yeah, I don't remember if it was last year or two years ago. But one of the things it allows us to do is really run lots and lots of Lambdas in parallel where you can guarantee that no two Lambdas access the same kind of business entity that you have in the same type. For example, for this mind mapping thing, we have lots and lots of people modifying lots and lots of files in parallel, but we need to aggregate a single map. If we have 50 people over here working with a single map and 60 people on a map working a different map, aggregation can run in parallel but I never ever, ever want two people modifying the same map their aggregation to run in parallel.And for Lambda, that was a massive challenge. You had to put Kinesis between Lambda and other Lambdas and things like that. Kinesis' provision capacity, it costs a lot, it doesn't auto-scale. But now with SQS FIFO queues, you can just send a message and you can say the kind of FIFO ID is this map ID that we have. Which means that SQS can run thousands of Lambdas in parallel but they'll never run more than one Lambda for the same map idea at the same time. Designing your protocols like that becomes how you decouple one end of your app that's massively scalable and massively parallel, and another end of your app that we have some reserved capacity or limits.Like for this kind of video thing, the original idea of that was letting me build marketing videos easier and I can't get rid of this accent. Unfortunately, everything I do sounds like I'm threatening someone to blackmail them. I'm like a cheap Bond villain, and that's not good, but I can't do anything else. I can pay other people to do it for me and we used to do that, but then that becomes a big problem when you want to modify tiny things. We paid this lady to professionally record audio for a marketing video that we needed and then six months later, we wanted to change one screen and now the narration is incorrect. And we paid the same woman again. Same equipment, same person, but the sound is totally different because two different equipment.Jeremy: Totally different, right.Gojko: You can't just stitch it up. Then you end up like, okay, do we go and pay for the whole thing again? And I realized the neurometric text-to-speech has learned so much that it can do English better than I can. You're a native English speaker so you can probably defeat those machines, but I can't.Jeremy: I don't know if I could. They're pretty good now. It's kind of scary.Gojko: I started looking at one like why don't they just put stuff in a Markdown and use Markdown to generate videos and things like that? All of these things, you get quota limits still. I thought we were limited on Google. Google gave us something like five requests per second in parallel, and it took me a really long time to even raise these quotas and things like that. I don't want to have lots of people requesting stuff and then in parallel trashing this other thing over there. We need to create these layers of running things in a decent limit, and I think that's where I think designing the protocol for this distributed system becomes an importance.Jeremy: I want to go back because I think you bring up a really good point just about a different type of architecture, or the architectural design of decoupling systems and these event-driven things. You mentioned a Lambda function processes something and sends it to SQS or sends it to SNS to it can do a fan-out pattern or in the case of the FIFO queue, doing an ordered pattern for sequential processing, which those were all great patterns. And even things that AWS has done, such as add things like Lambda destination. Now if you run an asynchronous Lambda function, you still have to write some code or you used to have to write some code that said, "When this is finished processing, now call some other component." And there's just another opportunity for failure there. They basically said, "Well, if it succeeds, then you can actually just forward it off to one of these other services automatically and we'll handle all of the retries and all the failures and that kind of stuff."And those things have been added in to basically give you that warm and fuzzy feeling that if an event doesn't reach where it's supposed to go, that some sort of cloud trickery will kick in and make sure that gets processed. But what that is introduced I think is a cognitive overload for a lot of developers that are designing these systems because you're no longer just writing a script that does X, Y, and Z and makes a few database calls. Now you're saying, okay, I've got to write a script that can massively scale and take the transactions that I need to maybe parallelize or that I maybe need to queue or delay or throttle or whatever, and pass those down to another subsystem. And then that subsystem has to pick those up and maybe that has to parallelize those or maybe there are failure modes in there and I've got all these other things that I have to think about.Just that effect on your average developer, I think you and I think about these things. I would consider myself to be a cloud architect, if that's a thing. But essentially, do you see this being I guess a wall for a lot of developers and something that really requires quite a bit of education to ramp them up to be able to start designing these systems?Gojko: One of the topics we touched upon is the cyclic nature of things, and I think we're going back to where moving from apps working on a single machine to client server architectures was a massive brain melt for a lot of people, and three-tier architectures, which is later, we're not just client server, but three-tier architectures ended up with their own host of problems and then design problems and things like that. That's where a lot of these architectural patterns and design patterns emerged like circuit breakers and things like that. I think there's a whole body of knowledge there for people to research. It's not something that's entirely new and I think you can get started with Lambda quite easily and not necessarily make a mess, but make something that won't necessarily scale well and then start improving it later.That's why I was mentioning that earlier in the discussion where, as long as the protocol makes sense, you can salvage almost anything late. Designing that protocol is important, but then we're going to good software design. I think teaching people how to do that is something that every 10 years, we have to recycle and reinvent and figure it out because people don't like to read books from more than 10 years ago. All of this stuff like designing fault tolerance systems and fail-safe systems, and things like that. There's a ton of books about that from 20 years ago, from 10 years ago. Amazon, for people listening to you and me, they probably use Amazon more for compute than they use for getting books. But Amazon has all these books. Use it for what Amazon was originally intended for and then get some books there and read through this stuff. And I think looking at design of distributed systems and stuff like that becomes really, really critical for Lambdas.Jeremy: Yeah, definitely. All right, we've got a few minutes left and I'd love to go back to something we were talking about a little bit earlier and that was everything moving onto a few of these major cloud providers. And one of the things, you've got scale. Scale is a problem when we talked about oh, we can spin up as many VMs as we want to, and now with serverless, we have unlimited capacity really. I know we didn't say that, but I think that's the general idea. The cloud just provides this unlimited capacity.Gojko: Until something else decides it's not unlimited.Jeremy: And that's my point here where every major cloud provider that I've been involved with and I've heard the stories of, where you start to move the needle at all, there's always an SA that reaches out to you and really wants to understand what your usage is going to be, and what your patterns were going to be. And that's because they need to make sure that where you're running your applications, that they provision enough capacity because there is not enough capacity, or there's not unlimited capacity in the cloud.Gojko: It's physically limited. There's only so much buildings where you can have data centers on the surface of Earth.Jeremy: And I guess that's where my question comes in because you always hear these things about lock-in. Like, well serverless, if you use Lambda, you're going to be locked in. And again, if you're using Oracle, you're locked in. Or, you're using MySQL you're locked in. Or, you're using any of the other things, you're locked in.Gojko: You're actually not locked in physically. There's a key and a lock.Jeremy: Right, but this idea of being locked in not to a specific cloud provider, but just locked into a cloud in general and relying on the cloud to do that scaling for you, where do you think the limitations there are?Gojko: I think again, going back to cyclic, cyclic, cyclic. The PC revolution started when a lot more edge compute was needed on mainframes, and people wanted to get stuff done on their own devices. And I think probably, if we do ever see the limitations of this and it goes into a next cycle, my best guess it's going to be driven by lots of tiny devices connected to a cloud. Not necessarily computers as we know computers today. I pulled out some research preparing for this from IDC. They are predicting basically from 18.3 zettabytes of data needed for IOT in 2019, to be 73.1 zettabytes by 2025. That's like times three in a space of six years. If you went to Amazon now and told them, "You need to have three times more data space in three years," I'm not sure how they would react to that.This stuff, everything is taking more and more data, and everything is more and more connected to the cloud. The impact of something like that going down now is becoming totally crazy. There was a case in 2017 where S3 started getting a bit more latency than usual in U.S. East 1, in I think February of 2018, or something like that. There were cases where people couldn't turn the lights on in their houses because the management software was working on S3 and depending on S3. Expecting S3 to be indestructible. Last year, in November, Kinesis pretty much went offline as far as everybody else outside AWS concerend for about 15 hours I think. There were people on Twitter that they can't go back into their house because their smart lock is no longer that smart.And I think we are getting to places where there will be more need for compute on the edge. First of all, there's going to be a lot more demand for data centers and cloud power and I think that's going to keep going on for the next five, ten years. But then people will realize they've hit some limitation of that, and they're going to start moving towards the edge. And we're going from mainframe back into client server computing I think. We're getting these products now. I assume most of your listeners have seen one like all these fancy ubiquity Wi-Fi thingies that are costing hundreds of dollars and they look like pieces of furniture that's just sitting discretely on the wall. And there was a massive security breach yesterday published. Somebody took their AWS keys and took all the customer data and everything.The big advantage over all the ugly routers was that it's just like a thin piece of glass that sits on your wall, and it's amazing and it looks good, but the reason why they could do a very thin piece of glass is the minimal amount of software is running on that piece of glass, the rest is running the cloud. It's not just locking in terms of is it on Amazon or Google, it's that it's so tightly coupled with something totally outside of your home, where your network router needs Amazon to be alive now in a very specific region of Amazon where everybody's been deploying for the last 15 years, and it's running out of capacity very often. Not very often but often enough.There's some really interesting questions that I guess we'll answer in the next five, ten years. We're on the verge of IOT I think exploding because people are trying to come up with these new products that you wouldn't even think before that you'd have smart shoes and smart whatnot. Smart glasses and things like that. And when that gets into consumer technology, we're no longer going to have five or ten computer devices per person, we'll have dozens and dozens of computing. I guess think about it this way, fifteen years ago, how many computer devices were you carrying with yourself? Probably mobile phone and laptop. Probably not more. Now, in the headphones you have there that's Bose ...Jeremy: Watch.Gojko: ... you have a microprocessor in the headphones, you have your watch, you have a ton of other stuff carrying with you that's low-powered, all doing a bit of processing there. A lot of that processing is probably happening on the cloud somewhere.Jeremy: Or, it's just sending data. It's just sending, hey here's the information. And you're right. For me, I got my Apple Watch, my thermostat is connected to Wi-Fi and to the cloud, my wife just bought a humidifier for our living room that is connected to Wi-Fi and I'm assuming it's sending data to the cloud. I'm not 100% sure, but the question is, I don't know why we need to keep track of the humidity in my living room. But that's the kind of thing too where, you mentioned from a security standpoint, I have a bunch of AWS access keys on my computer that I send over the network, and I'm assuming they're secure. But if I've got another device that can access my network and somebody hacked something on the cloud side and then they can get in, it gets really dangerous.But you're right, the amount of data that we are now generating and compute that we're using in the cloud for probably some really dumb things like humidity in my living room, is that going to get to a point where... You said there's going to be a limitation like five years, ten years, whatever it is. What does the cloud do then? What does the cloud do when it can no longer keep up with the pace of these IOT devices?Gojko: Well, if history is repeating and we'll see if history is repeating, people will start getting throttled and all of a sudden, your unlimited supply of Lambdas will no longer be unlimited supply of Lambdas. It will be something that you have to reserve upfront and pay upfront, and who knows, we'll see when we get there. Or, we get things that we have with power networks like you had a Texas power cut there that was completely severe, and you get a IT cut. I don't know. We'll see. The more we go into utility, the more we'll start seeing parallels between compute and power networks. And maybe power networks are something that you can look at and later name. That's why I think the next cycle is probably going to be some equivalent of client server computing reemerging.Jeremy: Yeah. All right, well, I got one more question for you and this is just something where it may be a little bit of a tongue-in-cheek question. Because we talked it a little bit ... we talked about the merging of Lambda, and of Fargate, and some of these other things. But just from your perspective, serverless in five years from now, where do you see that going? Do you see that just becoming the main ... This idea of utility computing, on-demand computing without setting up servers and managing ops and some of these other things, do you see that as the future of serverless and it just becoming just the way we build applications? Or do you think that it's got a different path?Gojko: There was a tweet by Simon Wardley. You mentioned Simon Wardley earlier in the talk. There was a tweet a few days ago where he mentioned some data. I'm not sure where he pulled it from. This might be unverified, but generally Simon knows what he's talking about. Amazon itself is deploying roughly 50% of all new apps they're building on serverless. I think five years from now, that way of running stuff, I'm not sure if it's Lambda or some new service that Amazon starts and gives it some even more confusing name that runs in parallel to everything. But, that kind of stuff where the operator takes care of all the ops, which they really should be doing, is going to be the default way of getting utility compute out.I think a lot of these other things will probably remain useful for specialists' use cases, where you can't really deploy it in that way, or you need more stability, or it's not transient and things like that. My best guess is first of all, we'll get Lambda's that run for longer, and I assume that after we get Lambdas that run for longer, we'll probably get some ways of controlling routing to Lambdas because you already can set up pre-provisioned Lambdas and hot Lambdas and reserved capacity and things like that. When you have reserved capacity and you have longer running Lambdas, the next logical thing there is to have session stickiness, and routing, and things like that. And I think we'll get a lot of the stuff that was really complicated to do earlier, and you had to run EC2 instances or you had to run complicated networks of services, you'll be able to do in Lambda.And Lambda is, I wouldn't be surprised if they launch a totally new service with some AWS cloud socket, whatever. Something that is a implementation of the same principle, just in a different way, that becomes a default we are running computer for lots of people. And I think GPUs are still a bit limited. I don't think you can run GPU utility anywhere now, and that's limiting for a whole host of use cases. And I think again, it's not like they don't have the technology to do it, it's just they probably didn't get around to doing it yet. But I assume in five years time, you'll be able to do GPUs on-demand, and processing GPUs, and things like that. I think that the buzzword itself will lose really any special meaning and that's going to just be a way of running stuff.Jeremy: Yeah, absolutely. Totally agree. Well, listen Gojko, thank you so much for spending the time chatting with me. Always great to talk with you.Gojko: You, too.Jeremy: If people want to get in touch with you, find out more about what you're doing, how do they do that?Gojko: Well, I'm very easy to find online because there's not a lot of people called Gojko. Type Gojko into Google, you'll find me. And gojko.networks, gojko.com works, gojko.org works, and all these other things. I was lucky enough to get all those domains.Jeremy: That's G-O-J-K-O ...Gojko: Yes, G-O-J-K-O.Jeremy: ... for people who need the spelling.Gojko: Excellent. Well, thanks very much for having me, this was a blast.Jeremy: All right, yeah. And make sure you check out ... You mentioned Narakeet. It's a speech thing?Gojko: Yeah, for developers that want to build videos without hassle, and want to put videos in continuous integration, and things like that. Narakeet, that's like parakeet with an N for narration. Check that out and thanks for plugging it.Jeremy: Awesome. And then, check out MindMup as well. Awesome stuff. I've got all the stuff in the show notes. Thanks again, Gojko.Gojko: Thank you. Bye-bye.

Was für eine großartige Episode! Florian Meyer gelingt es, dieses wirklich komplizierte Thema sehr greifbar zu erklären. Wir konzentrieren uns für den Einstieg v.a. auf das Artefakt der "Wardley Map" und streifen den ganzen Strategiezyklus des "Wardley Mappings" nur oberflächlich. Unser Ziel war es aber auch nie, euch das komplette Wardley Mapping zu erklären, sondern einen guten ersten Impuls zu setzen, damit ihr euch nach diesem Einstieg für das Thema interessiert und einen guten Einstieg ins weitere Material findet. Wir glauben, das ist Florian im Gespräch mit Tim gelungen. Als Einstieg vor den originalen Wardley Videos empfehlen wir Euch den deutschen Vortrag von Markus Andrezak von der LeanDUS14 ansehen: (https://leandus.de/veranstaltung/lean-dus-14-innovation-produkt-experiment). Dort erklärt Markus ab der 32.Minute die Wardley Maps (ab der 50.Minute kommt dann nochmals etwas zu Wardley): https://leandus.de/veranstaltung/lean-dus-14-innovation-produkt-experiment Und danach empfehlen wir das Original auf Vimeo anzusehen: Simon Wardley: Crossing the river by feeling the stones: vimeo.com/189984496 Ansonsten haben wir weiter unten noch sie superguten YouTube Playlists mit einer super Übersicht über alle von Florian Meyer empfohlenen Videos aufgeführt. Literatur: - Simon Wardley: On being lost (link.medium.com/80CYi8tSYV) - John Boyd zu OODA-Loops im Buch The Fighter Pilot Who Changed the Art of War - Sun Tsu ("Sunzi"): Die Kunst des Krieges https://de.wikipedia.org/wiki/Die_Kunst_des_Krieges_(Sunzi) YouTube Channels/Playlists: - Wardley Mapping (Videos auf Deutsch) - Wardley Mapping (Allgemeine Videos) - Wardley Maps Channel - Ben Mosior Hired Thought (Videos) Tools: - Strategie-Phrasen-Generator: "What is my Strategy?" - Miro-Vorlage von Ben Mosior und Miro-Artikel - Super Tool Übersicht von Ben Mosior: https://learnwardleymapping.com/tools/ - Online-Tool von Damon Skelhorn inkl. Visual Studio Extension: https://onlinewardleymaps.com/ - Tool von Excalidraw https://excalidraw.com/ - Wardley's Doctrine (universally useful patterns that a user can apply regardless of context) https://doctrine.wardleymaps.com

Dominic Cummings wanted to set up a thing to invent the next internet and then BRITAIN WOULD BE RICH. We respond to his appearance before MPs in Downing Street on the 17th March and think perhaps he hasn’t thought it through.Streamed Live on https://twitch.tv/michaelforrest, Friday 26th March 2021---- Stuff we made ----Try Donegood https://donegood.app Get Michael’s Apps https://goodtohear.co.ukRestaurants Brighton: https://restaurantsbrighton.co.uk---- This Week's Links ----[1] Dominic Cummings appears before MPs after Downing Street exit - https://youtu.be/d2ZNneX4TqI [2] Simon Wardley’s Analysis - https://twitter.com/swardley/status/1372864326470619141 [3] Dana Carvey’s Joe Biden - https://www.youtube.com/watch?v=EufXiqAXNG4---- Credits ----Talking is by Ivanka Majic and Michael ForrestMusic and editing by http://michaelforrestmusic.comMusic available on Apple Music | Spotify | Amazon | Google Play | Bandcamp---- Support Us ----On Patreon and Join Our Slack: https://patreon.com/grandpodcastBuy our mug: https://www.etsy.com/uk/listing/672419524/grand-podcast-mugPaypal Donation: https://paypal.me/grandpodcastRestaurants Brighton Jobs: https://restaurantsbrighton.co.uk/jobs Get Michael’s Apps: https://goodtohear.co.uk ---- Follow us on Twitter ----https://twitter.com/ivankahttps://twitter.com/michaelforresthttps://twitter.com/PodcastGrand---- Grand Podcast Library ----Find links to everything we've mentioned on the podcast at http://grandpodcast.com/library See acast.com/privacy for privacy and opt-out information.

In his consulting practice, Ben Mosior teaches Wardley Mapping, a tool for visualizing strategic intent. In this conversation, we dive into Wardley Maps: what they are and how they can help us make better strategic decisions.   Listen to the show   Download episode 57   Show notes   Learn Wardley Mapping @HiredThought on Twitter The Phoenix Project by Kevin Behr Leading Edge Forum Wardley maps: Topographical intelligence in business by Simon Wardley The Art of War by Sun Tzu How to Read a Wardley Map video   Some show notes may include Amazon affiliate links. I get a small commission for purchases made through these links.   Read the transcript   Jorge: Ben, welcome to the show.   Ben: Thank you for having me, Jorge.   Jorge: I'm excited to have you here. For folks who might not know you, would you mind please telling us about yourself?   About Ben   Ben: So, I started out my career in systems administration, which I'll very lovingly describe as telling computers how to do things. And I actually worked for the state of Pennsylvania for a while. I worked in higher education to basically learn how to deploy lots of systems and actually we ran a whole library network for the entire state. We also did some local things for the school that we were based at. And, I was learning about all sorts of technical concepts, like configuration management and all this kind of stuff. And eventually I wandered my way into the world of DevOps.   Which, DevOps is like a word that it's a portmanteau: development operations. And there are a lot of different meanings that people load it up with. The one that I tend to see as being most foundational for me is 'viewing the divide between development and operations and what it takes to get two groups of people to work together.' So, I had this experience where I started to realize that, oh! Turns out if you are just managing the computers, that's not enough to create value at the end of the day for the people that you're here to serve.   So, I went to a DevOps days conference in Pittsburgh. I met Kevin Behr who wrote The Phoenix Project. Long story short, I find myself like thrust into this world of like, hey! Systems thinking! Global thinking! Like let's actually not just focus on our local part. Let's see how the local part fits into the whole thing. And gradually what that ended up doing is it actually took me out of the world of computers and into the world of humans. Like the human side of it. It turns out you can't just have one or the other; you have to have both. And long story short, I've just had a lot of weird experiences working on the social and the technical. So, the socio-technical aspects of these organizations that we all work in.   I left the state. I started working for a corporation. I gradually found myself running my own startup, my own little kind of software development company with a couple of friends. Eventually I ended up in consulting and I really don't know how I ended up there from the beginning to getting to that point. It doesn't really make a lot of sense. But I found myself running into weirder and weirder ideas about how to make sense of things inside socio-technical systems. So that led me to a network of people on Twitter who just kept feeding me all these weird ideas and eventually, I ended up learning about Wardley mapping, which is a thing that I care a lot about because I spend a lot of time teaching people about it.   But roughly I think it's very aligned with what The Informed Life is all about. It's about making sense of things. It's about sharing that experience with others and collectively creating coherence so that you all can act meaningfully together. So that's kind of the arc of my career. That's why I'm here. That's why I'm doing what I do, and I wouldn't trade it for anything else.   Wardley Maps   Jorge: I love this phrase, "collectively creating coherence," and you mentioned Wardley maps as a way of achieving that. What are Wardley maps?   Ben: So Wardley maps are an invention of Simon Wardley. And Simon Wardley is a kind person who works currently for The Leading Edge Forum. He's a researcher. He basically wanted to design a tool that would rid the world of parasitic consultants. And so, he sat down and that was his purpose for designing this tool. It came from his interest in trying to basically do a good job as a CEO. He has a journey, like there's actually a book that he's written, which you can find on Medium, where he basically talks through his whole career arc about, you know, he was an "imposter CEO." He thought that maybe he was missing the all-important lessons of how to do strategy, that kind of stuff.   And what he ended up discovering is that not many people actually have this figured out, and there are no real secrets. And so, he felt like he had to go out and find his own. That led him to studying military history, led him to understanding, in particular, Sun Tzu's The Art of War, and integrating that into Eastern philosophies of strategy and long story short, what he brought back to the world was a way of making individuals more capable of making sense of their environment and thinking through what to do about it. And based on his intent to rid the world of parasitic consultants. His whole idea is that if you equip executive leaders with the capability of making sense of the world for themselves, then they won't need consultants as much. Consultants won't be a crutch anymore. Maybe you'll bring them in to help you challenge and refine ideas, but you don't need a consultant in order to come up with a strategy.   So, concretely, Wardley mapping is a visual way of representing systems: its users, its needs, its capabilities, its relationships between all those three things. And then it's also positioning those things in a way that helps their qualities become more apparent. So, there's this thing that Simon Research called "Evolution." It's basically how do things evolve and get better or die under the pressures of supply demand competition, and what you get is like things start out new, uncertain, high risk, high failure, but with a high potential for future value. But then as they evolve, they get better. You know, someone's always like looking at these weird ideas and trying to make them better because capitalism basically suggest there's money to be made. So, someone out there is going to try to make it better. And over time, if the idea is worth investing in, it will continue to get better, more known, more boring, more predictable, and the value of it will be more concrete. And eventually, if it evolves to a certain extent, it becomes an invisible part of our everyday lives.   And so, Simon says, look, you want to represent the systems that we're a part of both in terms of their parts and relationships, but also in terms of how evolved each of those parts are. Because what that does is it sets you up to understand the implications of those qualities. New stuff is going to be high failure, old stuff that everybody understands, that's just part of everyday reality like power in the wall. It is going to be less surprising; it's going to be less failure. And so that means that depending on the context, depending on the part of the system we're looking at, we need to have a different way of approaching it. And I think that's the entire point. By making visual artifacts — by talking about our systems visually — we can come together, look at a specific part of it, appreciate its qualities, and then together determine what our collective intent is about that part of the system. And I don't think that's just for executives. I think that's for anyone who is making decisions at any level of the organization.   Jorge: If I were someone who's listening in, I'd be desperately wanting to look at one of these things. You've described it as a visual artifact. And I'm wondering if we could give a shot at trying to describe one for folks who are listening.   Ben: Absolutely. And what I'd suggest is if you are in a situation where you are listening and you can pull something up in a new browser tab or something like that, go to learnwardleymapping.com and scroll down until you see a funny looking diagram. You'll see a video down there called "How to Read a Wardley Map," or depending on when you're listening to this episode, maybe you'll have to search a little bit harder. Maybe look into the reference section of the site a little bit.   But you'll find an artifact with an X and a Y axis. So, the Y axis will be labeled the "Value Chain" and the X axis will be labeled "Evolution." and the X axis will have four segments. Four sections within it. And these correspond to those four stages of evolution. We have different labels for these stages. It can just be one, two, three, or four. Simon likes to say Genesis, Custom-Built, Product, and Commodity. But you can also look at it through like a knowledge lens or a practice lens. There are these different lenses that you can look at that same evolution and use different words to describe it. There's an evolutionary characteristics cheat sheet that you can use to get a deeper appreciation for evolution.   Thinking about this visual, it's about what goes on this Y axis and X axis space. And what you have at the very top is who's being served by the system. Who benefits, who is getting value from it. Underneath that is usually a set of needs. So, what the user needs from the system, and these are connected by relationships. Needs relationships. So, X depends on Y. Citizens depend on pandemic safety, for example, or users depend on the dashboard in your SASS application or whatever it ends up being, right? And then underneath that is yet more components. Yet more parts of the map. And these are the capabilities that the system has within it that all add up to produce this set of benefits for the user. And all of them have those relationships. X depends on Y, Y depends on Z, and so on and so forth.   And so, by making an artifact like this together, what you really quickly start to see is that inside your organization, or even inside your own head, there are things you ought to know that you don't know. And it's really a kind of a mechanical, "how does this work?" kind of question. And by discussing it together, and instead of talking at each other, talking past each other, you talk through an artifact that you're constructing together? That specifically describes these dimensions. You'll be able to more carefully and articulately describe what the system is and therefore more carefully and articulately described what your intent is with respect to that system.   Wardley Maps vs other systems diagrams   Jorge: There are many different types of systems diagrams. How is a Wardley map different from other ways of visualizing systems?   Ben: That's a really good question. And it's one that I get a lot of the time and the blunt answer is, it's not all that different with respect to the benefits that working in any visual methods will get you. I mean, when you're in a meeting and you're not actually looking at something together? It can be very, very hard to make sure you're talking about the same thing. can be very, very hard to make sure that you're understood. But when you're using a visual thing, any sort of visual thinking tool, that gets a lot easier.   What Wardley mapping brings to the table, however, is two additional things to the visual side of it. One is this evolution concept that we've been talking about, which has its own implications for, hey! If something is high failure, we should approach it in a way that makes that failure safe. Versus something is boring, totally known, hey! Maybe we should approach this with an expectation that we should reduce the deviation. We should make it as knowable and portable as possible. So, like the approach that we take towards that thing is different. So, appreciating those qualities is really important because otherwise you end up doing things like building stuff that you don't need to build. You might outsource things that you shouldn't outsource. And roughly it's just a way of bringing capitalism and the implications that capitalism has to the forefront of your decision-making.   Now that's one thing. The second thing is the strategic thinking process. Simon Wardley describes a process for sitting with your understanding of the system that breaks that, that sort of understanding down into five steps, only one of which is making the map.   The first is Purpose. It's why we all do what we do. It's the reason we're getting out of bed, showing up to do the work. It's the purpose of the entire system. It's the moral imperative... it's the view of aesthetic truth and beauty that we are trying to imagine for the future through the work that we do every day. that's Purpose.   The second thing is Landscape, and that's making maps. That's making these visual artifacts of the competitive landscape to understand the circumstances that we're playing in, that we're dealing with right now. Who else is there? It's not just us, right? It's the wider market.   And then the third thing is Climate. These are the patterns that more or less dictate the rules of the game. It's things like everything will evolve from stage one of evolution to stage four, over time. And so, what does that imply is a worthy question. But Simon has a whole table of like, I don't know, 30 or 40 of these different rules of the game that one by one you can learn to appreciate over time.   The fourth thing is Doctrine. And these are the universal principles that we choose to apply inside our organization. Things like always focus on user needs. So, it's about how you equip your organization to be the best that it can be to actually be able to participate strategically in the wider market. In the wider competitive landscape.   And then finally, it's the question of what you would do given what you know. It's the integration of everything that we've already discussed — the purpose, the specific landscape that you're in, the rules of the game, those climatic patterns, and the training of your organization. The doctrinal principles that you always apply. It's the synthesis of all those things that enables you to start thinking about what moves to make. Should we do this, or should we do that? And that is entirely about how to spend the precious, limited time, attention, all of scarce resources that you have at your disposal? Where do you put that? How do you decide how to invest all that in a way that makes sense?   I think the most common mistakes that organizations make is they spread that investment too wide. They don't be intentional about what they're doing, and the result is they don't make progress quickly. They don't actually achieve what they set out to achieve. And you have an organization full of individuals just showing up to work every day, not really connecting to that bigger purpose, not really making a difference in the world. And it's a system that actively trains you, that what you do doesn't matter.   So, those are the five factors of Simon's strategy cycle. That's what Wardley mapping brings in addition to being just a visual method. It brings this idea of how to pay attention and appreciate and understand the implications of capitalism, and that's evolution. And then the second thing is it brings the strategic thinking process to apply to the visual artifact with others.   Example of a Wardley Map   Jorge: Can you give us an example of a Wardley map being used to make strategic decisions?   Ben: Yeah, absolutely. I often use Wardley mapping for myself, although a lot of the times, the map never leaves my head, just because if you do this so many times, you start building up an intuition for it. But the one that I often like to share because it certainly deeply impacted me especially because it involved my family, is COVID-19 pandemic related health and safety.   And so, I made a map a little while ago, and it was broadly about citizens... sort of citizens of various countries, right? I'm in the United States. That's what I'm focused on. Citizens need health. And so, at the top of my map, those are the first things that are shared. And then I framed it this way: I said there are two ways, two different capabilities that the system has that produces health. And one is prevention, and one is treatment. So, sometimes there's shorthand in these maps. Part of the fun is like trying to find words that very concretely and concisely describe a very vast phenomenological experience. So just roll with me — prevention and treatment is about: either you prevent yourself from getting COVID-19, or you treat the issue once you have it.   Looking at these two different sides of the Wardley map, underneath prevention you have a lot more novelty. So, this chain seems to be way more towards the left side of the map, the stage one and two side of evolution. They're uncertain, they're more unknown, they're more risky, and yet the payoff could be really huge if we get it right. So, prevention, I wrote, needs things like mask wearing and things like social distancing. And what I noticed here is that these are things that feel like they should be much more evolved. They really ought to be more ubiquitous. Like the way I would hope things to be is that the obvious effective thing, like wearing a mask, is something that you would do as a citizen, in a country to prevent the spread of the virus. And I think it would be really interesting to dig into why these things are less evolved. But for whatever reason, they're less evolved. Mask-wearing, social distancing... these are things that are really, really hard for people to do, and I think it has something to do with the entanglement of like the social side of it. Like people need to see other people.   The problematic and contradictory messaging that they're getting, the emergent nature of conspiracy theories and anti-vaccination and why those things have come about. And it's a really, really kind of deep rabbit hole that you'd go into and dig into if you wanted to explore that more deeply. But for me, I just wanted to emphasize these two things in my situation. That, in our house, we will be wearing masks and we will be social distancing. And because those things are less evolved, we may actually have to do some of our own research to figure out how to effectively do that. And so that led us to things like, The New England Institute of Complex Systems. I think I'm getting that wrong. There was a really fabulous paper that basically described how to do the New Zealand pod system, but for family units. And so, the social distancing part of that, we could actually like do some research and find some new cutting-edge things that we could try and apply. For a while, we were actually able to form a household unit with our upstairs neighbors. We all had collective rules that we were following based on this cutting-edge research. That was our experiments that we had to run because this thing was so less evolved.   Now, so that's the prevention side of it. The treatment side of it is a little bit more straightforward because it's all about what to do within the context of the existing medical system. Treatment is more towards the right of the map because generally treatment disease and is something that's, largely more evolved. And underneath treatment, you have things like diagnosis, care, triage. These kinds of activities that you would expect to happen in a hospital, for example. And so, diagnosis depends on testing. Treatment depends on care, and care depends on personal protective equipment and medical knowledge. And so, you start to appreciate all these different parts of the system that add up to treatment. Then you can have a conversation about how, when PPE isn't available, the part of the system that provides care, enables treatment, and that therefore enables health for the citizens, starts to fall apart. When testing isn't available, the same thing happens. And so, you have this like question when you have the full system, "okay. We've got prevention kind of questions that are more towards the left of the map. You have the treatment side, which is more towards the right of the map. Where do you put your time and attention?" And as an individual? One person with a family?   I felt like the best thing we could do is invest our time and attention in the prevention side of it. On the mask wearing and the social distancing. It's really, really hard for us to do something with testing and PPE and things like that. So, it just wasn't an option for us. So very practically, just by having the whole system in front of us, we were able to make more informed decisions. And frankly, I share this with other people and saw what they thought. And that made it better. Because then we could refine and expand our awareness of what was and wasn't actually happening out in the wider world. So, any biases we had about how things worked, could get checked at the door. And we could actually work together on designing something better together.   Collaborative map-making   Jorge: The way that sounds to me is like, the artifacts that we see — these charismatic maps that you were referring to earlier — are the outcome of a process and the real value lies in the process. And it also sounds to me like the value of the process is dependent on the collaborative way in which it comes about, right? Because in the process of making this thing together, you build alignment. You tap into people's diverse knowledge, etc. Is that fair?   Ben: That's absolutely fair. And there's always the problem with any methodology that you have to somehow convince other people to do it with you. I never want to underestimate the value of one person paying attention using this method, just to get themselves figured out, to understand why they interact in the way that they do with the system. But yes, like it is enormously valuable to do with another person, or if you're on a team to do it together.   And my general advice with any methodology is kind of get past the, "everybody has to learn how to do it." Like, ignore that! And instead, just get started. Just take half an hour, try to understand one simple part of the whole thing. Just get a little bit better every day. And so, I don't think you need to be an expert Wardley mapper. You can start out by making lists. Like one of the first steps of Wardley mapping is who is being served by the system? And so, what you can do right now, today, is in the next meeting that you attend, you can sit there and you can make a list of who is being served by this system. And then you can ask other people what they think. Does this list make sense to you? Is this what you think? What am I missing? Who do you disagree with my inclusion of, on this list? Right? So, it doesn't have to be this like whole thing, this whole like methodology, it's like little parts of it, a little bit by bit every day.   Jorge: You said that Simon Wardley's goal with this was to rid the world of parasitic consultants. You're a consultant.   Ben: Yes.   Jorge: Given that it sounds like the true value in this resides in teams doing it for themselves to get their bearings and figure out where they're going next, what role do you play in that process?   Ben: That's a really good question. Because as a consultant, it seems like I am convinced that I have no value by saying that it's an anti-consulting framework. And that's not quite true. There are a lot of different ways we could explore this, but I think I'll start by saying the first thing is consultants are not useless. It's the dependence on consultants in a way that takes away an organization's own agency that I think is problematic. Simon in particular is looking at the example of, maybe one of the big consulting firms coming into an organization, talking with an executive and basically executive delegates the act of creating strategy to that consulting organization. That's probably the exact scenario that Simon is designing against by providing Wardley mapping.   I'm playing a little bit of a different game, personally. And whenever I work with other consultants, this is the question, a set of questions that I have for them. It's like, which game are you playing inside this organization? Are you playing the game where you just make money and you go home, like, it's just your job? Are you playing the game where you're trying to reduce harm? And so, your being in the organization is not about creating dependence on you, but it's about you reducing harm inside the organization. And that kind of has this implication, that you're just... you're there in order to watch for those moments where you can do one small thing that helps someone make one huge step forward and kicks off this snowball that turns into an avalanche of ideas and thoughts for them. Or are you actually doing a long-term and extended intervention?   And a lot of those games, I have a hard time with, just generally speaking. And so, I tend to focus on: how do I build people up? How do I help them increase their own capability? So that, I'm never building a dependence. It's never a situation where they're going to ask me to come back over and over and over and over and over again about the same thing, because they've delegated something to me. Instead, I want it to be something where if they invite me back, it's because we're going to have a new experience that genuinely stretches them, genuinely helps them grow about new things that we haven't already covered.   So, when I come in to teach mapping, it's about enabling the individuals of the organization, which is why I'm not focused just on executives, it's leaders at all levels. How do I help every person that I interact with have a little bit more agency in the decisions that they make every day? And 1) that's just helping them notice the system that they're in, but 2) knowing how to make sense of that system, and then also be able to take action to change it, to shape it. And so, a lot of times my "consulting" ends up looking more like one-on-one sparring or coaching, things along those lines. Sure, I do a lot of Wardley maps too and maybe I'm teaching you how to do that. That's why you brought me in, right? But there are these little opportunities to, on a one-on-one basis, build people up so that they individually have more power in the system that they're in.   Jorge: When I was thinking about this role of helping people map the systems they find themselves in and consulting, I was thinking that maybe the role was like a cartographer. But it sounds to me like there is a little bit of cartography involved, but it's cartography in service of learning to do cartography.   Ben: I think the worst thing you could do is delegate the cartography to someone else. Because unlike a specialized field like literal map-making — so mapping the physical world — this is different. This is like ontological map-making; this is about understanding what exists inside an organization. And it's not just like what furniture is in the rooms. It's about what ideas are in people's heads. What ontology has the organization created that is not understood in an appropriate way across the organization? And this is one of the things that we often get into where it's like, "well, are you trying to help everyone understand every part of the organization?" No, absolutely not. What we're trying to do is help individuals understand their parts of the organization, but also understand how their parts connect to other parts of the organization and where the shared understandings need to exist. It's really about understanding the boundaries of where different areas of autonomy in an organization overlap, so that collectively they can negotiate along those boundaries.   And I think it's just about knowing where to invest your attention in the organization, because if you're doing work heads down 80% of the time, and you're not paying attention to how the overall system is functioning, you're going to immediately run into the problem — that initial career-arc mind-blowing moment that I had — which was, "Oh my gosh, I'm just trying to make the local thing better. And it's actually making it worse for everyone around me!" Trying to see how you and your individual part of the organization fit into a larger whole is what this is all about. It's really about making the organization more intentional at all levels and within all parts.   Closing   Jorge: That sounds like a great way to summarize this. I love the phrase "ontological map-making." It sounds like a beautiful encapsulation of what this is about. I'm sure that folks are going to be wondering about where they can follow up with you. Where can we point them to?   Ben: I am really accessible on Twitter. And so, if you'd like to follow me @hiredthought, you are always welcome to direct message me or reach out. I can also be emailed if you want to go that way: ben@hiredthought.com. And of course, if you want to learn more about Wardley mapping, you can go to learnwardleymapping.com. There's a free book that Simon's written. We've made it available in multiple formats. There's a short introduction video on the homepage that you can just play with and see if you'd like the concepts that you're hearing about. You can decide for yourself whether to dip your toes further. And then I would encourage you to reach out and say hello if you need any help or have any questions. I'm always happy to hear from you.   Jorge: That's fantastic. Thank you so much for being on the show.   Ben: Thank you so much for having me.

Wardley Mapping is a method used to help generate a shared understanding of strategic landscapes and their evolution. From all levels – individual businesses, industries, to Nation States and even culture – it can be applied to pretty much anything. And as our adopters know well, Wardley maps are a key feature of platform strategy design. And the person who invented these maps is joining us on the podcast today: Simon Wardley.    Simon Wardley is a former CEO and advisory board member of startups (all now acquired by US Giants) and a fellow of Open Europe. He’s a regular conference speaker and a researcher for the Leading Edge Forum. Simon uses mapping in his research at the Leading Edge Forum, covering areas from Serverless to Nation State competition whilst also advising/teaching clients on mapping, strategy, organisation and leadership.   We’re referring a lot to the “Wardley’s Doctrine” table - which is linked in the notes. Go to our medium publication to find it: https://platformdesigntoolkit.com/podcast-S2E11-Simon-Wardley     You’ll hear about why the Economy should start learning from China, why Tech should go serverless, why Businesses should focus on doctrine, and what Simon means when he says Society should have that “We vs Me” conversation. You’ll probably find that this episode is worth listening to a few times to get the depth and breadth of the conversation!    If you enjoy the show, we’d kindly like to ask you to go to your favorite podcast platform and rate the show. In our ethos to keep all our knowledge open, we want to spread ideas as widely as possible and high ratings help us secure important guests. Thanks so much for your help!    Remember that you can find the show notes and transcripts from all our episodes on our Medium publication: https://platformdesigntoolkit.com/podcast-S2E11-Simon-Wardley   To find out more about Simon’s work:   > Website: https://learnwardleymapping.com/  > Twitter: https://twitter.com/swardley  > Medium: https://medium.com/wardleymaps  > Wardley Maps: https://list.wardleymaps.com/   Other references and mentions:   > Simon Wardley, Wardley Mapping, The Knowledge: Part One, 2020: https://www.amazon.com/Wardley-Mapping-Knowledge-Topographical-intelligence/dp/1913805182/ > Avinash Dixit and Barry Nalebuff, The Art of Strategy: A Game Theorist's Guide to Success in Business and Life, 2010: https://www.amazon.com/Art-Strategy-Theorists-Success-Business/dp/0393337170/r   > Giancarlo Gonzalez Ascar, From Intention to Action: A Plan for the Digitalization of Puerto Rico, 2020: https://www.amazon.com/Intention-Action-Digitalization-Puerto-Episode/dp/B08HGTJHJR/    > Jonathan Allen and Thomas Blood, Reaching Cloud Velocity: A Leader's Guide to Success in the AWS Cloud, 2020: https://www.amazon.com/Reaching-Cloud-Velocity-Leaders-Success/dp/B086PTDP51   > Margaret Mead: https://en.wikipedia.org/wiki/Margaret_Mead    > The Entrepreneurial Age: Networks and a fragmenting world — with Nicolas Colin: https://stories.platformdesigntoolkit.com/the-entrepreneurial-age-networks-and-a-fragmenting-world-with-nicolas-colin-718c066b19bc    > Control and Coherence in the New Strategy Playbook — with Rita McGrath: https://stories.platformdesigntoolkit.com/control-and-coherence-in-the-new-strategy-playbook-with-rita-mcgrath-5346fefc7a36    > Re-bundling the Firm around Problems to Be Solved — with Sangeet Paul Choudary: https://stories.platformdesigntoolkit.com/re-bundling-the-firm-around-jobs-to-be-done-with-sangeet-paul-choudary-af69f7d2bcbb    > Boundaryless whitepaper (2020), New Foundations of Platform-Ecosystem Thinking — Designing Products and Organizations for a changing world, https://platformdesigntoolkit.com/DOWNLOAD-NF Find out more about the show and the research at Boundaryless at www.platformdesigntoolkit.com/podcast   Thanks for the ad-hoc music to Liosound / Walter Mobilio. Find his portfolio here: www.platformdesigntoolkit.com/music   Recorded on 27 January 2021.

For today’s episode, I want to share an out-take from my consulting work, something I think might be interesting for anyone working in the technology industry. It’s a set of 20 questions that can help you uncover the current state of play in your business. The questions are mainly useful for technology companies for reasons I’ll get to, and are probably of limited value to non-technology businesses, but you’re welcome to try using them for non-technology businesses.A caution: The only person who can usefully answer these questions for the company as a whole is the CEO. But it’s a fun game to play from any position, and useful to the extent you are close to, and aligned with, the CEO. I put this list together in the course of some work I’m doing with a client, and in doing that, I realized that these are the questions I tend to explore free-form in the first couple of orientation calls with all new clients. I don’t explore these via an explicit Q&A, but more in a sort of bingo-card format, where I look for answers to these in a free-form conversation. For me, it’s a way to efficiently learn about the business, and for them, it tends to be a useful exercise to turn an unconscious sense of the state of play into a conscious one.So here are the questions, with some commentary afterwards. Note that this is written text is a skeletal outline, not a transcript. The audio has me riffing on all these questions and explaining the logic of the sequence, so you’ll have to listen if you want the whole thing.The QuestionsWhat is the primary operational bottleneck or "firefight" currently consuming the bulk of your attention? (eg: "growing schedule slippage on launch of product X" or "difficulty filling critical CxO position" or "PR damage control due to issue X")What is currently the biggest source of uncertainty/doubt/anxiety for the company? (Be specific, eg: "high failure rate of manufacturing process X" or "poor conversion rates of sales campaign for product Y" or "What customer Z will decide for their product P")What are the top 5-7 events coming up on the company roadmap in the next few years? (eg: key technology tests, decision points, product launches, sales drives, external events like elections) Who/what are the top 5-7 most important external entities shaping your business sector environment? (key customers, value chain partners, government agencies etc. Name either individual entities, or classes that are as specific as possible, like "small food-service business owners").Which entity in the list from Q4 above exercises the MOST strategic control over the primary value chain of interest to the business?Which entity in the list from Q4 consumes the largest share of your personal attention? (can be the same as 5)What is the MAIN line of business (LOB) the company MUST win in, within the current business model, to be successful?What is currently the MAIN strategic metric/measure that tells you whether you're winning or losing in that LOB? (be specific, eg: "free cash flow" or "increasing yield rate from process X" or "rate of increase of production volume")Who is the ultimate customer/end user for the overall value chain this LOB is part of? (Be as specific as possible. Eg, "fast-food restaurant chains")Who is the immediate prototypical customer for this LOB for your business? (Eg, "commercial kitchen equipment manufacturers")What is ONE belief held by this prototypical customer that you would like to change, and what would you like it to change to?What they believe:What you would like them to believe:What is your "Thielean Secret"? ONE key belief held by you/your company that is NOT widely shared by the industry?What is working unexpectedly well, where you seem to be getting surprisingly lucky?What is working predictably badly, and seems hopeless/doomed?Overall, how well is the current business model working? Use a qualitative phrase in the range from "succeeding wildly" to "in big trouble"What do you estimate are the % chances you'll need to execute a major business model pivot within the next 3 years?If you do need to pivot, what is the most likely alternative business model you will be considering?What are the top 3-5 macro trends affecting your business environment (Be specific: examples: Covid, China trade war, climate change, software eating the world, input X commoditizing, industry structure going from horizontal to vertical…)What are the top 3-5 elements of the business environment that are NOT changing?Based on reflection on your answers to questions 1-19, list  between 3-5 problems that you consider to be the top strategic priorities. Describe each with a single sentence. They can relate to any aspect of the business: internal or external, relating to marketing, engineering, HR, sales, or cutting across functional boundaries. Try and state it in terms of key details that have strategic significance, not generalities (eg, "Get defect rate for manufacturing process X below Y%" not "Improve quality") These questions are specifically useful for technology businesses — businesses that develop and sell products or services that take significant engineering, and are driven by, and drive, technology trends. This is because technology businesses are strongly time-based, and have to evolve and maneuver in a marketplace where competition is based primarily on innovation, not supply and demand shifts due to macro factors in an otherwise unchanging market. In other words, there is a sort of fast-evolving real history to technology businesses that’s not really there in non-technology businesses, like managing a corner grocery store or even a consulting business like mine. These questions assume that the logic of the business is the logic of time-based competition, which means your approach will include things like OODA loops, S-curves, disruption, Simon Wardley’s Wardley Maps, Ben Thompson’s Aggregation Theory, and so on.Even though the questions might seem banal and obvious, the thing is there’s a lot of banal and obvious questions you can ask about any business, like hundreds, and it’s not immediately obvious, at least to me, that these are the right ones. These questions — in this rough sequence — are ones I’ve converged on through trial-and-error over nearly a decade of initial orientation conversations with new clients. Many other questions can be usefully asked once you have a sense of the answers to these basic questions, but skipping these and going straight to other questions is usually a recipe for frustration.So that’s it for this episode. You’ve been listening to/reading a free podcast issue of the Breaking Smart newsletter, where I send out a longform piece for subscribers every Friday, usually an installment from one of my multi-part projects, and sometimes stand-alone essays. Once every 3 or 4 weeks, I publish a free public podcast like this. In the previous 3 weeks, I published 3 subscribers-only essays:Control Failure -1 from my Great Weirding essay series, about the global transformation of the last few years.The Descent of the Public, from my After Westphalia essay series, about what comes after the nation-state.Operating in Time -2, the concluding part of Chapter 3 of my book project, The Clockless Clock.Thank you for listening, andI’ll be back next week with another longform piece. Get full access to Breaking Smart at breakingsmart.substack.com/subscribe

Simon Wardley   Simon Wardley is a researcher for Leading Edge Forum, a global research programme dedicated to helping large organizations reimagine their organizations and leadership for a technology-driven future.   He is also the inventor of Wardley Maps   Find the entire book on Wardley Maps here:   Chapter 1 — On being lost Chapter 2 — Finding a path Chapter 3 — Exploring the map Chapter 4 — Doctrine Chapter 5 — The play and a decision to act Chapter 6 — Getting started yourself Chapter 7 — Finding a new purpose Chapter 8 — Keeping the wolves at bay Chapter 9 — Charting the future Chapter 10 — I wasn’t expecting that! Chapter 11 — A smorgasbord of the slightly useful Chapter 12 — The scenario Chapter 13 — Something wicked this way comes Chapter 14 — To thine own self be true Chapter 15 — On the practice of scenario planning Chapter 16 — Super Looper Chapter 17 — To infinity and beyond Chapter 18 — Better for Less   You can find Simon on   Twitter: 
@swardley and Medium: https://medium.com/@swardley     SUPPORT THE PODCAST   This show is brought to you by the Visual Thinking and Sketchnoting Boot Camp online course. This unique and highly practical signature course will teach you all the necessary elements that you need to employ visual thinking for your profession.   With the help of the course, you will boost your thinking and communication skills as well as improve your productivity and effectiveness.   Find more information at https://www.udemy.com/course/visual-thinking-and-sketchnoting-boot-camp/?referralCode=D0574A03FF3E6CADC63F   Subscribe to Yuri's newsletter: http://eepurl.com/gWi_if

You can find Ionut Craciunescu on Twitter as @icraciunescu. Check out his medium posts here. You can also find Wealth Wizard's engineering blog here, and their GitHub projects here.This is the talk by Simon Wardley that Ionut mentioned in the episode:Crossing the River by Feeling the StonesAnd here is the earlier episode where I talked about FinDev and Wardley Mapping with Aleksandar Simovic and Slobodan Stojanovic:#17: FinDev and Wardley mapping with Aleksandar Simovic and Slobodan StojanovicFor more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.Opening theme song:Cheery Monday by Kevin MacLeodLink: https://incompetech.filmmusic.io/song/3495-cheery-mondayLicense: http://creativecommons.org/licenses/by/4.0

In this episode we have two leading platform thinkers on the show: Marshall Van Alstyne, Questrom Chair Professor at Boston University and Geoffrey Parker, professor of engineering at the Thayer School of Dartmouth College. They are both visiting scholars at the MIT Initiative for the Digital Economy and co-chair the annual MIT Platform Summit (see references below)Marshall Van Alstyne and Geoffrey Parker - together with Sangeet Choudary - are the authors of Platform Revolution: How Networked Markets Are Transforming the Economy - and How to Make Them Work for You, from 2016. As originators of the concept of the inverted firm, they were further joint winners of the Thinkers50 2019 Digital Thinking Award. In this conversation, we talk about what democratising access to data means for the ability of players in a platform-ecosystem context to innovate and how regulation should be conceived participatory and ex ante. With creating human value as the North star, Marshall and Geoffrey ponder that we might want to see the creation of a Magna Carta of citizens rights for how we should be able to operate and influence on powerful platforms.Remember that you can find the show notes and transcripts from all our episodes on our own Medium publication.  Here are some important links from the conversation: Find out more about Marshall and Geoffrey’s work> Geoffrey G. Parker, Marshall W. Van Alstyne, Sangeet Paul Choudary, Platform Revolution: How Networked Markets Are Transforming the Economy and How to Make Them Work for You, 2016. https://www.amazon.com/Platform-Revolution-Networked-Markets-Transforming/dp/0393249131> MIT Platform Strategy Summit, 2020 edition taking place virtually on 8 July: http://ide.mit.edu/events/2020-mit-platform-strategy-summit> Platform Revolution - Offers an operator's manual for building platforms (easy read)  https://www.amazon.com/Platform-Revolution-Networked-Markets-Transforming/dp/0393354350/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1591806248&sr=1-1> Digital Platforms & Antitrust - Categorizes the harms from platforms, critiques existing solutions, and offers one path forward (easy read).  https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3608397> Pipelines, Platforms & New The Rules of Strategy - Tells how strategy differs from products to platforms (Harvard Business Review "Must Read" - easy read).  https://hbr.org/2016/04/pipelines-platforms-and-the-new-rules-of-strategy> Platform Ecosystems: How Developers Invert the Firm - Provides a proof that platforms become "inverted firms," moving production from inside to outside, once network effects become large enough (MISQ Best Paper - hard read). https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2861574 > The Social Efficiency of Fairness - Provides proof that treating people fairly increases rates of innovation (mimeo - hard read)  https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1514137 Other mentions and references>  Simon Wardley on the Innovate-Leverage-Componentize (ILC) cycle. Part I: https://blog.gardeviance.org/2014/03/understanding-ecosystems-part-i-of-ii.html; Part II: https://blog.gardeviance.org/2015/08/on-platforms-and-ecosystems.html> Simone Cicero, “Long Tails, Aggregators & Infrastructures”: https://stories.platformdesigntoolkit.com/long-tails-aggregators-infrastructures-bdf84e32531d> Avivah Wittenberg-Cox, “5 Economists Redefining… Everything. Oh Yes, And They’re Women”. Mariana Mazzucato on the role of government investment in early innovations: https://www-forbes-com.cdn.ampproject.org/c/s/www.forbes.com/sites/avivahwittenbergcox/2020/05/31/5-economists-redefining-everything--oh-yes-and-theyre-women/amp/ Find out more about the show and the research at Boundaryless at www.platformdesigntoolkit.com/podcast Thanks for the ad-hoc music to Liosound / Walter Mobilio. Find his portfolio here: www.platformdesigntoolkit.com/music Recorded on June 10th 2020

Karen Catlin on Retaining WIT, Jonathan Cutrell on Maintainable, Dr. Aneika L. Simmons on Hanselminutes, Sarah Wells on Engineering Culture by InfoQ, and Dave Thomas and Andy Hunt on Tech Done Right by Table XI. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting September 16, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. KAREN CATLIN ON RETAINING WIT The Retaining WIT podcast featured Karen Catlin with hosts Jossie Haines and Jordanna Kwok. Karen, who is a leadership coach and diversity advocate, got interested in tech when she saw an issue of Money magazine with a cover story about successful women with computer science backgrounds and her father pointed out the connection between a career in software and Karen’s love of crafting, puzzle-solving, and mathematics. She started her career in 1985, which was a peak year for women in Computer Science. In that year, 37% of the Computer Science degrees went to women. It dropped to a low of 17% but has started to go up again in recent years. Karen started a coaching practice because she wanted to help women who wanted to grow their careers and stay in tech. She soon realized that, even if she could be the most amazing coach on the planet, her clients would still be facing an uphill battle because they were working in companies that were not the meritocracies they claimed to be. This led Karen to explore an idea: “Instead of trying to fix the women, let’s start fixing the men.” She says there is a role for every man who is working in tech to create a more inclusive workplace on his work team and at his company. Karen says that mentoring programs are a great opportunity for people to pass on advice to someone who hasn’t had the same amount of experience, but there is a trap: studies have shown that most of us mentor people who remind us of our younger self. Karen’s advice is, if you’re doing mentoring, mentor someone who doesn’t look like you. Don’t have a mini-me protégé. Another piece of advice from Karen is to pay attention in meetings. Look out for interruptions. There is research showing that men interrupt women much more than the reverse and that women who are getting interrupted tend to step back and not participate in the rest of the meeting or future meetings. So, when you see people getting interrupted, say something like, “Jordanna was making a great point. I’d like to hear more about that.” Another thing to watch for is what Karen calls “bro-propriation”: a woman says something in a meeting that falls flat and then, later on in the same meeting, a man says the same thing and gets all the credit. An ally can say something like, “Hey, I see that you agree with the point that May was making earlier.” Discussing hiring, Karen says she used to grab old job descriptions and add new requirements to them, reasoning that all the old requirements are still relevant. She says that you should instead try to get your job description down to just five requirements. Research has shown that women apply for jobs when they have all the skills listed in the job description while men apply even if they have little more than half of the listed skills. Karen also says to have objective criteria to use for every single candidate. Ideally, use the same interview questions. She told a story about moving to Silicon Valley with her partner Tim and applying to work at the same company in the same software engineering role. The two of them had interviews the same day. Driving home at the end of the day, Tim related to Karen that his interviews were among the most difficult he had ever had while her own experience was that the interviews had all been easy. The interviewers had dumbed down the questions when interviewing her. They were both offered jobs, but she decided not to take her offer because the company didn’t respect her enough to ask her the same difficult questions they had asked men applying for the same position. She then spoke about the importance of public speaking in gaining visibility and how it can help with both recruiting in the case of giving external talks and with getting your ideas considered.  Apple Podcasts link: https://podcasts.apple.com/ca/podcast/karen-catlin-on-being-better-allies/id1458996260?i=1000440710563 Website link: https://www.retainingwit.com/karen-catlin JONATHAN CUTRELL ON MAINTAINABLE The Maintainable podcast featured Jonathan Cutrell with host Robby Russell. Jonathan is the host of the Developer Tea podcast and is a senior engineer at Clearbit. Robby asked Jonathan what he thinks are the characteristics of a healthy and maintainable codebase. Jonathan says testing and having a consistent way of testing is critical to maintainability. He also looks at the size of each concept the code expresses to see if it can fit in a person’s head. Robby asked how Jonathan’s teams have achieved consistent testing. Jonathan says that human beings are pretty good at being about 90% consistent, which is almost worse than being 0% consistent. He says to take the load off the human engineer and, for those times when you still need to put the load on them, have a way to proceduralize things such as by having a checklist or template. Robby asked what Jonathan thinks developers often get wrong when they talk about technical debt. Jonathan says that debt is an easy term to throw around because, in the financial sense, it is a very clear concept. Technical debt does not have so clear a definition. You need to evaluate what your team cares about and what has been costly from a business perspective. Some things that we may think are debt are just emotionally difficult to accept: code that we wish was different but isn’t actually causing any real problems or even forecasted to cause problems. One factor that Jonathan thinks should be consistently considered technical debt is code that is staying around but for which you don’t have any kind of validation.  I liked Jonathan’s metaphor for attempting to refactor code that is not under a lot of churn. Picking up code that isn’t changing much and improving its design, he says is like paying off low-interest mortgage debt. There are probably better places to expend our effort. Developers tend to treat decisions around technical debt like one would treat the decision to clean up your house. You have the sense of ownership over your home and, regardless of whether there is risk of future problems, we feel the need to clean things up. They talked about why Jonathan started the Developer Tea podcast. Jonathan wanted a podcast that he could listen to on an afternoon walk for five to ten minutes and learn something new. Most podcasts at the time were much longer and more entertainment-driven, and he wanted something that focused on the more human aspects of the job in a short, inspirational form. He says that the podcast has been one of the most rewarding things he has done in his career. The most rewarding experiences have been when people send him emails about how an episode or series of episodes have shifted the way they think about a topic or even about how they think about their career. They talked about whether there is a correlation between healthy code and healthy teams. Jonathan says there is data around teams in general that says teams that good relationships with their manager and the people they work with have the highest performance and the lowest turnover. These good team dynamics have visible effects on the code. Strong teams, Jonathan says, eradicate fear. These fears are things like fearing that someone is going to judge you poorly when they look at your code. Second, the best teams also know how to come up with the best ideas, which involves one or more team members being able to give up their own idea without attaching a sense of failure to letting that idea go. Third, members of strong teams recognize the humanity of everyone on their team. Robby asked what developers get wrong when evaluating their peers. Jonathan says that people, in general, tend to see everyone around them as inadequate as a way to containerize the rest of the world. This bias helps us to make decisions without being riddled with anxiety about them. The downside of this shows up when we are tasked with evaluating another person. This feeling that everyone else is inadequate combines in a bad way with our natural loss aversion when we try to make sense of things. Most failures are the result of factors that could not be controlled or predicted. With hindsight, when a project is late, we try to think of why it was late and we often come up with a reason, rightly or wrongly. We don’t often come to the conclusion that the project failed because something random happened. As a result, performance reviews tend towards the negative side unless we actively bias away from that. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear/id1459893010?i=1000447238745 Website link: https://maintainable.fm/episodes/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear-LgRTt32R DR. ANEIKA L. SIMMONS ON HANSELMINUTES The Hanselminutes podcast featured Dr. Aneika L. Simmons with host Scott Hanselman. Scott asked Aneika about the talk she gave with her husband Anjuan, “Managing The Burnout Burndown” at the Lead Dev conference: https://www.youtube.com/watch?v=e2dgOfedI3A. She talked about burnout having multiple dimensions including emotional exhaustion and depersonalization. When you are burned out, the people you work with start to lose, in your eyes, their personhood. Scott asked about how having a culture that depersonalized employees, such as by referring to them as “resources”, might lead to burnout. Aneika talked about how having a culture that values the highly-engaged software developer counter-intuitively increases rather than decreases burnout. She talked about managing burnout with the help of your relationships. When Aneika is looking burned out, Anjuan will often say, “Aneika, let’s go for a walk.” She talked about the American notion of the “protestant work ethic” and how the work itself is valued and makes the worker feel important and gives them a sense of meaning. Those that are not working are made to feel like they are not contributing. Scott connected this to how many Americans do not take all of their vacation days. Aneika talked about the difficulty of achieving work-life balance when pleasing your boss means disappointing your family and vice versa and she described how stress is the cause of many illnesses, telling her own story about getting a sore jaw while working on her dissertation because the stress caused her to start grinding her teeth. Aneika suggested building relationships with your boss and your team so that they see you as a person and not just as a contributor. When they see you as a person, they are less likely to attempt to make you feel small when you need to take time for yourself. Here's Aneika on the relationship between engagement and burnout. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/managing-the-burnout-burndown-with-dr-aneika-simmons/id117488860?i=1000447003518 Website link: https://hanselminutes.simplecast.com/episodes/managing-the-burnout-burndown-with-dr-aneika-simmons-1caMsclq SARAH WELLS ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Sarah Wells with host Shane Hastie. Sarah is the technical director of operations and reliability at The Financial Times. When Sarah joined FT in 2011, the company was full of smart people, but they were hampered by a frustrating set of processes. During the last eight years, they adopted a DevOps culture with a focus on automation. When she joined, it took an average of 120 days to provision a new server. They stopped tracking the improvement when they got it down to minutes. They moved from 12 releases a year to many thousand releases a year. This required pushing decision-making down to the individuals making the changes. Shane asked about how to achieve a culture of safety and experimentation. Sarah says it has to come down from the top. You cannot have a CIO or CTO is saying, “What went wrong? Who did this?” You optimize for the speed of release and for speed of fixing. You do incident reviews, but their goal is to improve things for next time, not lay blame. If you drop a database in production as a developer, that is not your fault. The fault is that it is too easy to do that. Shane asked what a culture of experimentation looks like at “the coal face.” Sarah referenced Linda Rising in saying that it is not an experiment if there is not a hypothesis and if it can’t fail. As soon as something costs a certain amount of money, very few organizations are willing to write it off, so if you’re going to experiment, it has to be something cheap and quick. Sarah gave an example of an experiment to test a design change in which they would show the star-rating on the list of film reviews. The thinking was that this would increase engagement. The experiment showed that engagement went down instead because people were less likely to click to see the full review once they had the star-rating. Shane asked about how Sarah limits the blast radius of changes. Sarah says that by releasing small amounts of code frequently and having an architecture like micro-services to keep components extremely decoupled, you are better able to understand the code you are releasing and the change is localized and less likely to affect distant parts of the product. You can also design your website to have graceful degradation when a particular service is not returning results. Shane asked about Sarah’s preference to buy rather than build. Sarah referenced Simon Wardley’s value-chain mapping and establishing the core thing a business does. For FT, the core business is news, so something like doing their own container orchestration is not part of that. Originally, they did their own container orchestration, but once Kubernetes was available, they moved to it. In discussing the sunk cost fallacy, Sarah says you always have to fight to invest in the technical stuff, so you need a good relationship between the tech leads and the product people to explain the benefits of particular technical decisions. You also need to accept that things change and you won’t always get it right. The flip side of moving fast is that sometimes you get it wrong. She related a quote from Jeff Bezos in a letter to shareholders about one-way door and two-way door decisions. For decisions that are likely a one-way door, invest time in getting them right, but for most decisions, you should just decide, commit, and revisit. Shane asked how the listeners who are working on monoliths that release once a month can get to where FT is at today. Sarah says that you need a continuous delivery pipeline so it takes no time at all to get a release out. The second thing is architectural changes. Get to zero-downtime deployments. The cultural aspects are things like process. Reduce anything that requires permission from an external team. It has to be possible for a team to just get going. She referenced Accelerate by Forsgren about the research that says not to have change approval boards. Architects get embedded in the individual teams instead. You want your engineers to be T-shaped, having one specialty but also having some skill in all areas. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/sarah-wells-on-fts-transition-to-devops/id1161431874?i=1000446732957 Website link: https://soundcloud.com/infoq-engineering-culture/sarah-wells-on-fts-transition-to-devops DAVE THOMAS AND ANDY HUNT ON TECH DONE RIGHT The Tech Done Right podcast featured Dave Thomas and Andy Hunt with host Noel Rappin. I realize that this is the third time in as many weeks that I have included a podcast episode featuring Dave and Andy talking about the 20th anniversary of The Pragmatic Programmer, but they keep saying different and interesting things on each podcast they visit that I keep wanting to share it. In this podcast, Dave described what being pragmatic means to him. He says that being pragmatic means doing what works, but nobody knows what works. The cool thing about software, which is also the scary thing about software, is that we are constantly reinventing the entire field. Every project is new: it has new circumstances, new technologies, and new requirements. When you don't know what to do, being pragmatic means exploring as much as you can to find out what works, having in place a system of feedback to tell you whether it is working or not, and taking steps that are reversible so that, if you make a mistake, you can go back and fix it. This, Dave says, is the essence of the book. Noel added a fourth variable, the team, that is different every time, and asked what the pragmatic approach is for how a team works. Dave says that a team is a voluntary collection of individuals. You don’t have a team that you put people into; you start with a group of people and try to turn them into a team. The book dedicates a chapter to teams that echos the previous chapters on individuals because teams need to know all the things that individuals need to know: they need to realize that they are going to make mistakes, they need to figure out when they’ve made a mistake, and they need to know how to fix those mistakes and minimize them in the future. As a programmer, your job is not to write perfect code; your job is to create something that does what the customer wants. If there are bugs along the way, that is not an exception; it just the way it is. The same applies to teams. When teams adopt that approach, they lose the incentive to blame people for things and they take on collective ownership. Andy says that the one thing that is unique to teams is an underlying trust of each other member of the team. You are much better off with relatively small, stable teams. Every time you add someone to or remove someone from a team, it is a new team and you need to start over building relationships, building trust, and learning to work with each other. Noel asked how they would compare The Pragmatic Programmer with the Agile Manifesto since they were involved in the creation of both. Dave suggested thinking of Agile methodologies like XP as a roadmap and The Pragmatic Programmer as your car. Noel said that, in re-reading The Pragmatic Programmer, he was struck by the emphasis on taking small steps and “not getting in front of your headlights”. Andy says that is critical idea because we fall into the trap of taking on too much at once all the time. Small steps, Dave added, also mean you can more easily undo and you are less likely to fall victim to the sunk cost fallacy because your sunk costs are smaller. Noel asked if the way in which developers learn has changed in the last twenty years. In reference to books versus StackOverflow searches and watching videos, Dave made the point that the distinguishing aspect of a book is that the content is curated; putting it together was difficult; it took a long time for the author to organize their thinking to make it clear and approachable and to produce something authoritative and easy to read as a whole. Noel asked Dave about the pragmatic value of automated testing. Dave says that when he gets too comfortable doing something, he tries to stop using it so that he doesn’t get stuck in a rut and so that he doesn’t start to believe something religiously simply because he has been doing it a long time. He had been telling people for years that it is good to test and he had never done the experiment of not testing. He decided not to test for a period and was surprised by the result. He kept an eye on bug rates and it was just as buggy as ever, his productivity went up a little bit, and his designs were just as flexible as before. His explanation is that, having done the requisite ten thousand hours, it is now so ingrained that he doesn’t have to test to get the benefits of testing. He still feels that tests are useful when working with others and as a regression barrier. He sees his experiment with not testing as another example that nothing is sacred: if you’re truly being pragmatic, you should always be experimenting. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-68-pragmatic-programmer-at-20-dave-thomas-andy/id1195695341?i=1000446898661 Website link: https://www.techdoneright.io/68 LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

Have your co-workers gotten on your last nerves? Do you drag yourself into office everyday? Are you drinking one more drink than you would typically would? Well this episode might be for you! This week Steph and Madblkman talk about burnout! Also, we discuss Game of Thrones, HouSecCon, Simon Wardley, and learn about the importance of building a strong support system.If you're not a GoT fan, you can skip from 5:44-12:31.Social MediaTwitter - @coolestnerdpodIG - @coolestnerdsintheroomEmail - coolestnerdsintheroom@gmail.comSteph on Twitter - @StephandSecMadblkman on Twitter - @MadblkmanNotesWhy the fuss about serverless“Discipline” by Larry JuneJob Burnout: How to spot it and take actionStress vs. BurnoutTribe of HackersCareerist Cyber TalkIntro/Outro produced by @chaisnuclear of the Chicken Social

Vi pratar Wardley-kartor. De är döpta efter sin upphovsman Simon Wardley och är ett sätt att kartlägga din produkt och miljön runt den. Kartan hjälper dig och ditt team att fokusera utvecklingen på rätt saker och kan också vara ett sätt att kunna optimera processen utifrån var produkten befinner sig i landskapet. Inzoomningen tillägnar vi enummar och hur de kan användas för att öka läsbarheten av booleaner.För att anmäla er till väg74-konferensen kan ni gå in på denna länk. För att vinna en t-shirt skall ni lista ut vad som står på den. Bild finns här. Några hållpunkter:[5:44 Inzoomningen][11:33 Huvudämnet]21:43 Har ni läst boken "The Secret Sputtify Moves"?30:30 Hur sjutton ser en sån här karta ut då?42:40 Potatisen fryser bort52:13 Ingen behöver väl mer än 650k minne?

What do companies have to keep in mind regarding sustainable business? Our fourteenth episode on The BTN Podcast is with Markus Andrezak, Founder and Managing Partner at uberproduct, on how to respond to the constant need for change in a human manner. He looks at how the constantly changing business world affects the market creating a declining average lifetime for companies today. He then talks about how to create a sustainable business today and discusses what the obstacles for this may be. “In this complex world, it means that you can get killed off by the market. So, the fastest learner wins, and you're not the fastest learner anymore, so you're gone.” DISCLAIMER *Due to the international nature of the interview, which was conducted via Skype, the audio isn't as high-quality as normal, therefore, we apologise in advance for the points at which the audio may drop out.* Links: Markus Andrezak wrote an article to accompany the information in this podcast, which explains the frameworks he discusses in a little more detail, titled "Visual Portfolio Management”: http://www.infoq.com/articles/visual-portfolio-management An introduction to Uberproduct http://ueberproduct.de/ References: Pioneers, Settlers, Town Planners, by Simon Wardley http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html Innovator's Dilemma, Wikipedia: https://upload.wikimedia.org/wikipedia/commons/c/c4/Disruptivetechnology.png Kotter's 8 Accelerators: http://www.managementpro.nl/strategie-bestuur/accelerate/ Additional Reading: John P Kotter "8 Accelerators“ : http://tinyurl.com/odsakw2 Clayton Christensen, "Innovator's Dilemma" / "Innovator's Solution" : http://tinyurl.com/o64veoq http://tinyurl.com/ouyqrwl Geoffrey Moore, "Escape Velocity" :http://tinyurl.com/njr5sj8 Simon Wardley, Blog "Bits or Pieces“ : http://blog.gardeviance.org/ Visit Us: www.thebtn.tv/join Join the Conversation: https://www.linkedin.com/company/the-business-transformation-network/ Follow Us: https://twitter.com/TheBusinessTN

Kein Militär würde ohne Karte losziehen. Keine Schachspieler ohne Brett spielen. Nur im Business versuchen wir Strategien ohne Kenntnis und Darstellung des Umfeldes und der Randbedingungen zu entwickeln. Simon Wardley stellt ein sehr mächtiges Konzept für eine Landkarte für das Business dar. Lassen Sie Sich inspirieren und erwerben Sie ein besseres strategisches Verständnis.

In this episode of The Goat Farm we are in wonderful Copenhagen, Denmark for Kubecon/CloudNativeCon EU 2018 where we sat down with three guests to talk about organizational inertia and overcoming that inertia. First we talk to Simon Wardley. Simon … Continue reading →

Coffee, books, booze, and Buddhists Marginalia and GoodReads (Coté’s list of books there (https://www.goodreads.com/user/show/254939-michael-cot)). Huffduffer: Coté (https://huffduffer.com/cote) & Robert (https://huffduffer.com/robertbrook). Simon Wardley (http://blog.gardeviance.org/). SpringOne Tour (http://springonetour.io/). Open Spaces, the mechanics (https://en.wikipedia.org/wiki/Open_Space_Technology). Usesthis (https://usesthis.com/) - Leonard Lin (https://usesthis.com/interviews/leonard.lin/). Federico Viticci (https://twitter.com/viticci), the Apple Italian guy (https://www.macstories.net/). Coté’s cover model days (https://www.instagram.com/p/BhVKwtWgk_A/?taken-by=bushwald). “I have traveled a good deal in Concord.” (https://www.goodreads.com/quotes/893348-i-have-traveled-a-good-deal-in-concord-and-everywhere) See more detailed show notes elsewhere (https://docs.google.com/document/d/1rGnVlXfLDhgrKq9DJX2EOvAvcOBieBBewN5TXjnfHxs/edit#heading=h.8d7s0um36ny6).

Coffee, books, booze, and Buddhists Marginalia and GoodReads (Coté's list of books there (https://www.goodreads.com/user/show/254939-michael-cot)). Huffduffer: Coté (https://huffduffer.com/cote) & Robert (https://huffduffer.com/robertbrook). Simon Wardley (http://blog.gardeviance.org/). SpringOne Tour (http://springonetour.io/). Open Spaces, the mechanics (https://en.wikipedia.org/wiki/Open_Space_Technology). Usesthis (https://usesthis.com/) - Leonard Lin (https://usesthis.com/interviews/leonard.lin/). Federico Viticci (https://twitter.com/viticci), the Apple Italian guy (https://www.macstories.net/). Coté's cover model days (https://www.instagram.com/p/BhVKwtWgk_A/?taken-by=bushwald). “I have traveled a good deal in Concord.” (https://www.goodreads.com/quotes/893348-i-have-traveled-a-good-deal-in-concord-and-everywhere) See more detailed show notes elsewhere (https://docs.google.com/document/d/1rGnVlXfLDhgrKq9DJX2EOvAvcOBieBBewN5TXjnfHxs/edit#heading=h.8d7s0um36ny6).

“In Australia, I have access to all the Full House episodes.” We finally nail down Amazon’s strategy with serverless (AWS Lambda), and also go over some recent AWS announcements in the security and compliance area. Plus, Cloudflare’s new consumer DNS service, The Man in the High Castle, and Oracle goes after those sweet government cloud contracts. And, Coté gets a little too angry about Google Fiber giving his neighborhood the finger. This episode brought to you by: Datadog! This episode is sponsored by Datadog, a monitoring platform for cloud-scale infrastructure and applications. Built by engineers, for engineers, Datadog provides visibility into more than 200 technologies, including AWS, Chef, and Docker, with built-in metric dashboards and automated alerts. With end-to-end request tracing, Datadog provides visibility into your applications and their underlying infrastructure—all in one place. Sign up for a free trial (https://www.datadoghq.com/ts/tshirt-landingpage/?utm_source=Advertisement&utm_medium=Advertisement&utm_campaign=SoftwareDefinedTalkRead-Tshirt) at www.datadog.com/sdt (http://www.datadog.com/sdt) Datadog wants you to know they provide APM and distributed tracing for Java applications (https://www.datadoghq.com/blog/java-monitoring-apm/). You can try it out by signing up for a trial at www.datadog.com/sdt (http://www.datadog.com/sdt). Relevant to your interests Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service (https://blog.cloudflare.com/announcing-1111/) Auditing - what you do after AD integration. AWS aggregating compliance gunk (https://aws.amazon.com/blogs/aws/aws-config-update-aggregate-compliance-data-across-accounts-regions/). AWS Summit SF: Most definitely not a sales event, nuh uh, no way (https://www.theregister.co.uk/2018/04/04/aws_summit_sf_definitely_not_a_sales_event/) AWS Secrets Manager: Store, Distribute, and Rotate Credentials Securely (https://aws.amazon.com/blogs/aws/aws-secrets-manager-store-distribute-and-rotate-credentials-securely/) AWS Config Rules Update: Aggregate Compliance Data Across Accounts and Regions (https://aws.amazon.com/blogs/aws/aws-config-update-aggregate-compliance-data-across-accounts-regions/) Oracle’s Safra Catz Raises Amazon Contract Fight With Trump (https://www.bloomberg.com/news/articles/2018-04-04/oracle-s-catz-is-said-to-raise-amazon-contract-fight-with-trump) Simon Wardley’s Serverless Tea Bet (https://twitter.com/mattray/status/972218216679333888) Microsoft’s Windows chief departs as the company pushes further toward AI and the cloud (https://www.theverge.com/2018/3/29/17176220/microsoft-windows-reorg-business-terry-myerson-ai-cloud) The End of Windows (https://stratechery.com/2018/the-end-of-windows/) State of DevOps Report now DORA + Google (https://devops-research.com/2018/03/dora-google-cloud-collaboration/) - not doing it with Puppet. Puppet layoffs not related! Zenoss Announces Partnership With Google Cloud (https://www.prnewswire.com/news-releases/zenoss-announces-partnership-with-google-cloud-300624223.html) Apple hires Google’s former AI boss to help improve Siri (https://www.theverge.com/2018/4/3/17195076/google-ai-chief-john-giannandrea-joining-apple-machine-learning-siri) Nonsense The Man in the High Castle (https://en.wikipedia.org/wiki/The_Man_in_the_High_Castle_(TV_series)), which is not really anything like the original book (https://amzn.to/2qa9N9O). 80’s neon in tumblr (https://www.tumblr.com/tagged/80s-neon). Conferences, et. al. April 11th, InnoTech San Antonio (http://www.innotechconferences.com/sanantonio/) - Coté speaking (http://sched.co/Dpzf). April 10-12th, Sydney AWS Summit (https://aws.amazon.com/summits/sydney/). April 26-27, DevOpsDays Jakarta (http://devopsdays.org/events/2018-jakarta/) - Matt (https://twitter.com/agilecircleindo/status/969511498287493120) is keynoting (https://twitter.com/agilecircleindo/status/969511498287493120), and Coté will be speaking too (https://twitter.com/agilecircleindo/status/969511498287493120). May 15th to 18th, 2018 - Coté talking EA at Continuous Lifecycle London (https://continuouslifecycle.london/sessions/the-death-of-enterprise-architecture-defeating-the-devops-microservices-and-cloud-native-assassins/). May 16-17, Matt presenting at Cloud Expo Hong Kong (https://www.cloudexpoasiahk.com/) May 22-25, ChefConf 2018 (https://chefconf.chef.io/), in Chicago. SDT news & hype Check out Software Defined Interviews (http://www.softwaredefinedinterviews.com/), our new podcast. Pretty self-descriptive, plus the #exegesis podcast we’ve been doing, all in one, for free. Keep up with the weekly newsletter (https://us1.campaign-archive.com/home/?u=ce6149b4008d62a08093a4fa6&id=5877922e21). Join us in Slack (http://www.softwaredefinedtalk.com/slack). Buy some t-shirts (https://fsgprints.myshopify.com/collections/software-defined-talk)! DISCOUNT CODE: SDTFSG (20% off) Send your name and address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you a sticker. If you run into Matt he’ll give you one too! Listener Feedback Tim says he really enjoys the show and asks if we send stickers to the U.K.? Damn right, we do and he got one! Email name and mailing address to stickers@softwaredefinedtalk.com and we will send you a sticker. Ray from California thanks us for “ all of the effort that goes into this podcast” an got sticker Ryan got his sticker in mangled envelope but the Postmaster apologized and the sticker was fine ! In-house illustrator for Docker (https://venturebeat.com/2017/01/13/meet-dockers-french-artist-who-spun-her-silicon-valley-misadventures-into-comic-book-glory/). Recommendations Matt: MuseScore (http://musescore.com) for learning piano and writing music Brandon: Developing iOS 11 Apps with Swift (https://itunes.apple.com/us/course/developing-ios-11-apps-with-swift/id1309275316) with course assignments (https://github.com/Scottiiee/cs193p-Fall-2017) Coté: Au Bon Pain in DFW, the little “protein” packs, gate A34.

Aaron and Brian talk about the evolution of Cloud Computing over that past 6+ years - The pace of change, the impact of open source and foundations, the critical elements of public cloud, and what has been a surprise. Show Links: Get a free eBook from O'Reilly media or use promo code PC20CLOUD for a discount - 40% off Print Books and 50% off eBooks and videos [DISCOUNT] Start Serverless Skills Bundle (4 courses) - (only $49 instead of $79) [FREE] Alexa Development for Absolute Beginners Show Notes: Topic 1 - We’re done nearly 7 days of shows (~160hrs), had 30 companies acquired, and over 3M+ listens. Thank you to everyone that listens and tells a friend. Rate the show on iTunes! Topic 2 - Looking back at the last 6+ years, what has surprised you the most or been the most expected? Pace of change? Rise of public cloud? 2011 - AWS at ~$250M/qtr; 2017 - AWS at $3.66B/qtr
 The Clouderati crowd
 OpenStack / Foundations
 Lack of Mega Mergers (“EMC Federation” model?)
 No one really talks IaaS, Paas, SaaS anymore
 All the $1 Billion investments in cloud…
 AWS grew to support Amazon, Google Cloud is spin off and not core to growth
 Kubernetes as the “final architecture” / or is it serverless... Topic 3 - Follow the money - How has VC funding been tracking? What about exits? VC investments in infrastructure have become rare, markets have moved on Lots of money went into big data; now going into AI. Is it paying off? Topic 4 - We’ve both now worked in open source. What impact have you seen this have on the tech industry? Interesting chart from Joseph Jacks about OSS-centric startups Big customers get invested and are vocal about it
 Small customers just want stuff to work and don’t want to hire experts
 Is public cloud the monetization model for OSS? Topic 5 - The divide between those on the cloud bandwagon (e.g. meetups, AWS/Serverless/CNCF events) and those not (e.g. Interop) seems to be growing. The revenues don’t exactly track this, but how do you see the next 3-5 years of the industry playing out for people in the industry? Infrastructure vendors will be squeezed and consolidated
 Public Cloud will give way to the next “Big 3-4”. It was IBM, Cisco, HP, Dell, etc. Now it is AWS, Azure, Google Cloud and SaaS based offerings
 Topic 6- Where are we thinking about going with the show? AI, Business-Centric SaaS Apps, Multi-Cloud realities (or horrors) Topic 7- Let’s end on something boring. There has been some talk about the need to make some element of technology boring (e.g. infrastructure). Do you think that’s possible in the competitive technology markets? We’ve seen on smartphones, virtualization, etc. Simon Wardley - Everything goes to Commodity over time Feedback? Email: show at thecloudcast dot net Twitter: @thecloudcastn

Michael Coté: @cote | cote.io | Pivotal | Software Defined Talk Show Notes: 00:54 - Pivotal 04:39 - Being a Professional Muller aka Analyst 11:08 - Iterative Development 32:54 - Getting a Job as a Professional Muller aka Analyst Resources: Pivotal Cloud Foundry GemFire Greenplum Pivotal Labs Wardley Maps Software Defined Talk Episode #79: From a vegan, clothing optional co-op to working with banks and oil companies - Coté's professional life, part 1 Software Defined Talk Episode #85: Being an analyst without being an asshole - Coté's professional life, part 2 RedMonk Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #66. I am a developer, Charles Lowell at The Frontside and also host-in-training for 65 episodes. This is my 66th and I'm flying alone this week but we do have on the show with us a very special guest. Actually, the person who taught me how to podcast, I think it was about 10 years ago and he was like, "Charles, we should do this podcasting thing." I started my very first podcast with him and I still haven't figured it out. But his name is Michael Coté and he's a fantastic guy and welcome to the show, Coté. MICHAEL: Thanks for having me, Charles. It's great to be here. CHARLES: Now, what are you up to these days? You're over at Pivotal. MICHAEL: That's right. I work at Pivotal and probably people who are in the developing world know them for Spring. We have most of the Spring people. Then we also have this thing Pivotal Cloud Foundry. We're not supposed to call it a platform as a service but for matters of concision, it's a platform as a service that's the runtime that you run your stuff in. Then we also have a bunch of data products like GemFire and Greenplum and things like that. Then, 'openymously', if that's a word, we have Pivotal Labs. Now -- CHARLES: I think, it's eponymously. MICHAEL: Eponymously, yes. Now, you might remember Pivotal Labs as the people who use Chef Scripts to configure their desktops. Remember that? CHARLES: Yeah, I remember that. I was into that. MICHAEL: Yeah, in coincidental kind of way, the inspiration for the project Sputnik thing, which is coincidentally because now Dell Technologies owns Pivotal so all of that stuff has come for a full circle. I guess also since I'm intro-ing myself, I work on what we call the Advocate Team because we don't call them evangelists. No one likes to be called that I guess. I guess there's 12 of us now. We just hired this person, also in Austin actually McNorma who's big in the Go community and apparently can make images of gophers really well. I'm sure she does many other extraordinary things, not just the illustrator master. Everyone else basically like codes or uses the terminal but I do slides. CHARLES: Well, that's your weapon of choice, right? It's a more elegant weapon for civilized time or something like that. I'm going to look it up on Wikia. MICHAEL: Yeah, basically what we do on our team is we just talk about all the stuff Pivotal does and problems that we solve in the way people in an organizations like would think to care about our stuff. Most of what I do is I guess you call it the management consultant type of stuff. Since I have a background as an analyst and I used to work on corporate strategy and M&A at Dell so I have a vantage point in addition to having programmed a long time ago. If you're changing your organization over to be more agile or trying to devops, we would say cloud-native with a hyphen. How do you change your organization over what works and doesn't work? Most people in large organizations, they sort of pat you on your head. I'm sure you encounter this. That sounds really nice that we would be doing all of the good, correct ways of using computers but we're basically terrible and we could never make that happen here. Thanks for talking with us, we're going to go back and stew in our own juices of awfulness. You've got to pluck them out of that self-imposed cannibal pot there in the jungle and show them that they actually can improve and do things well. CHARLES: Would you say you feel like your job is being that person who shakes them away and can be like, "Good God! Get a grip on yourself!" MICHAEL: Sure. That's a very popular second or third slide in a presentation -- the FUD slide, the Fear of Uncertainty and Doubt slide where you're basically like, "Uber!" and then everyone just like soils their pants because they're afraid that are like Airbnb and Uber and [inaudible] and Google is going to come in and, as they say, disrupt their state industry. I try not to use the slides anymore because they're obnoxious. Also, most people in large organizations nowadays, they know all of that and they've already moved to putting on a new pair of pants stage of their strategizing. CHARLES: You've got the kind of the corporate wakeup call aspect of it but then it's also seems like a huge component of your job which is when you were at RedMonk, when you were at 451 and even to a lesser extent, it was Dell who was paid well to just kind of mull it over, like just kind of sit there and asynchronously process the tech industry, kind of like organizational yeast and let it ferment, kind of trying to see where the connections lie and then once you've made that presented, do you think that's fair? That's what sprung to mind when I heard you say like, "Yeah, we just kind of sit around and think about what is Pivotal and what does it do and what's it going," but like how do you get that job of like, "I'm just kind of a professional muller." MICHAEL: That's right. First of all, I think professional muller is accurate, as long as, I guess mulling is also for -- what's that thing you drink at Christmas that you put the little -- CHARLES: Mulled wine. Like low wine. MICHAEL: I can feel like that sometimes late at night. But having a job as an analyst, I was an industry analyst at two places for a total of about eight years or so. Then as you're saying doing strategy at a company, now what I do here, essentially a lot of what you do is very difficult. I know it sounds to people. You just read a lot of the Internet. You just consume a lot of the commentary and the ideas of things that are going out there and you try to understand it and then synthesize to use that cheesy word. Synthesize it into a new form that explains what it is and then finally, the consultant part comes in where you go and meet with people or you proactively think about what people might be asking and they say something like, "What does this mean for me? And how would I apply it to solve my problems?" I guess as an example of that -- I apologize for being a little commercial but these are just the ideas I have in my head -- Ford is a customer of ours and they also have invested in us which is kind of novel. We have GE and Ford invested in Pivotal and Microsoft and Dell Technologies as an interesting mix but anyways, they have this application called the Ford Pass Application. I drive a Ford Focus -- CHARLES: Like Subaru? But you do drive a Ford. MICHAEL: Yeah, because I don't care about cars. It's a bunch of nonsense. I see this app and basically the app, if you have a more advanced one, it might tell you your mileage and even like remotely start your car. But it doesn't really do that much. You have the app and it will tell you information about your car and where to park and it even has this thing where it links to another site to book a dealership thing, which is annoying. CHARLES: Why would you want to book a dealership? To buy another car? MICHAEL: Well because the Ford Focus I have is notorious for having transmission problems so you're like, "I got to go and take it into the dealer to get all this recall stuff taken care of," so wouldn't it be nice... I don't know if you've ever worked with a car dealer but it's not desirable. CHARLES: Yeah, it would be nice if they didn't charge $6000 for everything. MICHAEL: Right. It's a classic system of having a closed market, therefore that jacks up prices and lowers customer service usually. What's the fancy word if there is a negative correlation, if you were to chart it out? Like price is negatively correlated to your satisfaction with it. Kind of like the airline industry, not to bring up a contemporary topic. You pay a lot of money to fly and you're like, "This is one of the worst experiences I've had in my life," whereas you go to the dentist and get a root canal and you're like $20 co-pay. Loving it. [Laughter] MICHAEL: Anyhow, this Ford Pass application doesn't really do very much so what does that mean for what I was explaining. If you go look up and read about it, starting back in the late-90s, your extreme programming and then your Agile Software Development and your devops nowadays, one of the major principles is what you should do is ship often. Maybe you should even ship every week or every day. Don't worry about this gigantic stack of requirements that you have and whatever you should be shipping all the time and then we've trained ourselves to no longer say failing fast. That was a fun cheeky thing back in the late-2000s. CHARLES: Did we trained ourselves not to say that anymore? MICHAEL: I don't hear it very often. CHARLES: Man, I got to go scrub my brain. MICHAEL: Yeah, well this is why you consult with me every 10 years as I tell you the new things. CHARLES: Okay, here we go. We're going to have you on the podcast again. MICHAEL: That's right. You have this idea of like, "We should be releasing weekly," but then if you go to Ford, you're like, "What does that mean?" To shave the shaggy dog here, essentially the idea that they're shipping this mobile application that doesn't really do very much is an embodiment of the idea that they should be shipping more frequently. This may be a stupid example. It's not that it's not going to do very much like permanently but as I have witnessed, very frequently they add new features so Ford is in this cadence but there's this app that instead of working on an application for two years and having everything in it, they're actually releasing it on, I don't know if it's weekly but they're releasing it on a very frequent basis, which allows them to add features. What that gets you is all the advantages of a fast iteration cycle small batch thing where they can study this actually a good feature. They can do all your Lean Startup nonsense. That's a very like weird, perhaps example of how you explain to someone like a large car manufacturer like Ford, this is what devops means for you. Therefore, why you should spend a lot of money on Pivotal? Now that's the part that lets me pay my mortgage every month, the last bit there. CHARLES: Right so Pivotal builds apps. MICHAEL: Well, the Labs people build apps for you. CHARLES: I'm kidding Coté. MICHAEL: Yeah, they actually do. The Labs people are like a boutique of another boutique like ThoughtWorks is kind of a boutique but they're kind of a boutique-y version of ThoughtWorks. That probably is terrible as someone who markets for Pivotal to do that. Do you ever notice how political candidates never really name their opposition? Like you never really want to name your competition but anyways... CHARLES: Pivotal marketing are going to come crashing through your window. Everybody, if we hear them in the next five seconds -- well, I guess you can't call 911 because this is not live. MICHAEL: Yeah, that's true. The Labs people build stuff for you and then the part that I work, in the Pivotal Cloud Foundry people, they have the actual runtime environment, the cloud platform that you would run all that stuff. Plus all the Spring nonsense for your microservices and your Spring Boot. I understand people like that. CHARLES: So good for Ford, for actually being able to experience, either in the development and the joys and the benefits that come with it. But this is actually something that I actually want to talk about independently was as I kind of advance in my career, I find myself pushing back a little bit against that incredibly tight, iterative schedule. Shipping things is fantastic and it's great but I find so much of my job these days is just trying to think out and chart a course for where those iterations will carry you and there is a huge amount of upfront design and upfront thought that it is speculatory but it's very necessary. You need to speculate about what needs to happen. Then you kind of measure against what's actually happening but I feel that kind of upfront design, upfront thought, we had this moment we're like, "We don't need that anymore. Let's throw it all in the garbage." In favor of doing things in these incredibly tight loops and finding where's the clutch point, that kind of long range thinking and long range planning comes and meets with the iterative development. I have no idea. What's the best way for those to match up those long cycles and those short cycles? Where is the clutch play? MICHAEL: I'll give you two and a half, so to speak trains of thoughts on that. One of them is I think -- CHARLES: Two and half trains of thought, I like that. Can we get straight to the half train of thought? MICHAEL: Yeah, I'm going to start with the half, which is just taking all of your questions and putting periods at the end of them before I round up to answering the question. I think a lot of the lore and the learnings you get from the Agile world is basically from consultants and teams of consultants. Necessarily, they are not domain experts in what they're doing so their notion is that we're going to learn about what it is we're doing and we don't actually know we can't predict ahead of time because we're not domain experts so they almost have this attitude of like, "We'll just figure it out on the job." Let's say The Frontside gets hired to go work on a system that allows the Forest Service to figure out which trees to go chop down or not -- CHARLES: If you're the Forest Service, we are available to do that. MICHAEL: I'm guessing you don't have a lot of arborists who have 10 or 20 years of experience working there. CHARLES: No, we don't. MICHAEL: And so you have no idea about that domain so in doing an iterative thing, you won't be able to sit down and predict like everyone knows that when you send the lumberjacks out, they're going to need these five things so we're going to have to put that that feature on there. They need to be able to call in flapjacks when they run out. That's just what's going to happen so you don't know all of these things they need to do so you just can't sit down and cogitate about it ahead of time. Also this comes in from the Lean Startup where there's a small percentage of software that's actually done globally and the notion of a Lean Startup is that when you're doing a startup, you're never going to be determined what your exit is, how you cash out, whether that's building a successful long term company while you get sold to someone or whether you IPO, you're not going to able to predict what that business model is so you just need to start churning and not think a lot ahead of time. Now, the problem becomes, I think that if you are a domain expert, as you can do the inverse of all the jokes I was just making there, you actually can sit down and start to predict things. You're like, "We know we're going to need a flapjack service," so we can predict that out and start to design around that and you can do some upfront thinking. Now similarly, developers often overlook the huge amount of governance and planning that they do for their own tools, which I know you're more cognizant of being older or more experienced, as they like to say. But basically, there's a bunch of, as we used to call it when I did real work and develop stuff, iteration zero work like we're going to need to build a build system, we're going to need a version control. You actually do know all these things you're going to need so there are all the things you can plan out and that's analogous to whatever domain you're working in. Sometimes, at least for your toolchain, it is worth sitting down and planning out what you want. Now, to hold back the people who are going to crash in my window, one of the things you should consider is using Pivotal Cloud Foundry. That's probably something you should cogitate on ahead of time. CHARLES: I think they're going to crash through your window and give you a Martini, if the marketing ninjas are going to do that and if you mention them in a positive light. MICHAEL: You know, it's 10:52 Central but if we were in London, it would probably be an appropriate time so we'll just think about that. Now, on the other hand, you don't want to go too overboard on this pre-planning. I'll give you an example from a large health insurance company that I was talking with recently. They had this mobile app -- it's always a mobile app -- that had been languishing for 15 months and it really wasn't doing anything very interesting. It was just not working well and they could never release it. This is a classic example of like, "We took a long time to release a mobile app and then we never released it again and then it blows." It's not achieving all of the business goals that we wanted. Mostly, what a health insurance company -- I've talked with a lot of the health insurance companies -- want with their mobile app is at least two things and probably many more but these would be the top of the list. One, they want their customers, their users to look up what their health insurance is, figure out doctors they can go to, the basic functioning that you expect from your health insurance company. And two, they want to encourage their customers to do healthy behaviors because if you think about it as a health insurance company, health insurance in my mind is basically like this weird gamble of like, "I'm gambling on the fact that you are going to be healthy," because then I pay out less to you and you just give me money so the healthier that your users can be, the more profit you're going to make. That's why they're always trying to encourage you to be healthy and stuff like that. The mobile app was not achieving, at least these two, if not other business goals they have. They basically were rebooting the effort. The way they started off is they had -- I don't know how many inches thick it was -- a big, old stack of requirements and the first few iterations, the product team was working on it and talking with the business analyst about this and going over it and what they sort of, as we were calling Pivotal Labs the product owner but the person who runs the team, realize is like -- to cut a long story short -- "This is kind of a waste of time. We shouldn't just prioritize these 300 features and put them in some back road and execute on them because these are the same features that we based the more abundant application on, we should probably just start releasing up the application," kind of like the FordPass app. That said, they did have a bunch of domain experience so they had a notion of basically what this app was going to do and they could start planning it out but they figured out a good balance of not paying attention to, as Martin Fowler used to call it the almighty thud, of all the requirements. What they ended up doing is they basically -- CHARLES: What's the almighty thud? MICHAEL: You know, he's got some bleaky or whatever. It's basically like we started a project and I think it's from 2004 and someone FedExed me about 600 pages of an MRD or whatever and I put it down on my table and it made a loud noise so he calls that the 'almighty thud', when you get this gigantic upfront requirement thing. What happened in this health insurance thing is they stopped listening and talking with those people and they kind of like chaff them out, not like when your rub your legs together but they kind of distracted them to that fact but eventually, they just got them out of the cycle and they started working on the app. Then lo and behold, they shipped it and things are working out better now. CHARLES: Hearing what you're saying and kind of thinking it over, I think if you're going to have an almighty thud, what you really want is you want all that upfront research and all that upfront requirements gathering or whatever, not necessarily to take the form of a set of features or some backlog of 300 things that the app 'needs' to do or 'should' do but just a catalogue of the problems, like a roadmap of the problems. MICHAEL: Exactly. CHARLES: You know, that actually is very valuable. If it's like, "These are things that are true about our users and these are the obstacles that they face. If we do choose that we want to go from Point A to Point B, where we are at Point A, then we actually have a map of what are the things that are sitting in front of that and what are the risks involved." It's like if you got -- you played, you're from my generation, you play the Oregon Trail, right? MICHAEL: Yeah. "You have dysentery." CHARLES: Right. I don't know where I'm going with this analogy but my point is developing that app is like going from Kansas City to Portland. But the thing about software is you don't necessarily have your corn meal. You don't need to say like, "We're going to need six pounds of cornmeal and we're going to need these wagons and we're going to need these mules," because this is software and you can just code a mule if you need it. But you might not need a mule, if the rivers are not in flood... I don't know. Like I said, I don't know where I'm going with this analogy. But do you see what I'm saying? The point I'm trying to make is that having the map of the Rockies and where the passes are is going to help you. MICHAEL: Yeah, this is probably where I'm supposed to expertly rattle off what Wardley maps are and how they help, which is fine. I think that's a great tool. There's this guy Simon Wardley and he's actually a great contemporary philosophizer on IT-led strategy. I think he works for CSC who no longer owns mercenaries but they used to -- Computer Science Corporations. I think they own a little bit of HP Services Division but he works for some think tank associated with CSC and he has got a couple of OSCON talks on it, where it's called a Wardley map and it's a way that you start figuring out what you're saying, which is to say your company's strategy. Using your front metaphor of the era of tall hats, if you remember that other movie, if you're on the Oregon Trail, broadly your strategy is -- and people get all up in your face about the difference between a plan and a strategy and we'll just put mute on them and edit them out of the audio because they're very annoying -- CHARLES: We'll call it an approach. MICHAEL: That's right. Your plan or your strategy -- and pardon me if I use these phrase free and loosely and everything -- is you would like to get to Oregon and you would like to live there and maybe grow apples or start a mustache wax company or some donuts, whatever it is you do out there once you get to Oregon and their strategy is -- what are the assets that I have. I have a family, I have some money and I also know some people who are going there so I'm going to buy a stagecoach and a mule, then I'm going to kind of wangle it out and we're going to go over there. Also, part of our strategy is we're going to go through the northern pass because we're used to winter versus the southern pass, which isn't the Oregon Trail because reasons. Maybe Texas isn't part of The Union yet so I don't want to deal with the transition between whatever that weird Texas thing down there -- CHARLES: The desert, there's the southwest and the desert. MICHAEL: I don't have the capabilities to survive in a desert so I need to go to the north and hopefully I won't be like that movie and have a grizzly bear rip up my backside and everything. You sort of put together this plan. Now going back to what you would do in IT world is to your point, someone does need to define what we would call the business value or the strategy, like what you want to do. Looking at the Ford thing, what Ford wants to do is they do cogitating thing ahead of time and they're like, "We manufacture cars," and you've got electric cars and Uber. That's where the scarce light comes in. In the future, who knows that people will still buy cars? It might be like that I-Robot movie where all the cars are automated and you just go into one. As a company, whose responsibility is to be as immortal as possible, we need to start making plans about how we can survive if individuals no longer buy cars. Let's do that. This is a huge upfront notion that you would have and then that does trickle down into things like my Ford thing -- I'm kind of speaking on their behalf -- if we have a direct connection with people, maybe eventually we introduce an Uber-like service. You can just check-out a Ford car. Then maybe this and maybe that. It's the strategy of how do we set ourselves up to do that. Now, I think the Agile people, what they would go for is it's really good to have that upfront strategy and you'll notice that in a lot of lean manufacturing in Agile talk, no one ever talks about this stuff, much to my extreme annoyance. They don't ever talk about who defines the strategy and who defines that you're working on this project. That's sort of left as an exercise to the reader. The Agile people would say like, "The implementation details of that are best left to the development team in an Agile model." Just like the developers are always arrogantly are like, "Hey, product manager. How about you f-off about how I should implement this? I am the expert here and let me decide how I'm going to implement the feature that you want for me." It's kind of like that rushing dolling down of things. To the development team, you worked on some, what was it? Band frame wire thing, a long time ago? It was basically like, "We don't know it. Maybe this is not the case. Let's pretend like it was." We don't know exactly how you're going to implement this stuff but our goal is that there's bands and they need sides and ways of interacting with their users so let's just figure out what that looks like but they had that upfront idea of ways that they were doing things. CHARLES: Let's start walking. MICHAEL: To add on some more. There's another edge case that you're making me think of, which is a good way of thinking through almighty thuds versus how much planning you have and that's government work. Government work that's done by contractors and especially, military contracting work. What you notice in government work is they have, seemingly way too much paperwork and process. They literally will have project managers for project managers and the project managers have to update how the project is going and they reports. If they don't do the reports correctly, their contract is penalize and you might even get fired for doing it. If anyone stops and says while the software is working, they were like, "No, no, no. don't be naive. It doesn't matter if the software is working or not, if we don't fill up the project report, we're fired." Until someone like yourself or me, it's just like your head explodes and you're like, "But working software, not a concern." In that case, it actually is part of the feature set, part of the deliverable is this nauseating amount of project reporting and upfront requirements, which has this trickle-down effect of annoyance but that's what you're getting paid for so that's what you do and if you want to make yourself feel better about it. I don't know how it is in the rest of the world but in the US, basically we think the only person worse than maybe, Lucifer is the government. I don't know why this comes about. We enjoy the fruits of the government all the time but for some reason, we just think they're awful. Whenever we give money over the government, we want to make sure that they're spending it well and if they're not corrupt and they don't hire their entire family to help them run the government and make sure that they're making extra money globally in their businesses, I wouldn't know anything about that. But essentially, you want to make sure there's no corruption so transparency is almost more important than working software. The way you achieve that transparency is with all this crazy documentation. CHARLES: Here's the thing. I agree the transparency is fantastic but nothing is more transparent than working software. Nothing is more transparent than monitored software. Nothing is more transparent than software whose, by its very nature is radiating information about itself. You can fudge a report but you can't fudge a million happy users. MICHAEL: Don't get me wrong. I'm not saying that the way that things currently operate is the ideal state. I'm saying that that desire for transparency has to be addressed and for example, using your example, let's say you were delivering working software but you were also skimming 20% off the top into some Swiss bank account -- you're basically embezzling -- and then it turns out that you need 500 developers but you only actually had 30 developers. There was corruption. The means even though the ends, even though the outcome was awesome, the means was corrupt so that's the thing in a lot of government work that you want to protect against. I just bring that up as an edge case so a principle to draw from that, when it comes to almighty thudding is like sometimes, that is part of the deliverable. We would aspire in our fail, fast, Agile world to not have a bunch of gratuitous documentation as part of the deliverable because it seems like a waste. It would be like every morning when you battle with your kids to get their shoes on, you had to write a two-page report about how you're getting ready to go to school stuff with your kids was going. As a parent you would be like, "I don't need that." However, maybe if you were like an abusive parent and it was required for you to fill out a daily status report for you to retain the parentship of your kids, maybe it would be worth of your time to fill out your daily status report. That was an awfully depressing example there. CHARLES: Let's go back to the Oregon Trail. What I'm hearing is that -- and we will take it back to the Oregon Trail -- you also need to consider, as were saying, you have some sort of strategy which is we want to go sell apples and moustache wax. But what we're going to do is we're just going to start walking, even though we don't have a map. But obviously, if you send out scouting missions, like you know where you're going, you know the West Coast is out there somewhere, you start walking but the stakes determine how much of your resources you spend on scouting and map drawing -- MICHAEL: Yeah. My way of thinking about strategy and again, people strategy is this overloaded word. But my way of thinking about strategy is you establish a goal: I would like to go to the West Coast. Now, how you figure that out could be a strategy on its own, like how did you figure out you want to go to the West Coast. But somehow, you've got to get to a prime mover. Maybe those tall hat people keep beating me up so I want to go to the West Coast. I want to go the West Coast is the prime mover. There's nothing before that. Then you've got to deal in a series of constraints. What capabilities do I have, which is another way of saying, what do I not have? And what's my current situation and context? On the Oregon Trail thing, you might be like, "I have a family of seven. I can't just get a horse and go buy a pack of cigarettes and never show up again." I guess I could do that. That's probably popular but I, as an individual have to take this family of six other people. Do I have the capabilities to do that? How could I get the cash for it? Because I need to defend against all the madness out there, I'm going to need to find some people to meet with. You're thinking and scenario planning out all of this stuff and this gets to your point of like, "If you're going to Oregon, it probably is a good idea to plan things out." You don't want to just like the next day, just figure it out. [inaudible] tell a joke. It's like, "Why do they sell luggage at the airport? Is anyone is just like, 'Screw it. Pack a clothes and we'll sort it out at the airport.'" It's an odd thing to sell at the airport. But you do some planning and you figure out ahead of time. Now, to continue the sort of pedantry of this metaphor, the other characteristic of going to the Oregon Trail, unless you're the first 10 people to do it is hundreds, if not thousands of people have done it already so you kind of know what it's going to be like. It's the equivalent, in a piece of software, if they were like, "This application is written in COBOL. I want you to now write it in --" I don't know, what are the kids do nowadays? Something.io? I-want-you-to-write-this-in-a-hot-new-language.io and basically just duplicate it. You're going to still have to discover how to do things and solve problems but if the job is just one-to-one duplicate something, then you can do a lot more upfront planning for it. CHARLES: While you're doing it, making the Uber and Airbnb. MICHAEL: Yes. CHARLES: Then you're done. MICHAEL: I think that's the truth and I want to put it another way. We used to be down here in Texas, the way we run government here is just lovely but we used to have this notion of a zero-budget, which is basically like, "Assume I'm going to give you nothing and justify every penny that I'm going to give you." I think that's a good way to think about defaults. I mean, about requirements is default is you don't need any and only get as many requirements as you need. If you're building tanks or going to the Oregon Trail, you might need a lot of requirements upfront that are actually helpful. CHARLES: But like a suit, you're just going to just strike out naked walking with. MICHAEL: That's probably a bad idea unless you -- CHARLES: Yeah, that is a bad idea but that's the bar but what happened if I were to do that? I might make it for 20 miles. MICHAEL: And build up from there and then have all the requirements that you need. I'm sure when Lewis and Clark went they were like, "We're going to need a quill and some paper and maybe a canoe and probably some guns and then let's see what happens." But that was a whole different situation than going to establish Portland. CHARLES: That was an ultimate Agile move. That was a pretty Agile project. They needed boats, they built them but they didn't leave St Louis carrying boats. MICHAEL: Right and they also didn't have a family of six that they needed to support and all this kind of stuff, right? CHARLES: Uhm-mm. MICHAEL: There was a question you asked a long time ago, not to steal the emceeing for you -- CHARLES: I would say, we need to get onto our topic -- MICHAEL: Oh, yeah. Well, maybe this is a good saying, what you're asking is, "How do you get this job?" and I don't think we ever addressed that. CHARLES: Yeah, that's a great question. You said you had to consume a lot of stuff on the internet. MICHAEL: Right. That's definitely how I do the job but I think how I get the job, there's an extended two-part interview with me on my Software Defined Talk Podcast Episode, available at SoftwareDefinedTalk.com, where I talk about my history of becoming an analyst and things like that but the way it happened is I don't have any visible hobbies, as you know Charles except reading the stuff in the Techworld. I would read about what's happening in the Techworld and would blog about it back in 2004, 2005 and I was discovered as it were by the people at RedMonk. I remember for some reason, I wrote some lengthy opinion piece about a release of Lotus Notes. I don't know why but that was a good example. This is back when all of the programming job were going to be off shored and I thought it was imminent that I was going to lose my job. I was looking for a job and I shifted over to being an analyst. That like the way that you get into this kind of business is you establish, there's two ways -- CHARLES: You established expertise, right? MICHAEL: Yeah, which is like always an unhelpful answer because it's sort of like, I was joking about this in another podcast, it's like Seth Godin's advice about doing good marketing, which is the way you do good marketing is you have an excellent product. If you have an excellent product that everyone wants to buy, then your marketing will take care of itself. I think if I'm asking how to market, I'm trying to figure out how to market a bad product. That's really what people want. CHARLES: That's also just not true. That's just like flat ass not true. That's a lie. MICHAEL: I mean, people who want to know how to diet better are not already healthy and dieting successful. You can't start with the base assumption of things are going well. CHARLES: Well, it is true. I like to think that we have an excellent product. We sell an excellent product but the thing is you can just sit on your excellent product all day and you have to tell people about it. If you want them to come sample it and try, maybe eventually buy it like the advice that you just need an excellent product. I'm amazed at anyone who can actually can say that with a straight face. MICHAEL: Well, he only writes like 150-word blogpost. I think his point is that you should aspire to have a unique situation and then marketing is easier. Similar with everyone's favorite example like an Apple or like a Pivotal or a ThoughtWorks. We eat all three of us and yourself as well, once someone gives you the benefit of the doubt of listening, you can explain why what you have is not available anywhere else. CHARLES: What it boils down to is if you want to easily differentiate, allow people to differentiate your products from others, then be different. That's fair. I'll give -- MICHAEL: To summarize it, it begets more of the tactics of how one gets a job like I do. What's the name of the short guy in Game of Thrones? 'Tyrian'? 'Tyran'? 'Tyron'? CHARLES: Tyrion. MICHAEL: At one point, Tyrion is like, "I do two things. I know things and I drink," so that's how you get into this type of business as you establish yourself as an expert and you know things. Now, the third thing which I guess Tyrion was not always required to do is you have to be able to communicate in pretty much all forms. You need to be good at written communication, at verbal communication, at PowerPoint communication, whatever all the mediums are. Just knowing something is not very useful. You also have to tell people these things. CHARLES: I think Tyrion is pretty good at that. MICHAEL: Yeah, that's true but he doesn't ever write anything. There is no Twitter or things like that. CHARLES: I feel like [inaudible] been a pretty big deal in the blogosphere. MICHAEL: Sure, no doubt. The metaphor kind of breaks down because the lattice for the continuing counterarguments do not exist in the Game of Thrones universe but whatever. CHARLES: They've got the ravens. That's like Twitter and it's bird. MICHAEL: That is true. Knowing how to deploy a raven at the right time, with the right message is valuable. CHARLES: We buffer up our ravens so that they fly right at eleven o'clock. MICHAEL: That's true. I could be convinced otherwise. CHARLES: That's why they arrived both at 6PM in the Westeros -- MICHAEL: I guess true to the metaphor of a tweet, most of the communications in Game of Thrones is either, what are they called? Little Birds? That the [inaudible] always has and then the Big Birds. You've got to tweets and the blogs. CHARLES: This is like it's nothing but Twitter. MICHAEL: Exactly. You got to really communicate across mediums. Now that the other thing that's helpful and you don't necessarily have to do this but this is what I think gets you into the larger margin. The more profitable parts of the work that I do is you have to be able to consult with people and give them advice and consulting is largely about, first figuring out the right opportunity to tell them how they can improve, which usually is it's good if they ask you first. I don't know about you but I've found that if you just pro-offer advice, especially with your spouse, you're basically told that you're a jerk. CHARLES: Well, it'd be like a personal trainer and walking around me like, "Hey man. Your muscle tone is kind of flabby. You got to really work on that." MICHAEL: The line between a good consultant and being overly-explain-y is difficult to discern but it's something that you have to master. Now, the other way you consult with people is you study them and understand what their problems are and you're sympathetic to them and I guess you can be like a British nanny and just scold them. That's a certain subset of consulting. CHARLES: Don Rickles of consulting? MICHAEL: That's right. You just help them understand how all of this knowledge that you have applies to them and hope solve their problems like the FordPass thing. When I went from being a developer to an analyst, it was a big risk to take on. I think I probably took like a $30,000 pay cut and I went from a big company health insurance to being on a $10.99 and buying your own health insurance which a whole other conversation. We talked about that every now and then but like it's a risky affair. It's not a promotion or even a lateral move. It's just an entirely different career that you go into. Then you talk with people a lot. As an analyst, you're constantly having to sort out the biases that you have with vendors who want to pay you to save things versus end-users who want to hear the truth. You can't really see a lot of Gartner and Forrester work but the work that you can see publicly from people like RedMonk, it's pretty straightforward. CHARLES: Yeah it is and whatever they did, a piece that was for one of their clients, there was always a big fat disclaimer. MICHAEL: Now, the other thing I would say is what I've noticed -- not to be all navel-gazing -- about myself and other people who are successful at whatever it is I do is there's two things. One, they constantly are putting themselves out there. I remember and this is probably still the case. This is probably all in Medium. There's probably a Medium post every quarter that's like, "If you're a developer, how do you give more talks. What your first conference talk?" Basically, the chief advice in there, other than bring business cards and rehearse is essentially like you just got to get over that idea of self-promotion. You basically have to self-promote yourself incessantly and do all those things that you find nauseous and be like, "Me, me, me," which is true. You've got to get over that thing. If you're like me and you're an introvert who actually doesn't really like that many people, except a handful of people like yourself that I'm friends or family with, you have to put on the mask of an extrovert and go out there and do all this extrovert stuff or you'll fail. I shouldn't say you'll fail, you won't increase your overall comp and margin and everything. You'll basically bottom out at about $120,000 a year or so because that's about as much as anyone will pay for someone who just write stuff but doesn't actually engage in the world and consult. You've got to do that. Then the other consequence of that is you always have to be trying out new types of content and mediums like here we are in a podcast. Long ago, you and I, in 2005 or 2004 -- CHARLES: You got me to sign up for Twitter. MICHAEL: Yeah, like we started off a podcast because I remember hearing the IT conversation stuff and John [inaudible], who is a big inspiration for me, a role model, I remember he was just trying out podcast and I was like, "All right. I'll try that out. That looks like fun," and then here we are. CHARLES: I remember you tried out the podcast and you're like, "Let's go into your backyard or my backyard. Let's talk about software for 15 minutes." I remember that very clearly and that was 12 years ago. Then I remember also like with Twitter, you're like, "Now, you should sign up for this Twitter thing," and I remember I did and that's when it was still coming through SMS on your phone and like "I'm walking around Teatown Lake. I'm going to get tea." And I was like, "Oh, my God. This is so fucking stupid." But little did I know, you were actually signed me up to a service that changed my life. MICHAEL: Yeah, it was the stage direction era of Web 2.0 where you're just supposed to give people your status updates, instead of your searing insights. But yeah, you've tried it all these different mediums because again it goes back to your job is to communicate. You need to tell people things that you know. CHARLES: Coté, what is your strategy on virtual reality? MICHAEL: My strategy in virtual reality. Well, you've caught me, Charles because I'm not into that. You remember when Time Magazine had that Chinese lady who was like a... Not Frontside. What was the name of the big virtual reality thing that was big...? CHARLES: Second Life. MICHAEL: Second Life, who is a Second Life millionaire. CHARLES: Yeah, she had armies of people. She was mining some resource in Second Life and then reselling it and she made a lot of money. MICHAEL: I don't really like visual mediums so as Marshall McLuhan would say 'hot mediums'. I guess I like the cool mediums. That's not my thing. That's where my principle fails. Maybe I'll do that one day. CHARLES: This is pretty hot. This medium is pretty like -- MICHAEL: I think maybe audio broadcast is hot. I'm just pretending like I know. This is another trick that you can deploy that my wife has picked on is most of the time, 78% of the time, I actually have no idea what I'm talking about. I just know words. I don't actually know Marshall McLuhan theory. I read that one book a long time ago and I remember that scene in Annie Hall where he gives a little diatribe to whatever the Woody Allen character is. That's the extent of my Marshall McLuhan knowledge. CHARLES: Was Marshall McLuhan actually in Annie Hall? MICHAEL: He was. CHARLES: Don't sell yourself short, Coté. MICHAEL: Sure. CHARLES: You know things and you drink so let's talk about that second aspect because I know that you like me whole tearing up as a role model. MICHAEL: I should say since we're both happily married, except for the third thing that he does which he -- CHARLES: Oh, right. MICHAEL: Another unmentionable word. He too freely hangs out with the ladies. CHARLES: Right, anyway aside from that, throughout doing all this stuff, you keep a very, very chill perspective on things. I feel like the tech world gets so wound up around itself and it gets so tight and so stressed about its own problems. There's constantly wars in JavaScript and before we were in the JavaScript world, we were warring in Ruby. I remember when Twitter went over to using Scala instead of Ruby. Oh, my goodness, it was terrible times. I feel like there's a lot of stress and yes, you want to take it seriously but I feel like you've always been able to maintain an even-keeled perspective about technology which actually allows you to commentate on it effectively and intelligently because you're able to unwind yourself from the squabbles of the day and see maybe a bigger picture or something like that. MICHAEL: That's nice of you to characterize me to use a -- is that a hanging, dangling participle there, when you're in [inaudible]? CHARLES: Yeah, I don't know. MICHAEL: I think that's also just a function of being old. CHARLES: So are you actually not stressed or is it just part of your persona of being an extrovert or something like that? MICHAEL: About the tech world? No, I'm not stressed about that. As you kind of outlined, especially I was not sent the demographics for the show, which is fine. I'll overlook that but I'm guessing that that was a joke. CHARLES: Who got some designers, developers -- MICHAEL: I'm guessing there's a lot of people who actually are on the frontlines of working on software. I think this happens also in the white collar set. But essentially, it's really easy to slip into over allegiance to something and I don't know what rhetorical fallacy this is but it's the bias of over allegiance to something, you get all wrapped up in defending a tool over something and the virtue of it, whether it's Emacs and vi. I'm sure reactive people, whatever that is, have all sorts of debates. The thing is when you're heads down on this stuff, you don't realize how petty all those discussions are. It's not so much that it's a waste of your time but it's just one battle in an overall war that you have. It's good to have opinions and figure things out but you should just relax about it because the more angry and emotional you get, you're going to make a lot of mistakes and decision and problems. I wish I had an example of this but this is one of those things that intuitively as you ages as developer, it's not like your literal age. It's just the amount of time you've been developing software. You could be a 25-year old who's been developing software for 10 years and you would probably get this notion but you just realize that stuff changes and you just learn the new things. It's kind of not a big deal like one day, you're going on and on about how vi is great and the next day you're using that Atom editor and then whatever and you just use the tool that's appropriate and it's annoying when you're younger and people are applying Hacker News with like, "You should use the tool that is appropriate," which is a stupid reply. That's just kind of how it is. Also the other thing, in the more white collar world, as an analyst, especially doing strategy for a company, you can't be biased by things because then you'll make poor decisions as an analyst. Also when you're doing strategy in M&A that result in bad business outcomes so you actually be very unbiased about things. CHARLES: I think it applies in everything. If you get too emotionally invested in one particular approach in software, literally in anything you do, it does result in bad outcomes. The problem is you may not actually realize the consequences of those bad outcomes far down the road from the poor decision that you made that caused you that outcome so you might not necessarily connect it back. MICHAEL: Yeah, and I keep bringing this up but I think another effect of being calmer in your nerd life is having something that you do outside of your programming life, which is either having a family or having hobbies or something like that but you know -- CHARLES: Or having a wild turkey. MICHAEL: Yeah but you've got to have something, a reason to stop thinking about your tech stuff or it'll consume you. I suspect when you see the older graybeards who go on and on about open source and they're very like... I don't know. What's the word? They're very over the top and fervent about tech stuff. It's probably because like me, that's their only hobby and they haven't figured out how to how to control it. It becomes part of their identity and it defines them and then they're down this twisty, turny path of annoyance to the rest of us. CHARLES: Again, don't sell yourself short, Coté. You've got plenty: you love the cooking and eating and the drinking so close this. Do you have a favorite drink that you've been mixing lately? MICHAEL: No. CHARLES: Or any kind of favorite food because every time I go over to your house, even if we're having pizza, there's always a nice hors d'oeuvre or something to drink, something to tweak that appetite for something special. I kind of wondering if there's anything that you're into. MICHAEL: I have some very basics. One, I don't know if I drink a lot or drink a little. I think the science on this is very confusing, kind of like drinking coffee. I try to drink less. I basically go back to the basics of I want cheap wine that's not terrible. That's what I'm always trying to discover. I think I've also started to rediscover just straight vodka. That's pretty good. I think that fits into the grand scheme. CHARLES: I just can't do it. I can't follow you there. I need some, what do they call them? Gin florals? I can drink gin -- MICHAEL: Oh yeah, that's good too. CHARLES: That's about as close as I can get to straight vodka. MICHAEL: And then food-wise, I just wrapped up finally figuring out how to cook fish and chicken without it tasting terrible. CHARLES: Oh! What's the secret? MICHAEL: No, I want to put a disclaimer out. There's a EULA on this. I'm not responsible for anything bad that happens but what you want to do is cook at about 10 degrees less than you're supposed to. A chicken is supposed to be 165 degrees but you take it out of the pot when it's like 150 or 155 on another part of the pan. Fish is supposed to be 145 degrees but you take it off when it's about 130 or 135. It cooks a little bit more but these guidelines to cook your meat to that thing, it ruins it. Also you can brine a chicken and things like that. Also, what you want to get is an instant meat thermometer. One of those that you can just poke in your meat so you're always checking the temperature. That's what I've been working on. CHARLES: I have a theory about that. I will laid out really quickly, maybe it's just because the juices. It's the juice that so yummy there so you want those to be locked in and boiling but not boiled away. I'm going to give that a try on my -- MICHAEL: And fish is particularly tricky. CHARLES: Because all it takes is five minutes. Sometimes, it's two minutes and 30 seconds too long and you ruin the fish. MICHAEL: Then the next theory I want to try out is that you can actually fry fish in pure butter but you've got to paper towel it off afterwards because too much butter ruins it. But I think if your paper tower it off like you do grease off of bacon, then I think that's how you achieve -- not as good as a restaurant because in a restaurant, they have those butane torches and the crisp it up on the outside or reverse sear or whatever -- CHARLES: Is that what they do? Do they just run their torch right over the fish? MICHAEL: That's all I can figure. They might also be professional cooks who know how to cook things. CHARLES: They might have done it a lot of times. They might have had someone like Gordon Ramsay yelling at them constantly. "I can't believe this fish is so terrible. Waah!" All right. I'm going to give the fish a try. I'm going to give the chicken a try and I'm going to give everything that you just spent the last hour talking about, also a try. MICHAEL: Well, thanks for having me on. It's always fun to have a show with you. I just posted yesterday our second revival of the Drunken Retired Podcast, which is over at Cote.show. It's just '.show'. URLs are crazy nowadays. I guess the only self-promotional thing I have is I'm over in Twitter @Cote. It'd be nice if everyone should just go follow me there because I'm always very sad that I don't have enough followers and they'll never verify me. I don't understand what the problem is. I'm clearly me. Then I mentioned earlier, the main podcast that I do is Software Defined Talk, which is at SoftwareDefinedTalk.com and you should come spend a lot of money on Pivotal stuff. I'm happy to tell you all about that. Just go check out Pivotal at Pivotal.io CHARLES: I guess that is about it. We will talk to everybody later. Thank you for staying tuned and listening to this supersized episode. Come check us out sometime!

On this episode I’m interviewing Simon Wardley and we’re talking about Wardley maps, which are Simon’s method for co-creating strategy with visual and context-specific maps.

Summary Alec Lazarescu, CTO of LearnBop tells me how to introduce and expand DevOps inside your organization. Details Who he is, what Learnbop does, how tutoring works; how Alec defines DevOps; how to introduce DevOps, lone consultant, re-branded admin team, dedicated team; why is software dev so messy; getting people to accept change, Conway's law, DevOps is about more than just dev; DevOps as facilitators; the role of microservices, harder in a big org; Simon Wardley - pioneers settlers and town planners; Spotify - squads, chapters, guilds, where do

Brian talks to Joel Davne (@woggenager, CEO of @cloudnexa) and MJ DiBerardino (CTO @cloudnexa) about the evolution of System Integrators, the evolving AWS ecosystem, Cloud Management -as-a-Service, and what types of applications customers are using with AWS. Interested in the O'Reilly OSCON? Want a chance at a free pass for OSCON? Send us your interesting journey in Open Source to show@thecloudcast.net by Friday July 10th and we'll pick a winner! Want to register for OSCON now? Use promo code 20CLOUD for 20% off Check out the OSCON Schedule Free eBook from O'Reilly Media for Cloudcast Listeners! Check out an excerpt from the upcoming Docker Cookbook Links from the show: Cloudnexa Website Cloudnexa Automates AWS Provisioning with vNOC Cloudnexa on theCUBE at AWS:reInvent Topic 1 - Welcome to the show. Tell us about your backgrounds and introduce the audience to Cloudnexa. Topic 2 - As public cloud was becoming more mainstream, a lot of people were saying that systems integrators (and maybe hosting providers) would go away. Talk about why you call Cloudnexa a “born in the cloud” company, and why your business models and technology are different than more traditional VAR/SI/Hosting models. Topic 3 - Aaron and I are big fans of Simon Wardley, who often talks about AWS having an advantage because they not only learn from their customers, but also from the AWS ecosystem. What are you learning from the AWS marketplace that the mainstream media isn’t discussing? Topic 4 - Let’s talk about vNOC. I’ve been saying for a while that Management-as-a-Service is hugely important, because too many companies can’t figure out how to operate a cloud - and most really shouldn’t be (costly, slow learning curve, wrong skills). Topic 5 - Whenever I read about Cloudnexa or hear you speak, the words “customer value” constantly come out. That goes from the service you offer to pricing models to migrations. Talk about how you think about that in this on-demand world. Topic 6 - The AWS ecosystem is very powerful and diverse - we’ve had many of the companies on the show. You do some unique things in how you partner with other AWS ecosystem companies. Give us some input about what that means from both a technical perspective and business perspective.

John and Damon chat with Simon Wardley about DevOps, the Cloud, and the nature of competitive advantage between companies. In Simon's usual style, he bridges the gap between the practical and the deep theoretical.  Show notes are at http://devopscafe.org

Aaron and Brian talk with Simon Wardley (@swardley) - Researcher, Organization Warfare and Evolution at LEF, about the evolving economics of Cloud Computing, open-source strategy and the current wartime environments for technology companies.

Aaron and Brian talk with Nick Weaver (@lynxbat) about recent conferences (CiscoLive, PartnerExchange, Cloud Connect), the Open Cloud controversy, the evolution of DevOps, and how IT will eventually break off space for new apps. Nick also explains how he name-dropped Christian Reilly (@reillyusa) to meet Adrian Cockcroft from NetFlix.

Are software as a service, open source software, subscription pricing disruptive to the market for manufacturing software? Just interviewed FuseSource, an open source messaging application. Recently an MIT/Sloan Management Review article cited research that top performing companies are 3x more likely to have a data analytics culture. On a podcast on IT Conversation, Simon Wardley argues that the Cloud is a source of innovation, http://itc.conversationsnetwork.org/shows/detail4628.html