Idara Uko | Pacemakers, Principal Engineers, & Product Fit

In this episode we talk about the nuts and bolts of how implantable pacemakers and defibrillators work, the difference between a principal engineer vs an individual contributor/project engineer, and how to ensure your team is developing the correct product (as opposed to simply developing the product correctly). 

Idara Uko holds bachelor’s and master’s degrees in electrical engineering, as well as an MBA. Working at Medtronic where he serves as Director of Software Operations, he has over fifteen years of experience in the regulated medical device industry, including R&D, market assessment, market development, understanding voice of the customer, system design, system verification & validation and product support.

Aaron Moncur, host


ABOUT BEING AN ENGINEER

The Being an Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.

The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us

About Being An Engineer

The Being An Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.

The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us

Transcript

Presenter: 0:00

Hi, everyone. We've set up this being an engineer podcast as an industry knowledge repository, if you will, we hope it'll be a tool where engineers can learn about and connect with other companies, technologies, people, resources and opportunities. So make some connections and enjoy the show.

Idara Uko: 0:18

What is it that we're trying to do our business? Right? What are we trying to? Who are the customers we're trying to serve? How can we best serve them?

Aaron Moncur: 0:41

Hello, and welcome to another exciting episode of The being an engineer podcast. Our guest today is Idara Uko, who holds a bachelor's and master's degrees in electrical engineering, as well as an MBA direct currently works at Medtronic where he serves as Director of software operations. He has over 15 years of experience in the regulated medical device industry, including r&d, market assessment, market development, understanding Voice of the Customer system design, system verification, and validation and product support. Idara. Thank you so much for being with me on the show today.

Idara Uko: 1:17

Hey, thanks, Aaron. Glad to be here. It's exciting.

Aaron Moncur: 1:20

Allright. Well, what made you decide to become an engineer?

Idara Uko: 1:25

To become an engineer? Wow. Okay. Really, that that was kind of easy for me that started way back from when I was a kid, but my dad was a mechanical engineer.

Aaron Moncur: 1:39

But but then you chose the dark side of electrical engineering.

Idara Uko: 1:42

I showed up like, Yeah, I did. mechanical. But no, so I went, I went into electrical engineering. My I had, so my dad died. And then I had the cousin that I looked up to who grew up with me. He was about six years older than I was, and he went into, he was interested in engineering. So I'll, you know, try to be like him, too. I chose the engineering path. But, but yeah, I had a lot of influences in my life that caused me to choose that engineering path. So

Aaron Moncur: 2:17

Excellent. Excellent. All right, I'm going to ask a question that's just going to expose my own ignorance here. But what you graduate from McMaster University, and at least those of us in the mechanical world are very, very familiar with mcmaster carr. Is there any relation there? Are they totally though nothing to do with each other? No

Idara Uko: 2:34

relation at all? So McMaster universities in Canada, Hamilton, Ontario. It's, it's actually after famous person in Canada.

Aaron Moncur: 2:46

Okay, okay. Now we know, all right. Well, that went to bed for good. All right. I'm going to continue asking questions that totally expose my ignorance. I am not as some of the people I work with. Say, I'm not Sparky. I don't, I'm not very good with electrical. So I'm going to ask some really basic questions under the assumption that there are others out there like me, who may be whizzes in mechanical engineering or different kinds of engineering, but don't don't have a firm grasp on electrical. So my first question here is what is the difference between firmware and software?

Idara Uko: 3:22

Hmm, that's a that's a good one. Yeah. So. So if so firmware is, so Okay, let me let me back up a little bit since so I studied electrical engineering, as part of your novel studies, you get exposed to computers, computer engineering, and CAD software design. And, and with that, I say, gradually, as I went into work for the first time, right after my internship and graduated, I got a job as a firmware engineer, and I was doing my firmware test. And at the time, too, it was new for me learning this, but from where you think you think of firmware as embedded software, so it's software that runs inside of a device, right? And then you can think of your regular software as something that, you know, you're, you're working on your software application, something that faces a customer, that, that you could consider software. So you think of that cloud or the application software applications. But that firmware, it's, it's, it's quite neat, because it's it's really the internal logic of a device and how it runs and it's still follows very similar principles as regular software. But, but yeah, we call it differently. So firmware is is essentially embedded software.

