Latest / You've Been Heard / 451 -Your Value Is Bigger Than Your Code w/Peter Vardaro

Transcript

451 -Your Value Is Bigger Than Your Code w/Peter Vardaro · You've Been Heard

• 0:00
  Speaker A: I try to tell every member of my team their value is not what they think it is. Every single time my developer thinks that their value is in the line of code that they wrote, my business analyst thinks that it's in the process they develop. Like it's never that. The brain that you have in your head can do better. You can come up with complex ideas that solve problems that make the world better for somebody else. That's your value, is making things better the same way we're trying to. However you do that, those are tools you're using. That's not what gives you value. So detach yourself from the thing that you think gives you value and change yourself. Rewrite what you think is true.
• 0:47
  Speaker B: After talking with IT leaders, I've come to discover one thing. And it's the same thing you know, it's the same thing everyone else knows, whether they want to admit it out loud or not. Nothing gets done in any company without it touching it. Nothing. But here's the thing. When everything's on fire, when nothing's working, when the ransomware hits, when the whole business grinds to a halt, it is completely indispensable. You're the most valuable asset in the company. But when everything's running like a well oiled Tesla, you're a line item, a cost center on a spreadsheet. You've done the work, you've built the career. You've earned your seat at the executive roundtable. But having a seat at the table is one thing. How much nicer would it be to actually be heard? This is. You've been heard.
• 1:40
  Speaker C: All right. Welcome back to you've Been heard, the show where we pull back the curtain for the IT leaders steering the ship today and the rising stars hungry for their own seat at the table. We've officially banned boardroom buzzwords and rehearsed corporate scripts in favor of genuine, unvarnished talk about what it really takes to lead. Peter, Huge, welcome to the show. We're thrilled you decided to join us today and trade stories with us over at you've been heard.com city. In the guest chair is Peter Bardaro, a tech executive who knows what it feels like to have grease on his hands from the IT engine room before stepping into the driver's seat. What makes Peter's playbook so compelling isn't just his track record with enterprise scale. It's his knack for cutting through tech complexity like a hot knife through butter. Proving you don't need an empire of jargon to build agile, resilient teams that actually love what they do. So, Peter, would you mind introducing yourself and sharing a little on the ride that you've gone through to get to where you're at today?
• 2:50
  Speaker A: Absolutely. My pleasure. And thank you so much for your warm welcome and thank you so much for having me on here. I've heard so much about your show and really, it seems like a cherished nugget in the community of just truth and unfiltered jokes, just rawness that I'm so happy to be a part of. Right.
• 3:09
  Speaker C: Appreciate that. Thank you.
• 3:11
  Speaker A: So thank you again. My name is Peter. I did start my career actually in business operations. So in the healthcare industry, I actually started as what's called a BMET biomedical Engineering technician. So I used to work on equipment and out of the pure hatred for the software I used, I started to like, say I need to come up with something better. And that led me down a path of it that led me into enterprise applications, where I've been very happily sitting and working with teams to make things better.
• 3:41
  Speaker C: So tell me a little bit more about that journey into the enterprise stuff, because we've talked a little before the show and we're talking about the differences between stuff for an individual and stuff for enterprise. And it amazes me how often people don't recognize the difference of trying to do like navigation for an enterprise compared to navigation for you or I on our phone to get to the store.
• 4:08
  Speaker A: Yeah, absolutely. It has to work at enterprise scale because there's going to be a lot of times where you're not going to hear about the small things that don't work because your soldiers and foot soldiers on the ground, they're going to keep trying to trudge ahead. And a process that takes five minutes and really should only take a minute and a half is costing your business money. And if you don't recognize that with a business process analysis, looking at it and just seeing why that's, oh, you can't scale your business. You have a thousand employees using this application at once. Your APIs have to be scalable. Right. They have to be able to accept that data. They have to be able to hit the database correctly. It's not like it's one time. And if you lose something, it's not too big of a deal. You're losing revenue, you're losing customers potentially, if it's not properly done.
• 4:53
  Speaker C: Yeah. So you started to recognize that, but I'm sure you didn't. Well, you already actually said that you came in with a little bit of that innate knowledge because you were One of those foot soldiers. And you were the guy that was suffering through that push the button five minutes. And so then you started wanting to. Well, I'm sure you probably started figuring out, hey, there's a button here, what's this one do? What's that one do? What's this one do?
