In a session from the London Live Tour, Sarah talks with Mike Gosling, IT Service Platforms Manager at Cubic Transportation Systems about the company’s successful transition to outcomes-based service with the help of AI. Mike shares key aspects of the transformation, including the importance of change management, tips for success with AI-based tools, and the role of continuous improvement.

Sarah Nicastro: So next up, I'm excited to be joined by my friend Mike Gosling, who is the IT service platforms manager at Cubic Transportation Systems, and we're going to talk a bit about outcomes based service. So Mike is essentially offering a different perspective on the path to advanced services, and we're going to talk a little bit about what his journey has looked like, what some of the learnings are, what is coming next, etc. So before we dig in, Mike, tell folks a little bit about yourself and about Cubic.

Mike Gosling: Okay. So good morning, everyone. I started many years ago as an electronics engineer in a computing company working right down to mainframe PCBs and things like that. They did their forecasting in teacups, which meant that they collapsed and burned pretty quickly and I was made redundant. Joined Cubic, they weren't call Cubic then, and I was an engineer, working electronics engineer and they started introducing business systems into the company. One day I went into the manager of the IT team and said that I can do better than that because I thought they weren't doing very well. So I did, and he said, "Right, have a go."

Sarah Nicastro: I like that confidence.

Mike Gosling: Years of being rugby captains and things. Yeah, big personality sorry about that, guys. Anyway, joined the team and then very quickly because of my field service experience and things like that. And because I'd also been out in the field by the way, troubleshooting out in the field and things like that because they'd put me in charge of the full service systems. Now, very interesting discussions that we've had early on today. Very interesting. And we are now outcomes and I'll get to that, but I don't think we nec... Oh by the way, sorry. Cubic.

Who remembers a London prior to Oyster Card? Yeah, it was pretty rubbish wasn't it? Because we are the people that basically do Oyster Card. We are the people that do all of the transport for London and most of the UK travel infrastructure. We do it all over the world. We're world leaders. So if you go to Sydney, we are there. Manhattan, we're all over the world. We are the European hub, but we do influence the rest of the world. My little team punches quite highly in the business, so I'm proud of the team. Rob's here, oh just heard me say that now he's going to want to pay raise anyway.

So yeah, Oyster card. So now Cubic, one of the couple of the things about Oyster, I'm sorry Cubic is that we have two mantras, we've got many strategies, but two mantras that are very important to us. Winning the customer obsession and innovation and our journey to outcome based. Those were the pillars that got us there. And by following those, we then fell into outcome based. And I'll explain how. When we first got the contract years ago, with Transport for London, who's our biggest customer. Transport for London, is an amazing customer to work for as well as the others. We've got other amazing customers in the rest of the UK. But Transport for London are amazing because London is an amazing city. It's the world leader and they want to be the best. Manhattan, Oh no, no, London's better. Sydney, no London's better. So they drove us to make sure that our technologies were up to date as good as possible for the infrastructure that they're in.

We wanted to innovate and win the customer. So as TFL were going on the journey of trying to be the best city and having things like the Olympics where their travel infrastructure was put under huge strain and stresses and the whole world and the Daily Mail was ready to write the horrible headlines, traffic congestion in London spores Olympics. It never happened. It never happened because the entire infrastructure was that TFL put into place was magnificent, and we paid a part of that innovation. Well okay, we want to start using smart cards or oyster cards. Okay, well how do you do that? Off you go Cubic, could you do that? We'd like to do it, you want to do it? Let's do it together. You plug readers in, you start taking data off readers. So you build the back office infrastructure. So you have back office IT services to manage those and then all of a sudden it's kind of like, hold on, we can now start taking that data as well and using it to log incidents because there's loads of information on that.

And then that day can be backfed into engineering because we can improve the product. Brilliant. So everything's connected and then they say now we want to go cards, card payments. Yeah, card payments. So we have to then again do better integration and better tokenization and go through PCI compliance and all this other stuff becoming more IT services, more back office services. And then we introduce, because now they've got cat cables and things like that, we can introduce better PCs and control boards and things inside them. We can also start monitoring. And so this innovation between ourselves and transportation for London and other companies, all of a sudden you go to bed one day quite proud of the Olympics going well and all this and you wake up next day and we're an IT services company.

We're no longer a company that sells machines; we supply IT services to Transport for London, and Transport for London in the last rebid recognized that and came back and said, "Okay guys, now that everything's in place, your contract is no longer, we want 20 gates here and break and fix" is now you are going to supply hours of retail and hours of validation at stations and on buses and you're going to supply hours of back office system support for your IT services and you're going to supply hours of retail support for the retail terminals. And how you do that is entirely up to you because that's it. The outcome is those hours and you're going to take all the risk of that and you'll take the revenue because we all want money. But you're going to have to do that. Now from my team, how are we innovating? Well, we'd already started to try and be more efficient in the way... By the way, if you want to ask a question at some point, just jump in. But

