The thing I noticed was the business technology divided so that was apparent in many companies and a lot of companies have got on this cannon wave of cloud and move to the cloud and then the value may be has not been there. It's just a fancy data center. So we get that real value. You have to really join the business and technology strategy. So Lady of the value flywheel effect is when you join business goals for technology goals, you start to see this momentum this flywheel effect.
Hey everyone. My name is Henry Surya, we Robin. And you're listening to the technology, you know, podcast the show where I'll be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So, let's dive into our Journal. Hello, again, my friends and my listeners.
Welcome to the package, you know, podcast the show where you can learn about technical leadership and Excellence from my conversations with great thought leaders in the tech industry. It's very great to be back here again with another new episode. If this is your first time listening to technology, you know, don't forget to subscribe and follow the show on your podcast app and on LinkedIn, Twitter and Instagram and to support my journey.
Creating this podcast, subscribe as a patron at technology. No, dot f / Patron, my guest for today's episode. Is David Anderson? David is the author of the value flywheel effect and the co-creator of the several has aged in this episode. David described the value flywheel effect concept and it's four stages, the clarity of purpose, The Challenge and Landscape the next best action.
And the long-term value, David also explained, the importance of worldly mapping and how we can use it to help improve the organization's situational awareness within the value flywheel during our discussion about the first day.
Yes, we also discussed several important Concepts such as the north star frame up for clarity of purpose, understanding the team psychological safety and socio-technical systems, landscape, the Severus first Paradigm as one way for the next best action and using the well architected framework and sustainability as guidelines for ensuring long-term value. I really enjoyed my conversation with David and learning about
the value flywheel effect. I find that all the four stages when used with Ellen, in any engineering organization, we can bring the transformation and the flywheel effect that David described in his book and this episode and the great thing is David has successfully used this concept to bring technology transformation and Cloud adoption at Liberty. Mutual, so definitely, there are a lot of practical things we can use within all engineering organization.
If you also enjoy listening to this episode, please help me by sharing it with others who can also benefit from listening to it. Also, leave this podcast a five-star Thing and review on a podcast and Spotify, it will help me a lot to make this podcast easily discovered by other people. Let's continue to the conversation with David after hearing a few words from our sponsors. Today's episode is proudly
sponsored by skills method. The global community and events platform with more than 100,000 software professionals here members, can organize their learning experiences around the technology topics. They care about most you get on-demand access. This to their latest content thought leadership insights, as well as the exciting schedule of tech events running across all time zones.
So whether the devops our data science is your bus or you are a fan of functional programming or all things Cloud, you can make real connections with people who share your interests head on over to skills method or calm to become part of the tech community that matters most to you. It's free to join and you will find it easy to keep up with the latest tech trends. Are you looking for a new cool swag tekhelet Journal? Now offers you some swags that
you can purchase online? These wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool tracks available by visiting technology, know the death, / shop and don't forget to break yourself. Once you receive any of those tracks. Hi everyone. Welcome back to another new episode of the package.
You know about Outkast. Today, I have a guest with me named David Anderson, or maybe I'll call you Dave. So David is the author of the book, titled the value flywheel effect. So in this book at this is very interesting, Journey. He gave some principles or how he actually did a cloud transformation but it's not just
called transformation. There are some principles that he also adopt which to him is a successful experience, which he shares that can be adopted by many other organizations as well or teams in the world. Specifically David. He's also a fan of serverless architecture, or Paradigm. So he has done a large-scale survey last deployment, especially the experience that he went through for writing the
book. And also he was the creator of the several has Edge. It's a community that Advocate several has architecture and some principles and paradigms. So David thank you so much for this opportunity. Looking forward to talk about your value flywheel effect and also the serverless Thank you Henry and thanks for having us on the podcast and I'm a big fan. So I'm looking forward to the conversation. So, David in the beginning, I always like to ask my guest to
introduce themselves. So maybe if you can share a little bit of your background or turning points in your career. Sure. So I'm based in Belfast and from dairy open the very north west of Ireland. I've always studied computer science. Always been a software engineer. Now, spent the first probably 10 years of my career working in Telecom a lot of Canada building big systems are working. It on big platforms. I then joined Liberty, Mutual around 2007, as an architect
building, an e-commerce system. And I'm looking off to get a CT opposition and around 2013. And I was very lucky because I was kind of at the table as Liberty, Mutual started speaking to a, to the S Vector, public Cloud Journey. So my background being software, the first thing I thought about was okay, as we move to the cloud, we're going to have a lot of security network in fuck. Our policy questions that answer who is answering the question around.
How do we write software and a cloud native way so I can. It took on that challenge with my small team and that led to a large canner served as First Transformation Liberty. Maybe we can touch and not through the book, like, that's for myself and my two. Co-authors Mark McHale and Michael Riley. Figure out this technique that we call the value flywheel effect. Our vision was, can we make Liberty? Mutual, I served as first Enterprise.
Which was a very bold statement especially for a few Architects and then Belfast but I think we seen a lot of successes and that Journey we see some fantastic things around modernize and applications of unlike over. Ninety percent Savings, of run costs, fantastic speed to Market times seen. Massive satisfaction from Engineers enable, the reduce, a lot of the operational. Burden around standing up big infrastructures and really focus on the business problem.
Deliver business Are you really quickly which also created a fantastic cohesion between the Business Leaders. All of a sudden 80 wasn't a bottleneck technology was no a differentiator. So it really it was a lot bigger than me driving this but there was a general wave of modernization transformation in the Enterprise and Liberty. Mutual been a Fortune 100 one of the world's leading insurance companies. That's a pretty big company whose exciting time to be at Liberty and to be driving that
story. And we can we touch on some of the stories as we go into 1021. Like I said, they can move on the new challenges and it was an agent Car. Craft whose x Netflix it with a successful. This is okay. You have to write a book. This is too exciting. I had no intention of being an author. So I thought, okay, I'll try this author thing and see what happens. So I told you go to the book and was absolutely delighted.
When 80 Revolution and Gene Kim, authors of accelerate devops handbook, Phoenix project, team, topology, Etc. So there are divided, you fly To their fantastic portfolio of books. I was already in that Kenna, devops Enterprise Community which is fantastic and really back to work. I can spend just over here with bizarre voice as a technical fellow driving, their killer modernization. And of course, they're working for globalization Partners or GP, which is very interesting
company. The mission of the company is taken at the breakdown fire, the global business nipple opportunities everywhere, Global Employment platform, that you can hire anyone anywhere in the world. Those are really exciting. We call it a service first, well, architect its ass. So we're building an entire employment platform. It's formed again for me, but I find really exciting is practicing these techniques and working with both technology teams, business teams really can
drive that value. So it sometimes we would say I'm a practitioner who accidentally became an offer, I think very rare, people wrote a book with, you know, like a childhood dream. I want to become an author, sometimes it because of an accident right through experience, Less than some people, advised them to write the book and you'll become an author. Think that's also, one thing that I also found throughout my
interviews, a few guests. Thanks for writing the book, by the way, it's really a great journey, which I think is worth to share with everyone. So for people who read the title of value flywheel effect, some people may be confused. What do you mean by that? Do you have like, maybe one statement pitch or value proposition? What is value flywheel effect and how do you get the
inspiration from? Yeah, well it's really around the thing I noticed was the business technology divided so that was apparent in many companies and a lot of companies have got on the scanner wave of cloud and move to the cloud and then the value may be has not been their competition. May be treating the cloud like someone else's data center, it's just a fancy data center so you get that real value. You have to really join the business and technology
strategy. So Lady of the value flywheel effect is when you join business. This gold for technology calls, you start to see this momentum this flywheel effect, so it's obviously influence from the Jim Collins is flywheel effect concept which is brilliant from good to great and then Jeff Bezos. Also had this amazones virtuous cycle which is really nice. Cannot fly will really have with the value flywheel effect. What we find is the four phases. The first pink, Lord, a purpose.
Let's start with why if we need to be extremely clear, that from technology and business, we know what our North Star is a new techniques to help people figure. Right. The second phase is challenge. You need to create the right environment that we can challenge each other in the team. We can challenge how we're going to achieve that North Star and set ourselves up for Success. The third phase is next.
Best action. Once you're pretty clear where you're going and you've got the right environment, you will be execute quickly and for me that's bringing in some of the modernization techniques around service exception service first. And then the fourth phase is long-term value. We can't build a throwaway. You need to have a really Solid understanding of what good looks like. So for me that's a problem prevention culture, which is running, well, architected and sustainability.
I can we build but build effectively for the long term not just build quickly. So that is a flywheel that will continue the turn. It's not just warm and on. Once you start that momentum and it builds very rapidly. It's like a rocket ship and then one of the things that you end up doing as you implement that is removing inertia removing sticking points. What is slowing down that movement? Because as you well know, Move to the cloud is not one and done.
You're an acceleration Journey. It gets faster. You need to change how you think and how you act. So if I can probably simplify a little bit for people, you take the concept from the flywheel effect from Jim Collins and also the Amazon virtuous cycle. So, what I can relate is that, it's an iterative process is not like one big bang Journey, where people now becomes transform, right? Either moving the technology to the cloud or the business becomes digitalized or something like that.
It's a virtual stink is a flywheel that's why and also So it's like a lot of things that you need to align alignment from business and technology. So it sounds like it's very similar to some other techniques, which are also well known things like agile software development of a gel business Transformations or it could be also deaf Ops or death, whatever, Ops this days, right? So what actually stands up from value flywheel effect that probably is different than the
other techniques. Well, there's a mindset so that for me is across the whole thing between extremely collaborative, main tools that I used as we created this value flywheel effect as a technique called Wort early, mapping and worldly mapping for me. It's a complete Game Change in
technique. When you start to map these different phases, it gives you Clarity on what you should do and what you shouldn't do. We can explain what worldly mop and is for me it's really about that Eddie of strategy and what should we do next? That's not business strategy or technology strategy is what do we as a team need to do next and worldly mapping gives you that Insight greater environment that you can build that alignment. I discovered this probably
around 10 years ago. There's a researcher in the UK called Simon wardley. The story was, he was a CEO of a technology company and he realized when he got the position of high growth technology company as CEO, that all the strategy was nonsense in his terms, he didn't think it was deep enough. Off. So we come up with this idea of worldly mapping and starts with the canvas, the canvas has got X and Y axis, the very top.
There's like a value chain. So the very top of the value chain, you've got a customer always starts with the customer and what's that customers need. So then there's a chain onto the customer, Nate for a component which is customer might need, for example, something like a cup of tea. The customer needs a cup of tea. So then what does the cup of tea depend on? It could be like a kettle.
Hot water some tea. Mr. Could build a devaluation of what things are dependent, the solve the customer need. So as you think in your head of a value chain going from top to bottom, the y axis of the map is visibility things at the top of that chain are very visible to the customer.
The customer is aware of the cup of tea, but they may not be aware of the cattle or electricity will learn that by Eugene, but they're very aware of the can see the cup of tea on the and from left to right in the bottom, this is the kind of exciting part. Art, that's where the x axis has in. This is really the evolutionary access for the evil assure access those four areas. So the first is Genesis. So every component and that will evolve and capability. I'll explain that in a second.
So Genesis of things that are brand new, they're like wondrous. I've never seen this before. It's fantastic in you. I don't even know I needed. I've never even thought of this. Next phase is custom. Maybe we understand how we might be able to build them. We're not very good at it yet. That's still quite emerging. The third phase is product things.
In the product phase are. We're starting to get good at building these and there's a strong customer, need the customer are aware of these things, and they want them to read customer demand. And then, the fourth phase is commodity. So things in commodity, we are very good at building these, we optimized new basically cost of doing business and customer may understand it, but it's like, yeah, everyone has one of those, two evil. Skinner axis is what's really exciting and the copper T sort
of up the cattle. Maybe commodity, you know, a cattle is a kettle, it warms the water, the water is likely commodity the cop maybe product may be given a scope which has the experience and the T could either be something very Bland like a standard type of tea or maybe something where you can have like a high quality, that's real differentiator so that could be more revolutionary and that every single component will
evolve from left to right. So we think of computers when computer start being used by business in the 60s, it was just a thing of Wonder, it was actually in the newspaper when a company got a computer as photographs of a computer being delivered to a company. Custom is probably more like the 70s and 80s. There was lots of different types of computers but they were looking at different and non-standard and then as we move down to the PC era, became product, computers are everywhere.
They can a standard get different features to solve the need lie with Claude. It moved it in the Aditi, it's not a big deal. Everyone has a computer and you just read one from somewhere. It's not really a
differentiator. So using that technique to figure out large strategy, business strategy, engineering strategy, it gets really interesting to figure out what's the customer need and then, what does it depend on and we can figure out what are the things that we needed really good at the things we can rent from elsewhere, survival has been a great example that we can actually rent a lot of the compute and services from a cloud provider, and not have to
build them ourselves. Thanks for sharing this. High-level overview of bodily mapping. I'm sure like poor people, maybe the first time you hear it, you probably don't get it. I would suggest looking at the canvas itself it will definitely give you a much better picture and analogy. What David is talking about. There's a great site by a guy called Ben Mercer called, learn orderly mopping.com bands, get some great videos where he explains this cause you can only do as you say, you need to see
the canvas. So I would look at the learn wardley mopping.com and I also, So have a previous episode as well about what they mapping, so please do check it out in that episode. We talk about what they might be in DDD and some other stuffs, please do check out. So one thing about what, a mapping that I realize, especially when you look at these websites, they always say that you will improve your situational awareness within the organization within the business and technology.
First of all, how do you actually improve your situational awareness and why it is important for organization to do so That's great question, actually, one of the things that we started to realize with myself and some of the Architects if I was to sit and write a PowerPoint or a document, it won't. I think we should do. I would go off by myself right that and present that because I've maybe spent a week right now to put that together if they give some feedback. It feels like they've been
critical of my work. So that becomes slightly awkward sometimes especially if it's a PowerPoint. Some of these in doing a presentation with a map, several Textmate sit down or several experts. Start the mop out in a collaborative manner what do we think those things are? And as you're performing the action of mopping, you start to build situational awareness, people say oh we need X. I know we don't we need X and Y,
why do we need that? So it becomes a more, tune fro conversation, you create the environment where you can challenge and build each other's knowledge. It comes less confrontational. So this is the idea of building situational awareness. So what you're really doing is having a structured conversation. So in the find out what's happening across the organization and what do we need to do?
So it's a great way of building trust within a team or a group of people and get in that situation awareness because you can't have people sitting like right and documents all day right in PowerPoints. All right, in loads of code because what you're not doing is exchanging information. So that idea of mapping is great with a bill situation, awareness, because you're having more collaborative conversation.
It's about the party we need to solve this problem, so it is not just about notation, or new techniques modeling techniques. Where you come up with a different kind of ways of representing what you want to do. But it's actually also the collaboration part, exchanging information, or what you also called Maps different maps at the end. I think the deliverables will be a strategy for the organization to execute, so it could be for a short period of time. Or it could be also for a long
time period of time. Is the outcome is almost like what should we do next. So will the map away the map represents our story. You're not creating a model, it's a thinking tool. It's a bit like the saying about plans planning is useful. The plans are useless. So the idea of the action of planning is very important, but once you got plans on the effect, you got to think on your feet. Yep. I've heard about that phrase as well.
I forget exactly the quote, but the I heard about that so you will fail if you don't plan, right? But once you plan, you can toss the Lan because in the real battle field, so to speak, the plan doesn't always work. So you are always need to adapt. You mention about the four phases of the value flywheel. So before we start to the faces actually, what Peaks my interest is the sequence of the faces and you kind of like pack along a Persona to those spaces.
So the phase one is actually for the CEO. The phase one is actually Clarity of purpose, the phase to the challenge and the landscape Are For Engineers. So you take the engineers Persona there and then for the third phase is about Out, next best action. You take product leaders here and then the last one, which is
about the long-term value. You Tech CTO, I find the sequences little bit odd because normally, you come from CEO and then you come to product, maybe, then to the CDO and then two Engineers. This is typically what happened in so many organizations. Why you're sequencing is like Co and then Engineers to product leaders? Then City, oh, maybe a little bit explanation on this part.
Sure, we can walk through each of the phases and definitely touch on the Persona. And mean, I don't think these are necessarily sequential but there is definitely an important order. It's already a purpose, I think CEO needs to be crystal clear on where we are heading this organization for me, the CEO is responsible for that vision and Mission. That's where the buck stops and it be sure that the camping change interaction for the boat, one of the techniques we've used as being great.
There's two different areas that are important here. One Eddie of a North star. I've been using the North Star framework from amplitude for many years, and it's a great exercise about asking teams. Okay, I understand you're doing this work. Do you know what that Northstar metric is? Can you connect the work to the metric? Like the CEOs, talking about? We're going to the Moon is the piece of work. You're doing. Going to help us get to the moon
and the answer needs to be yes. And if so high it's like there's maybe what two or three steps if it's like no I'm not doing that. What I'm doing is different. That useful. The other thing is about time, the value, a big part of the North Star framework is leading and lagging metrics and I think an innovation is a lagging metric, the leading metric of something different. Maybe it's time to value fast feedback loops, be able to deploy quickly. You will have those conversations.
So once you've got good Clarity of purpose, you very clear in Direction then you want to obsess over time the value which is how can we create value quickly and test if it actually is right? We test our assumptions. This related is like a technical bet. We think there's a bet that this feature will be useful or customers. Let's get in their hands as quick as possible, start the feedback loop. So really, like Clarity of purpose is understanding.
What are we doing and why? It's very difficult. As, you know when a software team, the team don't really understand why we're doing the work. The work will not be good. So yeah, it's always great to start with Clarity of purpose, right? So for example Simon sinek always say start with the why I think. All understand, you need to start with a vision with the mission. The problem statement to solve for the customer at the end, we solve for our users. Our customers is not for
something else. When you mention about this, not start framework from amplitude. So for some people who may not be familiar, what is not star framework here, maybe you can explain a little bit how it works here. Mean it's worth looking opportunist, Googling Northstar framework. John Cutler was the product. Lines has with amplitude for many years. I think he's moved on over. There he is. Is a lot of great talks with the North Star framework.
It's kind of like a V shape. You start off with the work, which is York in the leading metric. And then the project of the piece of work, you're doing, might have good measure of success, not measure of success, will have an input into maybe an objective and then that objective will link into your North Star metric Spotify. They had a nice example about number of minutes listened to by customers, so how many minutes of Music customers listening to
so that was an All-Star metric. And then after the North Star metric, there's like a long-term volumetric, which maybe, three years right, which can be something like a three to five-year evasion. So you always want to be Tangy work through that, you know. So you can look at your project say, well for Spotify, will this piece of work, help increase listening time on the Spotify platform.
So if you have a project around fixing up, the debug statements and a what your glasses and maybe it will, or maybe it won't, it's a nice questions. We will lie in it frame. The work you're doing. And there's also a nice thing here, but mapping is the North Star going to differentiate in the market are used creating a better moisture trap. We create something that's going to genuinely be different. So the whole idea of from a business and product
perspective. Are we building something that's going to meet a market. Need the, a few other techniques as well. Which I have heard in the industry. The other one is okay, are, or you can just list down a few metrics. So maybe the differentiator here, maybe it's just like the way it is being mapped if I understand correctly. There's a scene. Through the book that this is a
collaborative exercise. So it's not like someone shows you the picture and say here it is, this is the answer, the team will work through and actually figure out how their work maps to the North Star. You may have like it's but like impact mapping. You may have like ten eighty years. It's like, let's go after this one because we think this one will be best. So again, for me, there's something deep rooted in, can I tell software development? It's not like you just been
handed a piece of work. They go do that. Now, you're figuring out. Out what type of work you can do to meet a goal. So you know make sure you really focus on the problem. Not so much. Been handed a solution. Yeah. Focus on the problem. Not handing in the solution. So the CEO or the leaders, their job is to actually pick the problem what they want to solve, right? But then the how how people will solve it is not something that is defined by the founders or the leaders in the company.
So I really like that. Once you have this Clarity of the bus, which is your notes app, that's a assume we use the North Star framework. So once we have the nonstop, The Next Step that you mention is actually to obsess over time to Value. I think this is very very
important as well. If you can touch on Mike how can actually people start to think about time to Value obsess about time to Value the singer Award of the metrics that matter in the ID of the dashboard celebrating some kind of Matrix. A lot of the work done by the Dora, the devops research assessment around four key metrics could deployment frequency. And lead time I think there are other metrics, but really think it's important to understand
what do we mean by value? Can we clarify that can be very clear and what is the metric that we're going to measure value by? Is it minutes listen to music? Or what is that? And then, how are we meeting that need? And really, if you have a modern cloud, or if you're in the cloud, you should be deploying very frequently. It shouldn't be every six months. You should be able to get feature some of the Hands Across America quite quickly.
So I think there's something about being very clear what the metrics that matter I've been quite transparent about those metrics. Can celebrate nose, creating the right culture that were trendy actually through these metrics. And that contains a proof of mindset and they're not kind of Hidden Away in some secret report somewhere or in a Kinect comparing teams. It was each other. So I think there is definitely a healthy obsession over those
metrics that matter. I really like the way you'll mention it, the metrics that matter because sometimes in any organization you have so many metrics, do they all really matter in one Unison? So, It's also one thing are they contributing to the same node star and the other thing that you touched on earlier, is that most of the metrics, like, for example, Innovation, or time to Market and things like that. Those are actually lagging indicators.
So I think in this face, what you also suggest is that we have to improve the leading metrics that we can control, for example, spotify's case minutes of songs. Listen, sometimes we cannot really drive people to just play the music, right? But what are the leading indicators that we can drive within our control to improve that Big metrics. So I really like this two-step. So maybe if we can go to the next phase about Challenge and Landscape the Persona Tech to this space is engineers.
And you mentioned about two things which I find really fascinating these days. These are the psychological safety and the socio. Technical aspect of the organization that started psychological safety. Why do you think this is very important in your value flywheel effect? I think massive piece around been team first, like the team is the you What of delivery teams deliver software, not individuals, teams lover software. So it's really important like a
soccer. Team will win the game and individual player May contribute, but the team wins the game, no point having a great Striker if you don't have a defense. So for me, it's always been the same and software for teams to survive and thrive, you need to create that psychological safety. When you walk through, Northstar exercise, people are empowered to say, I don't understand that metric.
Is that really the right, Patrick it Can't be correct because the CEO said so there needs to be some rational. People may just not understand thinking behind the metric which is okay. You need to be in a safe environment. You can say can you please explain to me what that means and it should also be able to say well I disagree, what's that? And you can maybe have a conversation.
There's very smart people and software teams so create the right environment to allow those people to ask questions. So for me having that team first environments the way a team gels trusting the team to go after? After a problem and not have that can a command and control type environment whether just told what to do. And they're told not to think, that's also part of how we largely map as well when we're figuring out. What we need to do, the people are allowed to respectfully challenge.
The thinking, is that really the right thing? We need to do. So that whole idea of psychological safety in how you work is about having that creative kind of environment, or we can figure out the best thing to do and okay, the disagree respectfully or board a piece of work. That's think that's massive. Again, keep going back to this, especially in the modern Cloud environment because there's so much technology.
There's so much Choice. Someone may have a much better way of doing something that someone else just made out of thought about it. You have to create that environment that Engineers are already challenged. Each other. Find the best way of doing something. So, again, for me, that's a team first environment, every time I really like that. So team first is always the unit of delivery, right?
So again, you touch on, it's not about individual and it's not only about the leaders who set the direction, set the goals and also even the house Ow, but it's always the team the team comes first and whenever the team has this psychological safety almost, kind of like translate to people's engagement and productivity. They can produce the best quality product or deliverables, simply because they are motivated. They understand they can
challenge. They are also okay to say, I don't know, and also less about blame, right? So if some mistakes happen, people are safe to say. Okay, I did make a mistake and we Rectify together as a team. I really love that one question. Maybe from your journey. Maybe Liberty Mutual, how do you actually gauge a teams psychological safety? There's a number of ways. I mean, I don't think it just depends on a single person.
It's an organizational measure. And I mean, one thing that I like is, I always would look at the Retro and I tell techniques. Is there an ID of improvement for me just personally that was one of the major that I would use. I would like to see, do I see continuous Improvement and a team, not forced contains Improvement. Do I see the team genuinely trying to make things better? We try and sings failing right and the gel.
So there's a number of things that I had put in place to try and kidnap Roper. Things we still talk about hearing demos, the do like kind of engineering Excellence, look at metrics for teams discuss what they'd like to improve. And then almost like there's a say, do Gap. The team say the really unhappy with their deployment Pipeline and, you know, create the environment or capacity that they can fix. It could be fix it. Or did you say no, we didn't have time when you go to the
team. Say what would you like to fix? Let him say, Well, this here is really annoying us and then you create the environment where they have space to fix it, they should actually fix it. If they have this long list of things that are kind of annoying them and they never get to fix them. That's a bit of a smell that maybe there's something else out there. Team deliver the work, it's not the managers the leadership, they create the environment to help the work happen.
So I think there's a number of things like that. It is also something about how the leadership behave or in those teams as well. That's it for another very important dynamic. For sure, I mean, there are many topics this day talking about psychological safety, but I really like the way you kind of like take as an example. How to gauge by looking at the how many kind of improvements the team has done, especially out of their initiatives.
It's not like being told from the top that they need to improve something because this means that the team also do a lot of retrospection repeating themselves. They are okay to say yeah we still do bad in this area and always continuously improve. They are always Improvement. I would also be probably concerned if they say the team doesn't have any backlog. Of improvements that they want
to do, right? Because that also means maybe they don't dare to speak up about what things are lacking and they might be possessed made of a lot of delivery ahead of them, which is also OK and the improvements can drop a bit but that's all part of the balance flow and the team. The second aspect is actually, you mentioned, the system is the asset and you bring up the point about socio-technical systems
view. So, tell us what this system about, and what is the social technical aspect of this view is there's an interesting phrase rowing socio-technical, which is a very old Phrase, I think it's still evolving. You can't think of the system as just a software system because there's also what are the teams are connected to those components, massive link here with domain driven design, and like, what is the organizational structure?
Or even think of Conway's law where your organizational structure is related to your software architecture. There's a piece here about what is that entire system? Look like teams and software and that is the asset. That's the thing. You have to design. You see some companies moving People in teams or own can a willy-nilly and to fix code, that never really works out too
well. So there's definitely a piece here around thinking, holistically around the team's, the organization and the software which combines two, it solves our business problem, it's a massive node here to him, topologies the work from Matthew skeleton, and manual part, which is also a book released on I.T Revolution. They talked with four different team types streamlined complex platform and neighborhood teams. So there's a big piece here,
right? Ensuring teams are set up for success of the right goals and are working on the right parts of the system. So I think that's certainly a combination between can of Engineering Management, kind of architectural, technical management to ensure that there is a more holistic system at work here, which I think is very interesting. And once you create that environment, where teams of a clear goal then you're setting them for Success, not giving them like ten goals that they're
just completely overwhelmed. So thanks for explaining that because I think you also mentioned in the book that we need to Build our enable empowered Engineers within the team's being able to analyze, not just from the technology point of view of people point of view, but the interactions between the technology and the people. And hence this term socio-technical rights, not just about the people is not just about the technology, but the interaction between people and Technology.
That's why you bring up things, like Conway's law, Team topologies, all these go into this research area, how do we actually, optimize the social technical aspects of any organization? So thanks for watching. Wind up. So let's move to the next phase which is Phase 3. You will mention as the next
best action. So once we know the clarity of purpose, once we know the challenge and the landscape that we have for the empowered teams or Engineers that we have, the third phase is to choose the next best action. So tell us about this because it seems very interesting, right?
The next best action, there's two parts to this to high-level Parts piece around developer enablement, creating the right environment for the engineers to move at read and that is linked directly to that service first strategy. It doesn't have to be service versus Morgan modern application strategy. But I used the term Service First Liberty, which is very successful. And really, the idea is that what service first means?
First of all, any kind of service technology is something that's more likely to be a managed Solution by the cloud provider. It's likely to be pay as you go. So you pay for what you consume and then wanders zero traffic.
Zero charge. So things will scale up at there's loads of demand and skill right back to zero and you're done, you know, it's not infrastructure code or you can people talk about function as a service, it's not really this concept where everything is a Lambda or everything is a function, you're really using services to solve the need. If you need a database, can you get a database behind an API? If you need an event thing system, can you get an event in
system behind an API? Really, the concept of service first? Is that the first selection when you're selecting architectural? Components will be a serverless service. So when a room that could be like Lambda event Bridge, step functions, even S3 where you're minimizing, the amount of infrastructure that you Day-Lewis from a software perspective Service First. Meaning, if, for some reason those Services, the work, you may then fall back to something like kubernetes or container
solution. When we started this thinking back six or seven years ago, there was something like cold starts, Etc. There was some features that weren't quite there yet. It was Reasons to fall back today. And the 2023, there is a lot less reasons to fall back. A lot of Service Solutions are very robust across all the major public Cloud providers. So once you engineers get into that, thinking that they don't
have to spend time, right? And thousands of lines of care reform to create all this complex kind of easy to use. They can focus on the problem that trying to solve for their business. So, evidenced by his very nature is event driven, so you start working more on event driven. Items. But is a nice link back to the stuff. We talked about teams.
And what the purpose of the team is now you get into teams emit events to each other using service technology and start to move and think in a different way. This can be sometimes challenging if you've spent the last 10 years working on traditional Enterprise Java. This is quite the leap to Mac, but if you've been immersed in clothes, we would maybe even starting your Cloud Journey. This is the way. These are The Primitives of the clothes, in my opinion. I think there's a massive shift
toward here. And there's lots of really good examples out there of body build a service architecture. Very quickly began that idea of developer enablement is a big part of this because you need to create the right enabling constraints for the engineers one being infrastructure as code as being maybe a single path to production or on your deployments third movie being a good coin strategy or some good. Can a cloud infrastructure setup?
You think about how security may be slightly different than traditional security? There's lots of really exciting thinking in this space but it's for me I can see this major can find dacian of how companies modernizing the cloud. Thanks for explaining that. So if I can understand you are not just saying everyone should adopt several as Technologies. Things like Lambda and things like that, but it's more about doing the simplest thing you can do to deliver value.
So as Engineers, we should not thinking about doing terraform creating infrastructure managing networks and things like that. But it's more about doing the simplest. Thing that we can do. I mean these days in Cloud Technologies there so many available Technologies, you can just choose not just maybe as function as a service only, but they are containers to service these day. They are platform that enables you to do that last time people used to do maybe hero, cool or things like that.
So I think that's also another some kind of like a serverless first Paradigm, right? The key Point here is to do the simplest thing, you can do to actually deliver value and you also mention a very interesting thing, you set the code is a liability. So as Engineers, our job, Not to write the code, but our job is actually to deliver value for the business. So, I think this is also very interesting because when people hire software engineer, they don't just see how they deliver the value.
But actually the technical competency, how they write code, how many programs they can create. So, I think this is also another important aspects in my view, just very quickly to something about engineers, understand what they're being asked to do. And sometimes when you have a problem, what you need to do is I need to notify another
software components. Something's And this problem you have to solve is a communication problem between A and B. So many years will say that, okay, I need to stand up like Africa venting system and we start building the huge platforms like, well, that may be the answer but the problem you have to solve is how they get an event from A to B know
what's the simplest way. I can make that happen if it's even asked us residents to start with that and then as things started to get complex, then you can think about. OK, how do I scale that do? Move to that. Hey scale, infrastructure solution, first. And also, it depends on the context of the organization, right? Some organization may have capability in Kafka. Maybe they have a platform team so you can just tap on that expertise, but some organizations. May not.
So, don't just introduce new technology, simply because it's the fancy. And the latest hype out there, do it in the simplest way to bring the value first. So I think that's the next best action. So, let's move on to the next one, which is about long-term value. So, this one you mentioned about problem, prevention, Culture, maybe a little bit of explanation, how we can actually do this problem. Prevention culture. Also things that used to sort
worry me slightly. Is that there's this idea that we don't need Architects anymore. And architecture is becoming less important. Architecture is very important. You know, if you're sitting in the house you should hope that it's been well architected. It was always problematic for me that, how do we communicate this to all of the organization sometimes like this feature has to scale, so we need to spend several weeks figuring out how to scale this. So it's working, but it's not
ready. You want to reward team? For doing the work up front to make sure that scales you can't reward individuals who want a system, doesn't scale and folds over on a Saturday, jump in and fix it. So let's try and reward the people who prevent the problem, rather than the people who fix the problem, is that the sign of good engineering. People can predict, where these
things are. And for me, we spent a lot of time trying to communicate this, a big fan of the well, architecture framework that awas use. Well, architected is a phrase that a Less Google and deserve all use, and they'll hold their own versions of well architected. So, whatever Cloud platform you're in, I would go and look at the, well, architected framework for that provider, but the experience I have is an AWS where the well architected pillar framework has the six
pillars. So it's security cost, optimization reliability, operational excellence performance and sustainability which is new is added to just over two years ago and really each of those pillars. As use their own 12 or 13 questions, it's a lot of best practice. What I did in the past was, instead of having that as a service, where an a SS architect comes in and assesses, your workload teams could assess their own workload and turn them into a continuous Improvement
practice. So, the team could say, well let's span Friday morning during the operational excellence, pillar, I'll name a spot that their own books are out of date. So let's add story to your backlog or and contains a proven to dinner on books. It's because it doesn't seem that important now. But when the system Falls over on Saturday night, it's going to be really important.
If certain books are correct and that's for me is a good problem, prevention culture, because the team may go through a checklist and release, it doesn't apply, and that's okay. But the team have the context and expertise. You understand, what will be problematic, and they're getting advice from the collective wisdom of all the cloud, vendor Architects here, all the things that we have seen gone. Wrong distilled into good practice.
Yes, you would be a fool, not the read that good practice, see if it applies to your work look. So that's the idea of a problem for ancient culture and I think if in an organization, there's a modern Cloud capability should be empowering your team's to do that work and really hard in the system, because the cloud fails all the time, distributed systems feel all the time. So, we need to ensure our teams of the capacity to prevent these
problems from happening. So, yeah, I've seen this a well architected Frameworks from different Cloud providers. They are really good. I would also highly suggest people reading those Frameworks because they touch on many things, but just one aspect. So, from AWS you mentioned, there are six pillars. Now, one question for me is that those things seem to be specific to Cloud, right? So does the organization also need to create their own version
of well architected framework. Maybe spend not just from cloud perspective but also maybe application development or some other aspects within the organization. That's a good question. Remember when people talk with non functional requirement and abilities? No one could remember what all the LEDs are because there's so many scalability. Observability reliability, what
I think is nice about. Well architected is you're saying, we're going to look at these six things I have done well, architected reviews on on-premise systems. Because you can still ask a question about a run book about the cost of the system about security about authorization authentication, you know, roll. Rules all the same questions. Apply the answer may be slightly different because sometimes an 80s will say you should look at control tire.
For example, you need to think of what's behind that. So you can still use the same approach for regular workloads that will have to be closed workloads, but again, for me, it's the way of standardizing on those non-functional requirements that apply the every team with. One thing I used to do list is the theme should say of were different. We have high amount of transactions. Were different because we have low transactions but the high value so every team is
completely different. So being able to say, okay let's assess reliability across all our teams. The answer is different for your application but you can still say you have any critical risks and liability reliability or do you only have lower risks? So really a good architecture is about managing risk. So you need to educate your teams on water, the pillars and help them assess their own level of risk. They understand their own, Text.
That's a very good point. So when we talk about long-term value is not just about the fanciness of framework we use, but it's actually to prevent problems from cropping up in the future, especially when scale, or when the load comes suddenly, your system should be able to kind of like withstand that pressure and definitely, well, architected framework. The name itself is like well, architect that, right?
That means there are so many experience or design patterns or best practices that people have come up with. So you don't always need to reinvent the wheel and come up with your own version. So what Aspect, which I think really important you mentioned in this long-term value as far as well as sustainability. I know, it's trendy topics as well, these days, but how can all the organizations are all teams think about sustainability aspect because some people might
think. Yeah, I'm just a small company or small team. I don't have a big impact on this so maybe you can have an explanation on this part here. So I think this is a great measure of good architecture.
I think sustainability is hugely important and there's lots of different aspects but specifically For software if you have a software system, one of the things that we used in the past to measure how efficient a software was cost, you could look at the actual Cloud Bill and lower cost is more efficient, but then sometimes the cloud providers will give like cost savings plans and different discounts. So maybe hide some of the lack of utilization.
Know what? A lot of the cloud providers are doing is giving you a carbon score for how much carbon that workload is using. So it will be an actual measure know, it's Hard to be very specific on this measure. It's calculated by the cloud provider. You could pretty much say that a lower carbon score or carbon Barn is a more efficient architecture.
And even though there's a lower carbon usage is likely going to be a lower cost and select Lee going to be simpler or less complex system probably design their architect slightly better than once for a wistful and burning a lot of extra Cycles. It doesn't need. So it's a nice kind of measure. You think is a goal or do we write sustained?
All software. So it's really about being efficient and writing well, design software because you think about it, if you think of a Lambda function you know it's API call it's been up. It runs four, maybe 500 milliseconds and disappeared versus any c 2, which is running 24/7 with APA. Open one. Call services that in 500 milliseconds, but it keeps running and waiting, you know, the amount of compute used between Lambda and easy to its way different.
So really? It's that idea of, can we Our to think of our carbon usage measured by the cloud provider. As a nice measure for good. Architecture has aged or let's say, they take care of sustainability of the clothes, they'll make sure the data center is sustainable. You have to make sure that your workload is sustainable. Is efficient. I think that's a really nice kind of measure how we can. Build good systems. You're dodging a very good point.
I would say that a good architecture is efficient and probably also gives a very low carbon footprint. Now, these days are so many technologies that that can just easily spin up spin down. You don't always have to have a VM running all the time or maybe except your database I guess.
Right. People don't want to have database being spin-up and spin-down out but apart from that I think for many back end so you can touch on a more carbon friendly Technologies. Things like containers also has paradigms have less Technologies and I think everyone has the responsibility. I would say to play our part in sustainability because the world is also changing because of this climate change and things related to sustainability.
We all have our Possibility to save the world, so to speak. So David? It's been a very exciting conversation. Unfortunately, we have to wrap up pretty soon, but I have one last question that I would like to ask you, which I call the three technical leadership wisdom. So you can think of it like, advice for listeners out there and maybe from your experience, or from your journey of from your book. So what will be your tree Tech leadership wisdom or questions?
First of all, I think is probably around your writing ability concise writing, think writing the same as coding whatever line Would you use? You should be a master of that language, they write in a concise manner as Engineers, we often learn mathematics and programming and we don't really learn how to write, but it's very important to be able to communicate to a lot of people to write well and writing is also a thinking tool so it helps gather your thoughts.
It's a lifetime practice, you can always get better out. So I think it's good to focus on concise writing. The second one's probably emotional intelligence which I think is interesting one. I think is your attack leader working with a lot of There's thinking to deal respond that they now make and different conversations where people are coming from, can't just assume that you're correct all the time and everyone else is wrong. You need to consider if different roles different experience.
So it's really important that at least, understand, emotional intelligence, and understand different signs, Etc. And just be a good human being and then the third is probably only won't, it's okay. Not to know the answer. People often assume that the technical lead knows all the answers but often they just know how they asked a question. Or they're brave enough to say, I don't know the answer. You create a good environment. So you'll probably find that all
three of those. If not really much through the technology, is there more to do with communicating with people think being a technical lead is more about how you can work with other people in your team's. You still need to know the technical knowledge. You still need to build the code. That's also really important but you need to have those really strong communication techniques. So, I would say writing emotional intelligence and it's
okay not to know the answer. And really liked the last one because many people think by being a leaders, you need to have all the answers. You need to be able on the spot, give some suggestions or fix the problems, but many things in software technology, these days are really hard and they are always new, right? So I don't think anyone could ever muster everything, so it's okay to be vulnerable and say, I
don't know. I'll try to figure out next time, so yeah, it's a very good and beautiful message for leaders out there, especially the engineering leaders. So David, if people want to connect with you they want to find out more about your books or Things. Is there place where they can find you online? Yeah, we've got the service age which is Surplus eight.com. Such for will have a lot of our blogs when we have a podcast called surface crack which is cracked.
That spelled CRA. I see, you can have an Irish word for can good foam so myself. Mike, we a very short podcast. We just have over the phone. Let me talk with these Concepts and obviously the value flywheel effect is available for all good. Booksellers from 80 Revolution, so it's on Amazon on Kindle. Inaudible and give her back. Thanks. I'll make sure to put all of them in the show notes. So thank you so much for your time. David. I really enjoyed our conversation. Thank you, Henry.
It's been a pleasure. Thank you for listening to this episode and for staying, right until the end if you highly enjoyed it. I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you are new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot. In order to grow this podcast
better. You can also find the full show notes of this conversation on the episode page at technology Arnold death website, including the full transcript enter, In quotes and links to the resources mention from the conversation. And lastly, make sure to subscribe to the shows mailing list on pack leader dot f to get notified for any future episodes. Stay tuned for the next technology, another episode. And until then goodbye,