• 5:19
  Speaker A: Yeah. And you go down.
• 5:20
  Speaker C: So you got to know the software.
• 5:22
  Speaker A: Yeah. You go down this dangerous path because then you come up with a proof of concept that's not scalable by any means too. Right. You come up with your own like proof of concept that just kind of gets you by and just shows you what it can do. And then you get a taste for what it can be, what it can do for the business overall. And then eventually you start digging into and you're like, oh, I need to do something different because this can't scale the way it is. So then you start kind of looking at, you know, your enterprise level softwares and getting involved in that stuff and you start finding that you can still do some of that really great tooling with something that's much more scalable.
• 5:57
  Speaker C: Stu, as you talk about scaling, help simplify that. Because you know what, it's almost one of those buzzwords that I said we weren't going to talk about. But it, it's a normal one and it's one that we just. In all honesty, in a majority of the conversations I've had with our fellows, we haven't really dove into scaling and what scaling means and what's it take. And back to your example, a five minute thing. It should take one minute. So there's four wasted minutes. And if you got a thousand people doing it, there's 4,000 wasted minutes per each of these transactions. That's when scaling absolutely kind of comes into play. But how does it come into play in the way that you're talking about setting the foundation?
• 6:49
  Speaker B: Most IT leaders don't have an Internet problem. They have a management problem. Multiple locations, multiple providers, multiple bills, different contracts. We help IT leaders make Internet boring again by consolidating visibility, billing support and monitoring without changing providers or forcing upgrades. If nothing needs fixing, we'll tell you that's vendor neutral advisory. Just go to you've been heard.com and answer the seven questions to simplify, streamline and save.
• 7:17
  Speaker C: Yeah.
• 7:17
  Speaker A: So the number of times you start and a big problem also that challenge that's presented by the business is sometimes if they have trouble foreseeing their own success, they tell you plan for X and then they're hitting Y which is Much further ahead. Right. One of the applications that we had built was planning for one service center. So all the application was planned to do is it's always going to have these certain types of transaction with one location. Well then by the time we released the demo, they had three support centers that were going to have to do this and it creates a whole new pathway that was completely missed during requirements gathering. So now, because that almost like planned obsolescence into let's just build it one way without thinking about how the business could grow without planning on what would 10 years in the future look like, five years in the future look like something that you're. What does success look like in your wildest dreams? Plan for it at the foundation.
• 8:14
  Speaker C: Now, here's an aspect of this that I've found that I need to be careful of because I have this tendency to gold plate things from the beginning. So when we're trying to do a minimally viable product, well, today's methodology is get out the bare bones and then
• 8:32
  Speaker A: there's nothing so permanent as a temporary solution.
• 8:34
  Speaker C: I remember hearing that. Or a different version of that. There's nothing as expensive as the cheapest solution. It was in Spanish, but they translated it for me. And there's nothing so permanent as the working on temporarily designing something in production. Yes.
• 8:52
  Speaker A: As soon as the business can see something works, they just want to roll with it. Right. Because then scaling is not necessarily understood until unfortunately you're in possibly a bind. Right. Something that you design, that you really only tested with a half dozen users just to see if you can get through a workflow doesn't mean it's going to behave the same way at a thousand users. Right. Especially when you're talking about records that are supposed to maybe stack on top of each other. Start exhibiting different behaviors. Once you're really starting to fire rapidly with a lot more traffic, that's when things start to get a little bit complicated.
• 9:29
  Speaker C: So for our fellows who find themselves in this situation, they started to build some kind of an application. They started to put something together and they did their job and they got their requirements and did the research, but didn't realize that the business was starting to look towards the future and what they could do tomorrow. What suggestions do you have for helping build that foundation in a way that will allow for the scaling generally always
• 10:03
  Speaker A: under promise over deliver. So keep a little bit in your back pocket from what your estimates are on what the thing can do and then put your project management hat on too and make sure that as long as everyone understands with what they're working with, what the scale is, that everybody understands that this will have this expected lifespan. Right. And if you are also very honest, that may help you get the seat at the table that you're looking for. Right. Because if you can be very raw and honest with the business as well and say this can has a viable life of this point, if we go this route or if we go this route, we can do this. Can you tell me a little bit about what our future plans look like? You can possibly be there for the business decision as well?
