Data as the Common Thread: Process Safety, Metrics, and Career Lessons with Kris Doering

Speaker 3 (00:00) Welcome to the ITOT Insider Podcast and David, think this is the first one of 2026. Now we're going to start this time with somebody who works in the field, who works in refinery, has lots of experience with data and production. Who did you bring this time, David? Speaker 4 (00:20) um I'm extremely excited to have Kris here with us, uh Kris Doering um I think he embodies the topics we'd love to discuss. No pressure, But I think he embodies the topics we'd love to discuss um about data, about cooperation, about becoming better at our jobs. and Kris done that at several companies. um So, but I'm not gonna try to tell your story. So Kris, first of all, thanks for joining us. And why don't you kick this episode off with a bit of introduction about yourself. For sure. Yeah. Speaker 1 (01:05) Thanks, David. Thanks, Willem. As you said, my name is Kris Doering. I've had a pretty uh broad ranging career doing a lot of different things. But what's been most interesting about it to me is that data has really been a common thread through the whole career. And no matter where I worked, what field I worked in. it's really been the thing that's tied all of my roles together. What I do now, I just recently took a role about a month ago at SaskEnergy, which is a government owned uh corporation that uh has the monopoly on transportation and delivery of natural gas in my home province of Saskatchewan. We do system modeling to determine uh the assets that we need to set up in the gas delivery and transportation system. um You know, we kind of help manage projects and things like that. Obviously the, um all of the simulation and modeling that we do is very data intensive. um And, know, without good data practices, you can run into problems, errors, um or a lot, just a lot of work. You know, it can be very manual if you don't have good data practices. So just starting that and working with a team of people here. I'm not a representative of SaskEnergy . So these views are mine. And it's very important that I say that, but other than that, I should be able to speak pretty freely. Speaker 4 (02:37) Hahaha Speaker 1 (02:40) Yeah, right. No, no. Yeah, I can't tell you all of the secrets of Saskatchewan gas transportation that I'm sure you're super interested in. That's true. Yeah. Speaker 4 (02:51) uh And so that's your job now since a couple of weeks. um What did you do before um moving into the energy or gas distribution sector? For sure. Speaker 1 (03:03) uh Yeah, David, before that, um we probably got to know each other through this, the Teradata Possible Conference in 2025. uh At the time, I was presenting on a project that I was working on in the data warehouse kind of business intelligence space. uh And I was working for a company called the Cooperative uh Refinery, Co-op Refinery Complex, uh also a refinery in Regina, Saskatchewan. it... It's a medium sized refinery. It's very complex refinery. And what I was doing there is I was the superintendent of, you know, like it's been so long, it's been a month. haven't, I haven't done my elevator speech on that place in a while. I was the superintendent of refinery performance improvement. And so we did, we did, you know, goal setting, strategic planning, that kind of thing. I call that outcomes and indicators that facet of work. We did benchmarking. There's a really large benchmarking study in refineries called Solomon. about 85 % of the world's refining capacity subscribes to that. And we were being really successful as a team inside of a refiner with no sibling refiners, the company only has one. And so was really important to do that benchmarking work for them. And we were being really successful. Solomon was really pleased with the work that we were doing in that area. And we were helping get good value to the business, understanding what it is, how we were performing. Before that, I worked at the refinery and process safety, which is a very data intensive role for sure. I was doing incident investigation lot. We did deploy a HSC software suite there though, which was, you know, obviously very data heavy. And then before that I was working in equipment reliability, rotating assets. know, like pumps and that sort of thing, motors. And that was at Mosaic at a Bell Plane solution mine facility. And they have a facility right nearby now actually owned by K plus S and other solution mine uh for potash. um Before that, I worked at Canada post for, for almost 10 years, maybe seven years or something. And Willem and I have that in common work in the postal industry, uh which is a fascinating industry. There's a lot of data there. worked on a number of IT projects, strangely uh at that place. And I did a lot of work in Lean Six Sigma. So continuous improvement. You know, I became passionate about that and that really helped with equipment reliability. and helps me all the time now. I was just in someone's office kind of learning about the business here, talking about IT and that, just popped their head into my office here. That work really kind of like has prepared me for all of the other stuff that I've done. And that person was talking about all of the interconnected data systems and was really happy that I knew Lean because then I would know processes and that was really important to her. And then before that, my first job, you know, kind of out of school was working at a small consultancy. And we did a lot of work delivering pie systems to upstream gas producers in Alberta. uh so, you know, one of the, had a pretty significant pie server. The company we working for had an unlimited license for pie tags. And so they ended up installing a server at every site. Yeah, it was awesome. It was great. was, I'm ruined as a pie person cause everything was cheap. Yeah. Why don't we just bring it all in? That's always the answer. Yeah. Why not? Yeah. Which I say, I say still in the data warehousing people generally don't like that. They like to be more organized, which I've learned is important for sure. So, you know, we'd bring in a lot of data and then all of the different site collector servers would then centralize into a central server and it allowed the engineers at head office to do, to do good work with, with near real time data. Um, there, was a really lengthy process before very manual is how they got the data off of charts and recorded it, sent it to the government and ended up getting the data six months to a year later. And that's what they used. Um, yeah, for, you know, like placing compressors and things like that, making million dollar decisions and, and not, uh, you know, just working off old data and, and the, the, you know, the well, pressures and flow has changed very dramatically, especially at first. And so if you're doing a lot of drilling activity, uh all of the like the dynamic situation could mean that you can't make good decisions though timely data. So that really impressed upon me the importance of getting real time or near real time data in. So that's a bit about my career. Yeah. Speaker 3 (07:32) lots of different things. I I think that's also interesting. It's like there's something to be said to have like been working 20 years in one field, but I think also if you go in different fields, you bring something from that with you. And it's super rare that I get to talk to anybody about the postal world. I mean, I only did like a... Speaker 1 (07:50) about that. Yeah. Speaker 3 (07:52) had a short stint of a year, so I mean, definitely the same as you. uh But I also found it super interesting and I think that people don't immediately think about postal as manufacturing. So I know that you know that that's absolutely not true. is. Maybe you can give some insights to our listeners what it's like. Speaker 1 (08:17) Yeah, so and especially, uh you know, so working at lots of companies, what ends up happening is you start to learn the importance of the context, right? So like the ownership structure, Canada Post is Crown corporation, a lot of postal companies are, but a lot of delivery like parcel delivery companies aren't, for example, right? And so that uh just kind of the nuances of like the legal situation in Canada with respect to Canada Post owning the monopoly rights to delivering letters, but not parcels was a really, really interesting aspect of that work. Um, but that's neither here nor there as far as manufacturing goes, um, in Regina, Saskatchewan, it's a small place in the middle of a big country. And so we didn't get a lot of letters and we didn't send a lot of letters. We didn't get a lot of parcels. didn't send a lot of parcels, but at all, you we had to, we had to, deal with that. Anyway, there had to be a lot of infrastructure. So, you know, you're getting things off of semi, you're getting semi loads of mail. Uh, what do you, what do you call a semi trailer? Is that right? Speaker 4 (09:13) This is what you're. Speaker 1 (09:14) Yeah. Okay. Yeah. Yeah. So you get like, you know, whatever they are, 52 foot semi trailers pulling in multiple times a day, full of mail, whether it was advertising mail or at the time newspapers were still a bit of a thing. You'd have parcels, Amazon was coming on and that was a big drop every day for us. There were small mailers that like manufacturers in Saskatchewan that needed to get their product out. And that was a big thing as well. There was, I remember there was like a... website that sold wedding stuff. And there was another guy who invented a machine where you'd flick a switch and a little finger would come out and flick the switch off. was a machine that did nothing. Yeah, there was a there was a guy who like invented that or whatever. And in I think it was in Regina and it's got Southern Saskatchewan anyway. Yeah. So we'd get a drop from him once a week. And so he see all this interesting mail going by, of course, you'd mail live bees in the in the in the springtime, the little baby chickens, the chicks. you'd mail the chicks and they'd all be squawking down there, chirping away. So it was, you know, it was just fascinating. You had to know a lot about geography, you know, all where all the roads went and the mail had to follow the roads. But the real key thing was not because you don't make a lot per letter, you've got to make sure that you don't touch each piece very often. You want to touch it as few times as possible. And so would come in a big container and inside that big shipping container, you'd have a smaller container and inside that smaller container, you'd have all these little pieces of mail and you'd want to like touch it once and it'd be destined for the end destination. uh Another interesting thing about that is because of that containerization, you ended up having to like, it was almost manufacturing where you disassembled the machine and then reassembled a different machine all of the time, which made it different. And you had to manage those, the containers as much as the mail. Really? Speaker 4 (11:03) I didn't know that. Speaker 1 (11:04) Yeah. Yeah. to go, it was easy to forget about the containers, but it was half of the work. because you had to get empty containers to a spot where you could fill them up and you had to get full containers uh empty so that you could fill those ones up and you had to get full containers out and you had to get full containers in. And so the container movement was actually some of the biggest stuff that you did. Speaker 3 (11:28) There's a lot of logistics happening. get, and also you have like a different movement. get like central places where the mail comes in to be sorted, to be routed to different places. So it comes in a place and then it's fenced out back to different places for distribution afterwards. ah And there you want things to go fast. You have stuff like, how much work in progress do I have? Do I have some letters waiting behind? Are machines being used properly? Speaker 1 (12:00) Yeah, so that's actually, that is very interesting um because of the volume of mail not being really big in Regina and some of the management of kind of like how that spoken hub kind of system would work was centrally managed. I didn't do a lot of that aspect. So I mostly did work within my own province. At the time though, we were working on a project where we were modernizing the mail delivery and kind of like changing the mail delivery model and um working to get away from door-to-door delivery. And so that's something there's currently a labor dispute going on at Canada Post actually, and it's still about that issue. And uh it looks like part of it will be uh reducing the amount of door-to-door delivery that happens and kind of mixing the parcel delivery and the letter mail delivery uh together. And so we replaced all of this mail sorting machines. And so these are machines that sort 40, 50,000 pieces an hour. of letter mail and you know going prrrr the mail is just flying through there and automatically sorting that being fed by a person being swept by a person but not you know the person's not doing any sorting and we replaced all of the machines in scotch and all the mechanized sorting machines um you know and really uh one of the things is is also that we had a legislated delivery standard um So it wasn't so much the kind of the business side of like next door in the morning or something like that, which also happened with parcels, but with letter mail was legislated uh mail standard. And so it was really carefully managing like this is all a Monday's mail and we need to deliver it by Monday, but not earlier than Monday because then you're over-processing. And so there was a really interesting system of like managing the inventory by day. uh You know, a lot of visual management to write. like making sure. that the work made sense. So it would be things like, you you'd paint travel pathways on the floor or tape travel pathways on the floor. And you'd have workers that would tell you like, I've worked here a long time. I don't need I don't follow that stuff anyways. Right. And then you talk to someone who would say that and you'd say, well, you know, like, if you ever parked in a gravel parking lot. Yeah. And how was that experience? Like, what was it like? Well, cars are parked everywhere. And then you'd say, well, have you ever parked in a paved one, you know, with the lines on it? Well, yeah, I'm what's that like? Well, I people like you know, generally park in the lines and every once in a while somebody parks between the lines and people get mad at them. Right. And, um, people naturally follow those paths once they're given to people, even if they think they don't, even if they don't think they don't want to, they will. Um, and so that actually guided a lot of my work around things like change management or, um, you know, so sometimes you want to customer to want things. Other times you just build a road that they're going to follow. Speaker 4 (14:47) Now we are already stepping into Lean Six Sigma. Was that, from your personal experience, did you have a background in Six Sigma before you started at Canada Post? Or was it like, learn on the job or... Speaker 1 (15:09) It's a good question. I'd been trained a little bit in it in university. So I'd taken some classes on it. And when I was working um at that job, installing the PI servers and stuff, I think that data management and figuring out how to minimize the amount, you know how, if you've got too many steps with the data, sometimes you can, you make it too complicated, it'll break that kind of thing. There's probably a technical word for it, which I don't know. But if you do that, Speaker 4 (15:39) And now with AI, all these AI tools, we're like repeating the wrong stuff from the past again. We again come in this very complex uh change with a lot of interdependencies where lot of links can fail. Speaker 1 (16:00) Yeah, towers of cards are, what do they call them? Those machines that, the overly complicated machines that do very simple things. Speaker 3 (16:07) Goldberg machines? Speaker 1 (16:10) Yeah. I was thinking about the Goldberg variations, but that's something else. Yeah. The Goldberg machines. Yeah. So, you know, you really have to avoid that. And I think that that's true. You know, that was true in those kind of like ITOT related uh things. And then from that, I kind of like, you know, like, recognize that that was an issue. And so when I started really delving deeply into Lean primarily, and a little bit of Six Sigma, which kind of came on a bit more later, I recognized where I could apply it later. uh I actually, so, you know, the Postal Service being involved in Lean, we were actually a member of the South Saskatchewan Manufacturing Consortium. And so there was a consortium of manufacturers that were Lean people. And one of the people that I worked with at Canada Post, he was kind of a co-worker of mine, he was kind of uh He was, had the former president, he had started up this Lean Consortium. And so we met with manufacturers every, you know, few months, we'd go to a different facility. We'd talk about Lean generally, we'd go into their facility, they'd show us a problem they had or a solution they made. And we'd learn from each other. And that was a really, really great experience and a good way to learn. And these manufacturers 100 % knew that the mail processing was very similar. And some of the changes that were made We made some really good changes in publications and ad mail, which is a very heavy, dense type of mail that then ends up having to be single flyers in somebody's mailbox kind of thing. That was, we made some really good changes there to avoid the double handling situation. For sure, you know, one of the interesting, maybe an interesting story about Canada Post, there was a facility that received mail from far out, it came in on a truck, like it's a small amount of mail, maybe like four little tubs of mail every day. And for that mail to make the next truck out to another place, they only had like an hour or two. So what those people would do is they would take those four tubs of mail and then make sure to sort them into a case so that they could pull like five letters out of one slot in that case and make sure that it went to the other town the next day. And that was were way far advanced from what the required mail delivery timelines were, but they really felt strongly about good customer service. So what they were doing is they were making sure those four letters got great customer service and maybe 2,000 other letters didn't. Or you over-processed everything to make sure you got those four letters out and that was a really key learning for me. Speaker 4 (18:50) um The link between Lean Six Sigma and data, you already mentioned it a couple of times. You can't unsee data from uh Six Sigma and vice versa. I think, especially on our blog, uh we often talk about or we often write about how do you build a data platform. m Let's also discuss a bit of data management later on. um But what we don't really talk about too much is like, Why would you? What is the value of becoming data driven? And I think when you link that to this type of optimization problems, there might be, or there hopefully is a clear link. Speaker 1 (19:49) Yeah, actually, it is is it is so essential. And like the why for me, and this is only in my mind, is that it's actually about people. Like, when you are trying to motivate people to do the things that need to be done to make an organization successful. They you need to find a way to motivate motivate them. because people only do what they want to do. That's it. Right? Like in like motivational theory or whatever, like they only do what you, what they want to do. And so you have to figure out a way for them to want to do it. And so one of the ways is, um, you know, encouraging, encouraging them, you know, maybe with like money or just kind words or, obvious signs of success. Or another way would be like discouraging them from doing bad things, like punishing them by taking away money if they don't do well, or, um, you know, like, uh, saying being mean to them in front of other people or something like that. Right. And so I think one of the, one of the reasons why it's so important to do good data work is that people are really naturally. People naturally want to be successful. And so one of the ways that you can help them. want to do what you want them to do is by giving them a scoreboard, just like in sports or whatever, I've played sports my whole life, by giving them a scoreboard that allows them to measure themselves and see whether they've been successful really quickly and really easily. But you have to make sure that those numbers are things that they can control that are also important to the business and show success. um That like targets. are achievable that systems can't be gamed, right? Because people will, like there's always perverse consequences or at least unintended consequences. And sometimes they can be counterproductive. And so I think the real reason why data is so important is because in the end, you need to get people to do what you want them to do and you need them to want to do it too. Speaker 4 (21:59) I really like that insight. It's another approach than what we typically or other people typically talk about. I wanna do a little bit of a fast forward to your more recent roles um because you um recently did a... Speaker 1 (22:15) been talking about them and you didn't even know it. Speaker 4 (22:19) But you recently did a talk also more on treating data or data systems as products. that's maybe a topic I'd like to do a bit of a deep dive in. You know what, why don't we start with defining what is a product? No. Speaker 1 (22:46) I would love it if you guys started with that. That sounds good if you could define what a product is. ah What is a product? Well, I think that a product is anything built for a customer they're willing to pay for. really. And so when you know, like linking in the lean stuff, like a product would be, uh you know, you have to be customer focused. And that's, that was one of the, the basis of success was kind of like that business need and collaboration, like you really have to understand what people want. And then you have to be able to deliver it with good value, right? So it either has to be really, if it's expensive to make, it's got to be high value that people are willing to pay for. And, you know, the, paying for a thing, I'm not just talking about money. And I know like as a Canadian, I might get associated with, with, you know, North American capitalism, that sort of thing. like, honestly, when I say pay for, I don't just mean money, like, people pay with their effort, people pay with their time. So if you're collaborating with people, and you're, you know, you're working with them doing business analysis, work with them, trying to understand their business, and you're asking them to share, they need to see value out of that. So that is a really important thing. And one of the things I talked about at that presentation, did at the start, I did a safety moment, right? I did a process safety moment. And one of the things about the process safety moment, it was an industry standard process or a well-known process safety event. They're in the States, they have the chemical safety board and they do really, really great documents and presentation. They're excellent. We don't have, yeah. Speaker 4 (24:29) a link in the article. uh Sorry to interrupt here, but when I was studying, so that's 17, 18 or so years ago, I remember that I was already watching the videos created by the Chemical Safety Board. For me, that was my personal first um experience. with chemical safety before I ever stepped foot in a chemical plant. Speaker 3 (24:59) But the content is brilliant. You did mathematical engineering David, in what context did you get that? I mean... Speaker 4 (25:06) I did mathematical engineering, but I started specializing in process uh optimization. So that's the link with chemical processes and you know. Speaker 3 (25:16) Because if you have like chemical safety courses, yes, of course, but... m Speaker 1 (25:22) you mustn't separate things though, right? Like, I mean, it really is important to have a broad background. uh You know, it allows you, you know, like if you're studying and then you're entering the workforce, you know, no matter what you, at least in my experience has been like, no matter what you specialize in, you end up getting a job that you kind of at the start you need, right? And no matter what it is, you've got to be successful at it, you got to be okay at it. And so you have to learn and it might not be exactly in the field that you selected. of your major or whatever. I think ITOT integration was a field in our... Speaker 3 (25:54) No? Speaker 1 (26:00) In any case... Speaker 4 (26:02) Yeah, not at all. Speaker 1 (26:05) Oh yeah, process safety moment. Yeah, that's right. Yeah, and the CSB is great. And they, you know, they've got a ton of good resources on YouTube and on their website. And so what I did is I talked about the process safety moment and I said kind of some things that, some recommendations that it made and that, you know, we could consider at our facility and. Then I said some things about those solutions that could be provided by the data analytics, what we call the data analytics solution that we are providing. And so in that way, what I was doing was I was giving a process safety moment, which was an expectation of meetings. Most of the time you should do a process safety moment at the start of a meeting in that context. so what I did is not only did I do a safety moment where people learned, but also I showed them that there was a product that we were delivering. that would help them with that if they came along with us, right? And I wasn't doing that sort of thing in meetings, kicking off data analytics meetings. I was doing that in meetings with leadership about performance. And so it was a completely different thing. Like the topic of the meeting was completely different, but I was taking every opportunity to just give people little tastes of what... could be achieved if we did the right thing and if we committed together to doing that work. Speaker 3 (27:28) I really like that focus now a bit more on safety because I think usually, again, David, when we're talking about data, it's like process optimization and how can we spend less? How can we produce more? Rarely, though, do we have people who have some experiences in how do we actually use data in health and safety environmental topics. So... yeah, yeah. interesting topic. Where does data fit in there? Because I'm sure there's like matter of change and data sheets and stuff like that. what's more? Speaker 1 (28:03) What's there? For sure, it is very like there's a lot of opportunities to do data work in especially process safety, also personal safety. I would say that generally my experience has been that that's personal safety. People don't come from as much of an engineering and math type background. And so they're not, uh it's generally not as sophisticated uh or kind of like not as data mature uh in those parts of organizations or even in those professions. uh In process safety, it's generally a bit more, uh more mature. uh What you'll see is, uh for example, the American Petroleum Institute API has a recommended practice called 754. I think it's uh process safety uh metrics and indicators or something like that is the recommended practice title. And it has an it has like an appendix and annex in it that basically goes through from start to finish exactly how you should structure your data management system. Like it literally just lays it right out there. um yeah, yeah. And so I would carry that around. I still have a copy and I would carry that around and show people like anytime that people would ask uh a question like this, like, how does this fit in? I would say, well, like there's actually a recommendation of how that should fit in. That's one of the recommend metrics. This is how the systems, the information systems should be structured. This is how the reporting should be structured. This is how we should deal with. leadership, this is how middle management should deal with it, this is how the frontline should be treated about it. So there's like, there's textbooks, there's a really great document too, from the British Health and Safety Executive, it's called HSG 254. And I can't think the name of it. But it's something about process safety metrics as well. And it lays out a step by step method of selecting metrics and the entire metrics hierarchy for setting up a process safety system. And it works uh a full example of one of the dimensions process safety. It's a tremendous document, highly recommended, available free download on the internet. I'll get you the link, David, and you can put in the links too. Oh, it's excellent. So there's tons of really good documentation on how to use data. There are some areas that really lend themselves to data. The fact that Hasop and Lopa, I don't know if you're maybe the Yeah. are hazard and operability studies. like doing a study, understanding using guiding questions, uh what bad uh situations could happen? Where would you have a high pressure that would cause a problem, a low pressure, high temperature, low flows, misdirected flows, all of these sorts of um kind of like situations that could happen and what would be the consequences? What would be the risk of that? What, how many um barriers do we need in place? So that kind of like that barrier theory that started coming up a lot in the public and during the COVID times, that barrier management thing and having many layers of protection, right? And LOPA is kind of like a deeper study similar to House Up, where it's literally layers of protection analysis, right? And so you're using like numeric analysis to determine how many layers you need and how much risk reduction you're going to get from certain barriers, right? And so all of that is very, very data heavy and some of the best data workers that I personally know, not me, work in that space for sure. Like people that I am very impressed by and who I call to ask questions from time to time, because I know that they're the people who think about data in the best ways some of the time. Another area would be incident management. You know, there's lots of statistics there. Uh, and then like how em all of the processes is back to lean all of those step-by-step processes, like MOC, like, um, it would be, it would be another one or like projects and making sure that projects have like safety considerations in them. You can measure aspects of certain steps to make sure. Right. And then if you have that data captured in systems, and if you're able to represent it in valuable ways that are meaningful to people that help them get what they want, like people hate MOC because they feel like it's time consuming. Right. The thing is, it's just documenting your due diligence anyway. And so if you can do a metric on reducing the time it takes to do an MOC, say, and you do that by increasing the efficiency of it, not by making people work harder, Speaker 2 (32:37) then it's a Speaker 1 (32:38) win-win, right? And so there are ways. One last thing is audit. Audit is just a really excellent. I was actually on, I was like the element lead for that element at the refinery. And we were really getting some good things set up with audit and audit obviously lends itself very much to measurement. Speaker 3 (32:58) How manual was that work though? um my experience, there's like, I just mean the data gathering and analysis. em There's always this view of everything is automated in systems and AI is gonna spit out all the answers for you out of data in the clouds. And then you set foot in a shop floor and you see it like there's paper forms, there's Excel sheets everywhere. Yeah. Speaker 1 (33:27) What did you see? Um, you know, so we were on our second generation of health and safety software platform. And, um, because I was involved in the implementation of it when we were doing the, the data warehousing and business intelligence stuff. Um, I found it pretty easy cause I was pretty familiar with the data structure and it had been intentionally set up. Like the incident module had been intentionally set up to align with that API seven 54, the process safety metrics standard. And so any information that it said you must gather on any sort of incident was gathered as part of that. And so right from the start, instead of the field entering it on paper and there being having to be transcription and stuff, the supervisors of the workers who in the area that experienced the event, they would enter that information directly. Yeah. And so then from there, it pretty much was automated. And the cloud and AI and on-prem and all of that stuff. is another conversation. Speaker 4 (34:30) say, given your background with all the different systems, the data management question or I would say, let's make it more concrete for the ones who don't have any formal data management yet. It's often really hard to start. Like if there would be an advice you can give people ah on how and where. To start with data management, what would it be? Speaker 3 (35:00) Or even what does it solve? mean, I mean, is the data gonna unmanage itself? Is it gonna ask for a raise or is it go to competition? Speaker 1 (35:12) I think maybe data management is about it. Data not unmanaging itself, isn't it? Yeah. These are excellent questions. So good that I actually have to think about them for a moment here. Speaker 4 (35:23) That's a nice thing of hosting a podcast Kris. So the fact is, we don't have the answer either, but you know, we can. uh Speaker 1 (35:34) Yeah, and you know, I really appreciate good questions for sure. And it's good to it's good to flex the thinking muscles. Where to start? You know, back to paper and Excel, I do think that doing the work manually first really helps. Like it. So way back at my first job, I ended up going uh It's kind of a long story, but I ended up going with the consultancy to a job in Aberdeen in Scotland. I worked on, this would have been in 2005, 2006. And there was a team of, I don't know, 30 or so developers and that sort of thing working on this project. we were kind of like business analysts and we did training and we did customer information gathering, that kind of thing. And we did pie work there as well, kind of like technical business analysis around that. And what, one of the things that I learned there was that we were trying to get the developers to do certain things. And they would be asking us kind of like around about ways about the algorithm, how would we do that? And we'd explain it to them kind of like in pretty fluffy terms and they would say, well, like, can you build it for us? Like in Excel? Because if you can't build it for us in Excel, like we can't do anything that Excel can't do really. So if you can't show us how the algorithm is going to calculate from the inputs, to the outputs. If you can't show that using like the formulas in Excel, then we can't do it either. And that was a really key learning because it's like, it's really useful to do uh prototyping using very simple tools. uh At Canada Post, one of the, this guy was really great at Lean. One of the best things he did was he would do presentations with like hundreds and hundreds of slides on them. And he would move little... like we were doing a parcel conveyor project and you would move little parcels and show people the parcels would move here and then they'd wait for this person to make a decision and that could go here, it could go here. And you just move these little parcels and little simple animations in PowerPoint and people loved it because it was so understandable. And so you do things like that, or you would use, instead of doing CAD, you'd have like pieces of paper with magnets that were the size of all the different containers, because container management was so important. And you would have like, people from the floor showing you how they thought things should be laid out doing like CAD, like computer assisted design with little magnets on pieces of paper. Speaker 4 (38:03) think it shows, what's a very interesting learning or takeaway from this ah is that it shows that data management is something which is hard to push down from top to bottom. Because we often get that question like, yeah, but management wants to see this and this, so we're gonna push down some certain initiatives. And what you're saying is you need to find some common ground between the practitioners, the people who actually understand what is going on. Mm-hmm. and that's of course the challenge, also somehow aligning that uh with company standards, especially if you are uh operating on multi-site with multi-site customers, that somehow those two uh need to align. And that's not too easy, but it's certainly possible if you have both dimensions. So if you have the practitioners and if you have um a set of company guidelines. Speaker 1 (39:01) Yeah, like the well-defined guidelines would really help. if you had, in a way, like it kind of sounds like the company or kind of the centralized site would have some sort of like, like a rule set for a result that they expect. And so you know what the result is, right? Like you know what the product needs to look like and you know what you have. or you could maybe consider what you might be able to make, right? And from that, then what you need to do is you've got two sets of constraints and you can use the inputs and the outputs to build the process that will get you the result that you need. I think that maybe... people need to work on the flexibility of the rules a little bit too. And I know that in the IT space, that's in some ways maybe harder, but sometimes when people say that they need something very specific, um what they mean is they need something like that. Like they're looking for a result, but they might say how to get the result as well as the result that they need. And my experience has been... um Like because I'm not an IT person and I'm not a super, super technical engineer. haven't done a lot of design work for example. Right. And so, um, for that reason, I ended up doing a lot of translation between groups of people that I'm not, I'm neither of them, but it kind of translate in between. Right. And so when somebody asks for something like a, you know, like head office, I'll ask for something. I'll hear it and an IT personal here at the same meeting, maybe an IT's personal say, well, I can't do that because these technical reasons. And after the meeting, I might go to that IT person and say, like, I heard what they're asking for and I heard what you answered. Is there a way of getting this result? Not fall in what they said in the middle. Um, do you have a way of doing that though? And they said, oh yeah, yeah, we could do it this way. And then I'd say, well, what if we did that? Like, what if, or what if we propose that we do that instead of what they said? And you, you could go to that management person and you could tell them what, you know, the suggestion they say, yeah, that's I was asking for. Cause they don't understand, like they're using, um, Yeah, yeah of course. like placeholders, they're like, you know, Xs and Ys for them, they're variables, they don't really know what they mean. They just really want the result, don't care about how. Speaker 3 (41:27) That's usually also best if the how is left to the people who actually need to implement it. uh Speaker 1 (41:36) the situation that they don't understand it completely, right? Like, mean, yeah. Speaker 3 (41:42) Yeah. um Now, Kris, one final question because we do need to uh start closing here. um You started saying like that you did a lot of different things in different fields and how that was enriching. You just started now in a new job. ah What will you do different in this job compared to what you learned in your previous one? What are you bringing to this job? Speaker 2 (42:10) Okay, well, those are two different things maybe. Speaker 1 (42:13) Yeah, no, no, it's okay. I think the thing is, is that like I have demonstrated experience and practice doing a really wide variety of things. So what I bring is like the ability to come on board quickly, uh the ability to work uh with kind of like data management, doing simulation and modeling with customer focus with lean with Six Sigma, which we didn't end up talking a lot about uh with we didn't really I kind of mentioned it as an aside but like performance based leadership, uh you kind of that kind of uh applied behavior and behavioral analysis kind of that psychological approach of like how to motivate people. Yeah, that's a whole nother podcast. uh But you know, like, so I bring all of these different practices and you know, not all of them have to do with engineering and there are things that I picked up through like leadership or reading, even things like philosophy, right? Speaker 4 (43:12) And applying them at different situations. Speaker 3 (43:17) Yeah. back like a discussion we had slightly before the podcast about the difference between complicated and complex work, which is, I don't know if all the listeners are familiar with it, but it's definitely worth looking it up different times for it. You can be very specialized in something, it can be very complicated to build. I mean, transportation, mechanism, separation, I mean, it's all lots of... very specialized work, very often very complicated. The work that you're working in, I think also a lot of our listeners is usually a bit more in that complex domain where the problems are not always well-defined. It's like that manager coming in, saying something. He didn't come with the spec sheet and saying, I want these different processes installed that are already defined and it's going to be hard to install them, but they're already known. It's rather, we need to figure out how we're going to do this. And that's maybe where that wider experience comes in handy, where maybe something you did in a postal office many years ago suddenly becomes uh relevant. Speaker 1 (44:26) And working with people, That is like, you know, it's so essential. I think the thing is, is that it's so important not to complexify things, right? Like it's so important not to build that house of cards kind of situation, right? You must come to the simplest solution. And as you gain, uh you know, more knowledge, more skill, more experience, what ends up happening is you recognize how to make things simple and break things down. So like we have infinite number of inputs nearly. we don't really know exactly what, but we don't know what the results should look like other than that. need a result and we have many tools that we can apply and we've to pick which ones. And so how, you know, how can we break that down? Um, you know, and there's a, there's a number of experts on, the team that are, um, you know, that know how to do a lot of technical things. and they all bring, bring their parts, but kind of like organizing that and getting them into a place where things are simple and they feel comfortable. because one of the things that I'm bringing to this role is a desire to not choose to take on too much for myself. Speaker 4 (45:31) So important as well, absolutely. em And by the way, because Willem mentioned complex versus complicated, for those who want to know a bit more about the differences, I highly advise you to read the book sooner, safer, happier. There is a brilliant explanation em of the... Speaker 3 (45:53) Yeah, I'll put the link in the show notes, but... the writers are great. mean... Speaker 4 (45:59) there is a brilliant, brilliant explanation on the complex versus complicated work with that. So for the ones who are watching this episode, it almost feels a little bit like a travel documentary because when we started, like your back drop, was still black and now... Speaker 3 (46:22) into i don't know some some office in the background and now Speaker 4 (46:26) a reflection. so now we see the beautiful snowy, if I can see it right, the beautiful snowy landscape behind you. Speaker 1 (46:35) yeah, yeah, it's not it's not too cold. We're in South-Seas in Canada. It was I think it started out minus 15 or so. So not not too cold. This weekend, it's going above zero. But normally this time of year, it's usually down minus 20 as a high usually. Yeah. Yeah. Speaker 4 (46:51) Anyways, that, or on that note, that's another wrap for another super insightful episode of the IT/OT, insider podcast. uh Thank you very much, Kris. Yeah, thanks David. Thanks Willem. donating your time to us and our listeners. um And of course to our listeners, if you enjoyed our conversation, don't forget to subscribe at itotinsider.com or if you want to learn more, you can go to itot.academy. um with that, Willem, the only thing we can say until the next time, take care, bye bye. Bye everybody. See ya.