Peer Check
Peer Check

Episode · 1 week ago

#14 - Hardware is Hard, But Does It Need to Be?

ABOUT THIS EPISODE

As software companies seem to build, iterate, and ship faster each year, hardware companies face increasing pressure to do the same. But designing and manufacturing hardware comes with a host of challenges that software teams don’t have to deal with.

So how can hardware companies keep up? What methods can help them scale their operations, build trusted partnerships with suppliers and distributors, and continue to develop amazing products?

Our very own Mark Morreale, Engineer-in-Residence at CoLab Software, has dedicated his life to building hardware and building it better. Mark joins the show to share his perspective on how hardware companies can prepare for the future by adopting new methods, building better partnerships, and embracing change.

Join us as we discuss:

  • Challenges and considerations when developing and shipping hardware
  • Adapting existing processes versus starting from scratch
  • Why hardware companies are facing increasing expectations around production speed and profit margin
  • The transition from planning and design to manufacturing
  • Whatsupply chain challenges really mean for hardware companies
  • How to build a trusted partner network by focusing on value-add rather than cost 

More information about Mark and today’s topics:

To hear this interview and more like it, subscribe to Peer Check! Find us on Apple Podcasts, Spotify, or our website—or just search for Peer Check in your favourite podcast player.

M. Welcome to Pierre Check, a Colab podcast. This is a show for engineering leaders who want to challenge the status quo for how design teams work together. You're about to hear a conversation about the ways the engineering world is changing and how top teams are carving a new path forward. Let's do it. Welcome to Pierre Check. I'm your host, Adam Keating, and today we're talking about what makes her we're so hard and what you can do about it to make it better. I guess is Mark Mrially. Our engineering residents are collab and honestly, one of the best engineers I've met and brightest in the industry, from the work he's done on a raw machines to just how he thinks about engineering from a modeling perspective and what the right way to do it is. Not many people care as much as mark. Mark, welcome to the show. I appreciate that, Adam. Great to be on. So, Mark, I'm gonna ask before we get into that. I want to know, like, on the topic of Harvard being heard, why have you decided to dedicate, you know, your life to both building hardware and then figure out how to build hardware better? Why, like you, could have chose so many other things. I mean, as a kid, I was I was always that kid who took apart my toys rather than playing with them, but my parents Chagrin, but it's because I was interested in how people managed to put these things together and how they worked, and I realized that, you know, what we take for granted in our day to day life is some are things that took a lot of human effort to be able to make a reality. And the more I got into it when I went into college, where I realized that every single product around us is actually the byproduct of not no doubt thousands of hours of work, and that's what I became fascinated with, how this built world around us came to be. But as I started working, I realized that the problems around hardware are mostly not necessarily products we're building, but the humans that are trying to build them and integrate them. Is that we can have a lot of great ideas and I've seen many ideas failed to come to fruition, not because they were bad ideas, but because of the communication that couldn't happen between the team members trying to put these things together and it's tragic right, especially working in the medical industry, you've seen, I've seen great ideas that that couldn't become real products, not because the market wasn't ready enough, because there was, they lacked scientific merit or medical merit, but because it was just too hard to accomplish. Yeah, I'm curious, markly, in each of these different experiences you had, like what are the key things in your mind that makes hardware so much harder to communicate about it and so much harder to work on together, because software is harder to write, like software is not a walk in the park by any means, but it feels like it's figured out at a different degree than hardware. What do you think makes a big difference? I think part of the challenges that hardware requires a huge commitment to a certain idea, that it's hard to walk back from that if you've put a lot of time and effort and resources into into this particular idea. And so it leads teams to Ay not want to change a lot of times or not want to let go of things that they've done because they've invested so much into that idea. So at that up until that point in time and so that's one of the things that makes it very difficult. In the world of software, you know, and I've been I've had managers from the software world do project management for hardware teams and it was a transition for them because in their world sprint cycles were two weeks and it was hard for us all to to communicate the fact that sometimes it takes a while just to get the drawing out let, alone getting the quote from the supplier and then getting that piece of physical hardware back into the facility and built and tested. So that was one of the biggest challenges. Is that we had to commit to certain ideas and if these ideas didn't pan out because of the lack of feedback in the beginning or because of some information that we weren't totally aware of, then we would end up having to essentially start all over again, and that's really a tough pill for a lot of project managers to swallow because, you know, there's oftentimes deadlines that we...