Sarah Nicastro: All right, I'll just…

Mike Gosling: You want to hear a story? I can tell a story. We wanted to be more efficient the way we operated. So we had all these engineers all over the place and we wanted to grow the business because to grow the business all over the UK, we didn't want to just throw engineers at it. And one of the dangers about outcome based is everyone talks about Rolls-Royce, you talk about Rolls-Royce, it's fantastic hours of air. Well it's same for us. If we wanted things to be working for 20 hours a day when the service is open or 24, let's just plant an engineer there all day long. And then the moment it fixes, press the button, it goes again. The moment it fixes tweak that it's back again. Well that's just totally inefficient. We'd been starting to use tools, dynamic scheduling tools to make sure that our engineers are more efficient the way they move around the business.

Huge change in the way they operated. They were no longer being governed by someone phoning up and saying, "Yeah, can you pop down to Waterloo? There's a couple of gates broken down there, do them in your own time and call us when you finish." And the guy's saying, "Oh actually there's a cafe at Seven Sisters. Do you mind if I can pop up there first?" "Oh yeah, actually there is a job there. Go there. Yeah, don't worry about the Waterloo." That's just totally inefficient. So we had dynamic scheduling tools come in. We had mobile comms come in because we were starting... If you are getting enriched data from your machines to engineering looking at. You want enriched data from your engineers to how they fix that data. And voice interface is the single worst thing in entire world. And if you ever go down mobile comms, which some of you always do, don't narrative, tiny bit of narrative because otherwise exploited and you'll get rubbish.

Anyway, we were building that to become more efficient. We were building that to become more the way that we operated. And it was a hard change. We can talk about that if want to later on, but there was a hard change. So all of a sudden we wake up one morning, our equipment's monitoring itself, we're getting all this data in. Our engineers are efficiently being scheduled around the system and we are using mobile comms and it's all fantastic. And then all of a sudden TFL said "Right now we're becoming outcome services." And literally go from the L contract starts tomorrow, you've got three months until the new contract starts and that's the way it is. Maybe we can crowbar some of the stages in organically in those four stages, but basically we were innovating to suit our own needs and then bang off you go and start exploiting.

And we did. We started exploiting and the transition to it was absolutely fantastic because it was almost like, "Oh that's what we... Yeah you're right. This makes more sense now." And there are certain things that you start to do. So when you think of a walkway now everyone says, "Oh you said a walkway." No, that triggers brooms. That walkway is just something that collects validation and as long as it does that for 20 hours a day, we're happy, and we can change every part of that if we need overnight to achieve our... And we make much more use of parts. I know Rolls-Royce do it. I have friends who work for the airports. They steal from Peter to feed Paul to keep that plane in the air. We do very much the same because it's about those hours. So we totally change the way that our food service operation works, our logistics operation and all this data coming in that we got as well we're able to back feed into our engineering and therefore improve the IT services.

They improve the outcome, they improve reliability. So our journey was kind of an organic win the customer and innovate. And then because everything was in place, the customer says, "Well we want..." Oh by the way, I want, sorry before we'll let you a second.

Sarah Nicastro: It's fine. No pressure. Take your time.

Mike Gosling: TFL, they had a mindset themselves few years ago and I apologize if this goes out and someone from TFL sees this, I hope they'll agree what I'm saying is true. Should be because I've spoken to the main people but they want to treat every single person as valued patrons of the service because people come from the whole world round here, fella, and they want the experience of integrating with the transport situation to be exactly the same for everyone.

And what that means is that if someone boards a bus out in Gravesend or someone gets trained in Waterloo or someone gets on Ongar or someone... The experience should be exactly the same. And that's why they wanted outcome. Because it wasn't just, if it was break fix to us, we weren't worry about Ongar. That doesn't care to us. We'd make sure Victoria's Waterloo is always working because there's a million people a day. No, they wanted exactly the same level of service for every patron because they wanted to be world class London. And that's important. And because of that, when we setting up our systems and our contracts, there is a temptation, an old mindset, it's an old engineering thing. Look, there's a million people going through Waterloo every day. Get yourself down there, get down there, get down there. Come on Ongar, don't worry about it.

Three people and the dog, don't worry about it. No actually the penalties are exactly the same for that station as they are for that station. If we lose hours on that, they are as punitive as they are at Waterloo. Final thing, that means that the outcome is, although the outcome's the same, we give 20 hours of retail per day per device or validation per device at some of the stations because of the strange dynamics of some of the stations, be it access, be it certification, be it all sorts of things. The field service underneath that is totally different. It's almost like the little legs go in because my name's Gosling called I'm called Goose. Everyone's called Goose. So the little legs on a goose. Anyway, everyone thinks that it's like standard service to maintain that we've utilized the scheduling tools and we utilize the dynamic, the tools, we've utilized those business rules to identify these unique circumstances to make sure that we do maintain that level of service and all that outcome different from others.