• 10:46
  Speaker C: Yeah. And. And that one's critical. I mean, it. It's part of understanding the business and having that business acumen. But being able to be with them while they're making those decisions helps you understand or better how to direct each of the individual projects that you're dealing with.
• 11:05
  Speaker A: Yeah. There's nothing hypically worse than when we're including in a reactive nature.
• 11:09
  Speaker C: Right.
• 11:10
  Speaker A: When we're included after a decision's been made, they, they've purchased the software, they've made decision to go this route, and maybe a quick conversation could have alleviated a lot of pain points or at least given us all the understanding. So that way we move forward together.
• 11:24
  Speaker C: Yeah. Sue, tell me a little bit more about this working with the medtech and some of your experiences there and the challenges of scaling up. What kinds of things have you seen or been involved in? I. I'm really interested in what were the constraints that got you to say, I'm tired of being a tech. I want to help the other guys like me who are suffering from this frustration.
• 11:51
  Speaker A: I found myself sitting in a hallway between like operating rooms working on a machine called the Cell Saver. It spins blood down from surgery, cleans it, and allows you to kind of reuse it for a patient during surgery. It's actually very good clinically to help with patients recovery. And I'm working on this machine and it's taking me so much longer to document my work than to actually work on the machine. The machine was actually a dream to work on. It used to be really fun. Machine had almost like a little bit of a flat surface, almost like you could put your laptop right on there. So it was perfect for the documentation portion of it, but I found like poor connectivity, having to rewrite things like 5 times. I always had the understanding you're going to do a lot of documentation when working on medical devices. It's critical part of it to understand what the thing is going through, but it just was exacerbated by the conditions of the software, my network connection, all of that. And I thought to myself, there's really got to be a better way. My guys are wasting a lot of time doing this too. A lot of times I'd have to send multiple guys out, one of them just to do documentation for the others, because the documentation just got that rigorous.
• 13:04
  Speaker C: And you're in between operating rooms and you think that you'd have all of the connectivity that you'd need. Hospitals are usually highly connected locations.
• 13:18
  Speaker A: There were definitely a lot of older hospitals, especially in the northeast here, where you've got a lot of masonry work that affects a lot of connections. And. And if you don't necessarily think that you're going to need an access point in an operating room, you may not have one very close.
• 13:34
  Speaker C: True. Because how many people are supposed to be on the computer while they're slicing somebody up?
• 13:39
  Speaker A: It starts to change over time. Right. Because they start using different technologies that then requires it. But at the time, you know, 15 years ago, that wasn't as much of a thought.
• 13:48
  Speaker C: Okay. And so you went from dealing with that, trying to figure out how to scale that. So what was some of the adventures that you undertook as you made that move? I mean, switching over to being a network admin and doing network scans and deploying connectivity throughout buildings like that. It sounds like you were dealing with multiple buildings and focus more on the equipment, not the facility.
• 14:15
  Speaker A: I was very focused on the machines. That was really everything that I did. So I almost had no thought on the network. And we tried to make it so I could always work offline if possible. So cellular connections, things like that, which were definitely difficult to work with, especially with the conditions of these northeast hospitals from time to time. Right. Essentially what I tried doing is I just tried building something like a little low code app builder just to get my hands dirty. I kind of showed it to team as like a proof of concept. And people like you got to show this to CEO, and CEO saw it and he's like, oh, you're going to do more of this. That's kind of moved me into that IT direction, because he recognized immediately that there was absolutely opportunity there.
• 14:57
  Speaker C: You bet. You didn't think to copyright it before you showed it to him.
• 15:01
  Speaker B: I was young.
• 15:02
  Speaker A: I had none of these ideas. Right. I was just looking to make things better.
• 15:06
  Speaker C: Right. And that seems to be a fundamental piece of many of us in these seats. And I want to solve the puzzle. Yes. I want to help and I want to make things better. I want to make in faster what other kinds of challenges do you run into with medical equipment and working with that in general?
• 15:25
  Speaker A: Well, eventually I got to work a little bit less with the medical equipment and started working more with the application, as one does. Right. And then I started to realize, okay, it wasn't even all of it just being the documentation, it was the whole logistics portion of it. So not working directly for hospitals, but actually being a service provider, we are providing medical devices to hospitals who need them just in time as their census spikes. They run out of these devices and need backups and need to fill things for patients that they are expecting coming in the door. And the whole logistics problem of it, that became much more interesting because you can start to plan a little bit based on a lot of different information. You start to look at things that are really cool, like the CDC's Flumat, and you look at your warehouse trends and you start looking at what your average inventory turn is. That's something. Now you can start using some of your regular data points to start solving those problems. And that became a really cool challenge.