...commit to and there's other teams, other stakeholders, who are expecting certain pieces of hardware to be delivered and when things go wrong it's very hard to recover from that, and so it's it's always been important to make better decisions early, but it's just not always clear how to do that. Yeah, you've talked to me a lot about like the as curve. Like the further give down this product development cycle, the more expensive every single change becomes. That it's not like software. I mean there is some build up to that for sure, but you can eat it right pretty quickly. If you ship bet software, you can pull it back and fix it pretty fast. Once you ship hardware, you know you're crude if that doesn't mark the way you want to go. I'm curious, from like a P D process perspective, you just said like the United manager software background. It changed what they thought. I've heard lots of teams talk about becoming agile and like then push back that that didn't quite work. Stage Gate not quite working. Like. What is the way to think about product development? How should managers and leaders be thinking about? Is it stage gate? Should I change that? Should I take elements of Agile and put together? Like? How do you even start that conversation inside your organ I think there's nothing wrong with any of those methods per se right state. Whether it's stagegate agile, there's other methods that have been introduced to in the past, but it's all about how they get implemented and making sure that it's not you're not looking at the process from a textbook standpoint. You have to adapt that to the realities of Your Business. It's oftentimes sort of a cop out where people say, well, we're just gonna go agile and we're gonna put up a white board with some tape on it for can band lines and and and swim lanes and stuff like that, and then just assume that the problem is solved. You have to frame whatever project and methodology you're choosing to follow in the realities of Your Business and understanding what the what kind of lead times are you dealing with, what kind of regulatory frameworks you're dealing what are the things that you can't change, and then you have to work around that. So in some cases organizations have to go through a more staged approach because, whether it's for funding reasons regulatory reasons, you have to frame that in the reality of your current business. I think the biggest mistake a lot of folks make is is saying, Hey, here's a methodology that I've read about in a book, we're just going to follow what the book says and move on from there. And it becomes problem because it becomes a problem because you almost have people performing the call to authority of saying, well, well, you know, the safe framework says this or the Agile says this and whatever, and it's you're you're abstracting yourself from the current problem and you're just sort of pointing to some map and saying, well, this is this is the way it ought to be, in ignoring reality. It's actually interesting because, like so, I worked at reflection medical and when I was there we were thinking and they were thinking about in the way you're describing, like taking elements of, you know, Agile and building into something that had a really long compliance timeline for medical device. But I think that like the part of the day took that I remember working well. At that point it was like they did like a couple of stand ups a week, that the communication was just happening more frequently and like that's not always the right thing, like we found, I think, here at Colab doing the big, broader stand ups were becoming overwhelming and many people to be from concepts. Now smaller stand ups happen and that works, but I think it's taking a little bits and pieces, like you said. My question to you, though, is like, in that mindset, how do you not just get spaghetti, like how do you not just selling an absolutely spaghetti process that nobody understands at all? Like, what's the boundaries to put in place for someone trying to experiment with us? I think it's important to give all the stakeholders a chance to provide feedback on the process itself and recognize that just because you started to rule something out, it's not the final word. The processes themselves need to be evaluated and you need to be able to first of all, measure is this process itself even effective? Are we doing things better, or are we actually doing ourselves a disservice by continuing to implement this? And this is it speaks to the commitment problem with hardware. Before is sometimes, when you decide...