And the way we use our engineers, the way we use our logistics, the way we have our access and certification and tools and skills there are many differences involved in that. They're pretty much all automated. But the result is that TFL you are to supply X amount of hours of retail, X amount of hours of validation and X amount of hours of back office support. And if you actually look at our schedules now, they're called LU services, they're called rail services, back office services, service transport services and retail services. Because we are not selling gates anymore. So that was a long introduction, sorry about that.

Sarah Nicastro: It's okay. All right. So that's Mike, that's everyone. So there's a couple things I want to comment on. So again, going back to the aha moments we talked about earlier, that can kind of spark this journey for Cubic, it was very clear because Transport for London with their objective of providing a high level of consistent customer experience across their whole system came to Cubic and essentially demanded, if you are going to be our partner then we want X percent uptime across the board. So figure that out.

Mike Gosling: And by the way, it's up in the near a hundred percent by the way. Yeah, it's not 60; its way up there.

Sarah Nicastro: I was going to say 96 or something.

Mike Gosling: No, it's much higher than that.

Sarah Nicastro: And so that put Cubic in a position of sorting it out and sorting it out quite quickly. And Mike and I have had a relationship over the past number of years and so we've talked about their journey quite a few times and one of the things that we just talked about, recently, is the fact that it really lended itself to them needing to be quite agile because it had to happen fast. They needed to act quickly and learn on their feet and get accustomed to that way of operating and then go back and refine. So the idea of, can we provide outcomes? Can we guarantee uptime as a minimum viable product? We need to do it no matter what. Then can we go back and reflect on, here's how we're doing it, here's how we can refine how we're doing it these things. And so there's some different learnings that come through doing it that way.

Mike Gosling: My team that I had that manage these services, that manage these because I didn't say that by the way. My team is responsible for the moment an alert appears on any device, be it a reader, be it an LCP, be it the back office. That alert becomes my property because we monitor it. We're monitoring the hundreds of thousands of bits of kit in the system in real time.

We then transform that. We decide whether or not it's an incident that gets logged as a ticket, which becomes a dashboard, which becomes a service report, which automatically sends engineers the mobile comms to all that happens automatically. I own all of that and that team, we use scrum ban process, we're trying to go to deliver when ready. But at the moment we have... We're not really sprints anymore. We've sort of got rid of sprints. We use the pull method from the scrum ban and that means we're very agile, which means that we can literally, the customer can come to us and say, we want this new change made. And if the timing's right it can be delivered in a number of weeks, days even sort of thing. Sorry.

Sarah Nicastro: No, that's okay. All right. So what I want to do is go back and talk about some of the key aspects of this. And so one of the things you mentioned is the idea of delivering outcomes manually is just impossible. If not impossible, I would say impossible. But if not, certainly unrealistic. The cost to Cubic of trying to scale up on man manpower, even if it were feasible to do that is not going to work. So you had to really rely on some of the technological innovation you already had underway and then add to that.

Mike Gosling: We had to totally even them with the contract.

Sarah Nicastro: Yeah. So talk about the importance of automation and intelligence in being able to deliver outcomes and how that gives you the ability to, as you said, really be able to in real time react to whatever complexity comes up. Because to your point, no matter what happens circumstantially with the workforce, with the technology, with Transport for London things going down world events, etc., you still have to deliver that uptime. And so you have to be able to react adeptly to any sort of circumstance.

Mike Gosling: Yeah, this could be a long answer again, sorry. So first things first, a device fails, it comes all the way through our systems and it says no, this is not a false positive. It is actually an error. The field service management tool says no. We know empirically from our knowledge of learning because of knowledge, knowledge, knowledge that the only way that this can be resolved is sending in the field engineer. It becomes an incident, it becomes a work package that gets dropped into the dynamic scheduling PSO. PSO will automatically assign that to an engineer based on their skill, their location, their tools, their certification and the contract. That's key. We'll come back to that in a minute. The contract. That will appear automatically on the engineer's device, it'll just ping up. They'll say, "Oh we've got to go to Victoria again because I hate it."

But they've got to go anyway. They'll go, they'll do all the interaction on the device which is back feeding into the systems, which is by the way real time going onto customer dashboards. The customer can look at Victoria and drill on and say, "Oh is there an engineer on site and oh, what's he doing in that? So they can see all that in real time, which means that there's no need for loads of comms between the customer. They're almost embedded in our service room if you like. The engineer can resolve that issue, leave it, the dashboard's updated the job out done. The only human interaction with that entire job is engineer. No one else has touched it. That is where the strength comes in. 80% of the heavy lifting is done on those sort of simple jobs. The system set up those rules I said about are to manage those 80% of heavy lifting and to utilize the contract knowledge, the skill knowledge, the tool knowledge, etc, then you get accept management on top of it.