• 16:30
  Speaker C: You've started to learn the data science or did you bring others in to help you through figure out those leading indicators and when they were telling you, okay, increase stock here, get move stock from there to there. Because assuming you were learning all of this prior to today's tool sets.
• 16:49
  Speaker A: Yeah, absolutely. So essentially, a lot of what our industry went through at the time was just understanding based on gut feel. So the only other thing that we have is we can compare to the Australian flu map, which is offset from the US flu map, to give us an indicator of how bad flu is going to be here. That gives us not really a very strong number, but almost like a coefficient to say, okay, this is what we can kind of expect. But really it's much more of a data science problem. And we're still working through that a bit more. You always kind of want to refine, just like with an AI model, just keep training it to see what you can. You want to reduce the number of wasted movements in your inventory transactions. So transfers cost money, getting equipment up and ready, preventive maintenance, all the cost money. You want to try to avoid having too much equipment and avoid moving stuff unnecessarily. So knowing where stuff should be at the right time is a really good thing to know.
• 17:44
  Speaker C: So the levels of inventory and the types of devices that you're talking about, are you talking about things that you can sling over your shoulder and move around the facility, or are you talking about like things that get deployed into a room and never move again until the lease is up.
• 18:02
  Speaker A: Majority of the stuff that we do is movable medical equipment, which is going to be like IV pumps that go on a pole, a lot of respiratory equipment like ventilators, high flow therapy devices. We also do a lot of beds and therapeutic surfaces. Those all have different inventory turns to them, which is really cool. And it's not something that necessarily all fits on the same schedule in the same way. Different types of illnesses also create spikes in the inventory differently.
• 18:32
  Speaker C: You were doing all of this back in 2020, weren't you?
• 18:35
  Speaker A: I was involved in 2020, actually. I even had to put my biomet hat back on for a little bit because there was nobody trained on some of the equipment that I was at the time. So we have a need for more and more technical people, and I really hope that more people get much more involved in the technology. But at time, there were certain devices that were hard to service that I still knew how to. So I put that hat back on and did a little bit of that with my sleeves rolled up too. But yeah, we were doing in 2020, but it got so bad. It was like you didn't have two ventilators to rub together if you needed to. Right, right.
• 19:10
  Speaker C: Yeah. And that's what made me think of that was because. Because you mentioned those.
• 19:14
  Speaker A: It completely destroys all your data sets too. You can't look back to 2020 or anytime around and like make sense of your data. It's completely disrupted. So now we're starting to get some good data again. But also, Postco, you had a lot of hospitals buy excess equipment. You had a lot of things that happen that disrupts the normal flow of inventory. So nothing's been the same. Nothing will probably be the same again. The only constants change, right?
• 19:41
  Speaker C: Yeah, unfortunately. Okay, so moved into the application. What kind of an application are we talking about then or at scale for your organization? Because it's not a warehouse management system, is it?
• 19:55
  Speaker A: It is a warehouse management system, and we're building off of standard platform tools like ServiceNow and Building with some plugins to that as well. So what's really cool is that something like that I can get developers who can turn things around very quickly. They have some baselines for the inventory management stuff. And then you can also build some of your data science. And then they've got great plugins that'll connect to Snowflake. So not to plug any vendors for anything, but, you know, that's just our tech stack.
• 20:25
  Speaker C: Yeah. And it's the norm of the day man. There's what, five different solutions out there that fit into that realm. So what are some of the other things that you found or challenges that you'd like to share with others whose eyes aren't going to glaze over and you understand what you're talking about?
• 20:46
  Speaker A: Yeah, I think a lot of the challenges is really the communication sometimes with the business and even coming from that business operation side when I start to talk to other units, there are things that even as things change and you step away from that, you're not involved in that day to day anymore. You have to spend a lot more time listening because their problems are changing day by day. You have to listen three times more than you think. You need to slow everything down, spend a lot more time listening and that trust will start to come your way that you're actually doing right by them too because they may not even tell you the entire truth until they believe that you're listening.