Aaron Moncur: 4:49

Would it be accurate to say that firmware does not have a GUI, but software does have a GUI?

Idara Uko: 4:56

Correct? That will be okay. Yes.

Aaron Moncur: 4:59

Excellent. Okay, you know, I never I always kind of had a sense firmwares like it's in the PCB doing its thing, but I think that was a good distinction for me right there firmware. There's no GUI associated with it.

Idara Uko: 5:11

Excellent. Well done Sparky or

Aaron Moncur: 5:16

maybe a tiny little glowing ember somewhere in there. Good. All right. You have spent quite a bit of time working on a next generation implantable pacemakers and defibrillators, and this is all in your LinkedIn profile. And of course, without disclosing anything confidential kid, can you share a little bit about how generally these devices work, implantable pacemakers and defibrillators.

Idara Uko: 5:45

Okay, yeah, it's it was so again, like, one of the things that for me, when I first joined the company was I was out in California walking around at a conference, and I came across a Tronic. And, and they were, you know, trying, recruiting and interviewing. And I saw a post there that said, Hey, we're looking for electrical engineers. And I'm like, wow, you can actually, you know, I can use my electrical engineering degree, because then initially, my direction was wireless communications. So I said, Hey, you could use my electrical engineering degree for to actually help people. And that's the way I saw it. Right? So you had a company that is actually focused on helping people helping people live better lives, right. So and, and I'm like, you can actually, it's all based on electrical engineering type principles, right. So the hearts all works, your body essentially has electrical signals that are unsure it already, right. So based on those type of principles, they were able to come up with different devices. So pacemaker, and implantable pacemaker is something that goes inside your body, on the your, your chest to spit it out yet, around you to the right or to the left, but below your, your breast. And they it's it's somewhat what it does, as a pacemaker, essentially paces your heart. So you find patients who have the they have syncope, or they have cases where the hot does not beat as regularly as you'd expect. So it could sometimes skip a beat. So you would, so your your beats really slow. So you tend to find patients who are you could have patients who are a weak and lethargic and it's made just because their heart's not beating as fast. So if you're not beating at irregular beat a rhythm, you're not pumping blood, properly treat your body at a regular rhythm. So what what a pacemaker does is when the hot speed into slow, it regulates the heartbeat, so it brings it back up to a normal heart beats. And it does this by simply sending small electrical pulses to the heart, and then the heart is able to contract, right? So it contracts with each electrical pulse, and that that enables the blood to pump for the heart to pump blood across around the body. So that's what a pacemaker is, are they

Aaron Moncur: 8:30

are they more commonly used to speed up a heartbeat or, or to slow down heartbeats or all of the above?

Idara Uko: 8:37

It's more commonly for pacemakers. It's more commonly to speed up the heartbeat. It's usually for patients where their heartbeats are too slow. So on average PPO heartbeats at about 60 beats per minute, right. So in some cases, some athletes it's a lot faster naturally, but then you can get to, can be slower to for some for some folks. But in cases where you have some hot hot problems, you can have patients that are hot beats of like 30 beats per minute, right? So that's way too slow and, and doesn't, that's where the folks get the lethargic and other things. And so what that does for the pacemaker does is it brings that back up to 60. Right? And the interesting thing about the pacemaker is it also needs to be smart enough to say, hey, this person is exercising, so I need to beat a lot faster. So if you're exercising, you're going to get it up to 100 beats per minute. So the pacemaker needs to be able to say alright, I need to adjust and help this help this patient continue to exercise without feeling tired so it speeds up is electrical pulses can catch up. So

Aaron Moncur: 9:50

that is interesting. I had never even considered the intelligence to regulate the heartbeat, depending on levels of activity.

Idara Uko: 10:00

Yep, another another tidbit there is when you sleep, your heart rate also drops. Right? So when you're asleep, your heart rate drops through What 4050 Baby beats per minute. And the pacemaker has to be smart enough to to know that, hey, my patients asleep, so I need to dial it back a little bit. Right. And that interesting, too high. So So picks that up.