So we have exception managers who spot those things that go on and that might be different, there might be real world situations, there might be, let's horrible thing to say, but there might be a blue light situation that needs some things. They can then overrule it and then start moving jobs around that they need to with that real world situation. The next thing is you understand your contracts because it sounds like it's, as I said to you earlier, okay the outcome is just 20 hours of per device of retail scale that to a hundred gates, etc., etc. When actual fact, as I said you before every place has their different dynamics and certification and access and sending someone nine o'clock in the morning to fix a walkway at Victoria, you're going to get trashed by that. And also there are other little things.

If for example if we consume in hours and then we get more than a certain amount go out, not only are we losing downtime and we are not fulfilling the outcome, we're actually a degraded service. So we get penalized again. So our contract, there's 115 SLAs or something. So really, really, really understanding the contract, not just think, "Yeah, I know the contract," really understanding it and how each interacts with that one and how each bullies that one and how if you set it up to do that one, you're going to suffer on that one and all that. And because we've taken the risk on we, again, I might get told for saying this, we have a slightly different view of it maybe to the customer sometimes because they are engineers and there are people and there are concerns humans, every two engineers, different people and different concerns and different things.

So they have to be treated differently. So we then set the system up to suit those, the required skills, that required tools, that required knowledge, all those sort of things so that the 80% of the jobs can be dealt with that. There are a lot of challenges understanding the contracts. One of them, we really put a lot of effort in front end to understand the contracts to the nth degree and how that one bullied that one. And also, by the way, I forgot to mention these sound engineers work on other customers as well as TFL, so not bullying other customers as well. And they've got a different regime because some of them are still break fix, they're still buying a gate. We are truly outcoming our biggest customer. And so not being bullinosed. So that was one challenge. The other challenge is people, because when you've got a kind of a voice and the people like that, you build up friendships, you get this, "Oh can I leave early today?" "Yeah." "I don't want to go to Kings Cross. I hate going Kings Cross." "Okay I'll never send you there again." That sort of thing. So you have to work through those. You got to get those people problems to manage those people. And let's base it, we're all here because field service, we would be lost without the brilliant engineers out in the field. They are really the bread and butter. And it would be great if more of them came here actually. Maybe if customers could be more encouraged to people real world it here so that they could have an understanding of what we are trying to do. And then we could listen to them because we all think, "Hey, what they got to do is go and fix that gate and then it'll turn up," and say right. Two things about it. One, the station supervisor at that place is really strappy and won't let you warn at this time.

Two, there's a shelf that means it's really difficult to get your body in, three and these are the real world scenarios that we have to take into account. So learning that, learning that. And the final thing is the technology side of it, is the taking that data and making meaningful use of that data, understanding is that really a system? Is that really alert? We do something which I don't think I've ever heard anyone else do. We log self-resolve incidents. We actually, an alert might occur and clear itself, but we actually log it as a valid incident and it looks just a normal incident log. It's totally cleared itself.

Take full downtime for it. We aggregate them, we are so transparent to the customer, we can go to them and say, these are all your incidents including the ones that killed themselves and the downtime and what it was and everything like that. So understanding how your incidents relate to each other and how to failure them and all that. So it's a really interesting journey. But we'd already started doing that as I say. And then when the customer came it was like, now let’s proper naval gaze at those challenges and really understand the contract, the people. Yeah

Sarah Nicastro: All right, so the first thing I want to dig into a bit is talking about the technology a little bit further and here's how. So Cubic happens to be an IFS customer and uses both field service management, which is the solution that the ticketing would go through and that the technicians interface with as well as the dynamic scheduling, which is referred to as planning and scheduling optimization or PSO for short. Now PSO is an automated scheduling tool that uses AI and essentially is self-learning. And so one of the most impactful conversations I've had with Mike is around his and his team's learnings of what it really takes to make use of an automated tool of that type and meaning, it is powerful but only if you trust it to do its job. And so for Cubic, what that has meant is to your point, understanding first and foremost the contractual obligations for uptime to Transport for London and making sure that the system prioritizes those, but then also takes into account all of these other things, the technician skills, inventory, locations, events, other customer jobs, etc.

And so what Mike is saying is that through the work that they've done with PSO, 80% of their jobs are done in a completely automated fashion. Meaning the ticket comes in, the job is dispatched to the technician, completed by the technician, closed by the technician without anyone other than the technician interfacing at all. The other 20% are where he's saying the exception managers have to put some sort of manual effort into doing some of that work. Now that's a really impressive feat to be at that point, but what it took for you was setting your success criteria and sticking to them while you let the system do its learning without acting on the human instinct to intervene, right? Because that's what they were used to doing. So can you talk a little bit about that part?