...to follow some specific project management methodology, a lot of times people don't want to walk back from that. They're afraid to. I mean, not gonna lie. I've seen people who are just afraid to admit that they've made a mistake, that what they were doing was not quite right. Just the PLM tool that they've chosen was not correct or something like that, and they need to swallow their pride and and acknowledge the fact that we need to change. And I think that's the biggest thing that leaders need to recognize is that the people who are responsible to implement these processes, they're the ones we're gonna give you the most important feedback about the process itself. Um, if it's not working, they're gonna say so in the beginning. But what unfortunately happens is that if those team members aren't listened to early on, then you just end up with complacency and you end up with, you know, there's a term that's happening right now called quiet quitting, where people are just sort of being the minimum of their job and they don't care anymore. They don't care to point out that there is a flaw in the process because they find oftentimes people just find that it doesn't matter what they say right and and that's a tragedy I've seen time and again in in in tech companies, where somebody would be given the task of being of imflumenting some new process. The process has often definitely good merits, but when there are issues with it, that they're not quite interested in hearing what could be done differently, and that's something that needs to change in hardware companies, because it's the likelihood of one getting the new process and product development methodology correct the first time slimp to enough. But there is definitely an opportunity to iterate on that based on the feedback that you get from your team, and that's the key, is listening to the team. Before we didn't supply chainces some of the other things that are hard about hardware. I just wanted to go back to the words you said, and I think it comes up here again. Use The word effective and also not being married to what you've done. Be Okay to say you made a mistake. I think one of the things that I see a lot is that when people think about improving their process, their mind immediately is like, how do I take this existing process and just make it better, versus thinking about it should we be doing this? Like if you think about a lean like the lean mindset for manufacturing and how you're building that, the whole thing is like challenging and questioning should you do this or not? I don't think what happens with product development. I think we assume. It's like a great example, I think we deal with every day is drawings. The efficient thing to do be not that's on paper, but do it, you know, in your browser or you just call over whatever. The effective thing might be to not to drawings at all. The move the mores model based. How do you think about effectiveness and efficiency in the lens of like what you just said, process iteration, not just product development? It right and speaking to what you said, it's it's definitely true, is that people are trying to take their existing process and adapt it right, and we see this with engineering drawings. Right, is that people are I have been trying to find ways to continue to use engineering drawings and we've been building standards that in many ways, the legacy standards of drawings are holding us back. The legacy standards of engineering drawings were designed for human consumption, to be able to communicate information about three d objects for humans to read. But what we're trying to do with model based is to try to rethink that from the ground up and make it so that machines primarily can be the consumers of this information, with humans making the decisions along the way. And I mean there's a quote that I think is attributed to Henry Ford. I'm not totally sure, but when people had asked him, or he had said, if I had asked my customers what we wanted, they would have just said they wanted a faster horse. And this is the same kind of problem, right, is that oftentimes the users are there, the people who are implementing these product development processes are really just looking at what's there and then, like you say, they're trying to make it faster better, but at the same time it's still just more of the same. Right. And in order to really get to the next level you have to drop everything sometimes and say well, what is it? What is the problem that we're really trying to solve here? Are we trying to make drawings more effectively...