Aaron Moncur: 10:24

Now, I would think that in order to regulate the frequency with which it stimulates the heart to beat it, it would use mean a heartbeat to as the input, but of course, the heartbeat is the output. So how, again, if it as long as you're not giving anything confidential away, how does the intelligence work to know, you know, if you're playing baseball or basketball versus sleeping?

Idara Uko: 10:50

Yeah, yeah. And it's, it's a sensor, right? So the one thing we can do is, so this is where the whole firmware and software come into play, right? So on the software side, I need to show a GUI. So the clinician and the clinician can tell can say, you this patient, this my patient, this patient is that's pretty fairly young guy. And right, they are pretty active, they play baseball, they do they go biking, they do other things. So I'm going to set it up in such a way that the pacemaker can account for those activities. And then the within the firmware, we now say, Okay, well, what do we need, we need inputs coming in. And using those inputs, we can tell what's happening. So the inputs end up being, we'll look at something called and we have something called an accelerometer. So an accelerometer, it's also in your watch your iPhone, and everything, your iPhone, also in your iWatch, too, as well. But if an accelerometer just indicates, gets a sense of how fast you're moving your movements, what's going on at a time. So using that sense, so we can use that to regulate, right? The heartbeats are the rate at which we send pulses to the heart. So that makes sense. Okay, so so it's all senses, it's one where we're picking up using so Ramita pickup dance, we're using our we have leads that goes into the heart from the device from the pacemaker, and sometimes now, now we have more recent ones that don't require leads, and leads are just more wires that go directly into the heart. So the other piece now that you have taken as the heart signals, you know, when the heart's beating, you know, when the atrium beats, you know, when the ventricle beats, you kind of based on that, you use that to regulate and decide when am I going to need to put a pace, pulse into the heart. So, so that's a pacemaker. I don't know if you have more questions on it. But

Aaron Moncur: 13:00

one more I thought of one more is just getting into the minutia here. But what would happen, and maybe this is why you see signs sometimes saying, like, don't do this thing if you have a pacemaker. But let's say that you were a patient on a roller coaster, and you're using the accelerometer as an input, can that be dangerous?

Idara Uko: 13:19

It's very dangerous. Yes, that does happen. So that's why you have that and even even long Moore's few years and a lot more. It vibrates. Yeah, so it could signal to the pacemaker that it looks like you have a lot, this person has been active, something's going on. So So those are the things that we do, where we actually we have, it's their standards in there already that we have to meet. And as part of those standards, we have to filter out a lot of noise, environmental noise, right and make sure we're focused on the right stuff. So we try to do that sometimes some, some things sneak in, but we were pretty good. Now it's being able to use a filter. And that's also where the firmware comes in. And the hardware is we can filter out a lot of the noise, that that's out there and focus on what we really care about. So

Aaron Moncur: 14:14

it's fascinating, and this is an implantable. So it's got to be pretty small, approximately what size are these?

Idara Uko: 14:23

So it's, it's, I think, if you can think of with net we're not making ones that are really as small as a as a as a quarter. Right? So there's some that now as small as equality that that's actually goes directly into your heart. So that's, that's the latest technology we've created. Others they honestly pacemaker started out from being really big. They really just essentially sat on the outside of your boat, your hip, and then patients carried it around and then now it's evolved to the point where it's really As small as really, you can't even tell that it's in you, right? It's a small little, little device. So it was the size of, yeah, like the smallest is the quarter, but you have some that are a little bit bigger than that those the devices that have the leads, they use the wires, they still just a little bit bigger, but it's really, really small.

Aaron Moncur: 15:25

That's amazing. Yeah. And how are they powered? Do they have their own power source? Or is it powered externally?

Idara Uko: 15:31

Yeah. Great. You're asking great questions. Yeah.

Aaron Moncur: 15:35

So engineer brain?

Idara Uko: 15:37