Mike Gosling: Well, yeah, you probably noticed that I've got a fairly big personality and that I'm not easily swayed.

Sarah Nicastro: The thing I like about you.

Mike Gosling: So when we went live the first day with our turning the PSO on, we've talked about understanding the SLAs and the skills and the people and all that. I absolutely made sure that no one played with the system. We'd put a lot of effort into understanding how the jobs with the contracts were SLAs, they needed the skills, etc. And it was absolutely "Now guys, you have to leave it alone because it will only work 80% of the time if it's allowed to work 80% of the time." And if you start saying, "Oh I disagree with that," and moving, it will rearrange the whole world around it and you will not get a true figure. I'll come back to data later because data for me is, that's the next big thing is using machine learning to back feed into engineering and stuff. But anyway, so we were pretty strong and mandated on that.

We would put in these continuous improvement steps and we would have, the first one would be one week and then one week and then it would go to three and then two. And if anyone spots anything, save the plan, then write down very clearly in language that was not ambiguous, it had to be understood because it wasn't just me that needed to convincing, it was the steering group, which someone talked about earlier about the leaders, man over there, your leaders, service leaders are, sometimes they're in their ivory tower, they've climbed up and a lot of them are out of touch maybe. So, you got to convince those people as well. So you literally do it and they might will moan and they will complain and they will, "Oh no, look this, no, there's no way they'll do that job first before that one" and look okay, we've got it wrong, but let's leave it for now because maybe it's something else that's happening.

Take that data and then literally analyze its nth degree. Think about it, learn about it, learn from the data, understand how it is. Now we got the SLA wrong, the first week clearly there was one actually that we got completely wrong and it was sticking out like a sore thumb. We still resisted the temptation to mess around with it because we had, I couldn't change my own goal post. I said we were going to leave it one week, we had to, it was clearly obvious it was wrong, but no, it had to stay there the whole week. Then you model, then you implement, you go through everyone. Those continuous improvement, I'm not going to go through that process. After a while all of a sudden. "Any complaints today?" "No." "Any complaints today?" "No," actually it's quite like that and excuse me. Yeah, can I change that note? You can't change the words and all of a sudden it just literally fell off a cliff.

You know, had loads of noise, loads of noise, fell off a cliff. And then it was a similar story, with our starting to meet these service outcomes, we... Oh, I forgot to mention, when we introduce these tools, we collaborated with our customer to say, "by the way, we are going to introduce a tool that the long term's going to benefit you and us. You are going to love it as much as we are going to love it. But there might be a bit of a hit to start with." And of course they were, "Ah, you can't do that." Then when they realized there was a potential hit, fine, you work through it. And this is why working with a collaborative customer, it's fantastic. All customers, but I should say brilliant, we took that hit and then the same time as all the thing, it literally bang, it fell off and we started to see a huge improvements in our SLA, huge improvements where we were and enabled us to actually grow the business over a number of years without having to take any extra engineers on.

Because we had everyone that says when you introduce these tools, "Oh we don't have enough engineers, we need more engineers. Throw engineers at it." No, actually it turns out we had probably in less than we needed to start with and able to grow the business. Either don't have enough hours in the day, put the jobs into the schedule, what's all that there? That's all spare hours, it's all there. You can see it. So yeah, so it was quite interesting that being firm and I think that's partly why it was brought in very quickly by these senior managers as being a critical business tool and is now seen as a critical business tool. And in fact, again, I'm conscious, a couple of times I've given demonstrations on behalf of TFL to other transport authorities around the world because TFLs say, "Look at this, this is the sort of tools our people are using and it's wonderful how they use it."

So they're recognizing the value of it as well. So yeah, that was one of the things is hold your nerve. The three tips I will give is one understands your SLAs to the nth degree really go in and just don't think them know them and how they bully each other. Two is work with your resources, manage the resources. It's going to be horrible. There's going to be a lot of people that really are going to fight and complain and there are key influences. They might not necessarily be the best resources, but they're the ones that shout loudest in the pub in the corner at night when they're moaning, invite them into discussion. Let them have their say. If you get two gems out of them that you are able to implement, they'll recognize that and they'll sing them from the rooftops and they'll influence the staff.

I know it's a horrible thing to say, but sometimes this is how you win people over and if something they do suggest is not necessarily right, don't rubbish them. Give them the honest reason why it's not right and they'll go away hopefully respecting you and you'll have better respect from them and then take that advice. So understand your SLAs, understand the people and hold your nerve. Do not mess around with the system, it'll fight back.

