Low code development platforms are simplifying processes, enabling agility, and transforming the way teams solve business challenges. In this episode of Connected & Ready, Gemma is joined by Russ Felker, CTO of GlobalTranz, for a conversation about the possibilities, applications, and advantages of low code technology—and practical strategies businesses of all sizes can use to adopt it. See how Power Automate helps organizations of all sizes accelerate their digital transformation through low-code automation. Watch this short video: https://aka.ms/AA8l72o
Host Gemma Milne is joined by Russ Felker, CTO of GlobalTranz. They discuss GlobalTranz’s experiences with adding low code technology to their logistics operations, the issues it resolves, and what it takes to implement it successfully.
About Russ Felker
Currently the Chief Technology Officer for GlobalTranz, Russ has been a leader in product development and technology for more than 25 years. He has led the creation of multiple technology products solving issues within business process optimization, IT management, and storage and blockchain across diverse industries.
Learn more about Russ Felker:
https://www.globaltranz.com/about/leadership/
Topics of discussion
Sponsor link
Learn how Microsoft Power Automate helps organizations digitize paper processes and automate time-consuming, manual tasks—without writing a single line of code—in this short video.
Helpful links
Follow us on social media
Twitter: https://twitter.com/msftdynamics365
LinkedIn: https://www.linkedin.com/showcase/microsoft-dynamics
YouTube: https://www.youtube.com/channel/UCJGCg4rB3QSs8y_1FquelBQ
Music playing [00:00:01]
Gemma [00:00:05] Hello and welcome. You're listening to Connected and Ready an ongoing conversation about innovation, resilience, and our capacity to succeed. Brought to you by Microsoft. I'm Gemma Milne. I'm a technology journalist and author. And I'm going to be exploring trends runs how companies are adapting to a disruptive world and preparing for tomorrow. We're going to speak to the innovators who are bringing products, operations, and people together in new ways. Today, I'm chatting to Russ Felker, CTO of GlobalTranz, about using low code automation and analytics to solve business challenges faster. We discuss how Russ and his team experimented with more basic low code applications, but quickly moved into using these platforms for even more complex and highly useful business solutions; how did teams across GlobalTranz not only adopted these new applications, but were queuing up to automate much more of their work after seeing the power of these low code apps; and what it takes to start employing local technology in businesses of all sizes today.
[00:01:06] Russ, thank you so much for joining us on the show. I would love it if you could start by giving us a little bit of an introduction to yourself and GlobalTranz.
Russ [00:01:14] Absolutely. So I am the CTO of GlobalTranz. I've been in technology for twenty-five years. I think I don't sound quite as old as I might actually be, but I've been doing this quite a while across a number of industries. Logistics has been always one of the ones that I've come back to on a regular basis. But right before this, I was doing a lot of work with private equity firms and acquisition strategy and acquisition diligence. GlobalTranz is a top 10 3PL. We have brokerage. We have managed transportation. We are the group that you come to when you need to move stuff from point A to point B. We work with shippers. We work with the different carriers to kind of smooth the process and make sure that as you're moving your stuff, you're doing at the best and most efficient way possible.
Gemma [00:02:05] So we hear a lot about this idea of being agile as a company, you know, being able to keep up with progress, accelerate timelines, be as informed as possible. Could you tell us about some of the tools or technology that's allowed you and your company to do just that?
Russ [00:02:20] Sure. So we started off as kind of a technology company and it was kind of, oh, well, logistics is a good place to use technology. And so we've always had our own custom software. We've always had internal development teams. And what we found over time, though, is that the pace of change never slows down. It simply increases. You need a toolbox that has more than just a hammer. I always kind of go back to that as a descriptor. You know, when people have a hammer, everything looks like a nail. And you've got to have that toolbox of technology that you can apply in different ways. And we find that in expanding that technology set and thinking about technology in different ways, that you get some real benefits from expanding and diversifying that toolset. For us, it's been over the last number of years, the addition of low code, but that addition to our toolset has been a huge benefit to us because we can use not just the tools themselves, but we can use teams more expansively. Everybody's not a low-level coder. That's not everybody that we have. We have people in business intelligence and people in data transformation. And they all have that capability and the knack, I'll call it, for kind of doing that logical thinking, thinking through a problem from start to finish. That's really core when you're trying to develop a technology solution. But they might not have necessarily gone in and really learned, oh, this is how I, you know, code in C-Sharp or a code in Java or anything like that. The advancements within the low code technologies allow us to tap into that skillset much more effectively than we've been able to in the past.
Gemma [00:04:11] So it's really interesting because obviously you said at start that you guys were a tech company that kind of became a logistics company at some point. And I'm curious because the idea of low code and in some sense seems like a strange thing for a company as a high tech company in a lot of ways and built around tech to dabble into. And so I wondered if you could kind of take us back and tell us a little bit about the decision to dig deeper into low code as a company, start exploring it. What was the sort of catalyst and what were you hoping to do?
Russ [00:04:43] You know, what we really looked at initially was, OK. So we have a bunch of processes. We have systems that back those processes, but they change, especially from customer to customer. You're always moving something from point A to point B. That's kind of logistics in a nutshell, but it's a little bit different for each customer. And they interact with their vendors and they have a different supply chain and the way that they need to communicate. So the amount of variability in how you communicate with customers, how you communicate with carriers, you know, the people that are actually moving the goods can be very different from individual company to individual company. And we found that, yes, we could try and code all of those things in, but it actually ended up being a faster path and a more malleable path to use low code technology. If you think about RPA and just the level of automation that that provides, that was a huge benefit to us in the malleability, because you can go in and make some changes, you can take a copy of it and you can run it with a slightly different take. And you didn't have to go in and make kind of these core changes to a system that deployment pipelines are a little bit simpler to set up. The QA processes are simpler. The other big thing that we were able to do with RPA was to take and apply that when we didn't necessarily have a partner that we were working with at the same level of sophistication. So not everybody has, you know, started as a tech company and decided to do something with tech. Some people started as a company and they had paper and they use paper. And then they went to spreadsheets and then they maybe they got a system in, but they just have it to almost take place to the spreadsheet. Or maybe they never got to that point. One thing that we found with low code technologies is that it was easier to work with companies who maybe weren't quite as far along in their kind of digital transformation journey as far as getting information from them and being able to process that through the same core systems that we were getting from those that we were doing things like full API connectivity, you know, or that we were using our data transformation team as far as flowing things like EDI documents or flash file documents or anything through a system. So those were kind of the two areas that were catalysts for us and where we saw kind of immediate benefit from this approach.
Gemma [00:07:20] You mentioned RPA. For people who are listening, who might not have come across RPA before, can tell us a little bit about what that is.
Russ [00:07:26] Yeah, so RPA stands for Robotic Process Automation. It is just simply a piece of code, because even though we're talking about low code, when we talk about RPA, it's still code that's actually occurring back there. So it's a piece of code that just simply runs and does a specific task in a repeated task, it can be a one off, whatever it is. But it just automates that task. And it's usually defined by having a more visual builder to where you're not typing in code, but you're linking different actions together. Sometimes you can have a recorder that will allow you to do things on the screen and it records it. Anybody's as old as I am listening to this, you would remember the macro recorder in Excel. Same principle. I mean, in reality, when you think about it, that was the precursor to true robotic process automation – just macro recording in itself. Well, this is it on a grander scale.
Gemma [00:08:28] I was going to say, you don’t need to be that old to use macros. I use macros. When I started starts in investment banking, we used macros all the time.
[00:08:36] So there you go. So I wonder if you could take us through some examples then of your low code approach. You know, tell us what the problem was, how you guys went about trying to tackle it through low code and tell us a little bit about some of the possible challenges or stumbling blocks along the way.
Russ [00:08:51] Yeah, absolutely. So, you know, we started with, as I said, kind of looking at this as a way to automate some tasks. One of the initial sets that we did was just moving information between our custom application and our financial system. So we had people that would look up reports and they would take those reports and they would transform them and then they would import them into a financial system. And we figured out pretty quickly, it's a lot more useful to have those people actually looking at the financials and doing trending and doing all sorts of analysis rather than copying and pasting. And so we initially put some bots in place to just say, OK, great, we're gonna take this from the system over here. We're going to transform it. We're going to put it into the system over here. Instant savings, instant ability to start leveraging people in more strategic ways. Bots are great. They're also very simple. They can do whatever you tell them to do and that's all they will do. And they take it very literally. People, on the other hand, can be strategic and they can think of different pathways and they can do things that a bot can't do. So we looked for other opportunities to use bots and to leverage bots. The next one that we really tackled was proof of delivery. So if that if you've ever gotten an email saying your package has been delivered and sometimes it has a picture and some other information about when they dropped it off and who the driver was, that's proof of delivery and that exists across all of logistics.
[00:10:23] Being able to go and get those, however, varies distinctly between different carriers. And so sometimes you can get em electronically through an API or something like that. Sometimes you have to go to their Web site to get the information. It's still electronic. It's still available digitally, but they don't have a way for us to reach in and get it other than going to a website and pulling it. Again, comes along kind of low code approaches where we can have an automated process, go and just look and say, OK, do I have a POD for this load? Do I have a POD? Oh, I've got it, great. Pull it down. Put it into the system. And now it's there. And now you don't have to worry about having a person that's sitting there just going and checking websites. We don't really want people to do that. And to have a fulfilling time at work. And so that's how we kind of approached it. So those were the initial things that was taking those rote tasks, those repetitive tasks that were fairly clearly defined and automating them. Now, of course, we immediately started noticing that, OK, well, it's not like it's just a set it and forget it. Surprisingly, businesses over time changed their website and a bot does not accept that well. And so you have to go in and say, oh, it's OK now. This button's over here. It's OK. The button's still there, but it's over here now. And then the bot goes, OK, all right. I can do this. And now it goes through and does what it needs to do again. But you have to have that management and that maintenance around the bots. The other one that we ran into was we're really, really successful. And so everybody in the company started going, “Can I have a bot to do…?” Because very few people want to do these kind of rote, repetitive tasks. It's The Simpsons episode where, you know, Homer is working from home and he gets the little bird that tips back and forth to hit the key on his keyboard. That is truly just the definition of what a bot can do. And if you've got a person doing that, that's just, oh, I can't imagine doing if it were me.
Gemma [00:12:44] That was actually what was going to be my next question was around getting staff on board, because you mentioned it in the beginning, you know, and not all of your staff are technical experts. You have people from all across the company that have expertise in other areas. But, of course, have parts of their job that would massively benefit from enhanced systems. It's interesting what you said about everyone's sort of jumping and going, “I want one, I want one.” Whereas a lot of the time when new technology comes in staff can be a little bit hesitant and kind of like, “I'm not sure about this new system, it doesn't work as well as the last one or I have to change things.” So I wonder if you could tell me a little bit about the staff reaction or possibly a culture shift that might have had to come in with this idea of actually you can build tech, too. It's not just the tech team that's doing this stuff.
Russ [00:13:31] Yeah. And I'd say we don't have a democratization necessarily of the technology in that anybody goes in and builds it. It's more of a republic, whereas it is a set of people who are kind of going in and building that technology. And I think there's a lot of talk about full democratization and oh, anybody can go build a bot. But that's just not the case. Even when you're using low code, it is still code. There is still the creation of a logical process. The understanding of how systems communicate. You know, you go to somebody who's a lifelong operations person in understanding logistical routes and, you know, the construction of, oh, I can move it across these three modes of transportation more effectively by doing consolidation and deconsolidation. I couldn't do that. Maybe I could get my way through it, but I would not do as good a job as somebody who's been doing it. The same is true for any type of code. You have to have that kind of at least base understanding. So what low code allowed us to do is really increase the number of people who could develop and who could develop production level technology from where it was before. Before you might have the business intelligence group and they would put a report together and then they'd have to hand it over to engineering and engineering, would have to wrap something around it and get it to display up and all this kind of stuff. Now, with the low code approach, BI can actually take from soup to nuts, a full delivery. We actually just had a business intelligence team take from the initial data set and push it all the way through to a UI and delivery to the business and in 30 days using low code technology, which was great. Yeah, because it sped up the delivery. It's allowed us to take and just leverage our larger technology group who are all familiar with a lot of the concepts that you need to be able to go in and leverage a low code technology. You know, when you think about something like RPA or any type of Power Platform stuff or anything like that, it lends itself well, if you understand basics of IT, if you don't and you don't really have that background – looks a little mushy. What you're supposed to do.
Gemma [00:16:03] Of course. And I think the thing that I'm thinking more about in, you know, when I've been having conversations with people about RPA and low code and these kind of approaches that are different from before, it's not so much about being like everyone in the business can now be building their own bot.
[00:16:19] But what I do seem to see as a bit of a trend is that it’s kind of like the penny drops for people who were in IT before and they go, “Ah, this is not just a task I do. This is something that can be automated.” And I think what that does is really interesting for companies is it basically means that you're starting to get the people who have the problems, being able to present them to the teams that are building the solutions, but not the ones living the problem right there in front of them. So I wondered, did you sort of see that with Globaltranz, that sort of shift within the staff? And also, did you see that the kind of original what you sort of was talking about, basic use cases started to evolve into perhaps more complex cases and still being able to use the low code solution?
Russ [00:17:07] Yes. So definitely from the perspective of people wanting to use bots to enable their kind of daily tasks. And it was it's a bit of a pendulum. So there's this you have it where nobody really knows it exists and then it tends to swing. It's like, well, can it just do all of these things? Yeah. And some of them fit, some of them don't. And then you have to go through and kind of define. And what we found is that it was a big rush. It was like this land rush.
[00:17:39] And that was great because it gave us a whole bunch of ideas. But then it became – OK, now let us walk you through how we define whether a bot can actually help or not. And it was actually more about having everybody understand how to communicate a process effectively, because that's really the grounding. Whether it's true coding or whether it's low code, it doesn't matter in the end. You have to start with that process.
Ad [00:18:15] Microsoft Power Automate is helping organizations digitize paper processes and automate time-consuming, manual tasks. By bringing together robotic process automation, digital process automation, and AI together on a single platform, Power Automate serves the entire spectrum of an organization’s automation needs. Watch a demo by following the link in the episode description.
Gemma [00:18:39] So you mentioned this idea of it not being fully democratized and you know that the ability to do low code doesn't mean that absolutely everyone can come in and do things. How involved, then, are you and your team when you start looking into building low code solutions? And also, how do you identify people who can be involved as the low code people, whether they're the ones coming in and helping build or even the ones just them putting forward projects are going to make sense for you guys.
Russ [00:19:09] So the involvement really has to do with tying the development of these into your other technology processes. So that means that it's not just an individual that sits there and does 100 percent of everything and then it deploys. It's somebody is building it. There has to be things like a test plan. And how do I validate that this actually works? And then it has to run through a QA type process to be tested and get the results and, you know, and then it goes through a deployment. So you have versioning and you can understand the history of it and see when it was deployed and how was deployed and the various dependencies that go along with any bot because any of these still have to interact with other aspects of the system. And so there are dependencies and how you roll those together and validate them is core to really the dev ops process. You know, even though it might be somebody that's not in traditional engineering that's building this, they still have to have all the same interactions. I deploy a new version of a bot. I need to be able to roll back if there's a problem. And those are things that are basically necessitate an interaction with the larger technology group to be able to make sure that you're in the same processes and tools and, you know, just approach that you're taking as an enterprise to technology. As far as how do you find people? What we found is that once you put it out there and once you start leveraging the technology, people find you, people start to gravitate towards it, and you can almost immediately find people who get it and start to understand how these flows work and can put it together and who are good at testing it and validating it. So it's involving the business and the different, you know, different staff helps to identify those people. And then in many cases, they'll come and say, hey, I want to use this more. Can I be more involved in this? And that's when you can start to do that. We do things like we shadow develop and, you know, they have to learn certain processes and go through certain trainings if they are coming in from a non kind of development group into the development group. Those are the kind of key ways that you can start to understand who is not just has a talent for it, but who's actually interested in doing it, too.
Gemma [00:21:37] So we're talking a lot about low code here. What is it that enables you guys to be able to do this low code? You know, is this something that you've built yourself kind of platform, have you partnered? Tell us a little bit about that.
Russ [00:21:50] Sure. We mainly leverage partnerships when it comes to low code. We use tool sets as opposed to having built it internally. There's a lot of great tools that's out there. We focused on using the Power Platform. So Power Apps, Power Automate, Power BI, Powershell. And then we have from an RPA perspective, we've started to dabble into the Power Apps side of that. So there's a number of tool sets that we use. And we went with the Microsoft solution mainly because, one, it fits our model. So we are a SharePoint group and we have AAD new active directory and we use Azure for our cloud provider. So it fit in with the kind of technology set that we were already leveraging.
Gemma [00:22:38] So I wondered if you could tell us a little bit about some of the more complex use cases. And kind of ironic, complicated use cases, but using low code, because that's one of the things I think is really exciting about what you guys are able to do at GlobalTranz. It's not just filling the gaps and getting rid of these inane but arguably simple automated tasks. You've been able to do some quite exciting stuff.
Russ [00:23:00] Yes. So we actually had just recently and I mentioned that it's a cost prediction model. So this is something that our analytics and business intelligence group has worked up and it's evolved over time to get better and better and better at saying, oh, you've got a shipment in this lane. And based on all of our historical knowledge, things that are going on in different parts of the country, here's what the cost of that lane is based on our estimation by having all of this in your data analyzed. And that's great. But you have to think about, a little bit about what just happened. So if you were looking at, say, 2019 data. On what the costs of a might be in a particular part of the country for a particular type of a shipment, and you're looking at March 2019 or April 2019, and you tried to compare that to 2020. That would be wrong. Yes, the analytics can say, based on my historical analysis, based on some other things I'm seeing, I can come to this conclusion. But then you need a person to come in and say, hold on. You're not taking into account “X.” And I know this because I've been watching this happen every day for the last week. And then I can see what's happening, even going out to next week. We actually took this model and we had a number of customers that were looking and saying, hey, we want, we want you to be able to give us more dynamic pricing. Sure. OK. And now we can take this model, we can bring it in, but then we can have a person actually review it to make sure. Yeah, this makes sense. This doesn't make sense. This is a little off. Make adjustments and send those out. That was all being done very manually. Now at least we have it using low code technology to be able to put the recommendation right in front of somebody. And then instead of them saying, OK, I see what that is. Let me call up the customer and tell them what the price is or send him an email or something like that. They can just click, verify, send, and it instantly goes to the customer, to the shipper, and say, here's your rate. We were able to leverage this low code technology to bring that data out, to effectively consolidate it, get the rating, put it in front of a person and allow them to interact with it. That would traditionally be a coding endeavor, something that would go to engineering. But with advances in low code and the availability to not just put it together, but also have it be enterprise or production ready. Now, you can actually bring up and have this as something that a team that traditionally wasn't deploying an entire system put together and deploy it out.
[00:25:50] And so we were able to get this cost prediction model ready to go for our customers in 30 days. Which could easily have been a two to two and a half month project. So it was a it was a huge benefit on timing and then an enormous benefit on the customer side to be able to just say, OK, great, we can do that now. That's something you've asked for it. Here we go. Here it is.
Gemma [00:26:17] So what's the bottom line? Why low code over other technologies? And how do you go about deciding when to use it versus some of the more complicated high tech, that you do have the capability in-house to do?
Russ [00:26:31] So one of the ways we've found it's been very advantageous for us to use low code technologies is that systems that we build don't last forever. Basically, as soon as you write a line of code. It's technical debt. And so we go into remediation process. Now, that doesn't mean that that system necessarily gets thrown out wholesale. But it might get put into a sunset or a maintenance mode. But that doesn't mean that there aren't things that the customers still need for us to do in that system or that we need internally to make that system more efficient based on a new process or something else as far as an interaction with a partner or a customer. So as you're thinking about going back into those sunseted or maintenance systems and making changes, low code is a really good way to say, oh, well, we can still do that, but I don't have to go touch the code. And that means you can also keep your engineering staff moving forward with what they're taking on. There's, I think, some, you know, deployment of low code apps and the UIs are still relatively simple. You know, you can make a simple UI with a low code to form a grid, but it doesn't have 100 percent of the functionality that the custom pieces do. And so you have to weigh is that functionality core and critical to the process, to where I need to take it into the high code or can I use low code here? And so then you start to dig in and say – what would it be to your day if you didn't have this feature and you go through that process and in some cases it kind of falls out. You say, yeah, I got to do high code on this. And in some cases it falls and you go, you know what? No, I can do this with low code. That makes perfect sense. And so it's really driven by the features, by the function and to an extent still by the scale. And so many times when you're looking at something that's got to just scale to this much larger size of, you know, hundreds and thousands or millions of transactions, you're going to want to get into the deeper level, you know, that high code solution so that you can truly optimize. But that might not exactly fit what you need to do from a speed perspective, from a resiliency perspective, from a scale perspective. And so in those situations, you've got to kind of look at that and go, you know what, this makes more sense for me to go in and really build this with that high level code component as opposed to using low code. The example that we've been talking about with our cost prediction model and the delivery of these rates to customers and things like that, we only need about 100, 150 users and they're all internal. And so it just fit the mold. But we go out and we say up to 10,000 people can access that and they're not all going to have active directory accounts and they're not all going to have the licensing necessary to do something like this. And we have to then start to mess around with how licensing works and how we can allocate and get that all set up and heads to start to fall over a little bit more into the high code.
Gemma [00:29:50] Particularly large companies that do have the departments, the IT departments to be able to do these things. And I think that's one of the things I find so fascinating about low code. In some sense, you would assume that a lot of the people who are building these products would be targeting them, that small, medium sized businesses that can't afford these teams. Actually, it sounds like what you're saying is it's a real huge benefit for you guys, not just in terms of your own costs and whatnot, but actually in terms of rethinking how to build some systems.
Russ [00:30:20] Rethinking how to build it, where to build it. You know, you're talking about just kind of, you know, who does the development and who actually does the creation. I always think of the movie Ratatouille. But, you know, to me, the whole theme is anyone can cook. And you learn through the movie, it's not that anybody can cook. It's not that everybody can look at the spices and smell and all those kind of stuff and know exactly what to put together to get it right. But a cook can come from anywhere. And that, I think, is what the promise of low code provides is that you have developers right now sitting in your company that they might not even know their developers. You know, we just recently in the last week, we had somebody come over from our IT Help Desk and infrastructure group. They're moving into our data transformation team, which is who does our low code technology. And they were somebody that was really big into Powershell. And they were using a lot of the behind the scenes scripting and things like that to automate things. And they said, you know what, I'd really like to get more into coding. And we're like, we got the job for you. We actually shifted him over and he took to it right away using things like logic apps and going in and building a POC. But he knows how the systems talk. He knows what is going to be expected when you're communicating between systems in between software components. Because he's had to support them for a number of years. So he has that background and he has that ability to kind of think logically, work through that problem and do that. And so that's, I think, a big plus. And those people are in your company right now. That's the thing that people don't think about. They think about, oh, I need to code something. Let me call a software developer. And that doesn't have to be the way it is.
Gemma [00:32:11] So for these people who are perhaps, as you say, a little bit hesitant, where should they start? How do you really begin to implement low code?
Russ [00:32:19] I mean, the first thing you want to do is and this is key. You've got to be very diligent about identifying your processes, whether it's full on lean Six Sigma and doing the, you know, work in process analysis and things like that. But you've got to at least be able to put a, you know, process flow together because that starts to give you an idea of what you should be doing. And then I would say it's really just a question of going in and trying, it is going in and building something, once you find that one or two or three processes and you go, you know what?
[00:33:00] This is a pretty straightforward thing. We're repeating it on a regular basis. Those are things we always look for, is how long does it take? How many people are doing it? And how often do they have to do it during the day? If you can answer those three things and you have high numbers on any of them, it's almost always a candidate for some sort of automation.
[00:33:22] And one person said to me once, and I really liked it, so I completely stole it. There's two types of automation. There's the big A automation and the little a automation. And this is where you can kind of I think with low code, you can do some of that little a automation to start. And then you can then expand into that big A where you're automating those more complicated processes and maybe even interacting with customs systems that you've built through custom connectors and moving things back and forth between low code and high code environments and all that kind of stuff. Start with that small a, start with that. Here's one thing that I've identified. It hits one of those three variables and a lot of people doing it. They do it on a number of times during the day and it takes a very set amount of time to execute. And once you've kind of identified those, you can pretty easily tick where you start.
Gemma [00:34:19] I wonder if you have any advice or lessons you've learned over your journey of using low code.
Russ [00:34:24] Yeah, I think a couple of things. One, don't be afraid to put it out there as a potential option for anything that you're doing. I challenge my teams all the time when they say, oh, we’ll need to program. We’ll need to get programmers involved. I will immediately say, well, why can't we do it in this way? What prevents us from doing it? Not necessarily saying that's the best solution. But you want to think about it more in parallel with your other types of technology endeavors. So that's one. The second one is. Use it as a way to figure out who can help you to more effectively bring forward your technology. Get people involved in that kind of custom coding that maybe hadn't been involved in it that much to date and use it as a way to foster diversity too within your programing environment. It's you know, it's a way to get people in and get that perspectives in and inject some business into IT effectively by having those people come in. And then, you know, the third one is make sure that whatever you're doing at an enterprise level, it has to be approached from an enterprise perspective. So you have to have the same rigor around testing, around deployment, around management, around monitoring that you would with anything that you do. Just because it's easier. I'll put that in quotes. “Easier” to build. It does not mean that you can kind of skip a lot of the other things. You know, scalability and a variety of other scalability, whether it's manageability or monitoring or anything, those are all critical components to make sure that as you make this an enterprise technology that is resilient enough to be an enterprise technology. Because you can deploy anything. I don't care what it is. It could be low code technology, it could be true kind of coding. You can deploy it in such a way that it's not enterprise technology. And so I think people skip that piece sometimes. When you think about, you know, RPA or low code, because it's so much more straightforward to just implement and get it out there and get it running. But you've got to have that that same level of rigor and that same level of kind of focus around making sure that it's enterprise ready.
Gemma [00:37:02] Amazing, Russ. Thank you so much both for sharing all of those amazingly actionable and useful pieces of advice and also taking us through some really clear examples. Because I think sometimes with technologies that people might not have dabbled in yet are only hearing about, it's so useful to be able to just hear these clear cut, you know, this is the problem, this is how we implemented it, these were some of those technical challenges as well as cultural challenges. So thank you so much for sharing so much of what you guys have been doing, and joining us here on the show.
Russ [00:37:29] Not a problem. Thank you, Gemma. Appreciate it.
Gemma [00:37:34] That's it for this week. Thank you so much for tuning in. You can find out more about Russ's work and indeed some of the broader themes we discussed today in the show notes. Don't forget to subscribe to the podcast and tune next time to continue our conversation about innovation, resilience, and our capacity to succeed.
Ad [00:37:56] Learn how Microsoft Power Automate is helping organizations digitize paper processes and automate time-consuming, manual tasks – without writing a single line of code. Watch a demo by following the link in the episode description.