Yeah, it's a great question. It's, it's internally powered. It's, that's always another challenge that we've had in the industry. So we use lithium ion batteries. And those can they, we put them in there, and they can last close to 10 years. Right. So in a lot of cases are amazing. They're pretty small. And we're always trying to reduce the size of those. So it's, it's always good, good advancements there. Of late.

Aaron Moncur: 16:05

So that's incredible to see the power draw is almost zero, all these things. Yep. Yep.

Idara Uko: 16:10

Again, that's all that's all the firmware design, because you have to make make sure that it's, it's very, very little current dream coming true. So I didn't answer your difficult latest question. So go for it, please. Okay, so defibrillator is really a kind of, at the at the a little different for pacemakers there, where if your heart's beating really fast, then we have to slow it down. So that's a little different. So what we do there is, your your heart's beating really fast. So we send the shock, pulse to the hearts. And we we slowly slow down the heart that in that case, so a lot of patients, you can have patients who have what they call an arrhythmia, ventricular arrhythmia, tachycardia, anything. And so when we do that says the defibrillator is their job is really to make sure if think of the, you know, the external defibrillators. Right? Says clear shot. Yeah, right. Yep. And so that's what we do with implantable devices without implantable defibrillators. It's, it's not an external one. It's implantable. It's in your heart. And what it does is if it detects that your heart beats going way too fast, and you have an arrhythmia, it shocks it shocks the heart. So it takes it out. It takes the Ruby away. So

Aaron Moncur: 17:31

I see. Okay, so I've just learned something else here, my journey towards spark Enos, I just assumed that there would be like the External Defibrillators where they're more intended to like, restart your heart, right? What if your heart stops there? Back in, but this is for when a heartbeat is too fast. It slows it down?

Idara Uko: 17:50

Yes, yes. When it's when it's too fast. That's a you have said and it's great. It's quickly in a lot not at a rhythm in any way. It's abnormal, for sure. So we it shocks back to normal.

Aaron Moncur: 18:04

Interesting. Okay. All right. Well, pacemakers and defibrillators are their life saving devices. So I'm assuming that they're classified as, as class three medical devices, how does software development for a class three medical device differ from software development for say, consumer electronic?

Idara Uko: 18:24

Yeah, that cases, it's a lot of regulation, it's really purely the regulations, they're tough to get get past, then you have to really prove you have to prove efficacy, you have to prove that like your device is work or your system works and, and does what's intended to do and it does it in a safe manner. So there's a lot of emphasis on the risk to patients. So we have to make sure that we've broken down every risk, or we've reduced the risk to as low as possible in our designs, and then we also do a lot of I think we go through, you can have multiple things, you can have like a 510 K for submissions to the FDA, or you go through an actual full on submission. And so the regulation is a lot more strict from that regular consumers. And we're all required, we have different standards were required to meet and be compliant to, so that that plays a role in it. So I think we've had scenarios and it became this way just years ago, many, many years ago, we had scenarios where folks we did software and just put it out there and the software caused problems in the field for patients and that led to us patient that's And so from then on pretty much regulators across the world, across the globe, have been regulating Medical Device Software for a while now. So, yeah,

Aaron Moncur: 20:03

no, this is a complete tangent here. I just heard on a podcast somewhere, or maybe I read it very recently, I can't remember now. But it was talking about the FDA and the role that they played in regulating medical devices and you know, pharma and things like that. And apparently, back, I think it was 1920, maybe right around that time. Pharma, pharmaceutical manufacturers were not required to verify the safety of their products, all they had to do was put the ingredients, you know, basically the cocktail of different chemicals on the label. And that's all they had to do. And they there's a case study that talked about where there's some cough syrup for children that had just been invented. And there was like, it wasn't cyanide, but it was something like that, you know, that was like, clearly toxic to humans that they had put in there. And they listed it on their labels. So you know, the FDA was like, okay, that's fine. As long as you list it, we don't. That's all

Idara Uko: 21:10

the warning is there. Yeah.

Aaron Moncur: 21:13

But a bunch of like, you know, children died from it. And that was kind of the turning point at which the the FDA said, okay, yeah, we're gonna require more than just putting a label on to tell consumers what's in the product. Now, we're actually going to require the organizations to verify that these things are are safe as well. Anyway,