Sarah Nicastro: So I think this is really important because at the end of the day to be able to deliver outcomes the way you are, you have to rely on technology. We've established that when we talked earlier...

Mike Gosling: And that's end to end. That is literally from... That is full IT services right the way up to the mobile comms. It all contributes to being able to do that.

Sarah Nicastro: And like we talked about earlier with James, ultimately when an organization can move to a Servitiization model, the more you can leverage tools like this to improve your efficiency, the greater your revenue is going to be, right? But time and time again, what we see is organizations who are hell bent on investing in automation but don't realize that they're not actually wanting to automate, they're wanting sophisticated technology but they still want to follow the old processes and have that manual interaction and you can't have both. So if you're going to try to leverage the power of an automated tool, you have to understand and be willing to commit to the process of getting it working the way it can.

Mike Gosling: And we are lucky that one of our key sponsors is on the board who absolutely, who lives by those two mantras winning the customer and innovate. And because he's on the board and he innovates and he's a very, very respected person and he's our assistant sponsor. He literally lives that and tells that. Rob will tell you, he's sitting at the back, we do have a couple of people still who've been at the company many years who still given the opportunity one Saturday morning when none of the managers there will start, "Yeah, I'll give you that job. No problem." And then you come in and go, "What the hell happened on Saturday?" But unfortunately this is the facts of life is that you can't... It's about managing those things. But yeah it is going to be committing to it and truly committing to it and living it and also plugging those continuous improvements in continuous to innovate.

I was saying about data, I'll come back to data because one of the things that I'm really keen to do now that we're getting all this data from stuff and is to really start, I was talking to someone earlier, we're starting to look at, I call it collision data, but basically if you look at say a device starts to fail, and I have done this in the past, I gave an example earlier; if you look at the ride device is failing, rather than fix the device, start looking at what's supporting that device.

And we found that certain things were happening at the same time, well hang on, 80% of the time that occurs that's failing, right? Well can you not engineeringly fix that rather than try to fix that, to cope with that and using that to make everything more efficient from an engineering point of view so that you are streamlining things so you're not building code on code on that to fix rubbish there. And that's something that we've started to do and we're really keen to explore it when we've got all this data because if you can do that, that's going to be in service longer, which means that we retain our targets, which we make more profit. So that's an area that I'm moving into.

Sarah Nicastro: And so going back to the topic of change management, it's a really important topic. I always say it's one of the topics I get most frustrated by because everyone talks about how important it is but then continually de-emphasizes, deprioritizes actually doing it. And that is such a big problem. You gave a couple examples of the very human side of this. So technicians used to be able to like, "Hey we have this thing at this station, can you go fix it?" "Yeah sure, I'll let you know when I'm done." They stop and grab a coffee, they do this or that.

And now they're far more structured, it's far more regimented and it's the right thing to do but that doesn't make it not challenging for them as individuals, right? And so I think it is an important aspect of these journeys. And so you mentioned, obviously, I like the point about looking for the biggest naysayers and try and get your arms around why are they frustrated, how are they frustrated and dealing with that head on. I think a lot of times we think if we ignore a problem long enough it will go away and that's usually not the case.

Mike Gosling: Invite them into the discussion.

Sarah Nicastro: Any other tips or advice when it comes to change management?

Mike Gosling: Well, it's other little things as well by the way, because you can sell the benefits of it because previously when it was all very much ad hoc, you'd end up with bizarre... When an exception would happen and the only resource available who's free, he may end up getting sent right across the other side of town at the end of his shift and then he'll moan about the fact that he's got, he's spending two hours of his own time traveling back to his home base. Well we set the system up to, it knows where they start and it knows where they end. So if they want to start at one place, maybe they end somewhere else, I don't know, maybe they've got a judo lesson or a mistress or something, I don't know, something like that. But wherever it is, the system doesn't care, we'll set them so that it will actually actively try to schedule them back to that place.

So the result is if they allow the system to do the 80%, they're going to end up fairly close to where they are going, which is a massive benefit to a lot of them. The other thing about it is also what was happening before is that when you were just ad hoc exception managers, there'd be a number of engineers that got lumped with all the rubbish jobs and all the do that and they're going, "Oh why is always me that's doing this?" This system's agnostic to that. As long as they've got the skills so they get a better variety of jobs, they get a better profile of jobs, they have more life, more work enjoyment and that sort of stuff because they're not the ones that are always dumped on to do the stuff because they're the ones that complain, "Can you go and do that job?" "No, I don't want to do that." "Oh sorry I know it's you again." So they get a better scope of jobs, they get a better things. And the final thing is that when, one of the frustrating thing, engineers actually like to do a really good job. I know that sounds strange but they actually do. That doesn't sound strange. What I'm saying is that we always, some people think of engineers like want to leave early and do that and I've portrayed them, they're brilliant. They are the bread and butter and when you give them a system where it's just go and do this job and do it and you're getting jobs, they're more empowered actually to do a what's the... They know that they're not going to have another phone call saying do this, where are you? What you doing? There's no kind of external pressure put on the mini board. They are literally just empowered to go and do a great job. Does that make sense? They got tools to do it.