• 21:27
  Speaker C: Yeah. And I was wondering, so how do you train your people to listen? Because you can no longer be out there doing all of that. So now you've got to have your team going out and doing that. And so how are you tempering them or training them to think about or look or try a little harder?
• 21:47
  Speaker A: Well, a lot of times I'll try to make sure people shadow me a little bit and I'll get right in there and have that conversation especially on certain high value initiatives. And I'll let my team after we'll do like little sync up meeting. What did you think? What could, what could have done better? And then I'll let them run with it a couple times and I'll shadow and we'll just kind of give our each other like honest advice. What could we have done better each other. And I try to just be very honest and open my team at all times. If I've done something wrong, I always want them to tell me. If they do anything wrong, I'm going to tell them. And not in any type of way that's supposed to be backlash. It's just fake. You're going to get better results if you do it this way. And team's always kind of appreciated. You treat everybody well. They're happy to hear it.
• 22:32
  Speaker C: Yeah. I was listening to a book recently and some of that's like the difference between being nice and being kind. And sometimes being nice is when you're not telling everybody the whole truth because you're trying to be kind or nice to their feelings and being kind is sometimes that harsh truth. And Giving it, showing them that kindness and being honest with them. Yeah.
• 22:58
  Speaker A: Not telling them truth isn't going to help your team grow. And you can't grow if your team's not growing. So I need somebody who's going to be able to take my old position for me to make grow up that ladder. And if I don't have that, I'm not going to get there, or even I'm given the opportunity to get there. Everything is collapsing behind me and I'm not going to stay there very long anyway.
• 23:19
  Speaker C: Yeah, because you'll get pulled back in. Yeah. And it seems to be something that so many of us don't really understand too, is that build my replacement. A lot of us get afraid of doing that and not recognizing that by having somebody that can follow behind me, I can move to a different. I can grow. I can continue to do something new and different. And they're growing because they're learning all of the things that I've learned.
• 23:50
  Speaker A: I try to tell every member of my team their value is not what they think it is. Every single time my developer thinks that their value is in the line of code that they wrote, my business analyst thinks that it's in the process they develop. Like, it's never that the brain that you have in your head can do better. You can come up with complex ideas that solve problems that make the world better for somebody else. That's your values, making things better. The same way we're trying to. However you do that, those are tools you're using. That's not what gives you value. So detach yourself from the thing that you think gives you value and change yourself. Rewrite what you think is true.
• 24:29
  Speaker C: Interesting. I really like that thought and the way that you've articulated it, because it's true. It really is. So what was the experience that helped you? You understand your value? When did you understand that lesson? Or did you have somebody teaching you?
• 24:47
  Speaker A: I feel like, for me, it was something that I just kind of saw in the little mini successes I had in building the first applications and little widgets that were making my life better. Because it wasn't just making my life better. It made life better for a lot of people. So a lot of times we'll kind of like bring our business analysts through from the help desk and say, and I'll tell them there are features in this help desk, whether you realize it or not. If somebody has a repeat issue, it's probably something we can automate and fix. So I'll try to get them started there. And Then I'll tell them, when you fix a ticket that helps one person, when you write a feature that helps everybody, that possibly helps hundreds of people. And now I get to tell them, when I get to grow one of you into a director, I've helped possibly thousands of people. So the scale just grew.
• 25:38
  Speaker C: That's awesome, Peter. At this point, I don't know how many of these podcasts I've done. To me, you're articulating a unique thought and I see it and I understand it and I, I like to think that I've done it myself, but I've never seen it in that light. You got any more? You can expand on it?
• 25:58
  Speaker A: I, I think that's just the beauty of scale. When you start to see the winds happen, you get a little bit hungrier for them. So I like to make sure that the team members know what that win feels like. And one thing that we also really like to go back to is let's calculate this internal return on our investment. So there are a couple times where team members will write something up, write up features, developers, work on it, make sure that everyone gets their shout out and their day in the light and a little bit of shine that we can put on them. But then we'll try and come back at that point of that ROI took at least a year. We'll look back and we'll say, okay, this is how many hours we saved. And when it's something huge, like I think there is one logistics, one that saved like 400 hours a month. We were just like completely floored.
• 26:44
  Speaker C: That's 10 employees. That's 10 full time employees.