Idara Uko: 21:32

it's very similar, very similar to ours, we have we have to be very careful about what we put on our labels. And we cannot encourage anyone to use it outside of the layman. Right? So yes, yes, it's entities. So it's, it's very strict. And if we, if someone uses it outside of the label, it has to be, we have to notify the body's regulatory bodies on that, too. So. And so I've actually captured and documented so yeah, okay.

Aaron Moncur: 22:08

All right. During the course of your career, at least today, you've progressed from being a senior engineer to a principal engineer. And I'm wondering, can you share what what is the difference in terms of day to day responsibilities between a senior and principal level engineer?

Idara Uko: 22:27

Yeah. And it's probably even broader than that. You could say, you're either new entry engineer. And then as you rise up to a principal engineer, what's the real what's the difference there, and some of it is just years of experience getting older losing hair, but but the but a lot of it to just becomes like growing responsibilities. So as an entry level engineer, you're more so really, right, just doing doing your tasks, taking the work for the team and taking, you're figuring out what your task is working on it and provide you're having some type of contribution. And then as you progress, you're taking on more responsibilities where at a principle level, essentially, you're, you're leading teams, you're a technical lead on a team, you're interfacing with key players outside of your own team. Right? So yeah, you end up being the face of the team and people look to you. And then also, you're, you have have more of a technical authority, in a sense, right? So yeah, people expect that you, you know what you're doing. And you can be counted on. So that's, that's, that's primarily I did nutshell, its defense, the way we look at it in general, is we talk about your span of influence. Right. So and then we talked about level of the level of independence you have, right, so principal level engineers are generally more independent, that's a new entry engineer. And then we'll talk about leadership, leadership capabilities and and also how you deliver on results. So

Aaron Moncur: 24:21

wonderful. Okay. What are some tips for how software teams and hardware teams can can communicate effectively with with one another? Maybe, if you can think of any what are some of the problems that you've seen in the interactions between these groups in the past? Yeah,

Idara Uko: 24:39

it's, it's, it's, it's interesting, like they definitely they can be a lot of different problems, but I feel there's in some ways, we were just talking about this too, with someone it's this you can have to two flavors of this in software, a lot of software teams and now you know, trying to use the Agile metadata Big for software development. And when then you have hardware teams that in most cases follow a waterfall type approach. And both of those like, Yeah, let's use is good communication and good understanding, you could bump heads into those tasks that was right. So if you're not talking about it well enough. So but I think the one piece for software and hardware that I found is, it's the communication, right? If there's there needs to be good communication, and we find ways to like, make sure that it's clear that interface is cleared. So we try to do a better job of documenting and capturing understanding of what's the interface between hardware and software. And so if we, as part of our designs, we we write that down, so that everybody knows this is it if I'm going to talk to, if my hardware component is going to talk to software, this is how he talks to software. And so everyone agrees to that. And then we follow those same principles across the board so that there's no mistakes, right? So. So that's one way to do it. The other piece, like I said, it's, it's really, documentation is one thing, but having just the teams together and working together, and just having conversations that really helps you at time. And it's also a way for us to ensure that we are growing, right? We're growing knowledge and sharing knowledge across both software and hardware, and have built in that good understanding. So

Aaron Moncur: 26:41

How about how about measuring progress with software development with hardware, I feel like it's it's fairly straightforward. You can look at something, hold it in your hands, it's tangible. You can touch it, you can move it around, and you can say, Yeah, I know what it is supposed to be at the end. And here's what it is right now. With software? It's, I don't know, for me, it seems less tangible. How do you measure progress with software development?

Idara Uko: 27:05