Sarah Nicastro: I think it's a really good clarification which is if you are investing in the right technology and you're doing it in the right way, it should be something that is helpful to them. If you're hearing a lot of complaining, it's probably, it could be partially because something is not working the way you intended it to, right?

Mike Gosling: Right. Yeah, exactly. So they no longer get the continual, "Where are you? Are you going to be finishing the next? There's a job at so and so." It's literally, I mean we tried to introduce something into the system to give them an awareness that it was busy whereby we sort of changed the hue on the colors so that they were aware that things, it never really worked. Because in actual fact they just chug through the jobs and they get and do a great job. So you sold them a number of benefits about lifestyle, being back at home, being more able to do a variety of work and stuff like that. And also if you want a better variety of jobs, get an extra skill because the system does it by skill, bang the skill and then away it goes, it'll just automatically the next day you might get one of those jobs.

So there were that, that's some of the methods we used as well as introducing some of the people in and stuff like that. Yeah. Oh another thing is that learn, there are certain things that I said to you earlier, two assets, the same thing. They've both got to be up the exact same amount of time. As I said the outcome is so many hours, so many hours. But the way that they're environmental conditions, one of them might be strategically important for us for reasons that I can't go into, others might be rubbish, but we don't know some of those, the engineers know some of those. So we learn from the engineers those things and because we then bolt them automatically into the processes and the rules and the business rules in their FSM and in PSO the engineers don't have to suffer the pain that they were suffering because just get there. The system now takes those into account and kind of works around them.

Sarah Nicastro: Democratizing some of the knowledge that prior was only in a certain technician's brain.

Mike Gosling: Yes, yes, yes. Thank you. I'm going to remember that. Democratizing the knowledge.

Sarah Nicastro: So one more thing I just want to talk about real quickly Mike, and this is another thing I like about you is you know mentioned earlier that your team and this tool are well regarded within the business and with good reason. But you could've gone through the initial pain and adjustment and got it working well and then just kicked back and put your feet up and you are of the mind not to do that. You're very focused on continual improvement and ongoing innovation and I think that's a very important mentality for leaders to have today because the pace of change isn't slowing down, you don't want to rest on your laurels. So talk about what that looks like for you.

Mike Gosling: What it looks like for me is in my team I'm scrum band, I'm the product owner and I'm with other things but I have pillars they fall into. Number one is our customers, external customers, winning the customer. I said that winning the customer. So that's the main pillar. So when they request something it drops into that pillar of work. Number two is our internal customers. Because if you're going to win external customers, you might as well win your internal customers. In fact, it's probably more important to win those so that you can win the external ones. So it's external customers, internal customers, then you've got your business as usual making. So checking the logs, checking the sus, this size, this thing, that sort of stuff you know are making sure that the infrastructure's working. Three then these are the two fun ones. Innovation, ideas, innovation, innovation.

I've had an idea, drop it in there, let's go that. And then the final one is continuous improvement driven innovation. And they are two very different things because continuous improvement is very often because you're looking at an issue that's occurred and then you're back feeding into. Innovation is dropping pure innovation into that cycle. There's a sixth one which is heart to mind and that's a sort of an overlay one where we want to be a wonderful team that everyone thinks is fantastic and it's just a reminder of the fact that sometimes changing the color of something has no discernible need to anything other than just the heart of minds of something. Does that make sense? And these tiny intangibles can add up to a massive thing. So if someone comes to us and says, I've always been fed up that it's red, can we change it to blue?

Sure, let's do that. So they're the pillars and we drop our work into those and when we go to the customer and say, you know, are paying us and all that, we actually say to them, I'd like a few of my releases a year to be innovation. And you might not necessarily get the full benefit of that because some of it might be to do with the way that our processes work. It might be a process innovation, it might be a sort of an internal technology innovation. But because we are more efficient, you will ultimately see it. And they very often come back said Yeah but we are paying you to deliver... Yeah. And then what happens is because you have good discussions with them, sure you can have that whole releases for your innovation, off you go, do it wherever you like. So they're the pillars and they're be dropping and that's the way we work.

Sarah Nicastro: I like it. Does anyone have a question for Mike?

Guest: Hi Mike. When Cubic changed to the hours were up time in quite a rush really?

Mike Gosling: It was, yeah.

Guest: You talked about really meticulously understanding the new contract with on your customer side. Did that change necessitate a contractual change with your engineers?