...or are we trying to communicate about our designs more effectively? And when you when, and we've seen this with our with our customers, is and when they start to drop that mindset of is this just a better way of making drawings or is it a better way to communicate engineering data? It's a mindset shift that that really, we've seen it with our customers, is really what enables that ten x improvement in their in their productivity. Right. It's it's letting go of the past and moving toward the future. Yeah, it's. It's a funny thing because, like, I think about Microsoft teams. I joke about all the time, but as much as people say no, I want to use the teams now. That's a huge behavioral change. That then brought people into digital technology who, you know, might have been hesitant about it. There's much bigger change the need to happen now, because I think the thing that makes hardware even harder now is that the expectations of hardware companies are starting to get closer to what people expect software companies. You see it in the public market outside of Apple and a couple of companies who arguably are like you know, a lot of software anyways, and they really technology companies. First companies are getting crushed on valuation is because they're not producing the same margin, they're not producing the same speed. You know, a new vehicle might take fifty, sixty months, whereas like the new phone. I know there's a difference with Complexi here, but like a new phone is coming out. Man, every feels like every day it's a new phone coming out and there's a new software up to every five minutes. It's like those two things are so unopposite ends of the spectrum. Then now you look at the electric vehicles, for example, what Tesla has done. Every other o a m feels okay. We now need to do thirty to forty development windows. Yet at the ground level we're thinking about making drawings five percent more efficient, like don't up. Yeah, the amount of productivity increase. That is necessary. You'RE NOT gonna get with small changes. And even then it's becomes a diminishing return. Right, if you can start making your drawings ten percent fat more effective, next iteration, you're probably only gonna be able to squeeze five percent. After that you're only gonna squeeze two percent. Right, and it there comes a certain point when it's not the process that you're following, it's the things that you're doing that are not effective and are going to get you there. Right. And you know, it's a good example from automotive manufacturers and this drive towards electrification. Right, and it's because, no matter what, when you're still a company that has to bang big pieces of metal together to to produce body panels and stuff like that, there's gonna be realities that you have to acknowledge that it's not like a cell phone right where you know, oftentimes the tooling is small and the it's it's it's easier to tool up it's it's arguably easier to tool up an assembly line for a phone than it is for a vehicle, right because just because from the number of components, just the amount of raw materials that's involved in the number of diverse industries that have to support that vehicle's manufacturing. Right, thinking about what goes into a car, it's not just, you know, mechanical components that you think about. Everything from the vehicle seats to its climate system to, you know, its tires, everything has a different verhical that has to support that that vehicle, whereas you know, a tech company that that produces phones, it's very closely related. And so that's the challenge that I think a lot of these larger manufacturers are facing is that they're trying to do things like tech companies, but there's a limit to what you can do because of just the type of product that you're building and the way that they're made today. Now, I think these problems can be solved again through this more proactive design approach where you're trying to get people into the conversation earlier, so that way, if you do push this very aggressive timeline, the likelihood of something going wrong towards the end of that forty month window isn't minimized, right, because it's all possible, right, and I've certainly been in projects where I've seen the project schedule laid out at the beginning and if all went fine, we would have over did...

...in time. But it's that big question it all goes fine and sometimes, going back to the project manager discussion, we have to suspend our belief of reality just to push that schedule out. But unfortunately, and this is another thing that plagues hardware companies I think, is that a lot of times the engineers themselves, to developers, don't even believe in the schedule. Right, they have a schedule that's put in front of them and they're just like, Yep, I guess that's just gonna be. It will be a conversation for the future of when that's going to slip, and that's a big problem. Right, people are knowing this information, they're keeping it to themselves and they're not raising this early and that's that's something that has to change and that, I think, is one of those those large shifts that we have to think about in our in our development methodologies. It's not just should we make our drawings a bit faster and that's how we'll get there. It has to be we need to rethink everything from the beginning. We need to be very proactive with our manufacturers and our tooling suppliers and those we're going to be doing things maybe two years from now in support of this project, but we need to think take that into account today so that way we're not in a world of hurt later on. Yeah, there's a pretty clear theme where I think you're coming across. is like, for hardware in particular, doing stuff early is really important, and I actually relate to dial in there on like the supply chain, like the external part. So I think from an internal design perspective there's a lot you can do. I think there's a lot of hesitancy about the later stage parts where a lot of the cost and mistakes do happen. It's like, how do you actually build this thing? It's like the hardest part is like how do you actually too? You've gone through the you know, exploration phase of building something. How do you actually go build it and productionize that thing? How do you think about like challenge, taking the challenges of what you know many people consider a multi pronged supply chain? Hell at this point, because there's one. It's like working across company boundaries is brutal in the first place. So that's hard. Then you lay around the fact that products, components, materials are scarce right now, so the supply chains are like unstable. How should teams think about building stronger supply chains in the same mindset you just talked about from design, like they have a rethinking design process. How should they rethink supply chain? I think it's important to look at your supply chain as experts in their own right right, and that's where a lot of these problems do arise. I think, is early in design process. We as engineers tend to we tend to overestimate, I think, our ability to anticipate what's going to happen down the road where, you know, I may be designing a product that you know has to be laser cut out of sheet metal or something like that. I May, I may make some assumptions about how it's going to be fixtured and how it's going to be measured and inspected, and that would lead me to make potentially some detrimental decisions and how that part is designed right. What really needs to happen is very early on the development process we need to bring in trusted suppliers or or you know, and usually it's more than one supplier, where we let them provide their expertise back to us and we say this is the functionally, this is what I'm trying to build and this is what I'm trying to achieve. This is our our initial concept. Can you help join the conversation and help us understand what is the best way to go about this to to achieve the desired results? What I find is a lot of times the engineering teams are trying to just do it all in many ways of getting these production drawings that would be perfect and flawless themselves without actually consulting a supplier first, and they throw it over the wall to their supply chain team who then turn just throws it to their suppliers and the suppliers might see a whole bunch of datums and tolerances that may or may not relate to the final function of the part and they'll just quote you based on what they read. But if you flip that on its head and you say well, before the drawing is even complete, before the model is even complete, if you can engage these suppliers and say look, this is what we're trying to build, can you help me put your by putting your expertise toward the problem and let me know what the most effective...