Yeah, that's a good one. Yeah, I'm actually reading a couple of books at this, similar to this. Now. It's the in software, it is less tangible. But we have we have multiple ways of doing this, like we could we look at, we have we create user stories, in a way. So user stories essentially says, Hey, here's what I plan to do. Right? And then I will look at how over time over a specific period of time, how much of that how many of those user stories have I completed. So So I work on and user stories could take the form of well, I want to create something that can turn the color of Aaron's beard from gray to black, right? So something like that be great. So, so, and then you define what is what you consider done? Well, my done is I'm going to test it. And I'm going to confirm that, yes, it does. I can I can do this in different scenarios. So. So that would be and we go for a sprint. So a sprint can be two weeks, four weeks. So let's say Well, given to my two week sprint, how am I progressing? At the end of my two week sprints? I can check to see if Am I done and I might not done with this. And so that gives me an indication of progress for each team. And so I look at in terms of metrics, we look at what we call burn downs, we look at velocity. How quickly is the team getting through all their user stories? How quickly are they burning down their backlog? So because the backlog essentially says, you have all these user stories, so you have a lot of things to do, and you've taken some and you're using it, you're trying to work on it for this sprint? Well, how quickly did you get through them? And then how much of it? Did you burn down like so? So I use that to show show metrics. And then obviously, there's still the other regular traditional approaches of people for providing status reports and then other bits, but you can with the tools we have in software, I can almost tell as long as everyone's following and doing it right. I can go in easily and look and see, okay, they're making progress. They're not making progress. So the user

Aaron Moncur: 29:41

story that's a new term for me, is that more or less synonymous with like a feature? Basically?

Idara Uko: 29:47

Yeah, yep.

Aaron Moncur: 29:48

Was it more than that? It's, it's,

Idara Uko: 29:50

it's very similar to a feature. Yes. Okay.

Aaron Moncur: 29:53

Okay, so great. All right. Well, this this is a good chance for me to take a very short break and share with the listeners that Team pipeline.us is where you can learn more about how we help medical device and other product engineering or manufacturing teams develop turnkey equipment, custom fixtures and automated machines to characterize, inspect, assemble, manufacture and perform verification testing on your devices. We're speaking with Daraa buco today, Dora is I feel like engineers, we always want to make the products that we work on perfect. And that can lead to scope creep and spending too much time on a particular product. So oftentimes, the features that go into these products will be broken up into like, a gen one release, a gen two release, and so on. How do you determine which features will be part of a gen one release and which needs to be saved for future generations of the project?

Idara Uko: 30:51

Yeah, good question. Yeah, it's, it's all of these, they all dispute it, they end up being discussions and negotiations between the product teams, the designers, some things just generally take longer to do. Right, and others do not. So we, if you think about the way we ended up doing this, because I once I learned point, le Miercurea, I was on a project for nearly, I think it was almost it took us almost seven years to get that product out the door. Wow. And that's in fraternity. So the market changes, everything changes way too quickly, for you to take so long to develop a product. So so we quickly stopped doing that. We we ended up saying, well, let's figure out what you can put out. You want to have something some type of release every every year, every two years, right? So so you figure out what is it that customers want, right? And what's more urgent or what's not. So you figure out what's important to customers. And then you pick those those features and say, Alright, let's try to deliver this, right in this timeframe. And something that's restricts you is there may be requirements for that region of the business or the customer where they need something at a certain time. So you have to deliver it, it's that time, so your timeframe becomes limited. And then also your budget, you don't really have that much money to spend. So it's better for you to phase it in ways so you can you can you can spend the money so so that's what we do is we essentially decide on Alright, let's this is going to be impactful in the marketplace. We think that it can make a difference for us. So we'll put it into phase one. And we know the things that might take us a lot longer. We'll look at the Phase Two for it. And so yeah, Gentoos it's what you call it the Gentoo really so

Aaron Moncur: 33:03

great. Okay, well in your LinkedIn profile, one of the things that you share about your role is owning the responsibility to manage a team have focused on ensuring that we build the right product or system for our stakeholders. Now, I'm being a little facetious here, but it may be especially for younger engineers that are listening to this. Isn't it easy and obvious what the right product is? I mean, you're working on it. Right? So how can you build anything but the right product?

Idara Uko: 33:36

