All right, okay, so thank you so much guys. Well done. Um, so hi. Hello everybody. My name is Bjorn. Oh You really means I'm a techie guy. I've been running cool back in the days For how many years and these days a lot of time the customers and clients Really talk to them about how they build software. How they do it right now How to kind of bring that to the next level modernize the way to do it It's not a secret Give them the kind of conference right here, of course a lot of time talking about Cloud Foundry How do you guys solve for to properly take advantage of that type of cloud-based platform? I'm gonna go beyond a little bit just Getting started on technology and really talking about kind of what happens. I call it like day two development You gotta start on the project things are going great with doing microservices. Everything is fantastic and you realize that there are new challenges coming into play that you may not necessarily have dealt with before and There are things that you need to think about that Maybe a little different compared to how you've been approaching approaching certain types of problems in the past So just as a quick hands up Who here is building microservices today? Quite a lot of people that's awesome How many are using spring? Of course, that was a given. Thank you. And finally, how many are you seeing the spring cloud frameworks? That's great quite a few people. That's awesome. So that means I mean for you guys are doing that It is not just that you're doing kind of Microservices by accident to see that quite a bit around Where they have to be building restful services and they kind of make it work Kind of scared of calling it microservices, but that's really what they're doing kind of by accident and They kind of make it work. Now in this case here It's really about us the story about a team who has his monolithic application It's been around for a long time and it's kind of been growing over time to become this big beast and They realize hey, it's hard to maintain this thing. It's hard to add more features to it We're not really confident in ourselves when we're trying to do anything to it either what it's going to work afterwards fixing bug and bugs and Releasing those bug fixes is always being really nervous doing it at three o'clock in the morning all that good fun stuff That comes along with That kind of applications over time and of course nobody wanted to end up there But that's kind of where you end up over time. So it was a good story about how the unearth that happened. But anyway There's only realized that hey, we need to do something about this We're following all the best practice everything that but people are preaching in terms of splitting up into two pizza teams Because that's what we're supposed to be doing. We're going to do microservices and everything is going to be great, right? Sans fantastic and of course if you're gonna do the microservices Yeah, you better be doing it on Cloud Founder, of course, that's a given so far so good Well, there are some questions coming up as well when you start going down this path and One is a very basic question, which is a matter of communication How do these teams work together to start building something that becomes a solution as a whole and Because you're gonna have find that some teams are more concerned about building services that others are supposed to be consuming And you would have to think like well the answer to that question is a very straightforward I mean you do restful services you use some Jason and you get to go. I mean, it's not that complicated, right? And technically speaking, it's not The bigger question is how do you make sure that the service are built are actually the right services are to be consumed by whoever is going to build more of the front end and What you tend to do then it's okay Maybe you'll do some actual teamwork you'll sit down you look at the requirements see what the business wants and you come up with an agreement Specification in terms of in order to deliver this functionality These are the APIs that I need so you get the point where you get an agreement on that You write it down put into a nice shiny word document I regret everybody's agrees upon you save it somewhere and then you kind of forget about it and That sounds like a good quite good strategy right and ideally speaking when you do that You set up in a way so that the team was building the services they get started They get start building all those great API So you're looking for when those that team is done building those APIs then the front-end guys and gals can get started and Build their front-end they can consume those APIs and we're all happy everything is fantastic Well reality is that it doesn't always work this way Really what tends to happen is more is that that API that you're relying on that that is under construction It's gonna remain under construction for quite some time you realize so not you're on different teams with different priorities Where you as a front-end team you realize that you cannot afford to wait For the other team to actually finish their work before you can get started because if you do that You're gonna miss your deadline and you're gonna look bad and that other team they say well We're busy with something else at the moment, but we promise we are gonna deliver at some point and it's gonna be Just in time for when you deliver need to deliver your stuff So if you know that kind of situation you have no way of Influencing that what are they supposed to do? Well What tends to happen or very common strategy to kind of address that is To start marking up those APIs that you need so in that way you as a consumer you don't have to wait For the producer to build those APIs that you rely on you take a look at that word document I was created you look at the API is there and you say it. Okay. This is the stuff I need. I'll just Walk that up myself not a problem And in that way I can keep on going at the pace that I want I'm not being held back by anybody else and I'll be good I'll get to where the point where I need and all my unit tests in my CS system They're running green and everything is good and everybody's happy, right? And That's not a bad idea. I mean If you think about it with the spring framework We've been preaching Mocking as a part of a unit testing strategy for 10 plus years now It was one of the big things that the spring guys Started preaching back in the days and it really has some real benefits Especially when it comes to doing proper unit testing and being then doing focused unit testing It also helps because we're not relying on the real implementation to even exist yet Which means that once again the consumer gets implemented faster Consumer build runs green. We're happy. We're not really held back by everybody else and the only caveat To what we're doing here is that we can't really do proper end-to-end integration testing because In order to do that kind of integration testing what you're going to be integrating with actually has to exist so we'll have to wait with that and One day when the other team is done with the service that we depend on then we'll flip some switches will turn out integration tests and Hopefully this will work because this is the last thing we need to do before we actually go into production, of course Doesn't go that well And these are the actually the fantastic kind of Bugs and errors to deal with it because they always happen late in the development cycle when you're the most stressed out You're almost done. Just make this thing work together. Everybody.  It's expensive And not at least it's extremely stressful to deal with this stuff so what went wrong well You got really two different worlds you're dealing with here that are compete that are going against each other you got that unicorn world on the one side where You as a client-side developer you're looking at the world through your Your view the way you think it should be working and you mock it up and you make it work and it turns out that that world does not match the real world and the real API that gets built and It will and there are of course a lot of good stories around like why that happened I mean, there is always a good reason for it. Sometimes things get lost in translation sometimes You realize that we had to make a few changes here they either in order to implement the client or the server in the right way and Tried to put into back into that word document that nobody reads anyway, and it just gets lost on the way There are also some more fundamental problems here that just adds on to the damage and kind of sets you up not for success but failure Somebody boils down to who's actually managing those stuffs in the first place Yes, it's the clients and needs them But if they're holding on to them if they're building them that represents their view of the world and their their Interpretation of what's needs to be delivered the best they can Which may not necessarily be the same as What's actually going to be delivered by the by the server team It also means that those stops are not being used to validate that their server team actually builds the same thing Saying that we have different two different implementations essentially that may or may not match So the question is then how do you even guarantee that those steps are valid? You built them You hope they work But you have no way of guaranteeing that they work and you may actually make them work at day one When you do your version one point over release of your software But as time progresses as you keep on changing the system do maintenance on it it becomes hard and hard to actually maintain these things And to make matters even more interesting if you're running an even larger project. We have multiple consumers Relying on the same service that is not there yet. You are gonna end up in a situation where you have multiple teams building multiple stubs multiple mocks of the same service and Not even them may actually look the same way So that way you have duplication of effort and if you're unlucky you have not only a Duplication of effort, but we may have multiple views on how the same service should work And they may all actually be wrong, which just makes matters in worse for you. So What are you supposed to do? I mean does this mean that this was a really bad idea? Not necessarily I mean mocking itself is not bad and especially I mean if the producer doesn't even exist What on earth are you supposed to do? there are however some Philosophical things in terms of how we approach this problem that is Worth emphasizing in the rethinking compared to the way we're usually used to thinking about Service providers and their APIs they provide first of all if you think about where your requirements Usually tend to come from they come from a business user somewhere and they view on the world Very often it is more in terms of from an end user point of view I need to this user needs to be able to do these and these things so I mean it's already there the Requirements and who's actually driving the API itself. It's actually coming from the consumer not from the server side It's not then so that that's one aspect of it that also means that not only should the consumers take part in defining the APIs But it also means that they actually should be the ones driving the design of the API and really telling these These sort of things we actually need and this is really what is a concept called consumer-driven contracts That is a concept that really reinforces that in terms of who is actually supposed to be Defining these contracts and defining the APIs is not necessarily The service side people who are building them It really is more matter of that letting the consumer the customer in many ways define what they actually need and I Think for us as people that's a very different way of thinking compared to the way where you used to Dealing with things like that. I mean if you think about it also is techie people We're used to seeing you less all over the place And user license agreements rise a lot of text and you have two buttons underneath it Accept or decline and you have no choice There's no way for you to negotiate this thing same thing you go and buy a new cell phone And you get this enormous contract by whatever cell phone provider you're dealing with and once again The only option you have if you want that service is to sign the dotted line And it's really the provider of the service you're buying that holds all the power in terms of what you actually get to do This is a different way of thinking we turn in the tables completely on this We're saying is really the consumer who knows best what they need and they are the ones who really should be Driving what actually gets delivered In addition to that that API specification that end up very beautifully in the word document earlier That should not just be this thing you write down somewhere and you leave it It really should be a specification that is written away So you can actually use it to generate stubs That you can use for mocking on the client side automatically So in that way you don't have to duplicate that effort and in the same way you should use the same Specification to validate that the producer implementation actually follows that specification And that's very important because that means not only do you define a contract in terms of what's supposed to be delivered Do you actually use it to both validate what happens on their service side and on the client side? Which means that if the contract is well written They'll the behavior between the will actually start lining and that's really where spring crowd the spring cloud contract comes into play And it's really a framework for consumers to drive the producer APIs through contracts What do I mean by that? It means that it's a way to define these contracts in a machine readable way through DSL's It's contracts that you store as part of your source code Manage the same way and that we can actually use automatically to get some value out of it That means that we can take these contracts and use them to validate that producer is actually working the way we expect it to And it means that we can take the very same contracts and use it on the client side to generate stubs Saying that way if you need to do mocking on that end we do that based on the very same contract What's the value of that it means that we can actually reduce the amount of end-to-end integration testing We need to do and we still need to do them of course, but The amount of bugs you're gonna find there is Are then going to be reduced dramatically Needless to say I'm in spring cloud contract is Java centric spring centric You're gonna find that if you're using spring cloud We can actually stub out completely frameworks like Eureka console and so forth And it's got a few different projects involved there both in terms of helping you use those contracts to validate the service side on the back end We also use wire mock to Generate more of a more stubs and that kind of things as well And we also have some neat frameworks into play So you use it from a client point of view can go out there and actually download those contracts on demand and Plug them into your project for your testing So what is a contract? Well? Here we're gonna example of it and it's essentially a groovy script And if you look there this little example of a guide here It's a login example Calling a login service in the upper half there You can see that we call this user login service to provide a username the password And then on the bottom here we were describing. Okay giving that input This is the kind of output. I'm expecting And I do I do understand I mean this is a very much a simple example The reword is a lot more complicated than that We're dealing with ideas that change all the time timestamps and a lot of information like that And what we do actually let you do when we describe when we define this contract It actually include variable fields like that so you can see it. Okay here I expecting a GUI D back that kind of thing so now we can deal with variable fields. Not a problem This is actually a fairly flexible framework. So let's do a demo See how this thing actually works and I have a Fairly not too complicated demo to show you guys is based on the same kind of login scenario Where I have a login service on the client side that I'm implemented and I've been providing Credentials there my username password when I get that I'm gonna forward that to a back-end service That says yes or no to those credentials and the business logic on that is very simple It's basically that if I get a password in that has mixed casing Then I'm gonna say thumbs up. This is a good password if I had get a lowercase password Then it's gonna be no So by all means this is not a proper login service, but it works great for a demo like this So let's take a look at this how this actually works so First Let's take a look at our contracts here So I have so this so where I'm going right now is I'm putting on my hat as a client side developer But when it comes to the contracts in terms of how the service side function works That is being stored together with the source code of The service side function you can actually decouple it completely so you can have a separate project with just your contracts It's up to you how you want to manage that and in this case here have two different contracts in here I have one describes the use login service with my username password and I get it okay result back And then I have another Example here for username bad password or lowercase in this case is not okay So this is kind of my contract here to find that I can get positive result back and a negative result back So what I do then is I can actually plug that into my client code And I've written some unit tests here That is testing that login function I implement on the client side So I have the same use cases here my username good password Okay, and the same way bad password not okay and To wire this all things together What I've done as well as I have a Annotation up here That's telling me to set those tells spring cloud contract to set up a stub runner So when I'm running these units test whenever I'm calling out to the backend service here It's actually going to stub out the services that I need in order to make this make this happen And the way it actually gets to those stubs is actually through a maven repository So really what I'm doing here is I'm referring to This is a package is this is this is a this is a component where my stubs are stored in a stub section in there I'm telling it to work offline in this case which basically means it's that on I'm not on the public internet right now We don't have a maven repository in the server somewhere So in this case, I'm actually leveraging my cash repository my laptop for it So that's what I'm saying telling to work offline in this case And I can run my unit test We'll now see that yep everything runs green everybody's happy everything is looking good now After implementing this so that show this to the business users they were like yeah, this is good But we've been reading up a little bit on security and stuff and we feel like Just saying that okay mix casing for user and password. That's not good enough You've got to have mix casing and some numbers in there in their trade in order to make it a valid password You know, okay, we can do that. We'll implement that so let's change our Unit test a little bit. So my password is not good enough anymore We need my password one two three in order to make that run and we also want to emphasize that doing bad password with Mix casing is also no longer good enough So implement those changes For my unit test and of course when I do that These tests are gonna run red. They're gonna fail because they're not according to The behavior of the service I'm calling the back end. So what do I need in order to fix that? Well for me as a client-side developer There is no way for me to fix that implementation because that's a different teams responsibility to do What I can do in this case is at least Start the conversation with that service side team and say hey We need to make some changes to the contract we have in place here to accommodate these new requirements that we got So what you do that is you check out the code from the service side team And we're not gonna Implement the changes for those for that team. I mean that's their job to do I mean maybe a simple change may be a big change What we can change on the other hand is the contract that we have between Us and that service so we're saying that okay. It's no longer my password is my password one two three Then it's gonna give me a positive result And we're gonna emphasize once again Bad password makes case not a good idea So now change a contract in order to make those changes available for me when I run my unit tests I need to Then maybe install But I'm not gonna rerun all the unit tests in there because I really don't care about that. That's not my job I'm probably breaking something on the service side implementation And that's okay. So all I'm doing now is just building that survey component With that new contract and putting that in my local Maven repository in my laptop right now So now I've done that And I can rerun my unit tests Where he's now using a Different implementation of those mocked-up services and we can see that okay We're good We've made our unit test run green again That means at least from our point of view in terms of what we're expecting This is the right behavior. It's what our business users are asking for So once I've done that then I can go back to the server team I can submit the pull request back to that team and say hey We made some changes to it Hopefully we couldn't talked a little bit about it before in between there. So this doesn't come as a big surprise to them But you made those changes to the contract and it's up to them to pick up on that Cheat those changes whenever they actually have time to do it. So Once they're ready for it And I kind of changed house here from being a client-side developer to server-side developer I could take a look at these changes And I can say well, yeah, that looks okay. I mean if that's what they want, we'll fix that and The first thing I can do then is actually run some unit tests to see if my current implementation aligns with those that new contract and The way you can do that is we have a plug-in as a part of spring cloud contract where they actually on the fly Generous unit tests based on those contracts. So I can do a Maven test of my server code and we're going to see here Build failure something went wrong We're on some unit tests One error here And if we look a little more in the stock trace what happened I'm saying that somewhere here We got an okay when you really expected A not okay result So here I can see suddenly that my implementation of my server code Does not fulfill the contract that I have my client Lucky for me. I mean I know exactly what the problem is and Fixing the bug is not too complicated So let's just fix it Down here has got some code. This is my authentication method When getting the password And up to this point. I've been making sure the password in there somewhere has a lowercase At least one lowercase letter and at least one uppercase letter And the only thing I need to do is Add another check to see that we have at least one number in here between zero and nine So I implement that change rerun my unit test And we're good to go Build success. Everybody's happy. We're all good So in that way, we've taken that change on the contract We've fixed our code. We can check it in Everybody's happy And the only thing that it needs to be done after that is to communicate back to the clients and developers that hey We picked up a change we made to the contract. This is looking good. We've implemented. We checked it in so in that way The only change that the clients that developers can do that at some point is to update their test I'm saying up here work offline Change it from true to false which basically means that when you run the unit test, we're going to download This component here and we're going to take it from our own hosted maven repository instead of trying to rebuild that component Ourself All right, so let's get back to our presentation. So Really, what have we achieved by doing all these things? Well Two things First of all, we improved communication. We've taken The type of information that ends up often in a word document That becomes immediately stale after it's been written and we turn it into an artifact that we can actually Put to good use So that means we're actually taking that information that contract we defined Not only can we use it, but it also means that we'll actually keep on updating it afterwards because there's an actually incentive for us To keep on updating that documentation It also means that we're reducing the risk of failed integration tests They can still go wrong But if you look at the kind of integration test failures you'll have Changed a lot of them you can actually write back to okay if we had a better defined contract between our teams We cannot avoid those failures in the first place That also means we get a better api in terms of That is something that also aligns better to what the consumer needs And it means that That api that contract you use Is managed as source code You can use it for verifying The actually implementation of the server implementation to make sure that one is good It also means that you can use a very same contract the very same specification To mark up your own implementations as well that you can use on the client side So thank you. That's all I had for today. Any questions? Yes So the question is do we have to use this dsl language? The answer is no We there are ways to use other types of specifications as well. I'm not sure if we have support for exactly The notation you guys are using there, but I mean at the end of the day We're open source. We're friendly. So I mean we'd be happy to work with you if that's something you're looking for Another question I'm sorry. I can't hear you Just saying that there are ways to do it. So I mean if you get if your gentlemen want to talk together afterwards I mean that's up to you guys any other questions All right. Well, thank you for so much everybody started for running a little bit over and I do appreciate hardly anybody fell asleep So that's fantastic. Thank you very much


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.  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.  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.  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.  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.   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?  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?  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.  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.  Sorry, I'm going to give long answers. Such a good question. Sometimes there are no easy answers, right?  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.  Thank you, everyone.