...way to do this is? In doing that, you're a empowering your supply chain to help you make better decisions for your product. You're letting them provide their expertise that you don't necessarily have, and you're basically letting yourself focus on what you, the product designer, are best at, which is usually interpreting somebody else's requirements for your particular product. Right. So it's all about letting everybody bring their best skills forward toward the project itself and letting people provide that feedback, that let's build that sort of institutional knowledge around the product, what it's supposed to do and how to best achieve that. When you do that, I think suppliers themselves will feel more empowered. They'll be part of your process and they'll help you make decisions that will help make better profits. I don't think very many suppliers are interested in selling you parts that would bankrupt your company, right. They want to sell your sell you your products that will produce an ongoing stream of business, right, even if, even if they can't make as many are as much money per unit, it's always in their best interest to have that ongoing revenue, right. And so, Um, that's the key, I think, for for supply chains today is to involve them as a partner but at the same time making sure that that the the sort of the keys still remain within your organization itself. You're trying to share just enough information with them so that you can make key decisions about your product without wasting too much time, because that's another another problem is that people, I think, spend a lot of time trying to solve problems that their suppliers can solve just like that. And that's that's a big problem that we need to remember where our expertise lies and bringing those experts who who can help solve the problems quickly and effectively. Yeah, I mean, I think like what I'm taking from this, and I think is it is a mindset shift simlar to the P D process we talked about. It's like suppliers are not just like a cost game. It really shouldn't just be like go out and get a bunch of quests and some some components maybe, but generally you use the term trusted suppliers and trusted partners. I'm hearing that more and more now from companies where they're basically building like, I would say, extensions of their company that they work more closely with, and you're going to see more and more of that now with the pressure to deliver faster, because it's not it's not all about costs in the sense of like the raw component cost. The cost of picking the wrong supplier, the costs of not working well together, the costs of missing a delivery is way higher than it being two more expensive to go with the manufacturers, a little more costly, you know, in the traditional cost sense. How do you go about figuring out, like building that trusted partner network that is such an important element for that to work? It's the same thing what you said earlier about building trust in the team and the process is critical to the feedback. It's critically that everyone feels heard. But how do you do with supply chains? There's not just just this like massive risk that you're then gonna get gout on price or something else like. What is the way to think about building that network? I think it's when we're talking about trust of our suppliers, it's all about making sure that they that they feel that they're being empowered to make the decisions to that that work for them as well, right, and I think one of these things it's it's to move away from the concept of suppliers as a as a cost center and moving towards suppliers as a value add when we move away from the idea of costs and we move towards value, right, and this is something that I've I've observed, you know, in Med device industry is someone called value based healthcare, where we're really trying to just help the patient as opposed to the symptoms themselves. And that's kind of the way I would look at this in terms of the product development processes, is that we look at our suppliers as somebody who can really add value to our our enterprise. When I say enterprise, I don't necessarily mean just our organization. It is sort of an environment of multiple organs stations trying to build a product right. And if you look...