That's yeah, that's a good one. Have you ever seen that? Have you ever seen that cartoon where it's, there's, that's someone says, it says, I need to I need a swing, right? And then you're this engineer goes off and builds this really fancy, fancy swing that you go up with that, like, makes music or something like that? I'm not sure but it looks very different. And but at the end of the day, the customer comes back and says, Well, I just needed the tie tied to my tree that's right here and small swing. So so it's, it's very similar. It's a you have to that term is really like a validation term. For us. We call it design validation. It's, it's ensuring that you're, you've built the right product for your customers. So and, and you only know that because in engineering and you notice too is that at someone can ask you for something but you have to really kind of check and make sure you have a good understanding of what they're asking for. Because you can end up building the wrong wrong thing for them. So it's, and that's what this is. So the way we do this is we're constantly going back and asking customers like hey, you asked For this, but he has a prototype, is this what you were thinking? And then they'll tell, they'll say, no, maybe this, this and this and it will go make modifications come back, say, Okay, here's another prototype is this kind of what you were thinking? And eventually, gradually along the way, it was like, Yep, this is doing exactly what I want, this is what I want it, then we go off and we go build it. And we come back as long as we don't take too long to build it. We come back. And we say, Yep, this is this is good. So they, they can use it. So that's, that's, that's that's the idea. It's constantly checking in with your stakeholders or your customers, and making sure Yep, you're meeting, what you're actually doing what they intend you to do, because it can look everything to look fine. But at the end of the day, it's still not the right product for for your customers. So you want to be careful about that. So and that is such

Aaron Moncur: 35:53

a perfect way to do it. I think it's it's so easy to create a requirements document and you send it back and forth. And everyone says, Yep, this is exactly what we want. And then, but then you build a prototype, like you say, you actually get something in their hands, whether it's software or hardware, and the customer starts using it. And even though everyone agreed to that, that product requirements document, there are always those cases where they get a prototype in their hand. And oh, I didn't realize that it was gonna be this way. Or we actually what we really need is, you know, this other thing, this other feature here so that the prototypes and the iterations of the prototypes is I think that's, I mean, practically speaking, that's, that's the way to do it. Yeah. All right. Well, what what advice would you give companies that are just starting to develop their own internal software group? I mean, are there best practices like we're like Scrum or agile that we should be learning about? Any tools that are very commonly used, or just anything else that comes to mind that should be considered for companies that are establishing their first team of software engineers? Yeah,

Idara Uko: 37:03

great. Like, I think I may have mentioned this earlier, but I did move from so I started off as an electrical engineer, worked in mod firmware area, and then I moved into more of a systems area, and that systems area is all about understanding what customers want and delivering that. And then, and then we act I started, then I first went into quality. And then I also now lead the software team. And we're constantly always asking about this, right? Like, how do we build our software teams? How do you? What's the right team structure? How do we want to set it up? And, and they already really good, right? Good templates are good examples out there in the industry, in the software industry and software world or any that, that we're even, we're trying to leverage and use. But at the end of the day, I sort of we step back and realize, well, what is it that we're trying to do our business? Right? What are we trying to who, for the customers we're trying to serve? How can we best serve them? Right. And so you set up your teams, and you set up your, your group in a way that you can do that. So for us, we're, I commit as a medical device company. And we are not just pure software, we're a software that needs to work with a medical device. So they it has to be good interoperability across with that, and also with other instruments that we build. So it becomes very complex. Right? And so every time we're always mixing them, trying to figure out what the right pattern is. One thing we do know that we're taking this from industry is yes, going with an agile scrum approach is as as pretty much the best way for developing software. And it's merely because of the know the principles behind agile and if we follow it to the tee, it's, it's great, because it's all about the customer. Yes, like you're trying to design things to make sure it's right for the customer. And so you're focused on that. And then you're doing what you can to get that out fast. So so that's why you look at a two week sprint. So you look at other approaches, and then it gets more detailed on the mechanics of it. But just fundamentally at a pretty high level. It's that's really what it's about. So so we found going with an agile scrum approach is working. Some of our teams do different things. Sometimes we we don't do typical like sprint format. So the squad and we go Kanban depending on what what we're working on, or what those teams are working on. So we allow that flexibility of the teams. I think getting to the point where we've also realized that it's good to have I mean the pluses and minuses to these things. But it's good to have it where teams are focused on doing their software development. And you have the required roles that help in terms of reporting out, making sure that there's a backlog and understanding what the user stories need to be the roadmap. So we have roles to handle that. So typically call that product owners. We call it, we have a scrum master now teams. And so those two essentially lead the teams. And the teams just kind of if they have those two are really good. The teams run themselves and you and they are autonomous. They, they make decisions, they they they click and they move. So if you get it right, and so it's beautiful to watch.

