1 00:00:00,000 --> 00:00:06,020 well uh thanks to brian we have we have a a guest who actually works in the you know i i don't know 2 00:00:06,020 --> 00:00:10,860 brian it can be said we work in the real world but you know who someone who works in the real 3 00:00:10,860 --> 00:00:14,820 world not the talking with everyone in a consultative way finding out what goes on in the 4 00:00:14,820 --> 00:00:20,720 real world which which i always uh find fun we speak we we anyways i could go on but i've dug 5 00:00:20,720 --> 00:00:25,880 myself into a strange rhetorical trap here why don't you introduce yourself guest oh yeah thanks 6 00:00:25,880 --> 00:00:32,060 having me so i'm mike scaith i'm head of engineering at jlr in the uk as i don't know 7 00:00:32,060 --> 00:00:39,060 um so i'm at a place called the digital delivery center in manchester in the uk so we essentially 8 00:00:39,060 --> 00:00:45,740 are jlr's digital software engineering devops hub up here in the northwest of the uk uh been 9 00:00:45,740 --> 00:00:49,680 here for about five years or so um building various software systems with jlr's i'm sure 10 00:00:49,680 --> 00:00:54,320 we'll talk about in this session uh my background personally so i started out as a software engineer 11 00:00:54,320 --> 00:00:58,460 different types routines of architecture technical leadership now being sort of head of engineering 12 00:00:58,460 --> 00:01:03,920 here so it was a brand new um brand new team brand new capability for jlr five years ago and we built 13 00:01:03,920 --> 00:01:11,500 it out now to being here 100 or so different engineers dev tests sre platform security etc uh yeah 14 00:01:11,500 --> 00:01:19,280 doing some hopefully some interesting stuff uh yeah and and so so it sounds like uh you know you're 15 00:01:19,280 --> 00:01:23,560 you're you're in a part of the company i mean exactly what i'm always interested in where you write 16 00:01:23,560 --> 00:01:28,780 the software i mean you and the people that you work with your group you you write the software 17 00:01:28,780 --> 00:01:34,740 the custom software that uh that jlr uses right i mean which which is that's great you went from 18 00:01:34,740 --> 00:01:41,600 programmer to uh you know managing other programmers and and the bit the big thinking and things like 19 00:01:41,600 --> 00:01:45,980 that which is always a topic on its own so so the first thing i i was i was interested in talking 20 00:01:45,980 --> 00:01:51,200 about is um you know i've i've been around long enough to know at least that i have this kind of 21 00:01:51,200 --> 00:01:57,160 like uh naive understanding of of the software that companies do like it's especially apparent in banking 22 00:01:57,160 --> 00:02:03,200 where like in in finance there's all sorts of stuff they do but my view of banking is just like i log in 23 00:02:03,200 --> 00:02:07,860 and look at my accounts and pay bills and so like anytime i think about software it's always that 24 00:02:07,860 --> 00:02:13,460 and i talk with uh you know some of your peers brian in in your group and they'll be like Coté Coté 25 00:02:13,460 --> 00:02:19,420 that's such a small part of banking there's so many other things that that go so like what is like 26 00:02:19,420 --> 00:02:25,200 when when y'all are working on like the software that jlr uses like what is the software like what does 27 00:02:25,200 --> 00:02:30,580 it do how does it fit into what the business needs yeah good question i'll give you an overview of of 28 00:02:30,580 --> 00:02:34,380 all the different software in general and i'll talk about the bit that we specifically work on i guess 29 00:02:34,380 --> 00:02:40,460 so i mean obviously software is everywhere these days in the automotive um i think the car itself um 30 00:02:40,460 --> 00:02:44,520 is with software so the most obvious part there is what we call the infotainment system that sort of 31 00:02:44,520 --> 00:02:51,100 screen on your dashboard when you sat now apple carplay etc um behind the scenes on the vehicle if you like 32 00:02:51,100 --> 00:02:54,960 there's obviously a ton of other software so i think there's something like close to a hundred 33 00:02:54,960 --> 00:03:00,340 different what's called ecus or electronic control units on the vehicle doing all sorts of you know 34 00:03:00,340 --> 00:03:07,280 braking systems engine management autonomous driving cruise control lights brakes everything's kind of 35 00:03:07,280 --> 00:03:10,860 software control these days right a ton of stuff on there and actually kind of yeah you're embedded 36 00:03:10,860 --> 00:03:18,720 software you see you see the real hardcore um around the vehicle so you've got um mobile apps so if 37 00:03:18,720 --> 00:03:22,600 you buy a fancy jaguar or a land driver you get a mobile app with the car that lets you use various 38 00:03:22,600 --> 00:03:27,980 connected services so you can you know lock and unlock your vehicle remotely you can set the temperature 39 00:03:27,980 --> 00:03:31,980 while you're having your breakfast and warm or cool warm up or cool down your car while you're eating 40 00:03:31,980 --> 00:03:37,640 breakfast you know important stuff like that um and then you've got kind of yeah various systems i guess 41 00:03:37,640 --> 00:03:41,980 customer facing web systems so obviously you can buy a vehicle online you can configure a vehicle by 42 00:03:41,980 --> 00:03:47,360 like your finance tool or that sort of stuff with it we've got you know a service where you can buy 43 00:03:47,360 --> 00:03:53,360 a vehicle on a subscription basis for example um there's various kind of again connectivity around 44 00:03:53,360 --> 00:03:57,360 yeah connected services like um the app i talked about there's various apis around the vehicle that can 45 00:03:57,360 --> 00:04:03,360 sort of do various vehicle we can send software updates to a vehicle which is one of the areas we work on 46 00:04:03,360 --> 00:04:07,620 so i'll talk about a second but then there's other stuff you don't think about kind of scenes again so 47 00:04:07,620 --> 00:04:12,660 like manufacturing plants again all software driven right robots manufacturing systems all the 48 00:04:12,660 --> 00:04:18,140 scheduling of that massively complex or software driven um other kind of business hr systems behind the 49 00:04:18,140 --> 00:04:24,340 scenes as well um design design user software yeah vehicle testing increasingly uses software so 50 00:04:24,340 --> 00:04:28,520 rather than smashing physical cars into a wall we try and use some software to do that and visualize 51 00:04:28,520 --> 00:04:39,140 that seems like an improvement that's fine but improvement less expensive yeah so it's a deadware 52 00:04:39,140 --> 00:04:42,920 essentially right and there's sort of like a finance systems or sort of usual business software 53 00:04:42,920 --> 00:04:49,640 and so the bit where my team specifically fit in so essentially what's called off-board web systems 54 00:04:49,640 --> 00:04:54,600 essentially so uh we're not doing the vehicle the software on the vehicle itself we'll do the stuff around 55 00:04:54,600 --> 00:04:59,720 it so we do a lot of apis and connectivity so that mobile app that i mentioned we do the 56 00:04:59,720 --> 00:05:03,880 um manage the subscriptions and the apis that provision those subscriptions on the vehicle 57 00:05:03,880 --> 00:05:11,080 um you manage that system that allows you to buy a vehicle subscription so rather than you know purchase 58 00:05:11,080 --> 00:05:16,200 or lease a vehicle you can sort of pay a fix and three but kind of all in deal with insurance breakdown 59 00:05:16,200 --> 00:05:21,000 etc you can manage that um yeah big enterprise api platform uh and then something called sota 60 00:05:21,000 --> 00:05:25,960 which is software over the air so that's a software platform for sending software to a vehicle bit 61 00:05:25,960 --> 00:05:30,280 method um but we're involved in that sort of things as well uh and yeah various sorts of web 62 00:05:30,280 --> 00:05:35,720 web systems like that essentially so web apps cloud that's our sort of sweet spot yeah and then yes 63 00:05:35,720 --> 00:05:39,400 again we're not the only engineering team in jail of course there's other teams also there's teams 64 00:05:39,400 --> 00:05:43,640 building that onboard software itself on vehicles most of that's done in-house some of it's done by 65 00:05:43,640 --> 00:05:49,960 partners for example uh but yeah that's that's kind of the sweet spot where we think yeah you know it's 66 00:05:49,960 --> 00:05:56,920 it's it's uh uh i'm i'm always as as a connoisseur i was joking earlier about the the fun world that we 67 00:05:56,920 --> 00:06:01,320 live in like i'm i'm always curious about like what digital means right it means different things in 68 00:06:01,320 --> 00:06:06,360 different domains but as you're going through like like what your group works on it seems like 69 00:06:06,360 --> 00:06:11,800 there's kind of two things one like digital means like you know imagine things that are sort of like 70 00:06:11,800 --> 00:06:17,240 let's say manual i guess that's the opposite of digital or analog right but like kind of analog manual 71 00:06:17,240 --> 00:06:24,520 things and imagine like replacing them with software and then on top of that like if we do that like you 72 00:06:24,520 --> 00:06:30,440 can think about the different sorts of new things you could do like like you know for example you 73 00:06:30,440 --> 00:06:35,960 might have like i'm again with my layman thing of thinking of things you might have like power windows 74 00:06:35,960 --> 00:06:41,880 right which is a very analog manual motor to put in somewhere but if if you made those more like 75 00:06:41,880 --> 00:06:46,760 digital and software driven you might i don't know this is a dumb example but now these power windows 76 00:06:46,760 --> 00:06:51,960 can do a dance right like you could actually send the software over the wire to do things some more 77 00:06:51,960 --> 00:06:57,400 complicated which which i think is like you know that's one of the more interesting i don't know maybe 78 00:06:57,400 --> 00:07:05,640 the most interesting like meaning of digital is like we're using like the fungible agile nature of 79 00:07:05,640 --> 00:07:13,960 software to like change how things work right beyond just like i can make this character bold right 80 00:07:13,960 --> 00:07:17,880 that to actually like change day-to-day activities and and make them more interesting 81 00:07:19,160 --> 00:07:23,640 exactly yeah yeah we we use software to improve the vehicle over its lifetime it used to be in 82 00:07:23,640 --> 00:07:27,080 the past when you'd buy a car and that was it you're stuck with it for life but we can now use 83 00:07:27,080 --> 00:07:31,720 digital and software to get to actually improve that car over its lifetime the best example of 84 00:07:31,720 --> 00:07:39,000 that one is where um our first electric vehicle the jaguar ipace um we've got a racing team in 85 00:07:39,000 --> 00:07:45,000 formula e electric racing series so that's all sort of software based as well and the racing team there 86 00:07:45,000 --> 00:07:49,880 made some software tree tweaks on the racing car to essentially extend the battery life or improve 87 00:07:49,880 --> 00:07:55,640 the efficiency efficiency battery and we were able to then translate that change to the systems 88 00:07:55,640 --> 00:08:00,840 on the ipace road car and send the software update over the air to essentially improve the 89 00:08:00,840 --> 00:08:04,600 battery efficiency of a road car after someone had bought it which is pretty cool right yeah 90 00:08:07,640 --> 00:08:10,520 yeah or or like living in amsterdam the car i have now 91 00:08:10,520 --> 00:08:14,680 uh i just need to get the uh the english version of everything on the dashboard 92 00:08:15,000 --> 00:08:19,240 then that would be nice to get over the air i mean just a very a very simple thing 93 00:08:21,800 --> 00:08:26,120 well that's so it's about to see it so we can we can sort of which on and off features remotely 94 00:08:26,120 --> 00:08:30,760 as well right so a good scenario there is imagine you've got a vehicle rental company like hertz or 95 00:08:30,760 --> 00:08:35,080 avius for example you've got a fleet of jaguar and london vehicle you can configure those per 96 00:08:35,080 --> 00:08:39,640 customer so you can sort of enable and disable features charge back to enable and on a heated seats 97 00:08:39,640 --> 00:08:44,920 etc um right do that through a software configuration over the air as well so the the power of it is 98 00:08:44,920 --> 00:08:49,400 is quite immense the flexibility offers you and the possibilities it offers you going forward is 99 00:08:49,400 --> 00:08:56,440 pretty impressive right yeah manufacturer as well right so that you're building the same car or you 100 00:08:56,440 --> 00:09:01,320 know many similar components but you're you're just reprogramming the software either at time or or 101 00:09:01,320 --> 00:09:06,040 remotely um there's still as well there's a big challenge as well when you're when you think about 102 00:09:06,040 --> 00:09:11,160 those electric windows it's not just some software from jaguar that are deciding when you push this button 103 00:09:11,160 --> 00:09:15,400 it goes up and down you're going to have components from bosch and other manufacturers 104 00:09:15,960 --> 00:09:20,680 tying that all together so you have all the same problems that you'd see like we see in the 105 00:09:20,680 --> 00:09:26,440 enterprise of older software talking to newer software apis abstraction layers and everything 106 00:09:26,440 --> 00:09:31,640 in between is it the same for jaguar as well uh yes it is it's very very complex the vehicle's 107 00:09:31,640 --> 00:09:35,160 massively complex like i say i think there's something like a hundred different ecs in the vehicle 108 00:09:35,160 --> 00:09:39,960 or something like that um a lot of them are built in house actually we were quite looking 109 00:09:39,960 --> 00:09:44,120 general a lot of it was bought in house a while ago and yeah there is still components from yeah 110 00:09:44,120 --> 00:09:49,560 bosch lg other partners etc um and getting them to interact and talk to each other and i think 111 00:09:49,560 --> 00:09:53,160 dependency management that's the biggest challenge right so when i talk about sending software updates 112 00:09:53,160 --> 00:09:57,720 over the air so say we're going to update one of those modules over the air there's a massively complex 113 00:09:58,120 --> 00:10:02,840 you know world web of dependencies and things compatible versions etc that's very very difficult 114 00:10:02,840 --> 00:10:08,120 to manage so yeah it's very very complex um to understand which version which ecu works with 115 00:10:08,120 --> 00:10:11,960 other versions etc that's incredible it's not trying to coordinate that in such a way that we don't 116 00:10:11,960 --> 00:10:15,640 obviously break someone's vehicle that's the worst case scenario there's a lot of complex 117 00:10:15,640 --> 00:10:19,480 dependency management we have what's called a digital twin that we use which is a kind of 118 00:10:20,360 --> 00:10:24,600 i guess big database big representation of all the different software on each different vehicle 119 00:10:24,600 --> 00:10:29,400 again what version is comparable with which etc so it's a bit of a complex thing it's not like i 120 00:10:29,400 --> 00:10:32,680 guess you're just firing software out like you would maybe you know you can't tear it down like a 121 00:10:32,680 --> 00:10:39,000 kubernetes pod and spell a new one up a bit more complex than that right yeah that's an interesting 122 00:10:39,000 --> 00:10:45,720 point you you raise brian like it's uh it's it's i mean this is a discussion for for another time 123 00:10:45,720 --> 00:10:50,760 or or or here or whatever but like it is uh maybe maybe one of the the key defining 124 00:10:50,760 --> 00:10:54,040 things of like let's call it enterprise software both like 125 00:10:54,760 --> 00:10:59,560 for office work so to speak but also as we're describing here for like like industrial 126 00:10:59,560 --> 00:11:05,400 things is is like at some point just managing your dependencies and everything you work with 127 00:11:05,400 --> 00:11:12,600 becomes almost a huge part of your job like just like if you want to forward something like it's hard 128 00:11:12,600 --> 00:11:19,080 to like you know going back to my now silly analogy you just want to update the power windows and next 129 00:11:19,080 --> 00:11:24,040 thing you know you're worrying about like how the tire pressure is checked and like this doesn't really 130 00:11:24,040 --> 00:11:30,280 make sense on an ideal whiteboard but at some point it made sense which which becomes complicated and 131 00:11:30,280 --> 00:11:37,480 so and so like going like kind of going to a slightly different area but definitely in that area of 132 00:11:37,480 --> 00:11:45,400 dependency management right so like i find that in manufacturing of of of any type uh there is like 133 00:11:46,680 --> 00:11:52,600 there there's this weird situation that that that comes up in my head so one in manufacturing 134 00:11:52,600 --> 00:11:57,000 like i mean it's it's literally like they're in the world with the word you have lean manufacturing which 135 00:11:57,000 --> 00:12:02,680 again from my naive understanding is sort of like one of the better ways to do manufacturing 136 00:12:04,200 --> 00:12:08,920 versus other ways and a lot of what we've been doing in the past let's see what i always have to remember 137 00:12:08,920 --> 00:12:14,840 what what year this is so that i can modify this but in the past like 20 years or so like we in the 138 00:12:14,840 --> 00:12:20,200 software world have been trying i think genuinely sincerely very hard to like learn from lean 139 00:12:20,200 --> 00:12:27,160 manufacturing and and and the way that it works and you know i'm often curious in manufacturing 140 00:12:27,160 --> 00:12:33,320 organizations like how that's going for the software people right like how the application of lean sync 141 00:12:34,040 --> 00:12:39,720 think uh kind of manifests itself in the software world because in theory people working in software 142 00:12:39,720 --> 00:12:45,080 manufacturing companies would be familiar with it and you know you might just run to someone in the uh 143 00:12:45,080 --> 00:12:53,000 the cafeteria who's like oh yes i'm a triple judicious black belt of whatever so i'm here to answer your 144 00:12:53,000 --> 00:13:00,600 questions about it but like but like how how how do you apply like lean think to the software process 145 00:13:01,720 --> 00:13:06,200 good question for you yeah and they are two very different worlds inside jlr specifically i think 146 00:13:06,200 --> 00:13:09,880 if you go to one of the manufacturing plants and you haven't got a chance to do that it's quite 147 00:13:09,880 --> 00:13:15,480 mind-blowing the automation there and the process there it's incredible to see in action um and yeah 148 00:13:15,480 --> 00:13:18,680 some of the some of the cultural aspects as well so there's something called the and on cord where 149 00:13:18,680 --> 00:13:22,360 you can pull this cord on the manufacturing line anyone can pull it if something's going wrong 150 00:13:22,360 --> 00:13:27,240 everyone sort of mobs around an issue review it have a post-mortem if you like after the incident 151 00:13:27,240 --> 00:13:32,680 and all that sort of cultural stuff is there in the manufacturing plants but in the digital world 152 00:13:32,680 --> 00:13:36,520 the off-board software world before we arrived a lot of that wasn't in place it was very 153 00:13:37,640 --> 00:13:42,920 old school if you like it was you had waterfall development not agile etc it's kind of weird it's 154 00:13:42,920 --> 00:13:46,040 kind of weird how you've got those two worlds because like i said there were plenty of people in the 155 00:13:46,040 --> 00:13:52,520 business who understand those principles of lead maybe haven't related them to devops and i don't 156 00:13:52,520 --> 00:13:57,800 specifically they understand the culture side of it and understand how that benefits um well yeah they 157 00:13:57,800 --> 00:14:03,480 are very two very different worlds i think um i guess that that's one of the roles that our team's 158 00:14:03,480 --> 00:14:08,600 played here has been trying to sort of not force but yeah sort of drive some of that transformation to 159 00:14:09,320 --> 00:14:16,120 those similar ways of working some of that similar culture in the digital as well um and it's tricky so 160 00:14:16,120 --> 00:14:20,200 so again i don't know if this is jlr specific thing we've got a lot of people in digital who you 161 00:14:20,200 --> 00:14:25,400 know have been here for 10 15 20 30 plus years they've never really known anything other than 162 00:14:25,400 --> 00:14:31,000 jlr software development so there's been a bit of an education piece there um then there's sort of 163 00:14:31,000 --> 00:14:36,360 actual transformation work as well so we've tried to introduce introduce things like ci cd that was a 164 00:14:36,360 --> 00:14:42,040 whole battle in itself i'm sure we can talk about um agile ways of working again that's all quite new 165 00:14:42,840 --> 00:14:46,280 and i'm sure we'll talk about how that ties in with some of the other processes like finance etc 166 00:14:47,880 --> 00:14:53,320 the point you know it's very traditional dev support dev test support separate teams separate 167 00:14:53,320 --> 00:14:57,720 parts of the process all that needs to change as well um so yeah the the assumption real perspective is 168 00:14:57,720 --> 00:15:02,760 right why is the whole business not working in that same way but for whatever reason the software the 169 00:15:02,760 --> 00:15:07,640 digital the it side of it was lagging behind and it's still sort of going through that transformation 170 00:15:08,520 --> 00:15:12,760 i guess part of my challenge is then yeah is trying to relate what we're talking about in that world to 171 00:15:12,760 --> 00:15:17,720 what they know in the manufacturing world and how there's similar similar concepts in the core pathways 172 00:15:17,720 --> 00:15:24,520 like i say that's the trip to it really yeah yeah well well brian tell me like like you especially 173 00:15:24,520 --> 00:15:31,400 nowadays like like me you talk with a lot of different organizations right and like uh i i wonder 174 00:15:31,400 --> 00:15:38,120 like there's that gap between like like you know here lean thinking in the core business versus like 175 00:15:38,120 --> 00:15:42,200 i don't even know how to express it but the theory that i have and this is what i i don't know looking 176 00:15:42,200 --> 00:15:48,120 for i'm always looking for validation but you know it's it's it's it'd be interesting to kind of like 177 00:15:48,120 --> 00:15:56,760 help shape the theory is that i think historically most organizations kind of think of software as like 178 00:15:57,960 --> 00:16:05,480 a supplier like like in the same way they might ask for like you know we don't just need like like the 179 00:16:05,480 --> 00:16:10,600 standard binder clip to hold our paper together we need this special binder clip but really i'm going 180 00:16:10,600 --> 00:16:14,520 to draw you a picture and i just need that binder clip and just deliver it to me right there's there's 181 00:16:14,520 --> 00:16:19,320 not sort of like a more sophisticated understanding you know like a product management approach to binders 182 00:16:19,320 --> 00:16:24,360 clips would annoyingly be like well let's step back what are you doing with these binder clips 183 00:16:26,120 --> 00:16:31,000 but i i don't know it seems like a lot of organizations just think of software as like 184 00:16:31,560 --> 00:16:37,240 an off-the-shelf thing and and therefore i don't know they don't kind of craft this more agile way 185 00:16:37,240 --> 00:16:45,240 of thinking about it intuitively or something so to to really milk your um your story about power windows 186 00:16:45,240 --> 00:16:51,480 um so i always love a good analogy especially when it gets silly um like if you think about a power 187 00:16:51,480 --> 00:16:55,880 window like in a modern car as mike was saying you've got an ecu that's connected to computer 188 00:16:55,880 --> 00:17:01,800 there's dependencies software programmed it could be put in many different cars but there'll be an 189 00:17:01,800 --> 00:17:07,080 engineer somewhere that just says why can't we just have a switch connect to a motor that just drives 190 00:17:07,080 --> 00:17:12,680 that it'll be nice and simple it'll be straightforward it'll be easy to easier to fix easier to to work with 191 00:17:12,680 --> 00:17:19,640 easier to design perhaps and it's only when you look at the the full picture of well actually that means we've got 192 00:17:19,640 --> 00:17:26,200 extra wires running into that door frame that means that we've got more things that can physically break 193 00:17:26,200 --> 00:17:29,720 it means that we've got a different switch in different cars so it affects the manufacturing 194 00:17:29,720 --> 00:17:36,920 process i think software is kind of the same you need to have an appreciation for how software can fit 195 00:17:36,920 --> 00:17:44,680 together ideally in a business whereas i think because we use it every day in our lives it's very straightforward 196 00:17:44,680 --> 00:17:49,880 thing well we'll we'll just make it do this or we'll just do that i think that's the difference i think 197 00:17:49,880 --> 00:17:56,520 businesses especially say the last five years have discovered that developing their own software which 198 00:17:56,520 --> 00:18:03,400 on face value seems really complicated right there's massive value there because i think in the manufacturing 199 00:18:03,400 --> 00:18:11,800 industry specifically around cars like it used to be we talked about zero to 60 and engine sizes and 200 00:18:11,800 --> 00:18:18,280 literate and all that whereas now we're talking a lot more about the the technology that's in cars 201 00:18:19,000 --> 00:18:24,120 um you know because i'm working with some some other old moves as well a lot of my social media feeds and 202 00:18:24,120 --> 00:18:31,720 research is full of the younger buyers not that i'm calling myself old quite yet but the younger buyers 203 00:18:31,720 --> 00:18:37,160 that are now looking at cars and they're really upset that the navigation software is not as good as what's on 204 00:18:37,160 --> 00:18:44,680 their phone right so i think challenge of understanding that we can make new value through software but 205 00:18:44,680 --> 00:18:48,440 appreciating that means that what we're going to build might be more complicated and there's more 206 00:18:48,440 --> 00:18:55,560 step and i think yeah carrying people through that process might challenging because we know a different 207 00:18:55,560 --> 00:19:02,040 way of doing it right yeah yeah yeah i get i guess like maybe the way i'd clarify my my foggy thinking 208 00:19:02,600 --> 00:19:09,560 when when i when i was talking earlier is like i guess i guess from my perspective and maybe from the 209 00:19:09,560 --> 00:19:15,720 perspective of the three of us a lot of organizations think of software as just like some commodity thing 210 00:19:15,720 --> 00:19:23,720 like it's not it's just like a supply that you buy it's not something that you want to customize and 211 00:19:23,720 --> 00:19:30,680 specialize because you can to really like be part of the product that you're building just exactly you're 212 00:19:30,680 --> 00:19:40,840 saying is like you know a really good like software driven dashboard like including the navigation and 213 00:19:40,840 --> 00:19:46,120 all this stuff is actually like a really important feature like it's it's a new feature that didn't 214 00:19:46,120 --> 00:19:51,640 exist that becomes part of your product so and maybe that's that's where like i feel like a lot of the 215 00:19:52,600 --> 00:20:00,040 consternating if that's a noun you can make into a verb like like happens is that like 216 00:20:00,040 --> 00:20:05,400 all of a sudden if you as an organization want to treat software as something other than a commodity 217 00:20:05,400 --> 00:20:09,640 you've got to give it the same attention that you would the other parts of your core business 218 00:20:09,640 --> 00:20:15,400 and then as you're getting to uh brian and then you discover the complexity of software 219 00:20:16,360 --> 00:20:20,360 right which which was easy to kind of hold if you you know hold back if you didn't want to 220 00:20:20,360 --> 00:20:27,240 customize it uh very much and transforming people right that's always the most interesting part of 221 00:20:27,240 --> 00:20:31,640 all of these journeys is that we can bring you software we can develop all these things we could 222 00:20:31,640 --> 00:20:37,400 hire lots of people but we need to take everyone on that journey um and they're all going to do that 223 00:20:37,400 --> 00:20:44,280 at different speeds universal across all the businesses i've worked with um i'm you know i 224 00:20:44,280 --> 00:20:49,640 generally say people say well i'm working with technology don't a lot of stuff i do day to day is 225 00:20:49,640 --> 00:20:54,760 actually just working with people um and helping them understand what that might look like and be more 226 00:20:54,760 --> 00:21:02,440 empathic in the way that we approach that change yeah yeah so so uh you you can help us get or at least 227 00:21:02,440 --> 00:21:07,320 me get a little grounded here mike i've i've stuck my head way up into the the the metaphor 228 00:21:07,320 --> 00:21:14,040 for like wacky zone uh but as you mentioned right like like i guess about five years ago you were 229 00:21:14,040 --> 00:21:20,520 moving from a uh you know a more waterfall way of doing things right which which i'll presume means 230 00:21:20,520 --> 00:21:25,480 there's a lot of upfront planning like at least on a yearly if not multi-year basis you specify what 231 00:21:25,480 --> 00:21:32,280 you want on day one and if you're lucky you get exactly what you asked for on day 365 232 00:21:33,720 --> 00:21:38,040 right which which you know the clever way of phrasing that is like maybe you don't want it 233 00:21:38,040 --> 00:21:44,200 anymore but whatever right like so you have that kind of long process um so what were like like like 234 00:21:45,800 --> 00:21:51,320 what was first like the in-state goal that you were looking for with being more agile and like 235 00:21:52,520 --> 00:21:58,040 how did you sort of like like what's the broad journey that it took that it took you to get 236 00:21:58,040 --> 00:22:02,840 there and then maybe we can hop into like the little obstacles and you know stories of of each 237 00:22:03,720 --> 00:22:08,360 yeah good question and brian's right here the majority of it is people based as well we'll say that 238 00:22:08,360 --> 00:22:13,240 the software is the easy bit right um yeah of course so five years ago yeah so you're quite right 239 00:22:13,240 --> 00:22:19,800 because a very waterfall um 12 months funding to do a project then it's done that's it give me some 240 00:22:19,800 --> 00:22:23,640 requirements documents see you in six months time when it's finished yeah that's the classic world 241 00:22:23,640 --> 00:22:28,600 right that's what we walked into um in terms of end goal i think it's probably a couple of things so 242 00:22:28,600 --> 00:22:34,760 one of it was around quality of software so making sure you have a real focus like we were just saying 243 00:22:34,760 --> 00:22:39,160 a second ago with sap are becoming more and more a crucial part of business start treating it the same 244 00:22:39,160 --> 00:22:42,920 way we do as it's quality on our vehicles you know we wouldn't send a half built vehicle out into the 245 00:22:42,920 --> 00:22:47,560 world but break them all the time but have the same attitude towards the software so quality was one 246 00:22:47,560 --> 00:22:52,600 part of it and i think speed was the other one as well right so again because software is now 247 00:22:52,600 --> 00:22:56,920 everywhere because software as you just touched on there is differentiated these days but to make 248 00:22:56,920 --> 00:23:03,000 sure that you know we can respond to change quicker changing customer demands that example i gave before 249 00:23:03,000 --> 00:23:07,240 about the sort of extending the back you know being able to sort of make sure we can respond to those 250 00:23:07,240 --> 00:23:11,640 sort of things a lot quicker so so speed and quality i think probably the two two main motivators 251 00:23:11,640 --> 00:23:17,000 there's probably a cost thing in there as well right but yeah um yeah probably those two things so 252 00:23:18,200 --> 00:23:23,320 in terms of the journey um one of the first things we went after in terms of bottlenecks i 253 00:23:23,320 --> 00:23:26,600 suppose what's in the bottlenecks in the process that are stopping that speed at the moment 254 00:23:27,880 --> 00:23:31,640 the main one being essentially getting things into production getting things released 255 00:23:31,640 --> 00:23:37,000 that kind of yeah that release cycle that lead time i recall um so we went after 256 00:23:37,240 --> 00:23:42,040 what jlr calls our change management process which is essentially to get any software change into 257 00:23:42,040 --> 00:23:47,160 a productive environment there's a sort of two week very governance heavy process where you've got 258 00:23:47,160 --> 00:23:52,920 to suddenly raise a ticket in a system it gets reviewed and approved by 87 different people 86 of you 259 00:23:52,920 --> 00:23:57,560 don't have any understanding what the change even is um take the wages to get through that cycle you've 260 00:23:57,560 --> 00:24:02,280 got to agree kind of downtime over a weekend what's your rollback plan but it's obviously the 261 00:24:02,280 --> 00:24:06,280 exact opposite of DevOps right so that's the first thing we went after was how do we 262 00:24:06,280 --> 00:24:11,080 if it's going to take two weeks to do a production release it's going to sort of kill a new attempt 263 00:24:11,080 --> 00:24:16,440 we've got to do is add to our ways of working etc make sure we can sort of do it multiple times 264 00:24:16,440 --> 00:24:20,920 per day so that's the first thing we went after and again the majority of that really was people 265 00:24:20,920 --> 00:24:25,960 side of things it was convincing people about how this fancy new way of working we were talking about 266 00:24:27,400 --> 00:24:31,000 just as good if not better than the original process how we'd still address the risk in the same 267 00:24:31,000 --> 00:24:35,720 way how it was how it was even less risky to do smaller more frequent deployments or good stuff using 268 00:24:35,720 --> 00:24:40,520 automation etc all the vendor reviews etc that's the first thing when we went to that was the biggest 269 00:24:40,520 --> 00:24:45,000 thing the biggest win because that obviously that unlocks everything else right once you can start 270 00:24:45,000 --> 00:24:50,760 pushing things to production no you want it unlocks everything else building in quality responding to 271 00:24:50,760 --> 00:24:55,640 demand etc etc uh-huh yes i'm rumbling on a bit there but i think yeah that's that's probably the biggest 272 00:24:55,640 --> 00:25:00,600 we went after and that helps improve speed improve the quality and we're built on that foundation from 273 00:25:00,600 --> 00:25:04,840 there essentially and by doing that by sort of having that first use case and started to push 274 00:25:04,840 --> 00:25:09,000 out some of our first few releases we then earn that trust to people to say actually okay these people 275 00:25:09,000 --> 00:25:13,320 know what they're talking about um and from there we've been able to build on on the sort of further 276 00:25:13,320 --> 00:25:18,920 change that that resonates with you brian but that's that's the main thing right now it's a great way as 277 00:25:18,920 --> 00:25:25,240 well of showing intent right so people can see that you've made a real world difference in how quickly you can do 278 00:25:25,240 --> 00:25:34,360 something all of a sudden your the rest of your plans might not seem so crazy yep yeah and and well so so 279 00:25:34,360 --> 00:25:40,600 i'm curious like like a lot of what you mentioned was um well not a lot of what you mentioned you 280 00:25:40,600 --> 00:25:48,360 most of it was just releasing the software right was was difficulty and you know does that does that 281 00:25:48,360 --> 00:25:57,000 imply that the actual like programming was kind of fine or or did the the like application developers 282 00:25:57,000 --> 00:26:02,840 did they also like need to change how how they were doing things okay i mean there's there's stuff 283 00:26:02,840 --> 00:26:07,400 around that of course that enables that automated um deployment so far so we're talking about things 284 00:26:07,400 --> 00:26:12,520 like um automated testing that wasn't in place before either um all right all that sort of stuff right 285 00:26:12,520 --> 00:26:18,040 yeah it's just stuff that enables the devops release cycle so yeah ultimate testing the crcd pipelines 286 00:26:18,040 --> 00:26:21,800 all the infrastructures kind of stuff that wasn't there as well so it's all that other other stuff 287 00:26:21,800 --> 00:26:27,160 that underpins the release process if you like the end goal was the faster release cycle and yeah to 288 00:26:27,160 --> 00:26:31,400 your point got here yeah there's some some changes in the way you actually build the software how we do 289 00:26:31,400 --> 00:26:35,720 the test and the fact that we all do that together in one team it's not handed off built tested by 290 00:26:35,720 --> 00:26:39,160 someone else or by something else it's all done with that one team there's that culture well around 291 00:26:39,160 --> 00:26:47,640 yeah the building of the software the end goal being release anytime so so how much like well at least at least 292 00:26:47,720 --> 00:26:55,720 you know in general but in your direct experience how much of the way people work day to day whether 293 00:26:55,720 --> 00:27:01,400 it's in development or operations or like architecture i mean all the various roles that are associated 294 00:27:01,400 --> 00:27:07,560 with getting software out the door how much do you think is driven by that pipeline and and not driven 295 00:27:07,560 --> 00:27:15,720 as in the pipeline does it but driven by the needs of the pipeline right like like analogously like you 296 00:27:15,720 --> 00:27:21,000 can look at the way a city is designed and you can say like ah the city is designed around the technology 297 00:27:21,000 --> 00:27:28,440 of bicycles or the city is designed around the technology of cars right and and you're making me realize i've 298 00:27:28,440 --> 00:27:34,920 always been curious like how the tool drives the culture if if if that makes sense and so like you 299 00:27:34,920 --> 00:27:40,840 have the goal i want to put this the cicd pipeline in place and therefore not only can we change things 300 00:27:40,840 --> 00:27:47,320 like having less manual reviews which is great but we also need to change these things to take full 301 00:27:47,320 --> 00:27:52,280 advantage of it yeah definitely we think that's the approach we took is we tried to use that to force 302 00:27:52,280 --> 00:27:57,240 the change out not force a change way to drive the change elsewhere right to reveal the benefits of 303 00:27:57,240 --> 00:28:02,760 changing yeah or whatever they were it became apparent we couldn't have a separate test team we 304 00:28:02,760 --> 00:28:08,280 couldn't do manual testing we couldn't have this um process yeah yeah exactly that i don't know if we 305 00:28:08,280 --> 00:28:12,040 consciously did that but once we started talking about the need to deploy much more frequently 306 00:28:12,760 --> 00:28:16,440 it kind of unearthed all these other blockers we did to sort of work on as well that makes sense 307 00:28:18,600 --> 00:28:25,080 i didn't remember the answer yeah yeah um i've lost my show i thought i'd be okay yeah well like for 308 00:28:25,080 --> 00:28:31,160 example like along along the area there that i was asking on it seems like like like like one 309 00:28:31,160 --> 00:28:36,120 consequence for application developers is if you are if you're going to be releasing your software 310 00:28:36,120 --> 00:28:41,720 every week instead of every as as let's say every month i mean if you have your final release every 311 00:28:41,720 --> 00:28:46,680 six months probably in development you're at least targeting like a month to kind of like bring all 312 00:28:46,680 --> 00:28:52,440 your code together whatever right you've got your own internal things but once you reduce your release 313 00:28:52,440 --> 00:28:59,640 cycle to like a week um because you want to have you want to support like the cicd doing this like 314 00:28:59,640 --> 00:29:05,640 like like it's it's obvious but it has kind of profound consequences like you can do less each release 315 00:29:06,760 --> 00:29:13,240 right like so you have to force yourself to do less code which sort of forces you as the way you're 316 00:29:13,240 --> 00:29:19,720 operating as an application developer to think in smaller chunks of functionality i don't know it 317 00:29:19,720 --> 00:29:25,800 has all sorts of consequences right and similarly like like i would imagine in operations like if you're 318 00:29:25,800 --> 00:29:32,680 supporting a pipeline like the way you do service request management has to change i don't i don't even 319 00:29:32,680 --> 00:29:39,400 know right but but it's it's interesting to think about like what kind of constraints or what kind of 320 00:29:39,400 --> 00:29:45,480 motivations that you get when you just because you're using a cicd pipeline right yeah even like 321 00:29:45,480 --> 00:29:50,600 architecture for example right so beforehand there was massive monolithic applications now we've moved to a more 322 00:29:50,600 --> 00:29:55,320 macrosix architecture to change things more independently all that sort of stuff and great 323 00:29:56,280 --> 00:30:00,840 all that sort of stuff but and like i say that's mentioned automated testing that's the same thing 324 00:30:00,840 --> 00:30:04,280 if you're going to release it quickly you need to be able to test it much quickly so we can't suddenly 325 00:30:04,280 --> 00:30:09,080 have big manual test scripts that we can work through step by step it's got to be automated and much 326 00:30:09,080 --> 00:30:13,000 more quickly all that sort of stuff comes off the back of it you're quite right um yeah the service 327 00:30:13,000 --> 00:30:17,400 misery piece is another interesting one because again there's uh this is where perhaps we're a little bit 328 00:30:17,400 --> 00:30:23,880 separated from other parts of jlr but jlr's got its sort of traditional it help desk and we kind of 329 00:30:24,600 --> 00:30:30,600 but that's very much um yeah ticket driven manual driven again and we kind of feed the hang off the 330 00:30:30,600 --> 00:30:35,080 back of that with our instant process so that that's my next area to go after and change actually is how 331 00:30:35,080 --> 00:30:39,800 we can sort of integrate more closer with that and yeah you're quite right coach it's it's it's driven 332 00:30:39,800 --> 00:30:44,600 some changes in in the way that we work in terms of building the software but the way that our stakeholders 333 00:30:44,600 --> 00:30:48,040 that we work with think about it as well right so like i said they can't suddenly come along with a 334 00:30:48,040 --> 00:30:52,840 big requirements document and say see you in six months we need that right as well right it's got 335 00:30:52,840 --> 00:30:56,600 to be we need to talk to you on an almost daily basis as well and get your feedback and make sure 336 00:30:56,600 --> 00:31:00,680 you're making the changes in the right way the people side of it as well as the tech side changes off 337 00:31:00,680 --> 00:31:04,440 the back of that that need to release quickly to production which is why that was the first one 338 00:31:04,440 --> 00:31:11,080 that's the enabler for everything else i think is getting stuff out yeah so so you brought up 339 00:31:11,800 --> 00:31:17,800 you brought up a a situation that i'm realizing connects to like this this thing i've been uh 340 00:31:18,520 --> 00:31:23,320 not stressing out but like you know staring at the wall and thinking about like so so the one you 341 00:31:23,320 --> 00:31:30,840 brought up was that to to to phrase it again in an experimental way so we wanted we for reasons of 342 00:31:30,840 --> 00:31:36,520 quality and also for like speed of getting features out so that so you have time to market basically 343 00:31:36,520 --> 00:31:43,000 um and and then also what comes with that is like we can experiments always about a scary word in 344 00:31:43,000 --> 00:31:48,360 manufacturing but we can try new things out business wise and see if it's a good business or not right 345 00:31:48,360 --> 00:31:54,760 we're not committed to like 10 years of something because we decided this thing in the physical 346 00:31:54,760 --> 00:32:00,760 whatever so but you can kind of refine and try out new business ideas um so you put a cicd pipeline in 347 00:32:00,760 --> 00:32:06,520 place so you can deliver things quickly um and as a consequence to that as you were saying like the 348 00:32:06,520 --> 00:32:12,920 way you architect your software has to be different and like microservices ideas are a good fit for that 349 00:32:12,920 --> 00:32:19,240 because microservices is basically like it's kind of like to not go on and on about it it's like 350 00:32:19,240 --> 00:32:24,520 having agility in your architecture by removing dependencies and kind of having smaller things 351 00:32:25,160 --> 00:32:31,400 um now with that same kind of like it's almost like a uh what's the the idiom a cart and a horse 352 00:32:31,400 --> 00:32:36,520 or a mule like which one's leading which and like if i look over in the infrastructure space 353 00:32:36,520 --> 00:32:43,000 i'm often wondering like i mean here we are at vmware we're big cloud native proponents but i often 354 00:32:43,000 --> 00:32:48,920 wonder like can you do agile development because you now have cloud native infrastructure or do you 355 00:32:48,920 --> 00:32:54,440 only do cloud native infrastructure because you want to do agile development right like like what 356 00:32:55,400 --> 00:33:00,120 where does it come in first and so like to that and i'm curious like when you move to this like 357 00:33:00,120 --> 00:33:06,760 shorter cycle like what did it uncover about the way you ran your infrastructure and you did your 358 00:33:06,760 --> 00:33:11,480 release management and all that operation stuff like what did it require you to do 359 00:33:12,760 --> 00:33:17,240 yeah i mean it included a lot of stuff right because i've mentioned things like testing there 360 00:33:17,240 --> 00:33:20,920 i mentioned the change render a bit there's then things like security as well and that's 361 00:33:20,920 --> 00:33:23,720 one of the part we've not talked on yet and then the infrastructure side of things um 362 00:33:24,360 --> 00:33:28,360 yeah i mean i think when we when we first wrapped up five years ago it was the beginnings of 363 00:33:28,360 --> 00:33:33,160 some cloud infrastructure there um jc but again to get that that involved raising a ticket 364 00:33:33,160 --> 00:33:37,880 against the team they'd spin some vms up etc and obviously we realized that that wasn't going to 365 00:33:37,880 --> 00:33:42,200 work for zyber so that that led us to then using things like terraform infrastructure as code and 366 00:33:42,200 --> 00:33:46,600 provisioning that in an automated way as well um that's one thing you're going to call it the 367 00:33:46,600 --> 00:33:50,040 security thing is important as well because again that's where you've got a traditional view of 368 00:33:50,040 --> 00:33:55,000 build the thing do a pen test if you're releasing and again again you need a different approach to 369 00:33:55,000 --> 00:33:59,240 security there as well so that's where we start to build in things like um vulnerability 370 00:33:59,240 --> 00:34:03,400 management and our pipelines etc how do we do more automated pen testing on a more frequent basis 371 00:34:04,120 --> 00:34:08,120 all that things there um then leads to who pays for this stuff we've got to look at furniture i'm 372 00:34:08,120 --> 00:34:12,840 sure we'll talk about that in a second that got all covered there as well um but yeah the whole 373 00:34:12,840 --> 00:34:17,960 it's interesting what came first agile or what i think they're both kind of hand in hand in that 374 00:34:17,960 --> 00:34:21,800 sense we we realized that well we knew from the start that we wanted to work in a certain way 375 00:34:21,800 --> 00:34:26,360 right we wanted to do agile wanted to do DevOps and that led to us uncovering all these different 376 00:34:26,360 --> 00:34:30,440 parts of jlr that sort of didn't facilitate that at the moment and driving that change 377 00:34:33,160 --> 00:34:38,600 yeah yeah i mean i guess i guess another way of of like thinking about it which which i've been 378 00:34:38,600 --> 00:34:46,120 trying to ponder is like why why couldn't you just like use what you already had right like like what 379 00:34:46,120 --> 00:34:55,880 like what uh what was preventing you with like just the infrastructure and the process we've kind of 380 00:34:55,880 --> 00:34:59,960 covered but like the tools that you already had such that you would want to try out new things 381 00:35:01,800 --> 00:35:08,440 good question think about one second you know i i think that's a really good question because i think 382 00:35:08,440 --> 00:35:14,680 this is where i've seen a lot of enterprises stumble and i think the answer is everything like if you 383 00:35:14,680 --> 00:35:23,480 want to build a car by hand you would approach it you'd approach everything in a very certain way whereas if you 384 00:35:23,480 --> 00:35:30,680 want to build 10 000 cars in a factory in a manufacturing line your thinking is different 385 00:35:30,680 --> 00:35:35,800 your culture is different your design is different your parts and management supply chain is going to 386 00:35:35,800 --> 00:35:40,120 be different the way you put them together is going to be different you're not going to start at the 387 00:35:40,120 --> 00:35:45,320 bottom and work your way up you're maybe going to do different panels of 10 cars first you'd be thinking 388 00:35:45,320 --> 00:35:51,560 about your release strategy in terms of having batches so that you can you can see what's changed over time 389 00:35:51,560 --> 00:35:58,200 so if someone reports a defect in a batch of cars you can then make a change or back to the mics this 390 00:35:58,200 --> 00:36:03,720 this concept bikes where you've got this this cable you can pull in the manufacturing process and that's 391 00:36:03,720 --> 00:36:09,640 that's got a real bit of psychological safety in in the workplace right you need to be brave enough to 392 00:36:09,640 --> 00:36:15,080 stop the manufacturing line to say i think we've got a problem let's all gather around and fix it and i 393 00:36:15,080 --> 00:36:19,320 think that's one thing we don't do well enough in software about getting in that tangent just now but i 394 00:36:19,320 --> 00:36:24,520 think yeah and sometimes it's where to begin like that's the nice thing about mike's story is that 395 00:36:25,160 --> 00:36:30,440 he he found a place to begin and start and then made changes and we're still on that journey right 396 00:36:30,440 --> 00:36:35,080 it's going to be you know we're not fixed yet that's why we're still still all in gainful 397 00:36:35,080 --> 00:36:40,920 employment which is lovely for for technology yeah i think it's everything mike is that what would 398 00:36:40,920 --> 00:36:45,480 you say yeah i agree i agree i think that's why yeah you're definitely right we're still on this 399 00:36:45,480 --> 00:36:49,640 journey right i don't want to paint this picture that jlr is this perfect software hustlers but not 400 00:36:49,640 --> 00:36:53,000 um yeah we've got a lot of challenges to fix still um i've mentioned the instant 401 00:36:53,000 --> 00:36:58,520 management side of things there yeah i agree brian i think it included everything um and the cultural 402 00:36:58,520 --> 00:37:04,280 aspect is really interesting to me let's talk about psychological psychological safety um i believe 403 00:37:04,280 --> 00:37:08,360 that's something that we've tried to influence as well right because again there's an element of when 404 00:37:08,360 --> 00:37:12,680 we had our first incidents or first few incidents like okay who do i blame who do i suck for this 405 00:37:12,680 --> 00:37:16,680 thing but we thought that we're going to take our time it's a blameless culture we're going to find 406 00:37:16,680 --> 00:37:20,920 the root cause we're going to review it together and identify how it happens again it's always a system 407 00:37:20,920 --> 00:37:24,440 problem not a person problem all that good stuff that's another part of the journey we've not talked 408 00:37:24,440 --> 00:37:29,320 about yet where yeah the tech is one part of it and that's fine but the the cultural side of 409 00:37:29,320 --> 00:37:33,320 things has been probably a bigger challenge but almost certainly a bigger challenge and try to 410 00:37:33,320 --> 00:37:39,640 change people's ways of thinking around uh like say incidents risk security testing all that sort of 411 00:37:39,640 --> 00:37:45,160 stuff again yeah i agree it it's just pervasive brian you're right so so there there's there's two 412 00:37:45,160 --> 00:37:50,040 two sort of hurdles or bottlenecks that that that i wanted to to talk about before before we run out 413 00:37:50,040 --> 00:37:55,800 of time and you you just one of them is uh as as you keep saying finance which which uh which is 414 00:37:55,800 --> 00:38:00,760 great because people always tell me finance is a problem and i have no idea why so it's always good 415 00:38:00,760 --> 00:38:10,360 to uh to ask people uh but the the other one was um changing how people work or changing the culture 416 00:38:10,360 --> 00:38:13,880 right and then and then i think i think you're hitting on a nuance that i don't think about too 417 00:38:13,880 --> 00:38:21,320 much is changing their perception which is usually fear about something right that's something their 418 00:38:21,320 --> 00:38:30,200 trust about something but but instead of me feeding you ideas as as i as i've kind of been uh allowing 419 00:38:30,200 --> 00:38:36,120 myself to do here too much like like what are those culture change problems like what are the what are 420 00:38:36,120 --> 00:38:41,800 the what are some of the the issues that that you faced because i often feel like if i went and read 421 00:38:41,800 --> 00:38:48,440 like a book on like just you know generic agile software development we could all agree it sounds 422 00:38:48,440 --> 00:38:55,240 great right like we can all agree on this in state that we want to get to but like getting there seems 423 00:38:55,240 --> 00:39:02,920 very difficult yeah there's a few cultural elements so i think risk is definitely one of them um it was 424 00:39:02,920 --> 00:39:08,280 definitely a kind of real risk aversion jlr around software changes possibly driven by you know being 425 00:39:08,280 --> 00:39:12,920 bitten in the past by big releases that have gone wrong etc you know if you're going to do releases 426 00:39:12,920 --> 00:39:17,640 all the time that's that's quite scary there's a risk thing there um and of course the impact of some 427 00:39:17,640 --> 00:39:22,200 of the software changes as well if you're talking about changing software on a vehicle there's a lot 428 00:39:22,200 --> 00:39:25,960 of risk to that right what if that goes wrong and you break someone's car or you know the braking 429 00:39:25,960 --> 00:39:30,920 system stops working or you know it can cause a lot of damage for that so i understand the risk aversion in that sense 430 00:39:30,920 --> 00:39:36,840 um another interesting part and again i don't know if this is jlr specific is i guess i'd call 431 00:39:36,840 --> 00:39:41,720 it siloed ways of working so when we're talking about agile teams working much more closely together 432 00:39:41,720 --> 00:39:47,240 end-to-end um when you've gone into world where you've got you know dev is here test is here release 433 00:39:47,240 --> 00:39:53,560 is here one of our supports there um there was yeah there's lots of very very siloed teams so we've 434 00:39:53,560 --> 00:39:58,920 had to sort of change how those teams work together um we've built kind of cross-functional squads to use the 435 00:39:58,920 --> 00:40:03,320 the buzzword um of all those different types of engineers and different business stakeholders 436 00:40:03,320 --> 00:40:07,560 working more closely together than they have done before i've mentioned a few times the idea of you 437 00:40:07,560 --> 00:40:11,640 know we get a requirements document thrown at us see you in six months that's how to completely change 438 00:40:11,640 --> 00:40:16,280 right with the relationship we've had with between the digital teams and the different stakeholders 439 00:40:16,280 --> 00:40:19,960 from other parts of the business that have been completely changed because as i said we can't 440 00:40:19,960 --> 00:40:24,520 we need to work much more closely together um to your point about being a commodity it's not 441 00:40:24,520 --> 00:40:27,400 something we can just check over the wall and get back when it's finished we need to change that 442 00:40:27,400 --> 00:40:32,520 kind of operation and those are probably the two biggest things you have that kind of risk aversion 443 00:40:32,520 --> 00:40:38,120 and then the collaboration side of things it may be specific to dll because jlr is just such a massive 444 00:40:38,120 --> 00:40:41,960 organization with so many different silos but i'm sure plenty of other people out there large 445 00:40:41,960 --> 00:40:50,600 enterprise companies see the same challenges right you're not alone you're not alone how about you brian 446 00:40:50,600 --> 00:40:58,440 like like what do you see as like like like if we go like one or two as as mike was doing there if we go 447 00:40:58,440 --> 00:41:06,520 one or two layers below like culture change is hard like like not only what but like why is it hard 448 00:41:06,520 --> 00:41:10,680 like like like to pick one thing that i think is good with the perspective you have looking at 449 00:41:10,680 --> 00:41:17,240 as you were just you know uh proving many different organizations right like like so if you have if 450 00:41:17,240 --> 00:41:23,640 you're changing the way that groups interact with each other or silos right like again it seems like 451 00:41:23,640 --> 00:41:27,880 we can all agree that it would be better if we didn't have silos and we all work together and yet 452 00:41:27,880 --> 00:41:34,040 like it's such a difficult thing to get people to change and so like what is i don't know why is that 453 00:41:35,080 --> 00:41:42,120 why why is the status quo so powerful so have you spent a lot of time thinking about this because like 454 00:41:42,120 --> 00:41:49,720 change is really really hard i mean we talk about it we all just say change is hard and trying to build 455 00:41:49,720 --> 00:41:53,800 a structure around it is is where i'm spending a lot of time so i think there's a couple things i think 456 00:41:53,800 --> 00:42:00,840 first of all um been writing article recently that you might recognize the subject of but bottom up and 457 00:42:00,840 --> 00:42:07,560 top down change um so you did a great video series around bottlenecks and i've been writing up some of the um 458 00:42:07,560 --> 00:42:15,480 the blog post on it writing on cocktails what i do best um but in that i've spent a lot of time really 459 00:42:15,480 --> 00:42:21,560 looking at what drives top down and bottom up change to fail or succeed because i've seen both and i've 460 00:42:21,560 --> 00:42:28,600 tried both um so i think pop down change we're all we all recognize mostly as a marketing campaign so 461 00:42:29,800 --> 00:42:34,760 leadership decide we're going to have a radical change towards agile we're all going to go and lean 462 00:42:34,760 --> 00:42:38,920 training we're all going to do this we're all in scrum teams now and you're all going to love it no matter 463 00:42:38,920 --> 00:42:47,480 what and that doesn't work and then likewise bottom up change it hits a limit of local optimization 464 00:42:47,480 --> 00:42:54,040 because as you were saying mike like you can you can build a fantastic system to to take an artifact 465 00:42:54,040 --> 00:42:59,880 and put it into production but unless qa are on board or less security on board or unless these other 466 00:42:59,880 --> 00:43:04,440 teams are on board you're going to be really limited in what you can achieve and so i think the 467 00:43:04,440 --> 00:43:11,160 reason that change is hard is because you need a mix of that top down and bottom up and they need 468 00:43:11,160 --> 00:43:17,320 to marry up in the middle and that's not something i think many businesses agree at i think we do one 469 00:43:17,320 --> 00:43:22,520 or color we don't normally see those two things come together because i don't think there's often a 470 00:43:22,520 --> 00:43:28,520 strategy up front to do that so i think when i'm thinking about my experience building platforms and 471 00:43:28,520 --> 00:43:33,640 helping customers with product i spend a lot of time talking about advocates and i think that's really 472 00:43:33,640 --> 00:43:39,080 important but you need to have people on the ground are going to be advocates for what you're doing 473 00:43:39,080 --> 00:43:44,760 why this change is important and if we think about the bell curve of adoption for change right the uh 474 00:43:45,400 --> 00:43:52,840 diffusion of innovation that's right oh yeah um we'll see the beginning curve innovators they just love 475 00:43:52,840 --> 00:43:58,520 new stuff so they'll do they'll do anyway you've got this other huge section though which are basically 476 00:43:58,520 --> 00:44:04,280 pragmatists they are going to adopt change as long as they can see value from it and then unfortunately 477 00:44:04,280 --> 00:44:08,920 you've got the other half of the bell curve which are people that are going to be resistant because 478 00:44:08,920 --> 00:44:13,800 they know what they're doing just now and the change is really uncomfortable and let's be honest it's 479 00:44:13,800 --> 00:44:18,520 uncomfortable for all of us but it's just whether you can see a value of it and i think that's what we 480 00:44:18,520 --> 00:44:23,160 need to do with change we need to find a way of getting that first half of the curve on board and 481 00:44:23,160 --> 00:44:29,320 then helping the second half but it's part technology it's part process it's part people 482 00:44:30,120 --> 00:44:37,480 again change is hard because change is everything um so again that's a rambly need to put a blog post 483 00:44:37,480 --> 00:44:41,560 together mindset but i think that that's that's kind of what i see in the real world is that we 484 00:44:42,760 --> 00:44:47,400 just fail to meet in the middle sometimes yeah yeah and and and you you talked about this a few 485 00:44:47,400 --> 00:44:55,160 times mike but there's the there's the needing to prove that it's a good idea beyond an intuitive 486 00:44:55,160 --> 00:45:00,760 understanding of like uh you know you have to prove that it's a good idea because essentially you have 487 00:45:00,760 --> 00:45:06,920 to like prove that it's worth the risk of it not working right and all the effort you're going to put 488 00:45:06,920 --> 00:45:12,280 in the position you're going to be in which which i think is uh i mean it's like all common sense 489 00:45:12,280 --> 00:45:16,920 it sounds really obvious when you say it but it's it's hard to actually put into practice but 490 00:45:16,920 --> 00:45:21,080 yeah speaking of like so again the last topic speaking of resistance to change so what is 491 00:45:21,720 --> 00:45:27,880 what is the deal with finance just like give us give us an overview what's how how does finance help 492 00:45:27,880 --> 00:45:34,120 how does it how is it a bottleneck that you know like what uh what's what's the mismatch such that 493 00:45:34,120 --> 00:45:38,840 like i don't think i've ever heard anyone say we were trying to move to speed up our software 494 00:45:38,840 --> 00:45:45,640 development process and boy finance was a big help no it looks okay so it's one of my finance colleagues 495 00:45:45,640 --> 00:45:49,800 may say this um yeah so i think the biggest challenge i think i've seen with it is when 496 00:45:49,800 --> 00:45:56,280 i think about what is is that classic project versus product mindset finance wants a funding for six 497 00:45:56,280 --> 00:46:01,080 months it gets built bosch done whereas obviously the world we want to live in is much more kind of 498 00:46:01,080 --> 00:46:07,480 ongoing funding for products um and part of that i think is is not necessarily knowing what you're going to get at the end of it 499 00:46:07,480 --> 00:46:11,880 so again if we move away from that world where we find set requirements here's my outcome here's how 500 00:46:11,880 --> 00:46:16,280 much it's going to cost done to a world of oh we're agile we don't necessarily know what you're going 501 00:46:16,280 --> 00:46:20,120 to get at the end of it if i'm a finance person i'm going to think right you want me to give millions 502 00:46:20,120 --> 00:46:24,920 of pounds and i don't know what i'm going to get back at the end of it so i think it all tied back to 503 00:46:24,920 --> 00:46:29,240 that for me i think project versus product mindset and that then links up to other things like um 504 00:46:30,280 --> 00:46:35,480 we talked about platforms a little bit so the funding of a platform to underpin some of this stuff is very 505 00:46:35,480 --> 00:46:40,200 difficult from a finance perspective and if it's not tied to a specific project a specific piece of 506 00:46:40,200 --> 00:46:44,840 work with the kind of very specific business outcome it can be different rate buying for it right so 507 00:46:44,840 --> 00:46:49,320 that and that then talks to other things like you know addressing technical data addressing kind of 508 00:46:49,320 --> 00:46:53,880 ongoing maintenance of products etc again unless you've got a specific stream of funding it's difficult to 509 00:46:53,880 --> 00:46:58,120 sort of get that paid well so i don't get tired about that that's what i've seen in jlr certainly is if it's not 510 00:46:58,120 --> 00:47:03,480 tied to a specific project and it's difficult to kind of access that funding and then that tends to 511 00:47:03,480 --> 00:47:07,400 you know funding resourcing funding software tooling etc all that stuff has to be tied back to the 512 00:47:07,400 --> 00:47:11,960 project so i wonder if that kind of underpins a lot of it just switching that mindset again to being 513 00:47:11,960 --> 00:47:17,800 much more long-term product focused and again tied into risk right so the risk of you might end up 514 00:47:17,800 --> 00:47:22,360 spending a lot of money and actually get no benefit from it but you you'll learn something along the way 515 00:47:22,360 --> 00:47:26,200 but to a finance person of course that's quite scary because that's just essentially throwing money away 516 00:47:27,880 --> 00:47:34,360 and and so so how do you like how do you maybe my understanding of the following is incorrect but 517 00:47:34,360 --> 00:47:41,720 how do you like square that with like well we just kind of kind of got to like mess around and discover 518 00:47:41,720 --> 00:47:47,240 new things about cars right like like we don't really know what's going to result 519 00:47:48,040 --> 00:47:53,720 but like we'll discover kind of like what you're saying right like like if if you were 520 00:47:53,720 --> 00:47:59,720 well i don't know maybe tell me if i'm being too naive here but if you're if you're funding the uh 521 00:47:59,720 --> 00:48:07,080 what was the electric sports car the e2 like racing like like if you're funding that and then 522 00:48:08,040 --> 00:48:14,200 like you couldn't have really tied that to a project of discovering a better way to run the car 523 00:48:14,200 --> 00:48:20,440 it just sort of happens and you sort of know that like well we're in the business of cars so if we 524 00:48:20,440 --> 00:48:26,680 spend a lot of time just driving cars and observe what happens we'll discover things now what that 525 00:48:26,680 --> 00:48:35,240 results and i have no idea but like it's will be something so it seems like that like finance is 526 00:48:35,240 --> 00:48:41,000 okay with that maybe but but not with kind of what you're saying is like we're going to build a 527 00:48:41,000 --> 00:48:45,720 platform we don't really know what we're going to need to build but we're going to need to build it 528 00:48:45,720 --> 00:48:50,520 so could i just have some money for that you're right because it's the same as i probably talked 529 00:48:50,520 --> 00:48:54,200 before about how manufacturing and software are different but you know they're using the same 530 00:48:54,200 --> 00:48:59,080 principles if you think about a vehicle you build prototypes we design prototypes they sometimes don't 531 00:48:59,080 --> 00:49:02,680 go anywhere we throw money after that sort of thing yeah it's the same sort of concept again 532 00:49:03,320 --> 00:49:07,560 it's i'm not quite sure why that doesn't translate into the digital software world in quite the same way 533 00:49:08,200 --> 00:49:11,960 you know you could spend millions and millions on a prototype vehicle and it never actually get 534 00:49:11,960 --> 00:49:15,480 released eventually you might discover there's no market for it or i think there's some engineering 535 00:49:15,480 --> 00:49:19,320 challenge along the way it's the same sort of concept again for whatever reason that just doesn't 536 00:49:19,320 --> 00:49:22,920 translate into the digital world in the same way we've got that same challenge there to sort of yeah 537 00:49:23,960 --> 00:49:27,320 you use it as an analogy i really like that analogy of sort of yeah relating back to lean 538 00:49:27,320 --> 00:49:32,040 manufacturing and using that maybe we need to use a kind of vehicle prototype thing as an analogy for 539 00:49:32,040 --> 00:49:38,280 the financial use case as well i think one of the things i've seen time and time again is that the 540 00:49:38,280 --> 00:49:44,920 the divide in finance and in software delivery is a lack of understanding i don't think that finance 541 00:49:44,920 --> 00:49:52,520 really understand it how it's built why it's there sometimes but specifically the mechanism of how we go 542 00:49:52,520 --> 00:49:58,200 about building it so how you build a car with a prototype etc there's maybe a a closer understanding 543 00:49:58,920 --> 00:50:06,040 um and as software people i think we're terrible at understanding finance absolutely you know so the one 544 00:50:06,040 --> 00:50:13,160 of the best things i ever did was when i became a new manager of an engineering team and i realized how 545 00:50:13,160 --> 00:50:20,120 out of my depth i was i called up one of the the young finance guys that was helping me with various 546 00:50:20,120 --> 00:50:26,040 questions and i said look can i can i just sit down with you for an hour over coffee and you can give 547 00:50:26,040 --> 00:50:31,400 me like a five-year-old's guide to finance in this company and i'll give you a five-year-old's guide to 548 00:50:31,400 --> 00:50:37,560 cloud computing and why why that exists what platform as a service is what platform product is 549 00:50:37,560 --> 00:50:44,600 what we're trying to achieve one of the best hours i've had i learned so much and we continued doing 550 00:50:44,600 --> 00:50:49,800 that in fact um on a kind of monthly cadence and it was really useful and for me it was it was the 551 00:50:49,800 --> 00:50:56,840 ability to understand why finance perhaps have some struggles with software teams a couple of big ones 552 00:50:56,840 --> 00:51:02,600 that stand out to me number one is that we don't spend the money that we say we're going to spend we 553 00:51:02,600 --> 00:51:09,720 either spend much more or much less and ironically you always understand that spending less is actually 554 00:51:09,720 --> 00:51:16,040 really bad too because if we've spent less money than we planned to it's not like we we hand it back 555 00:51:16,040 --> 00:51:21,080 like a savings account the problem is that means that other parts of the business didn't get to do 556 00:51:21,080 --> 00:51:25,240 what they wanted to do and the finance person now has a problem because now he's got a lot of money 557 00:51:25,240 --> 00:51:30,360 but we said our stock price was going to be this and the stock market likes repeatability so if we're 558 00:51:30,360 --> 00:51:34,840 not on that line that's a big problem so there's a constraint on finance that sometimes the software 559 00:51:34,840 --> 00:51:43,320 on we're unaware of i think the other aspect is that we are terrible absolutely terrible at telling 560 00:51:43,320 --> 00:51:49,480 finance what value we achieved so i i'd love to know what it's like in jlr but many of the businesses 561 00:51:49,480 --> 00:51:55,720 i've worked in personally and the ones i'm working with you go to finance almost like the gatekeeper 562 00:51:55,720 --> 00:52:00,760 the troll on the bridge right to try and get the money you get your money you run off with it big 563 00:52:00,760 --> 00:52:06,920 big huge sack of cash and you promise you're gonna do good stuff in a year's time and then you never 564 00:52:06,920 --> 00:52:12,840 really report back but also well like the modeling that you've done is like i need all the money and 565 00:52:12,840 --> 00:52:18,120 i'll tell you when i'm done and one of the things i changed in my time was that i began to look at big 566 00:52:18,120 --> 00:52:22,520 scary projects like building a new car building a new platform and i said well actually don't give 567 00:52:22,520 --> 00:52:28,440 me the money don't give me all the money i'm going to want this amount over the year but i want this 568 00:52:28,440 --> 00:52:35,560 amount this quarter this about next quarter and this and so far and if i get point at the end of the 569 00:52:35,560 --> 00:52:40,440 prototype stage i might actually come back to you and say i don't want the money or i might come back and 570 00:52:40,440 --> 00:52:46,040 say i need more and having that type of conversation flip things for me from begging for cash to actually 571 00:52:46,040 --> 00:52:52,680 being at q3 how you know kind of at that scary point for finance people and finance would approach 572 00:52:52,680 --> 00:52:58,600 me and say how much more could you achieve if we gave you some extra money now and could you get 573 00:52:58,600 --> 00:53:04,360 it all receipted and invoiced in time for our timelines and that's because truck being built up and 574 00:53:04,360 --> 00:53:10,760 understanding but what's it like in in glr mike is it that is there a good system for reporting back 575 00:53:10,760 --> 00:53:15,560 to finance or are they so busy with just trying to guard the cash in the first place that there's 576 00:53:15,560 --> 00:53:20,920 never really that that cycle that happens yep it's it's option b brian sadly oh yeah i think we're 577 00:53:20,920 --> 00:53:25,880 kind of missing that feedback that's not the trigger um yeah we're in that first situation you talked 578 00:53:25,880 --> 00:53:30,280 about where we take the cash run away and we're very very bad at reporting back about what we've done 579 00:53:30,280 --> 00:53:34,600 back of it um or at least talking to the finance people very good at kind of talking to business 580 00:53:34,600 --> 00:53:38,760 stakeholders about sort of value you've delivered them what the product does but closing that 581 00:53:38,760 --> 00:53:43,160 feedback loop with financing it's definitely a big gap um yeah to exactly what we just talked about 582 00:53:43,160 --> 00:53:47,480 then right that's it so what we want to get to is exactly that kind of quarterly model just don't 583 00:53:47,480 --> 00:53:52,280 give us it all up front just do it bit by bit do the feedback lead review do we need to keep going 584 00:53:52,280 --> 00:53:56,440 do we need to do we need to can this project have those discussions not there yet that's the journey 585 00:53:56,440 --> 00:54:01,320 you want to go on and i think that will help a lot yeah it's currently the situation where we don't 586 00:54:01,320 --> 00:54:05,000 have that feedback loop at the other end to sort of close the loop and say yeah here's what we did 587 00:54:05,000 --> 00:54:10,440 here's what we didn't do give us some more money or don't and it's a tremendous power out for finance 588 00:54:10,440 --> 00:54:14,840 because all of a sudden you've turned that agile thing we're talking about being quite scary 589 00:54:14,840 --> 00:54:20,440 into being a fantastic tool because now finance have an understanding that they don't have to spend all the 590 00:54:20,440 --> 00:54:26,120 money they'll still get some value delivered along the way they can pause a project they can ramp up a 591 00:54:26,120 --> 00:54:31,080 project all based on those outputs so if you're doing really well and they've got spare money great 592 00:54:31,080 --> 00:54:36,600 let's double down well actually you know financial world has changed some something else has happened 593 00:54:36,600 --> 00:54:43,640 either macro or in the business itself we need to change our plans agile can help us do that 594 00:54:43,640 --> 00:54:49,720 modern cloud native practices can help us do that why monoliths are have their place but they're they're 595 00:54:49,720 --> 00:54:54,200 harder in that regard um but i think having that feedback would be so we go building the trust so 596 00:54:54,200 --> 00:54:58,920 we can actually demonstrate that this crazy world of we don't know what we're going to have at the end 597 00:54:58,920 --> 00:55:06,200 of it is better than waiting until the end and maybe building their own thing yeah you know y'all are 598 00:55:06,200 --> 00:55:13,080 like i i i i like the the points you're making and one of them so so so to add my my my bit to it it 599 00:55:13,080 --> 00:55:20,280 seems like like finance maybe in respect to what we're talking about wants three things they want 600 00:55:20,280 --> 00:55:26,040 like to be as deterministic as possible right like you know i mean that's the way we all are with money 601 00:55:26,040 --> 00:55:32,360 if if i if i put you know 50 50 pounds over here i would love it if one it stays there and doesn't 602 00:55:32,360 --> 00:55:37,640 disappear and then two like it gives me a return that's known like in the direction that i wanted 603 00:55:37,640 --> 00:55:43,800 right like and in corporate finance it's even more so and then and then two like i think i think brian 604 00:55:43,800 --> 00:55:50,360 you're hitting on this is like there's this expectation of repeatability which is almost like being 605 00:55:51,320 --> 00:55:55,640 deterministic like you know that this thing is just going to keep acting the same way and returning 606 00:55:55,640 --> 00:55:59,880 the same thing and i think that that hits on a little you know it's it's one of the reasons why 607 00:56:00,520 --> 00:56:07,080 not spending enough money is annoying because if if there's the opportunity to have made more money 608 00:56:07,960 --> 00:56:12,520 you you would have wanted this person to spend more right and and you know kind of have that be 609 00:56:12,520 --> 00:56:17,480 repeatable and deterministic you don't want to miss out on making money and then one that i don't think 610 00:56:17,480 --> 00:56:24,680 about very much but but but you two were kind of going over is it's almost like it's like two sides of 611 00:56:24,680 --> 00:56:32,280 the same thing like finance wants to have or finance would like to have options like optionality when 612 00:56:32,280 --> 00:56:38,920 things change they can like put something on pause or spin more which also implies they have controls 613 00:56:38,920 --> 00:56:45,320 like they can actually like having an option without being able to do anything about it is annoying it's 614 00:56:45,320 --> 00:56:51,080 more stressful right and so they need those controls that they can go in there and then and then the 615 00:56:51,080 --> 00:56:55,160 the other side of that which which i'll have to think about some more but i think is 616 00:56:56,440 --> 00:57:01,320 i think it's something that we should work on an industry is not only like speaking the language of 617 00:57:01,320 --> 00:57:07,720 finance but like like y'all were saying we should just speak to them like like at the end of the cycle 618 00:57:07,720 --> 00:57:16,280 and then also know how to show the the as you were saying uh i think it was you brian the value that 619 00:57:16,280 --> 00:57:23,240 got delivered right and so like i think i think intuitively like if we build out a platform and the 620 00:57:23,240 --> 00:57:29,560 middleware and all this stuff like we understand the value that was achieved but like it's hard to 621 00:57:30,280 --> 00:57:35,080 like you have to express that to people right you have to say that and and it takes a certain amount 622 00:57:35,080 --> 00:57:39,560 of of meeting each other in the middle about the technical parts of it right like you've got to 623 00:57:39,560 --> 00:57:44,600 get somewhere beyond like i don't know i just bought you a bunch of computers why isn't it working 624 00:57:44,600 --> 00:57:51,480 and you have to say like well let me tell you how that works right and and why investing in this cloud 625 00:57:51,480 --> 00:57:57,400 native way of doing such as an example was better than this other way of doing it even though it's just 626 00:57:57,400 --> 00:58:03,400 computers or something like that but i don't know i i don't know what the uh further delve into that is but 627 00:58:04,280 --> 00:58:06,840 i i think i think as y'all two are getting to it's just sort of like 628 00:58:08,760 --> 00:58:13,800 uh a misunderstanding not even a misunderstanding just not knowing how each side works and having 629 00:58:13,800 --> 00:58:19,640 different expectations for it uh which which i think is helpful well speaking of being helpful 630 00:58:19,640 --> 00:58:23,960 we we should uh we should let mike get on to the other helpful things he does rather than entertaining 631 00:58:23,960 --> 00:58:29,560 us like it was it was great to go over this stuff it was really nice that uh uh you know brian's been 632 00:58:29,560 --> 00:58:34,200 working with you and and he uh he thought to bring you on here so that's good and and i think uh your 633 00:58:34,200 --> 00:58:40,520 your willingness to come on is always great because i find that people in your position uh don't always 634 00:58:40,520 --> 00:58:45,640 share with the rest of the community what what's going on you know if only because they got other stuff 635 00:58:45,640 --> 00:58:51,400 going on but but thanks a lot for going over that that that was that was great if uh is there anything 636 00:58:51,400 --> 00:58:56,760 you want to uh if people are interested in more that you would point them to any uh any uh things 637 00:58:56,760 --> 00:59:01,400 like that i mean i'm always happy to talk about any of this sort of stuff devops cloud soft engineering 638 00:59:01,400 --> 00:59:05,960 keep a shout out on linkedin i've got no alternative in terms of hiring anybody so it's a great conversation 639 00:59:05,960 --> 00:59:12,040 yeah thanks thanks the best of yours look after me good yeah well i appreciate well as always this has 640 00:59:12,040 --> 00:59:18,040 been uh tonsu talk you've either watched a video of this or uh you've downloaded a podcast or perhaps 641 00:59:18,040 --> 00:59:22,920 one of your your parents or someone in your house is listening to it while they're making a meal and 642 00:59:22,920 --> 00:59:28,120 you're thinking what is this you're being subjected to it from uh from the kitchen uh but if you want to 643 00:59:28,120 --> 00:59:33,640 get the show notes from this uh we'll put any relevant links you can go to tonsutalk.com and find out how to 644 00:59:33,640 --> 00:59:39,720 subscribe to the podcast if you prefer audio find the videos things like that and as always thanks and we'll 645 00:59:39,720 --> 00:59:40,680 see everyone next time