...at a supplier, somebody who can add value as opposed to somebody who just is a center of cost, and I agree with what you're saying, in some cases, for commodity products, it's hard to see that additional value that gets added. But for a lot of industries, our suppliers themselves are value adders and when we start looking at who can add the most value to our organization, it's no longer just this race to the bottom for the lowest price anymore. Right some you may have a supplier who costs slightly more than the next, but when you look at the value that they can provide, whether it's in terms of giving you innovative ideas in terms of how to tool us up, how to produce this, how to reduce costs in terms of peace parts, or how to improve value right, how can oftentimes our suppliers can help us understand what is a better way of doing this, what you know, or you know what might be a better material to use, or something like that that would allow them allow us to deliver out of value to our customers, and that's something that is usually outside the realm of expertise of our organization. It's something that Aires themselves specialize in and we need to leverage that value that they can add. Yeah, I think like one of the interesting things that you talked a bit about here there's a bit of like a common theme of like really trying to get the most out of the humans who are involved here, like the people who are involved here. And, Um, the last ways I want to kind of go with this because there's lots of pieces. You think through the thing that you're seeing, to use term quiet quitting, but there's also like a transition happening. Like, if you look at the university level, I went through mechanical when I started in engineering, twenty thirteen mechanicals the number one degree chosen in the university. By the time I finished, software was the number one degree and they had flipped, like completely flipped in terms of ranking. You're seeing that now an industry. People are shifting away from it. People suppliers are like eventually going to go out of business. Like people are moving away. How do how do we think about fixing that problem? Because that's a huge risk. Making hardware way harder is if people don't keep investing and people stop prioritizing. How do we think about the people's side, given like what you said earlier with the P D process, really sounds like it's important in a way. With people supply chain. We're talking about leveraging their knowledge. What happens if all that goes away, or at least starts like? How do you prevent that from making hardware impossible? Yeah, and the idea of a brain drain and cardware is frightening, right, because it's about making making it make me desirable for people, almost making it fun. Gat Right. I can relate my personal experience. When I started in college way back in two thousand and one, we were the first cohort to use three D cads. So previously classes before us we're using two D autocab based products and we were sort of an experimental group. We were using this new tool, new wish tool called pro engineer. Wasn't buy any means new by then, but it was new for our school and the reading I'm mentioning that is because it was a mindset shift where we were no longer making drawings of things, we're making three dimensional models, and then drawing was a byproduct, and I think that itself has influenced how I viewed engineering. From there on forward, I was no longer putting lines on the page, I was building a model of something. That empowered me to quickly make a page full of lines that represented that object, and that was fun to me right. I also saw the power of parametric cab modeling, where you could, if you build a very robust model, you can change a few values and boom, you've got something totally new. That was actually fun and it was something that helped put me through university afterwards as a set of skills a will be able to employ, and I think that's something that has to happen again with the new generation. I spent a lot of time talking to people about model based engineering, which is sort of an extension of the ideas of three d cad, but now extending that beyond just geometric models and now into models of requirements, of models of system architectures, models of tests, and how do we tile that back to the models of the products that we're building in one environment, and that's something that they've referred to called the model based enterprise, where people do feel empowered by the decisions that they can...