• 26:48
  Speaker A: Absolutely. Now of course it doesn't mean that you can like reduce 10 employees headcount. It just means that now you have that scalability in the business. I have capacity fill with more revenue generating activity actually. Instead there you can give people a little bit of room to breathe and do their job better. Instead, look at a feature like that. I'll highlight to the team members who worked on it. This is because of you. You guys put your hands on this and made the people who do this their day easier. They could now do their job better. And ultimately at the end of the day in our industry, it helped the patient,
• 27:23
  Speaker C: which is always a good thing to be able to bring about you as you're affecting lives and not just in the way that we're talking about of our co workers and making their days a little bit easier. It's also an interesting way to think of scale too, because when you started talking about scale, I'm thinking about, yeah, okay, build this widget for this office and it's going to help that group or that company. But, oh, now we need to get it to five distribution centers and scaling like that. Or you built it for 10 people and now you want it for a hundred people. Now you want it for a thousand people. But trying to teach the tech supporter, the help desk guys, hey, a ticket equals helping one person, a feature or, or that fix the stops. That recurring issue helps the organization.
• 28:20
  Speaker A: Yep, absolutely. And as they start, I can see the gears turning and then as those features get released, those bug fixes get released and they start to realize that their regular ticket count went down at post release. They're like, oh, I get it now. That's kind of the cool thing I love. Kind of teaching that to people and then seeing it actually happen. That's really great.
• 28:40
  Speaker C: Got any examples?
• 28:41
  Speaker A: Well, there was definitely that one with that large feature with the saving 400 hours. There was another one where we just automated a billing process that was just taking up a lot of time and we just put a bunch of hours back in everyone's plate and that was huge. I think one of the ones I'm probably a little bit more proud of, our customer experience team was really starting to run a bit ragged because they were just one of the hardest work working groups in our organization because they run a 24 hour business, because our customers are 24, 7, 365. So they have to staff overnight. They have to keep people running through holidays and everything. And we found that we could automate a couple of ordering processes that came through certain pathways and we were able to reduce something like 300 orders in a certain given time period, which just made everyone breathe easier. Now the rush to hire people because, okay, if we're not, we're going to burn more people out. That slowed and they got that breathing room. That is one that I thought was exceptional.
• 29:50
  Speaker C: That's awesome. So there was some hints to the vendor circus when I was doing my background research on it. What things have you learned from working with vendors and trying to manage the hype and the promises? And it almost sounds like part of your organization is dealing or being a vendor yourself too. Yes. So it's gotta be an interesting dichotomy there.
• 30:19
  Speaker A: Yeah. Providing the service from what we do for our customers. A lot of the service that we provide has to be ready well in advance. So there's not just a just in time delivery like when you're working with an IT vendor. So That's a little bit different because that, that battleground is actually every day way in advance. You usually keep like a queue of equipment in advance. So our battlegrounds are really more in supply chain, making sure parts are ready at the right time and all that. But when it comes to managing IT vendors, that does become a little bit tricky because especially, I mean, for a while it's interviewed many people who worked in different areas, work with different programming languages for a long time and it doesn't necessarily tell you what they're willing to understand about the business. And it's really that if they don't understand it themselves, then they're really just going to be able to write code off of what a story gives them and it will be absent of anything that's missing there. So that puts a lot more pressure on internally to make sure that that story is written perfectly. And so I really look for people who can think and preempt the problems the business isn't thinking about. And I try to also be very honest that I don't expect every relationship to be perfect. I expect us to be open and honest with each other and us just to work through things.
• 31:44
  Speaker C: Yeah, I'm that honesty again and just being able to talk it through and be able to tell people when it's not working, when it is working and look for the new solution and, and
• 31:55
  Speaker A: give them the opportunity to correct course if they're willing to course correct, then let's be teammates. Let's do this. If you're not willing to because you don't think that you should have to learn the business, I don't really have time for that.
• 32:07
  Speaker C: Yeah, it's kind of harsh, but if you're not learning the business anymore, then yeah, yeah.
• 32:13
  Speaker A: In the world of AI that is going to really dragically transform the way everyone does everything, I think it is more important than ever for us to understand the core reason why do we do anything. That should be your statement. Every meeting we start needs to be why are we here?
• 32:31
  Speaker B: Right.
• 32:31
  Speaker A: Stay focused. What is it that we're doing? What problem are we trying to solve today? And stay on that track. If you have people who are not understanding the depths of that, then they're not really fully engaged. They're just going to write code. And writing code is being simplified.