Aaron Moncur: 40:48

Wonderful, wonderful, man. All right. Well, let's see, before we before we enter, is there anything else that that we haven't talked about that you think we should talk about?

Idara Uko: 41:01

Yeah, I think I think I think in general, I think if there are folks out there that a look into to do this for the first time, or to set up a team. Of course, I didn't mention this, but you did multiple ways. Like the a lot of software houses out there, right? A lot of people go with vendors, right, and they grew up with us to do the work that they need to do. So I think the way we think about it is, is it's something that's core to our right, our offering, is it something that's core to our company, and what we bring to the table? If it is then we want to build those teams in house, if it's not something that's core to us, then then we'll probably outsource it out and, and work with those those teams. So those are some other things to consider for anyone. So who's there who's building this? Who's trying to set up a team for the first time? So I think I think it would like with anything engineering in you know this as well as it's all about the AI you're trying, you're experimenting, you're learning, you're constantly learning along the way. And you make mistakes, that's fine. Bounce back, keep going. So

Aaron Moncur: 42:16

that reminds me of a book that we were discussing in our team meeting yesterday. It's a book called culture code, who one of our team members suggested I read? Have you read it?

Idara Uko: 42:25

I just sent that link out to my team. So wonderful. So good. I've read it. I like it. Yeah.

Aaron Moncur: 42:33

It's one of the best teams on books on team building I've ever read, I think, anyway, it reminded me you remember the part in the beginning about the the sticks in the marshmallows and the tape with the kindergarteners and yeah, kindergarteners, for those out there who haven't haven't heard it. Don't take my word for gluten Biden and read it because it's wonderful. There's so much there. But there, there was a study done where kids kindergarteners were given, like little, I don't know wooden dowels skiers, with some tape and marshmallow. And the rule was that the marshmallow had to end up on top they had to build these structures and the taller you could build it the the better you scored. And and so this team of kindergartners would do this. And then the researchers went out and had teams of MBA students and attorneys and even CEOs do the same thing. And of course, you would assume that well, the the business school students and the attorneys and the CEOs, they're going to crush the kindergarteners right. And that was completely the opposite. In fact, they replicated this dozens of times. And every time, the kindergarteners, one on average, there's where I think like 26 inches tall and the MBA students were like 12 inches tall, and attorneys were like 16 inches tall. And CEOs were like 22 inches tall. But the amazing thing was they said the professional groups would spend a lot of their energy thinking and strategizing and even kind of trying to figure out like where they stood on the social hierarchy, you know, just trying to figure out their place within the group. And the kindergarten, they just jumped in, they just dived in. And it was messy and kind of chaotic. And people were talking over each other, but they were just trying different things right from the start. And that was the strategy that really ended up being the best one. So anyway, remind me of that. It's good. Yeah, I like it. Well, Idara how can people get in touch with you?

Idara Uko: 44:37

Yeah, Im on the. You can reach me through LinkedIn. Certainly Welcome to I'll continue to network with others and share what I know and also learn from others as well. So I'm on LinkedIn. I'm also on Twitter so you can hashtag UK Oh ID so you can also reach me there as well. So

Aaron Moncur: 45:00

Terrific. Terrific. All right. Well, Idara, thank you so much for spending some time with me on the show today. Really appreciate everything you've shared and it's just been a pleasure to get to know you a little bit.

Idara Uko: 45:11

Okay. Thanks, Aaron. much appreciate it. This was fun.

Aaron Moncur: 45:18

I'm Aaron Moncur, founder of pipeline design and engineering. If you liked what you heard today, please share the episode. To learn how your team can leverage our team's expertise developing turnkey equipment, custom fixtures and automated machines and with product design, visit us at Team pipeline.us. Thanks for listening