...make because they feel they trust that the information that they're seeing is an accurate representation of the full picture, of the full truth. And I was in a conversation with yesterday with somebody who she was having many arguments with people are on their their engineering drawing saying, well, there's too many datums, there's too many datums and and the problem is that these individuals just see these datums as a liability and they don't see how that connects to the rest of the product and it's really demoralizing for somebody who's put a lot of work into a drawing to be told, Oh, there's too much of this, that or the other thing. I think that's where model based methods will help, that that the newer generation they're going to learn to tie the things that they're designing to requirements, to other things that are both upstream and downstream. And just like I found it awesome that I could, you know, change a three d model by changing a few numbers here, we can now change a full product of design too to accommodate different changing requirements and we can all so test those designs and be confident that what we're testing actually satisfies those requirements. That's the promise of model based engineering that I think when the newer generations start to think about things these this way, they're going to surprise us in terms of what they can accomplish. Right and and that's that's been sort of one of my goals, is helping to promote these methods, because I know that in the future it's about putting these tools in the hands of the subsequent generations of engineers, because that's going to be what gives them their superpowers, so speak. Right in the same way that you know, I was part of the Nintendo generation that when they put cat in front of us three D cad, we picked it up very quickly. Right and right now. You know, I used to teach solid works at university. I don't need to anymore because kids can learn solid works from youtube, which is crazy but it's awesome at the same time. And so what we need to do is we need to put these tools in the hands of the new generation and make sure that the development methodologies that we do can let them do their best work using these models and using using the information that is actually there. But it is a huge mindset shift and I think we need to we need to step out of the ways that we've been doing things historically and think about these new methods. Now, I shouldn't say we have to completely step out of them. We've been working towards model based methods for the past twenty years, but it's about asking ourselves the question of do these older legacy methods still serve us, or should we be sort of Cherry picking from the more recent things that we've been more recent successes that we've seen, and understanding there are a better way to do things, because again, I I I shudder to think that somebody who's entering university today is going to be spending too much of their time making drawings because they just don't have to. They just it's pointless. And if they spend too much time doing that, then we're going to see even more of a brain drain because there's they're going to recognize there's better ways of doing things. They're gonna jump to a software world where, you know, things don't seem so ridiculous and just to get things done. Um, you know, I've been in situations where just to share a drawing with my supply chain engineer took a week and they didn't have a computer that could open the cab file and so they had to set up a meeting with another manufacturing engineer just to open the drawing. That is not going to fly for the next generation of engineers and we need to rethink this today to pick for it's already enough flying for even folks who would be like their career staged in stay drafting, for example. I don't think there's become you know, there was resistance to change and there still is some degree, but you start to see these people latch onto that. I brought up Microsoft teams. You started seeing him blashing onto digital tools. Once they see the change, they're like, I never want to print this stuff off again. I never want to I don't want to spend my time. I haven't. They have value they can add in a different place. That is like taking more take their per unit of time. They're adding more value to the business and, like you said, like for the...