• 32:49
  Speaker C: Yeah, very simplified. And writing many things like that documentation. I wonder how radically different your life would be had you had the tools that are available today back then. So talk to me a little about AI and the influences into your world and are you seeing it on the front end? Are you dealing with it, trying to build it into the back end? How is AI affecting you and and what you do on a regular day?
• 33:16
  Speaker A: Yeah, absolutely. We've actually just started up with AI strategy and governance. And actually the director who oversees that was one of my BAs at one point. And honestly one of the proudest things was actually having him move into that role. We're starting to look at the new things that we can do with it. It's one of those things where we also have to be a bit cautious and really like hone in on the governance because there is protected health information involved in some of these orders. So there are certain types of orders that we can kind of already start implementing some AI around. So most movable medical equipment will not have an attachment to a patient, hardly ever. But a bed and therapeutic surface, the bed and mattress and frame and all that stuff that typically does get attached to a patient in a database standpoint. So it's one of those things that we've been a little bit cautious about making sure that all of the tools are compliant because you have to make sure the entire chain of command through that's holding that data has to be encrypted at rest in transit all the way through. So every tool that you use in between has to be okay. So we're getting to those initiatives. A lot of times AI is very beneficial for us on the problems that everybody has logistics problems. How many parts should I order? I have this many preventive maintenance things coming up. So we get to plug it in for things like that. That's very helpful. But we're looking to really try solve bigger and bigger problems with it.
• 34:46
  Speaker C: Yeah, like trying to have it or feeding it the flu data and let eat it help solve some of these things or just trying to train that model and working with that. But then again, DII and hipaa, you
• 35:02
  Speaker A: have to be careful. We can let it make recommendations. Right. But have to still have a human drive in it.
• 35:08
  Speaker C: Yeah, I keep seeing it now. H I T L Human in the loop. And then I started to see human on the loop where they're watching it versus it being in there and interacting with it. And so how many AIs are being forced upon you compared to AI that you're implementing? Because that's been kind of a discussion too third party.
• 35:33
  Speaker A: I don't think that anything is really forced on us. I think my organization's been really curious to see what we can do with it. So I have a lot of people excited and we're kind of trying a little bit with everything. Some of what we're doing, like I mentioned, some of the platform we'll work on is ServiceNow. So we're using some of their native AI tools as well to try it through that just because it kind of also simplifies things when you have less integrations to work with. That also is nice to not have to troubleshoot that. So we are definitely doing a big chunk with that and then building a few things on a Gemini chat.
• 36:08
  Speaker C: How are you guys trying to control that and keep people from just grabbing or using the public models?
• 36:16
  Speaker A: So what we started to do and this is really. I'll have to see if I can get John introduced to you guys because he's doing a phenomenal job with this. He has actually helped worked with infrastructure to see who's using it and then he just gave them licensing because you know they're going to use it. Give them the R licensing to make sure that they're using the right version.
• 36:35
  Speaker C: Right version. And then does that give you guys the administrative control to make sure. Yes. Training public models and all of those pieces.
• 36:42
  Speaker A: Okay.
• 36:42
  Speaker C: Yeah.
• 36:43
  Speaker A: So now it's not like shame on you for using AI, it's hey, saw you were going to use AI launch. Let's get you working collaboratively with us.
• 36:51
  Speaker C: Yeah, work with us and let us pay for it. Yeah, you just go do. All right. I so I had a conversation with somebody a little earlier today and we were talking about Vibe coding. What are you running into in that world? Because I keep hearing that one being double edged sword or dagger or there
• 37:11
  Speaker A: are some dangerous points with it because if someone doesn't understand what they're. Vibe coding is probably just going to be a proof of concept. Does not necessarily have the ability to scale because now more of the pure infrastructure things. Right. So a lot of times you end up with something that someone thought of actually a pretty good workflow. Right. But and then you get into it and underneath the surface, the technologies that are used are not going to work the same way. I keep thinking about even scalability is one of those things that comes up when humans write it, when computer writes it. Right. It's going to be if I use say something like Azure Sync, which doesn't give you a lot of control over the data that sinks across versus I use an API sync that has a lot more control. There's a clear difference in scalability. One gets implemented a lot faster than the other. So if you're Vibe coding, a lot of times speed is Your goal, and it's going to be reflected in that and the technology underneath. It absolutely has some challenges there. And you do have to try to work collaborative with the business, because if they're happy to see this, you have to realize there's something that they like in it. So you can take that as a proof of concept, but then you still have to build it into an enterprise tool.