Mike Gosling: I've asked that question and I think it probably did, but I was so deep in the systems working that I've never, I could have taken that away. I don't You are probably right. It probably did. It probably did I've got your details. I think I can I take that away and get back to you? Yeah, certainly because of the recording of information, we had to go down the GDPR route and understand the PII and that may have meant that there was contractual changes to allow certain PII to be recorded and stuff like that.

But yeah, can I come back to that? Because it did totally change the way that they're working. One classic example was is that the very first day I was in the office, an engineer literally got allocated a job and the phone rang and he phoned up to complain his exact words were, "I hadn't been to F-ing Kings Cross in 10 years and I don't intend going today," because the system had, because he'd built that personal relationship with the FRC. So they had totally changed their way of working. But yeah, I'll have to find that out for you.

Guest: Nothing perhaps more of an observation than a question then what I saw were you saying is that when you put in the sort of looking after those devices at scale with the automation, what you're actually doing is taking away all the manual time that Cubic were investing in sort of booking jobs and dispatching them to using the information you learn from the field to try and engineer in improvements so they didn't fail in the first place.

Mike Gosling: I've got this, Rob was going to get really well because I say this all the time, I've invented this, it's my term I think there's no one called toast, but knocking the corners of spheres. My team hate that. What it is we've designed, there is a service or machine that creates perfect spheres and then one day it starts dropping cubes out. So a whole team jump in to knock the corners off that and turn them back into spheres. And then the end result is that we've got spheres coming out of it. I'm always saying, hold on a second, why are we knocking the corners off spheres? Why are we not fixing it up upfront? Why are we not going back to the original process? And whenever we have our innovation it's like okay guys, are we just knocking the corners of spheres here?

And they all go, oh he said it again. But it's kind of a little mantra that says no actually let's go back to why is that? Is that actually failing because that is the thing or is it because something prior to its causing. You are always here, every system, oh there's a new back office release happening tomorrow. New back office release, new back office release, new DGC release, new back office release. Back office releases nine times out of 10 will actually be, if you've got integrated solutions and your IT services and readers and things, something's going to have an impact on that, whether you like it or not. And it might be that a transaction that's coming up there to pass a payment transaction is now colliding with a new clock in the back office that's doing this. Now they've never tested it in the real world expanse.

They did limited testing because we all know testing's very expensive. So you'll do workshop testing for one week 2000 jobs, bang real world, one week 2 million jobs fails, fails, fails. And that's where I'm really keen to look at that data and that's why I call it collisions because you look at it and say let's actually look at what's happening, what alerts are happening, what time is happening. Oh look that P1 is occurring because you'll get that file transfer the exact moment it's trying to do a reboot act or something like that. Oh hang on. What about if you separated those and that sort of thing? So apps, this is the thing I'm really engaged in now is that back engineering and I'm annoying quite a few people by doing that. It's difficult because it's difficult because once you've got something working really well and everyone's profits are up and everyone's applauding it and everyone's off having big cigars in race meetings and things because all think they're fantastic, upsetting the apple cart, it's like, oh and this is where innovation is.

It's like do we really want to do that? So we are looking at tools to have machine learning and stuff like that. But the other thing is by the way, you've got to have a story. You can't just look at data for the sake of it. You've got to be solving a specific problem. For example, that reader has a P1 that occurs 20% readers four times a period. That is, and then when you are looking at the data stop, you must not stray out of that. You must not go off and start getting, oh I've noticed this, hang on. Is it having a direct responsibility of that? If not part that for something else and come back to it actually that. Because that's the thing with data, you fall into this ocean of it, everyone calls it the ocean of data and you end up swimming in a massive sea of it. So make sure you really define your story and your success criteria. The success is that you'll no longer have P1s 20% of the thing.

Guest: Yeah, it sounds a really healthy thing to do. You're actually, service organizations are good at being busy and sorting out the here and now, but you sort of looping it back and preventing a lot of it is sounds a really good thing to do.

Mike Gosling: Let's stop knocking the corners off spheres. I think there's number one called toast, isn't it? Toaster comes out burnt and everyone scrapes the burnt off to turn it back into toast. It's same sort of thing, isn't it? Yeah.

Guest: Okay. Thanks Mike.

Sarah Nicastro: Yep. All right. So guys, we're going to break now for lunch. We are going to have 45 minutes for lunch. Okay. So everything is on the back bar, it's help yourself. So please go ahead and do that. And one favor that I will ask if you can each take just a couple of minutes on this back wall in this networking area, there's a board of what's your biggest challenge. If you can write something on there, I would greatly appreciate it. Okay, so that's your homework for lunchtime, we're going to have lunch and then we'll be back for three more sessions. So we'll see you back here around 1:30. Thank you, Mike.