...next generation, like they grew up on cell phones, which, like when I went through high school, I got one in the very end. Like the difference that's going to have in terms of how people expect to work together, like seven day turnarounds on communicating something is like a foreign thing, right and be the equivalent of like walking something between St John's and Toronto. is how it would feel. But that still happens. Right. Like I think about the kids. They're gonna be home and going to university, building stuff together, real time Google Docs, and then they're gonna go work and they're gonna work in systems where it might take like two weeks to just get the latest information. I'm not gonna fly what I guess my last question for you is, like, on that side of things, outside of the model based approach, what else should companies be thinking about for that next generation so they actually want to do it? Use The word fun. You're thinking about the trends. You use the example of you go in university and like be able to do something like a more innovative way. Like what is going to make is so that that next generation of high school kids who are looking at building stuff soa cool I want to build physical products, not just software. Like what is it that's going to get them there? I think it's it's letting them see that they can get from idea to product quickly. Right. At the same time, it's not the end of the world if it's not, it doesn't work in the beginning. I think getting people. There's often been this this emphasis towards, you know, doing it perfectly the first time, and you know, there's definitely something to be said for that, or trying to get it as right as you can the first time. But what I think organizations need to be able to do, and this is this is actually a very holistic thing. It's organizations, education systems. We have to start encouraging students to take these risks in in in putting ideas out there and feeling safe to do so right and feeling that you know, if they're going to enter into an organization where you still have you know. But, as they call them, the graveyards right there was those very senior engineers. You want them to be. You want newer engineers to be able to feel heard and empowered and learn from the senior engineers, but that still involves being able to put their ideas forth and take risks in a way, and I think that's the biggest challenge that a lot of newer engineers face, is that they don't want to take risks by by proposing new methods. They sort of want to go along to get along, so to speak, and we need to create environments for and it's not just new engineers, it's it's even engineers who have been there for five, ten years who feel that they their voice is not being heard still because, you know, someone who might be there forty years takes all the air out of the room. That, I think, is going to be a huge are very important shift for for hardware companies. We're facing a huge retirement right now, you know, as the baby boomers are all reaching, you know, definitely retirement age, and the generations that followed are starting to reach into their more senior roles. It becomes a lot harder for somebody who's in a junior position to speak up and put their ideas out when they're just trying to do things the way that things have been done previously. I think that's that's the key, is making sure that organizations feel that they're a safe place to try something different and if, even if it doesn't work, it's all about how do how does the organization handle it after that? You know, how do you perform a good retrospective and learn from these things, because otherwise you're going to have a whole generation of engineers in a few years we won't quite know what to do because all the institutional knowledge is left. And so that's that's the key, is just making sure that people are encourage to take risks. And I got admit we're in it. We we live in a world right now where I mentioned, you know, Youtube and learning cab is a thing, but you know, for a few hundred dollars somebody can also go and buy a three d printer, and that's right there that you know, you can try ideas and it's okay to fail, right. That's that's the Nice thing about about, you know, this additive and rapid manufacturing that we have today. It's okay to fail as long as...

...you learn from that failure, right, and that's the key is making sure that that we create those environments where people can put ideas out, you can try them and then if it doesn't work, then you learn from it, even if it's a if it's a partial failure. It's about being being able to, as an organization, understand what was good what was bad about that and then keep going roll it into the next interation. Yeah, well, there's something interesting like this whole theme. I think it comes back and we talk a lot about, which is culture and like each company's culture is importantly. I always look at the example. Right now, I think Ford is an interesting example. Like legacy, O e m brings in new leadership, really goes hardcore on the V train. There there is a kick back towards for now that people are excited about what they're doing and what they're building. For a long time, for the last decade probably, people are talking about Tesla, only talking about RV and talking about zoos, talking about lucid right. But I think what like the summary of this whole conversation is, I think, how worries but there's like a massive cultural shift as needed, not just for the companies but like for hardware, like the people. And it comes back to supply chain and come back to process and it's going to happen only or another. It's just a matter of how ugly is it, and I think if we if we just embrace it, it can be a really beautiful thing. Man. There's so many things that need to be built that are just being held up by bureaucracy and like the way we used to do it. You use that example of like go along and get along, like that's such a dangerous thing. It makes me nervous, but like taking that and doing that I think can change the whole game and I'm thinking we might need a part two of this podcast mark, because I got a whole bunch more to dive into. But there's a super bross man. I really appreciate the time the insight. I also appreciate the work of doing to get these ideas out there and spending time working with that as and be spending time working with customers, spending time thinking about kids like yourself and two dozen one going into prob you know, one of the next thing. So thank you for all you do for the world anytime. Appreciate Collab is on a mission to accelerate the pace of engineering innovation by giving design teams a better way to work. As an engineering leader, you know it's crucial to empower your team to do their best work. Let collab help you achieve your goals with our web based tool that makes it easy to share and review cad files with anyone, so you can focus on the work that batters without missing a beat or a bolt. Learn more at COLLAB SOFTWARE DOT COM. You've been listening to pure check, a Colab podcast. Keep connected with us by subscribing to the show in your favorite podcast player, and please leave a rating on the show. That helps us keep delivering conversations about how the engineering world is changing and how you can challenge the status quo. Until next time,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (15)