• 38:26
  Speaker C: Yeah, I was going to bring that up. Individual product versus an enterprise product. So you got to take that individual product that they've created or coded or that concept that they came up with with, and then start to turn it into an enterprise solution.
• 38:40
  Speaker A: Absolutely. But it's great. Almost like a wireframe, if you think about it. Right. A user is trying to understand. What can I get out of my brain to give to you? That this is exactly what I want to flow. They vibe, code it, they give you a wireframe. This is what I want to have a button here, I want to click here. I want to bring me here. And this is what I all I want the app to do do. That's great. Wireframing. Now, that makes it a lot easier to communicate to a development team. All right, let's build this. But let's put some best practices in it. Yeah.
• 39:15
  Speaker C: And not only the wireframe, but it also helps them, being the business user, communicate in or translate their ideas into something that those coders can use. Yeah, yeah.
• 39:30
  Speaker A: There's always this communication gap that you're trying to resolve between what somebody has in their head and what they can't put down and the repeatable processes that you might have in your head, and also the other things that the business is trying to accomplish simultaneously. So you want to fit all that stuff together at the same time, and the better of an image you have, the faster you can get there.
• 39:55
  Speaker C: Yeah, so true. What other lessons do you want to impart to our peers that are listening to us and. Or those that are listening, trying to move forward? Scalability values. Not where you think it is. Yeah.
• 40:12
  Speaker A: I think that a lot of things is just the human aspect of it. Listen more than you talk. Where you can guide people with kindness and humility and all that stuff will always pay off. It doesn't matter what it is that's going on. Be kind and it'll pay back.
• 40:29
  Speaker C: That's an awesome thought. I really like that because in all honesty, I try to follow those ideals myself. So the question that I warned you about earlier, what do you think we'll be talking about in 18 months that we haven't been talking about now.
• 40:47
  Speaker A: So I think that we're going to have a need for more humans. I think that that's actually going to be the surprising thing. As much as this stuff is really cool. We're going to realize that some of it needs to be a little bit more human. And I see that some of that is also coming true in what is starting to be built. They're talking about Claude watermarking its work because we need to know what's human generated and we're going to put value differently on the things that are human generated. We're going to want things that are human generated in other aspects of our life. Not really so much the tech industry. Right. It's going to be more so that we're going to value these human to human conversations and relationships. And I think that that's going to be a big deal. I think that we're going to see a few different waves of what happens with AI, that people will panic, things will subside, they'll panic again, that'll happen. That's going to be a natural wave and progression. But I think more than ever, eventually we're going to say, I really miss talking to people the same way that we used to.
• 41:55
  Speaker C: Yeah, very interesting time and wave analogy because in my mind I was thinking the same thing. Tsunami of oh comes through, wipes everything out. All of these people get taken out of customer service and being the human interacting with people and then right now we're in that point where everything's rescinding back in and now they're starting to hire people back. So very absolutely thought.
• 42:21
  Speaker A: I think actually one of my favorite use cases is Ikea that reduce so much of their customer service, team with AI and just repurpose them into kitchen designers. That opened up a brand new vertical for them. So they expanded everything, their entire business by shifting customer service representatives into a much more valuable teammate.
• 42:45
  Speaker C: Oh, and you know what? I haven't followed that story. Have they needed to bring any of their customer service people back yet or.
• 42:54
  Speaker A: I think that's working pretty well when it's targeted. Because if you've got someone who says this is my order number and these are the parts that I needed, I think that works pretty well. And you can have that kind of do that type of work. Absolutely. And now you can have a human being who isn't just looking at a manual looking things up and what you previously think is lower value work. And now they can do something like put the creativity into kitchen design. So I love that we can shift people into new verticals altogether. And then you realize you need more
• 43:23
  Speaker C: people in this and you kind of hit your circle on and we need more people. Well, I have enjoyed this conversation. I hope you enjoyed it as well. I hope our listeners enjoyed it. And remember to drop us a like listen to some more and join the community at you've been heard.com Peter I appreciate the conversation and the sharing of your experience, your honesty and your wisdom. Thank you so much for your time today.
• 43:51
  Speaker A: Thank you Mike. This was a lot of fun. I really appreciate you so much. This was great.
• 43:55
  Speaker C: Sa.