 All right, so we have a lot of people in the room. So thank you for joining us today. And with me, I have Daniel North, Dan North. That's how we used to call him back in the ThoughtWorks days. And I'm sure most of you know the awesome work that Dan has done popularizing, inventing BDD. He's the originator for behavior-driven development. I think that's one specific practice that's really helped bring business and tech people to collaborate very effectively. And thank you, Dan, for really pushing hard. I remember having all those debates with you about why do we need another term. Isn't that already confusing? It's nearly 20 years later. We're still having them, so. Absolutely. So yeah, it's such an honor to have you here. I know I've been trying to get you for quite a few years, and I'm really glad we finally made it, at least virtually. And I've had the pleasure of actually working closely now with Dan for almost a year and a half. Dan has been involved with Geo, and he's been helping kind of work with a lot of different things over there, driving the overall transformation to a product company. And so Dan is going to talk a lot more about the details of that and share some of his insights. So with that, I want to hand it over to Dan. If you have questions along the way, please use the discuss panel. And in that, you would see the Q&A section. So please add in your questions and meet that. And I see that a lot of thumbs up, so that's awesome. Thank you for that. And that's your feedback, Dan, as we go. Wow, I see a cloud of likes, so that's awesome. Thank you. Wave of thumbs. That's cool. I'm going to do that through my talk. Every now and then, I'll just do that. And I want to see like a wave of thumbs go up. Fantastic. All right. Audience participation. So if you want to share your stories. Marvelous. Let me talk to you about agility at scale. Now, or at the end of day one of the conference proper, I know there's been a day or two of pre-conference training and workshops and things. So this is day one of the actual conference. I've been dipping in and out of it. It's been a fantastic day, and there's still plenty more to come. So in particular, I had to catch Professor Dave Snowden's session earlier on, because he was asking whether mindset was just another agile buzzword. And then I'm coming along talking about agility and meeting of mindsets. This was not planned. This happened by accident. But it's a happy accident. I think we've actually very pleased with some of the things Dave said really do align with some of the things I want to talk about. What I found interesting is he's coming from a very different angle. So Dave, Professor Snowden, his angle is complexity. He looks at how people and groups of people, teams, organizations, societies, countries work together and some of the kind of complexity models within that. And so he's coming at it from systems of people. And what I've been doing, although I'm very interested in systems of people, I've been coming at it from systems of work. So how does an organization create value? How does an organization get work done? And what's really interesting and quite exciting for me is that the things that I've observed from that direction seem to align very much with the things that Dave is talking about from a people and research perspective. The reason I say excited is this. He's one of a handful of people I know. And they're quite rare that I call academic practitioners. So these are people who both have the rigor and discipline to research things properly, like in an academically robust way. Nicole Forsgren, Dr. Nicole Forsgren is another. Dr. Linda Rising is another. So some of these folks are out in the field doing work and also studying it. And so to have someone who I think of as a grownup, like proper academic rigor, saying the same things as me, I feel like I've been vindicated a bit because I'm not going to do that research. So there's a couple of things that I want to refer back to to Dave. And also if you're in a Yunkyu session just before this, she mentioned a couple of models as well that I think are really relevant here. So I want to talk about agility at scale. I want to talk about a meeting of mindsets. This is a talk in two parts. So the first part I want to talk about mindsets. The second part is about a theme, a meme that's been around for a few years now, the idea of autonomy with alignment. And I want to speak about autonomy. I want to speak about alignment. And particularly I want to introduce a new term, which is a model, if you like, a thinking framework that I've been working on for a while now. I feel like I'm just about ready to take it out into the world. So this is one of the first times I've shared it with a bunch of human beings. So I'd love to get your feedback on this. So without any further ado then, let's talk about a tale of two mindsets. I want to talk about two different mindsets. And the mindsets I want to talk about are what I think of as digital product mindsets and industrial mindsets. I'm being very specific. When I talk about digital products, there is definitely a product mindset. There's an attitude, there's a way of thinking about people who are building products. When people are building digital products, so when materials and supply chain and those kinds of things are less of a factor and it really is, if you can type it as fast as you can think it, you can ship it, then you see the stark contrast between digital and industrial mindsets. And this plays very well with what Dave Snowden earlier on was talking about dispositional control and process-based control. So dispositional control is about dancing in the moment, if you like, is understanding the disposition of a system and responding to that. Whereas process control is we're gonna do these steps in this sequence no matter what. And I hope you picked up from what he was saying, neither of them is wrong. Okay, they are both just useful in or more or less useful in different situations. So I want to introduce a couple of people. I want to introduce Martha Lane Fox, who's, she's one of the great success stories of the first.com boom, around sort of 1999, 2000. She founded a company called lastminute.com in the UK whose business model was taking perishable, if you like, products and selling them just at the point where they were going to expire hence last minute. So things like cinema tickets, events, shows, sporting events, maybe restaurant bookings, that kind of thing, where there's only so, there's a limited amount and they have a date on them. And the brilliant thing with her model is it wasn't just a digital play. So in order to be successful, she had to then make arrangements, create contracts with all kinds of different organizations with theater groups, with event groups, with sporting groups. So the model itself is very easy to copy, but by the time anyone thought to copy it, she's already sewn up all of the interesting players. So it was a brilliant business and or commercial and technology play. And she did very, very well. I came across Martha Lane Fox much later obviously I knew about her then, but I came across her much later when she was working for the UK government in a project or an initiative called GDS, Government Digital Services. So GDS was a response by the UK government to some spectacular digital failures. I mean like eye-watering tens of billions of pounds of wasted UK taxpayer money on digital initiatives that simply failed. The UK government finally said we need to do something about this. And now Dame Martha Lane Fox led the charge. So she's my representative of digital product mindset. In the opposite corner, we have Isambard Kingdom Brunel. I have a particular affinity with Isambard Kingdom Brunel because I went to Brunel University, which is an engineering university in, well it's a general university, but it's main pedigrees in engineering in the UK. And he is one of the kind of founding folks, if you like, of the industrial age. So he built ships and bridges and railways and he was a great industrial operator. Some thumbs up for Isambard, I approve. Some thumbs up for Martha as well, brilliant. So these are my two folks. I wanna just have them explain how these mindsets are different. And again, I wanna refer back to what Dave was saying. He said specifically, he said a mindset, he says is triggered memories. And I thought that was a brilliant description. So it's the response you have to stimulus and the response you have comes from memories that you have. And he says, you never remember the same thing twice, the same way. So when you remember later on and no different things, you'll behave differently. Another way of talking about triggered responses to memories, like the unconscious triggered responses is habits, okay? So your habits are what you do when you're not thinking about what you do. So your habits are what you fall back on. So a mindset really is about the set of habits that you bring to a particular situation. So let's take a look at this. So we start with a digital product mindset, we start with a higher uncertainty and a need for learning. We know when we're building a product that we don't know, okay? We know that we know that we have an idea. We know that we think we know what the customer might want but we know that we can't just go and design it all upfront. So productivity then is measured by customer impact. So it's not by how many features we ship, it's by how much the features that we do ship impact our customers. And again, the great example, one great example that this is Google Docs versus Microsoft Word. Microsoft Word has been around for 30 years, a long time. It has every possible feature you can imagine, including a thing called Mail Merge which no one has used in the last 15 years. Google Docs is a much, much lighter weight editing tool. It sits in your browser. Now, the interesting thing is that Google Docs probably has less than 10% of the feature set of Word. And yet it is hugely popular because of that, right? Because it has the 10% of features that you use 95% of the time. So what they've understood is that they can get enormous customer impact with a tiny feature set. And then what we do is in a digital product world is we organize by product. So we organize, we bring all the people together that we need to build a product and then we get them building the product. And so we organize by products and so we reward generalists or specifically we reward T-shaped people. So people who have some deep skills but also no other thing. So if I have a developer who also knows how to administer a database, that's really useful. If I have a tester who can also program so they can start automating tests, that's brilliant, right? So having people who can have feet in different camps is really valuable. And this arguably is where the DevOps movement came from was developers who knew how operations works and wanted to help and operators who had development backgrounds and who knew that operations could be much, much more agile, if you like. So we reward generalists and what are we trying to do? We're trying to maximize discovery. That's our goal. Our goal is to maximize discovery and we do that through experimenting. We do that by assuming we don't know the answers and then we have hypotheses and our hypothesis let's all say it together, it's a falsifiable statement. I'll say it again, it's a falsifiable statement. So our hypothesis is a belief. It's an assumption that I set out to disprove. We don't set out to prove hypotheses with product testing, we set out to disprove them. And the more we fail to disprove them, the more we can trust them. And science is asymmetric. It's really easy to, once you disprove something once, it's false. But if you fail to disprove something many, many times it might still be true. We believe Newton's laws of gravity for nearly 400 years because they're really hard to disprove. They only fail when things are going very, very fast or they're very, very big or they're very, very small. And for most situations, that's not the case. And even in NASA, these people are putting rockets into space, they're launching satellites, they're sending rovers to Mars. Most of the math they use, most of the physics they use is Newtonian because it's much, much easier, right? And it's nearly right. And then when things get really crazy, like when you start getting into orbital circuits around Mars, that's when you start looking at the relativistic math, where you need it to be accurate, but the math is much harder. So again, they use a blend. I'm getting off track, I love physics. So then let's take a look at what Isambar has to say. And he says, well, you know, industrial mindset is fantastic when it's low uncertainty and it's well understood, right? Laying a few miles of railway once you've laid already laid 200 miles of railway, laying the next 100 miles of railway largely the same, okay? When you are, as Mr. Jane said, I've been working with Geo for the last couple of years, when you are rolling out two lakh towers, 200,000 towers across the whole of India, right? Then once you've put the first few towers in, all the other towers are kind of pretty similar. So it's an industrial process. It's low uncertainty, it's well understood, we can commoditize it. So now we measure productivity simply by output. If we need to get 200,000 towers down, how many towers have we done? How many towers have we got left? That's our business metric, okay? So more is better in a digital product world. Actually, ironically, fewer is better, right? If I can achieve customer impact with the fewest possible, with the smallest possible feature set, then I'm winning. So how do I organize? I organize by function. I organize by function and that means I reward specialists. So I might have, so there's a telecom phrase that I hadn't heard before. And the telecom phrase is you separate make from operate. So in telecoms you make your network and then you operate your network. And the people who do make are separate from the people who do operate. That makes perfect sense, okay? Engineering and designing a phone switch and a phone network is one set of skills. Having thousands, tens of thousands of field engineers running around laying cable, installing things, fixing things is another whole set of skills. And so now what's the industrial mindset optimizing for? It's trying to minimize variance, okay? So if I have many, many towers or many, many miles or kilometers of fiber and they're all the same, then I'm very happy. If I find that some of them aren't the same that usually means bad things are happening, okay? So I minimize variance through strict control. And again, neither of these is right or wrong. They're just different from each other. So then the industrial world has been around for a long time, a good 150 years, probably longer. And then along came digital products in the last couple of generations, okay? And the digital product mindset introduces new habits. And again, I'm using this word habits, okay? We could call them methods, but I think of them as habits. So we create new memories, we fall back on those new memories, we start acting differently. This list of six items was, is a very short version of a longer document. I was a little bit involved in this at GDS, this is government digital services again. And what they, the challenge was after about a year or two of they built a website called gov.uk which is still running on still the original, you know, it was designed as a Python Django website. Most of government source code is open source and it's on GitHub. So if you go to GitHub and look for GDS team, you'll find the whole gov.uk website, all of the code is there. So yeah, so digital product mindset then. So when GDS started, they were basically building a website. They were replacing a government website with a new website. And that was a very deliberate choice. They said, we don't wanna do anything transactional, anything complicated like that. What we want to do is make a read only, make just the published side of government but make it really, really good. And so that was the model they went after. And that worked really well. They had a small team, about 30 people who built this thing in a number of months and it was a very, very successful delivery. Then what happens is you scale. So then they went into 25 different government departments and tried all kinds of things that people want out of government. Renewing a passport, driver's license, things about legal system. There's a whole bunch of ways in which you interact with government. And they built lots of little pilot, they called it exemplar projects for this. And what they realized was people were saying, you know, this is great. This is great when you've got a team of like a dozen people. But what if you have something like tax? When our tax is many hundreds of people, maybe thousands of people working on tax, not because they're inefficient, because it's a very big problem. Okay, so tax is, you know, personal tax, corporate tax, sales tax, all kinds of different inheritance tax, all kinds of different taxation systems that are all different from each other, separate from each other, implementing really complex law and accounting practice and whatever else. And so it's a wide problem. It needs lots of people. And so they said, we need to think about governance. So I did some work with the UK government thinking about governance. And this was one of the outputs, is they said, governance, if you want governance in a digital product world, here are our six rules. First rule, don't slow down delivery, right? I love the idea that PMOs, I spoke to a PMO at a well-known online ticketing firm and he's the head of their PMO. And he said, the first rule of the PMO is to get out of the way. And I was just floored. But what a brilliant insight. And it's not just to get themselves out of the way, it's to get the company out of the way, is to allow people to do work. So don't slow down delivery. The second rule, if you like, of governance, of agile governance, digital product governance, is make decisions where they're needed at the right level. So we don't have all this stuff bubbling up to the top top people who are massive then bottleneck for decisions and they're also very different distance from the information. Instead, we push the responsibility down into the organization. So we federate the responsibility. Do it with the right people. So this is our, again, our cross-functional teams. This is making sure the right people are involved. Go see for yourself. It's a really important rule. So rather than relying on reports or indirect information, Dave Snowden again used this lovely word earlier today, disintermediation. Get rid of the intermediaries. If we can disintermediate information, we can make better decisions faster. Only do it if it adds value and trust and verify. So let's take a look at what this means then. Well, the first thing this means for not slowing down delivery is we want to automate all along the value stream. If we can get into that habit, that's a really good habit. If we can shift left on testing, on infosec, on compliance, on any of these things that are usually kind of gatekeepers, stage gates at the end of a process, rather than that, we shift them all left into our delivery model. So we're doing testing all the time. We're thinking infosec all the time. We're thinking compliance all the time. Then by the time we get to release, did you do the things we discussed? Yes, we did, right? So much, much shorter conversation. Decisions when they're needed. Know that we don't know, okay? And again, so the industrial model is upfront design, upfront analysis, upfront project planning. Because we know, we may as well, because we know. And what digital product thinking says is we don't know. So that's a crazy time to make these decisions. We'll defer those decisions. So now our leadership defines the boundaries. It says what we're allowed to do, but then we make the decisions ourselves. Do it with the right people. You build it, you run it. I'll come back to this idea in a moment. You build it, you run it. And it's a phrase by Werner Vogels, Werner Vogels, who's the CTO at Amazon. He's been a CTO there for a lot of years. And the idea behind you build it, you run it. Is, again, it's the diametric opposite of make versus operate. You're saying that teams make and operate their own stuff. So the same people who build the thing, run the thing. And when you run the stuff you build, you're literally carrying the pager. You're on support. You're speaking to angry customers. You're debugging in the middle of the night. Suddenly, do you know what? It makes you a much more careful driver. And this again was a lot of the impetus behind DevOps and behind continuous delivery is that if you have development teams carrying the pager, then you have an immediate and very visceral feedback loop. And we still want specialists, right? I still want someone who can look at a big complicated Nali database and understand how to interpret a query execution plan, understand where to put indexes, where not to put indexes, where to partition tables. Those sorts of that sort of skill set takes years and years to learn, years and years to acquire and lots and lots of mistakes along the way. So I want those specialists. I want someone who can understand why a network packet is taking a few microseconds longer than it should to get across a network. I want those sorts of nerds in my team. I've been those sorts of nerds. It's a lot of fun. But what I do is we don't have the DBA team. We don't have the networking team. We embed those specialists in the teams. Okay. Go see for yourself. And this is again, team members, developers interacting directly with customers. Again, reinforcing Dave's Snowden's point from earlier, disintermediation. That's my new favorite word. I didn't know that word before today. Only do it if it adds value. So I describe three types of work that I think of as value-adding. The first is delivery. Shipping features to people. Okay. But obviously making sure they're the right features and we do that by the second one, which is discovery. Okay. We're going to do learning. Yeah. We're going to do learning through experimentation, learning through customer research, learning through trying to disprove our hypotheses. And the third is Kaizen. And Kaizen, I've broadened the definition. So the strict definition of Kaizen is about process improvement. So things that improve typically a production type process. I think of Kaizen as anything that improves the system of work. So learning is Kaizen. So if I know that I have a bottleneck in terms of say Java development, or in terms of people who understand how phone calls get routed through a complex network. If I know I don't have those skills and people in my team are learning those skills, that's giving me a different system. That's giving me a system where I now have more people with those skills and that gives us higher capacity for that kind of work. So learning and training, you know, the counterpoint to that. If Nuresh knows something that I don't know and he takes the time to teach me, that's both of us are now out of the game, right? Where both he's taking his time to teach me, I'm taking my time to learn. We're not doing other stuff. Okay. That's first-class work because we come back with a different system. I now know that stuff. So that's Kaizen. And the last part, trust and verify. This is a, I discovered this is a Russian proverb. Trust but verify, you know? And it sounds like it's counterintuitive. You know, why are you verifying if you trust? It's not quite that. Trust and verify says, I'm pretty sure you know what you're doing. What I'm gonna do is look across a whole load of other teams. I'm gonna have a different perspective than you have. And therefore I can help you make good choices compared to other people's choices. So a lovely phrase from Adrian Cockroft who was the head of engineering at Netflix when they migrated from on-prem into Amazon. He says, hire smart people and get out of their way. It turns out a lot of organizations, particularly tech organizations, are very good at hiring smart people. They're then very bad at getting out of their way. And so the smart people come in and this is into like banks and insurance firms and big companies have big problems and engineers like big problems. So they come in with all these ideas about how they're gonna attack these big problems and then they can't get anything done and then they quit. So this is our trust and verify model. But now if we look at industrial habits, those industrial habits then clash with the product mindset, okay? So in an industrial world, we have release coordination, right? We have a cab as a gatekeeper. And now in ITIL terms, the cab is a change advisory board. Okay, so in other words, they advise on how to make change safely. In a lot of organizations, the cab is a gatekeeper on the way to production. You know, it's a meeting or a document or something that has to be done. And then likewise, you have these formal integration and test stages. Now integration, understanding integration is important. Testing is important. They don't need to be stages at the end of a process. What they can be instead is continual activities during development. Decisions when they're needed, what do we see in industrial habits are about upfront technical and visual design? Why would you not make those decisions then when you know that you know the answer? And we do work breakdown then. And we can prioritize and design, I'm sorry, priorities and design are mandated from above because they can be, because we know what the product needs to look like. Doing it with the right people, I can separate, make and operate because they are such different things. And all of the specialist work happens outside of the team. So if I need networking support or if I need integration with a particular ZACCOT system, then there are teams that manage that COT system or teams that manage network support and the work moves around the organization rather than the people coming to the work and collaborating on it. Go see for yourself. Again, we have a separation of business and delivery teams because business teams have one set of incentives and goals and objectives and the delivery teams have another set of incentives and goals and objectives. And it's easier to manage if you keep them separate. That's industrial thinking. In an industrial context, that's right. And only if it adds value is about following the process. And again, this is minimizing variance. We do it because the process tells us to do it. This again is what Dave calls process-based control rather than dispositional control. And then finally, trust and verify. Rather than trust and verify, which is when something goes wrong, we work as a team, we collaborate to find out what went wrong and what we want to improve. When something goes wrong, we add more process. It's quite a typical thing, is we add more process. And then when you come along much later, you see layers and layers and layers of process and you can almost do archeology on it or anthropology on it. You can look at what probably happened in order for these new layers of process to appear. One of my favorite illustrations of this is if you look at the C suite in a large organization, the chief officers, you can tell what happened. So if they have a chief product officer, it's because at some point their product management was going really badly. So they brought someone in to fix it. If they have a chief security officer, CISO, Chief Info Security Officer, that usually means they had a massive security breach and then they had to hire someone to maybe look after security. So you get all these chief something officers is looking back on problems we've had and saying, oh, you know, we need all these people. But I'm not here to bury industrial thinking. And this is, I'm eating humble pie here. I've changed my tune on this. What I've realized is agility at scale requires both of these mindsets. It's not that we've evolved beyond industrial thinking into product thinking. It's that we are very, very good at industrial thinking. And rather than that being the only tool we have, we also now overlay digital product thinking and we have the best of both. So what does that mean? Well, that means that we have teams that build and run their own products. And that gives us that rapid feedback, which is fantastic. We also have the tech ops folks and they build and run what I'm referring to as runtime as a product. So runtime as a product is much bigger than PaaS or infrastructure as a service. That's a small part of it. But the runtime as a product is you are building the operability environment for your development teams, for your product teams. So that is self-serve environments. I can provision my own environments, self-serve integration. This is self-serve path to live, self-serve instrumentation, self-serve telemetry, self-serve observability in all my different environments, not just production, self-serve performance environment. So the role of tech ops now is to make and operate all of the pieces that allow me as a product team to self-serve all of the stuff I need for my runtime. A good friend of mine who worked at Google for a lot of years, he said Google's SREs, they're site reliability engineers. He said, they're the best engineers I've never met. And I thought that was a fantastic phrase. He says, you know, I know they exist because this stuff's so good, but I've never seen them because I've never had to, because this stuff's so good. So getting the runtime as a product right is hard and it's different. It's a very different mindset from the operate side of make and operate. We empower teams to adapt for the local case. We know that each product is different. We know that each product team is different. We know that each group of people is working in a different context. But then we harvest and amplify. So what does that mean? That means that we go out into these teams and we look at what they're doing and we harvest that. We say, hey, that's brilliant. Emily's doing this fantastic thing. Ravi's doing this amazing thing in his team. And we say, right, what we're gonna do is we're gonna harvest that and we're gonna make it famous. But you're busy, you've got a day job. You haven't got time to do this. We will amplify this and we will send it out there. And so then we have components for reuse. We have ideas for reuse. We have patterns that we can reuse. And then as an organization, we can scale that knowledge. So now we have teams that track and report on their own progress because we trust them, okay. But the leadership defines the overall expectations. The leadership defines the metrics that matter and they define how we're going to measure ourselves against those things. And that gives us what we call autonomy with alignment, okay. So autonomy is the ability to execute. Alignment is making sure we're all pointing in the same direction. So this brings me to part two, autonomy with alignment. Autonomy then, according to a dictionary, is independence or freedom as of the will, which I rather like. Autonomy requires six things, okay. There are other things it requires, but here are six things. I've been doing a lot of thinking about this and these are the six things I think you need for autonomy. The first thing you need is skills and capabilities. I'm gonna use the example of driving, okay. Driving in a car or having many cars on the road driving around, obviously right now we have this crazy world situation of lockdown, but I've been in Mumbai a bunch of times. Mumbai traffic is the greatest example of autonomy I know. All of these cars and tuk-tuk's and people on bicycles and scooters and whatever else, all moving between each other, all doing independent things, mostly not bumping into each other is kind of miraculous. So let's take one of those people. They need to know how to drive a car. The next thing they need is the resources. They need a car, right, and fuel. There's no point knowing how to drive a car if you don't have a car. That just makes it academic. The next thing you need is permission to drive a car, right? So you have a driver's license and you demonstrate that you are competent to drive a car and then you're allowed to drive a car. Then you need constraints. These are, in driving terms, literally the rules of the road. So your constraints are things like drive on the left. That's a completely arbitrary decision. In the US, in mainland Europe, they drive on the right. In the UK, in India, in South Africa, in Australia, they drive on the left. They just happen to. That was the side they were driving on when they started driving. It doesn't matter. What matters is we all do the same thing. If we all decide to drive on whatever side of the road we like, bad things happen. A constraint is that we stop at a red light and we've proceeded a green light if it's safe to do so. The constraints about how we merge onto highways. So these rules of the road are above and beyond the basic mechanics of driving a car and they mean that we can all drive safely with each other. We then need a goal. We need a purpose. We need a reason for driving. So I get in a car to do something. I might get in a car because I wanna go for a drive and that's okay. So my purpose is enjoying driving in my car or enjoying riding my bike. But there's a goal. And the final thing is accountability. So Kent Beck, kind of famously tweeted a couple of years ago, says, autonomy without accountability is just a vacation. If you cannot be autonomous without being accountable. And so this raises some interesting questions. What would an autonomy spider chart look like if you took each of these six dimensions in your team? And you said, well, on a scale of one being hardly any to 10 being lots, how much do we have the skills and capabilities to do the work we're trying to do? What about the resources for what we're trying to do? And this is all relative. This is all relative to what you're trying to do. If what you're trying to do changes, it may be that the skills and capabilities in the team are no longer sufficient. So we start with the purpose. We start with the goal and the constraints. And we say, given the goal and the constraints, what skills and capabilities do we need? What resources do we need? What authority permissions do we need? How are we gonna measure ourselves? How are we gonna hold ourselves accountable or be held accountable? And so this is now the term, the new phrase I want to introduce. And this phrase I've been playing with for a while, autonomy, liquidity. Now, some years ago, a chap called Chris Matz, he's been a business analyst. He's largely doing kind of product management consulting these days. He has a very, very deep background in finance and financial systems and trading systems. And he introduced this idea of skills, liquidity. So skills, liquidity is this, is if I have a lack of skills in a team, what can I do? How do I get more skills? And he says, well, it's kind of like financial, you know, like stocks and shares and things. He says, so finance has this term liquidity, which basically means how easy is it to get hold of something, okay? So if I need Python skills in my team, Python is a very liquid skill. You can learn Python pretty quickly from scratch, okay? If you know one or two other programming languages, Python you'll pick up in a week. Python is a very liquid skill. If what I need, if the skill I need is pricing exotic derivatives for trading systems, you might spend 15 years getting good at that. I can't just learn pricing exotic derivatives in a few days. And so that limits or that changes the choices I have, that changes the way in which I might manage that lack of skills. So I've expanded the idea of skills, liquidity into all of those dimensions of autonomy. So each dimension you can think of as an asset. Skills and capabilities are an asset. Authority is an asset. Resources are physical assets typically. But the constraints for an asset, knowing which side of the road to drive on is valuable. Knowing how the game works, knowing how the system works is valuable. Having a clearly defined purpose is an asset. And having accountability is an asset. Knowing that you're doing well, knowing how to hold yourself to account is an asset. So we look at each of these and then we can say each asset has liquidity. How easy is it to come by? And so for instance, authority. Maybe that I need to make some changes to our firewall. I need to make some changes to database configuration. I need to make some changes to how the network works. I need to make some changes to physical infrastructure. Now only certain people are allowed to do that. Maybe that authority is hard to come by. So that authority might be quite illiquid. Likewise, resources, it may be that the things I need to do the work are in short supply. And so they're then illiquid. They're harder to come by. So how easy to obtain or change? And then what I do is I use liquidity as a guide to strategy. So liquidity, again, things that are easy to find I treat in one way, things that are hard to find I treat in another way. And just a note, remember liquidity changes with time. So maybe early on, I find it hard to get authority. I find it because maybe people don't know me and they don't trust me yet. But over time, as I have gained authority in a number of other areas and I've demonstrated that I'm safe, I'm responsible with that authority, maybe then authority comes easier. People can see that I have the permission to do these things. It's probably safe to let me do some other things as well. So let's see how this works. If it's easy to obtain, if these skills or resources or accountability or whatever, if it's easy to obtain, go get it, okay? That's where we go, go get it. I mean, if it's harder, try and borrow some. So in skills terms, that might mean contractors or consultants, in resource terms, it might mean trading with someone or lending some stuff. If it's impossible to obtain, right? Don't waste energy on it, for least for now, okay? So understanding, change what you can, accept what you can't. And again, remember that the liquidity of each of these dimensions is going to change over time. So that's autonomy, liquidity. Alignment very briefly then, I see three dimensions of alignment and again, we care about all of them. Alignment of purpose, why are we all here, okay? So if you look at GEO, I've been working with it as I say for a while now, GEO's purpose is to create the digital society for India, nothing less, it's this huge bold vision, okay? And it's really exciting and that comes through vision, that comes through leadership. Alignment of direction, comes through objectives and key results. I don't have time today to go into OKRs, please, please look them up, there's some fantastic resources on OKRs. They are effectively a way of setting bold goals, which are objectives, and being able to measure them, which is key results. So that gives you your purpose and your accountability. And finally, alignment of method, doing things in a similar way. And this is about practices. And Emily Webber was talking earlier today about communities of practice. That's a much, much bigger topic that I'm talking about now. Communities there are about connection and belonging and support and a whole lot of human factors. One very important aspect of community is about communication, is about learning and is about creating shared ways of working, ways of doing things. And creating shared habits, and that's where the mindset comes from. So we connect people through practices. So autonomy with alignment then. Let's see what happens. If I have autonomy, but no alignment, that's anarchy. That's a bunch of people flying off in different directions. If I have alignment, but no autonomy, I have autocracy. I have a whole bunch of people doing what they're told to do with no degrees of freedom, okay? So my thesis, if you like, my message today is this, is that agility at scale requires both autonomy and alignment, okay? So then we look at agility at scale as a meeting of mindsets, a meeting of, and something else that Dave Snowden said earlier on, he says, you are what you do, not what you say you do. Your culture is what you do. Your culture is not what you talk about. Your culture is how you act. And this is very aligned with what I'm saying here. You don't scale agile. Scaled frameworks don't work, right? You just borrow language from somewhere else and overlay it on what you were already doing. Nothing changes. You can't scale agile. What you can do is you can enable agility at scale. And that comes through autonomy with alignment. And that requires both your industrial thinking and your digital product thinking, okay? Both of those things come together. Alignment comes through those three dimensions, vision, direction, connection, okay? So alignment of vision, alignment of direction, alignment of methods of habits, yeah? Through connecting people through practices. And autonomy then comes through managing liquidity. We manage the liquidity of autonomy through a number of different dimensions. Now, I've gone slightly over time. I do apologize. That is all I wanted to say. So I'm now happy to jump to the, excuse me, the discussion topics and pick up the questions from the Q&A tab. Noresh, would you like to steer me on the questions, please while my screen- Yes, absolutely. Thanks, Dan. This was awesome. I did request, I did ask people if you're okay to overshoot and it was like, yes, absolutely. So I think that's great feedback. I see 694 likes. Let's shoot for 1,000 likes. There we go. Game it. I'm gonna refresh this. I may drop off for a moment. My browser has decided to go on the fritz with the connection. So just give me a moment. All right, we're gonna have Dan back in a second and then we will go through the questions. He's also gonna be around in his, oh, there we are. All right, Dan. So I'm gonna go through the questions. I see four questions here. So we'll try and go through a few of them. And then if there is more questions, we can then take it to your VIP room. So I'm picking the first one which says as we embed specialists in the team, would we need a lot more specialists than before? How do we find the balance? This is a question from Vinaya. I saw that is such a brilliant question. Thanks, Vinaya. So, yes, do we need a lot more specialists than before? Not really. So what happens is this, there's a pattern that I describe which is called near and far. And it was originally pioneered by a company called Object Mentor back in the 2000s. Oh, sorry, just a moment. Yeah, so something happening off to my right. There's, yeah, initially pioneered by Object Mentor back in the 2000s who were one of the early agile software consultancies. So they had folks like Mike Feathers out in the field coaching teams. And the model, what they realized is this is it doesn't matter how experienced the coach you are, how brilliant the developer you are, when you're on the ground in an organization, you're kind of really close up and it really helps to have someone who's got a bit of perspective. And so what they would do is pair up coaches. So the near coach was the person on the ground, the far coach was their buddy. And it wasn't a senior junior thing. You often have people near and far coaching each other or certainly in circles or whatever. But the idea was that say, Nuresh is in there consulting and he's working with a team. And he's the near coach and I'm the far coach. And we'll check in and they'll say, oh, I'm having this real problem. And I'll say, well, let's just look at it from this perspective and I'll go, oh, thank you. Right? And it's not that I'm no more than him. It's that I'm not there. And he could do exactly the same thing for me. And so what we do is exactly the same model but with specialists. So I will still have my networking team. I'll still have my database team. What I'll have though is there'll be database specialists that will parachute into teams in order to help them, but they don't go in there to solve. And again, this is the skills liquidity piece. They don't go in there to solve. They go in there to show them how to solve. They go into teach how to fish. And so the idea is that I might have an infosec person embedded in my team for a few weeks while we look at some security challenges. That person is educating the team in good infosec practice. And so now the team has enough knowledge that they can probably cover off most of it themselves. And this is where we get the T-shaping. You don't T-shap, you T-shap by learning from other people. So we have, and it's okay as well. And I wanna really make this point. It's okay to not want to do that. It's okay as a DBA to be an utter database nerd and to not want to get involved in delivery teams. That's completely okay. So now what happens is I have my little core of DBA specialist team and a whole bunch of DBA specialists that will then parachute into delivery teams as needed. Raising the bar of database awareness, raising the bar of infosec, raising the bar of domain knowledge, raising the bar of whatever it is we need help with right now. Raising the bar of testing. Testing is one of those specialist skills. So you have teams of dedicated testers and that team on their own are making sure they're up to date with the state of the art of testing. Building test tools, building test infrastructure, building things that can scale out across the organization. And they're also available to inject into teams to teach them how to do good testing. So yes, you'll still have specialist teams and what you'll have is you'll have near and far setups of specialist embedded in teams helping tactically helping them move forward and grow. And so they're core group if you like that they go back to creating that consistency. And they will typically be the leads in those practices that I was talking about. All right, awesome, thanks Dan. There are a lot of interesting questions. Unfortunately, we won't be able to take everything. We'll do one last if that's okay with you Dan and then we can take the rest of them on your VIP room. So the next one is from Sakshi, which is she's asking sometimes people show resistance to shift to new practices to an agile mindset which in turn impacts the work culture. Any suggestions on how this can be handled? How can we handle the resistance to shifting to new practices? This is such a brilliant question. It's a perennial question. The phrase I fall back on again and again, I don't know who said this originally. I can probably guess but I'll be wrong is people don't resist change. They resist being changed, okay? People, children, infants are voracious learners. They're voracious experimenters. Every three-year-old just goes, why, why, why? I have a young son, he's just turning three and he started saying why and it came out of nowhere and it's on everything, right? Okay, we're just gonna go to the shop now. Why is we need to buy some food? Why, because then we're gonna have some food to eat. Why, right? And I read up on this and it turns out that one of the reasons that children ask why, they want to explore their world and they found it's a really good way to get adults to open up. They're also testing consistency. They're also testing if they ask why for the same thing a number of times and get the same answer, then they can trust that thing. If they ask why and they get a different answer each time, they know that that thing is transient, that thing changes and so that they need to keep on testing it. And so children have this amazing scientific mindset, this amazing curiosity and we beat it out of them. It's cool, you know, we become conformist and we become rule followers and we lose our curiosity. So really it's about can you make this something I want to do? Okay, I'm not gonna come in and do change at you. Why would I do that? What I'm gonna maybe do is come in and make some suggestions how your life could be better, how your work could be more fulfilling, how your organization could be a more fun place to work in, a more rewarding place to work in, increasing your psychological safety, which is something I've been reading about a lot recently. So how safety you feel asking questions, right? Exposing your ignorance, how safety you feel asking for help, which is exposing incompetence, how safety you feel challenging the status quo, which is exposing that you're difficult to work with. All of those things are criticisms leveled at people or at least they're fears that people have. I fear being viewed as incompetent, being viewed as ignorant, being viewed as difficult. And so I hide behind and Joanne Juncker was talking about this earlier. This adapted system we have, you know, this shell that we put on that looks competent and easy to get along with and I'm dying inside, right? Because everything's wrong. And so if I can say that we can go on a journey together that will allow you to enjoy what you do more, then usually the response is when can we start? So if you can help, if you can set up a change environment, a transition environment in which the people changing are directing their own journey, directing their own change, and accept that it's non-uniform. I mean, we've had this model for 30 years at least, what's called the technology adoption model where you have the pioneers, early adopters, early majority, late majority, laggards, right? They're crossing the chasm model. For decades, we've known that when you start change, you're gonna bring maybe 5% of people with you, right? 5% of people are gonna jump into the new change. Brilliant, find them, recruit them, get them excited, don't worry about the others, they'll come along when they're ready. Okay, and then when they're ready, make it safe for them. So if we try and change everyone at once, we'll fail, we know this, and yet we still try. If we accept that different people are gonna change in different ways at different times, then we are more prepared to help them on that journey. And you co-create that journey with the people involved. And that I tend to find you get much, much better traction that way. Awesome, what a detailed answer. Sorry, I'm going to give long answers. Such a good question. Sometimes there are no easy answers, right? There's no, just, you can't give us, and you just can't give like a silver bullet answer. There isn't one, right? And sometimes, yeah, there are hard questions and there are long answers for that, which is required. I mean, more than long, I think it's deep, is what I would think about. So yeah, anyway, I think we've kind of overshot the time, but it's fantastic always, Dan, to have you. So greatly appreciate that. I would appreciate if you could join the VIP room. There are a lot of people who still have a few questions. So if you could hang in there, that would be awesome. So I think folks know the drill, they click on the VIP button on the left, and then you can search for Daniel and you should see me, Daniel, and you can join the room. I'll help you, Dan, get there after we knock off. So one other thing, I saw there was one other really, I think, useful question to comment on, which also had a couple of hearts, which was, can communities of practice help in improving agile mindset? The short answer is yes, right? Because the agile mindset, and if we think of mindset again as habits, is what you do rather than what you say, then communities of practice are about connecting up people with common interests and goals and values. And Emily Weber, who was speaking just before me, is I think of as an authority on communities of practice, particularly in the context of agility. So please, please hit her up, ask her about communities of practice in the context of agile mindset because she's got a lot of really valuable things to say. Absolutely. All right, fantastic. Thanks again. Thank you everyone. It'll be almost 5,000 likes. Let's push it. That's my fault. I've got a fault that's just pressing on the thumb button now. It's just making it big, Oz. Thank you, everyone.