Being an Engineer
Being an Engineer
S7E14 Brad & Aaron | How To Accelerate The Speed of Engineering (Episode 3 of 3)
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this final episode of the three-part series on accelerating the speed of engineering, Aaron Moncur and Brad Hirayama zoom out to focus on the organizational and cultural levers that compound over time.
While earlier episodes explored how individuals and teams can move faster, this conversation tackles the bigger picture—how companies structure their environments, decision-making, and culture to consistently deliver results.
They break down practical strategies like vertically integrating key capabilities to reduce dependency on vendors, staying close to the production floor to improve decision-making, and building psychological safety so teams surface problems early instead of hiding them. The discussion also highlights the power of informal communication, mentorship in onboarding, and creating reusable systems that prevent engineers from solving the same problem twice.
One of the most impactful themes centers around defining ROI early—and having the discipline to pivot or stop projects when the “juice isn’t worth the squeeze.” Through real-world examples, Aaron and Brad show how even well-intentioned engineering efforts can go off track without clear constraints and alignment.
Perhaps the biggest takeaway? The fastest engineering teams aren’t just technically strong—they excel at communication, trust, and culture.
If you’re looking to build a team that moves faster, makes better decisions, and delivers meaningful results, this episode brings together 21 actionable lessons from across the entire series into one powerful conclusion.
Aaron Moncur, host
Subscribe to the show to get notified so you don't miss new episodes every Friday.
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 like cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us at www.teampipeline.us
Watch the show on YouTube: www.youtube.com/@TeamPipelineus
As engineers, you have this idea and vision of what it should be, whether it's a design or a fixture or process, but that's not always what the end result is going to be. And so from the start, if you kind of reframe the way that you're thinking, to really define out is my juice. Is my output worth the squeeze, worth the amount of work it's going to take to get that output? I Brad.
Aaron Moncur:Hello and welcome to another exciting episode of The being an engineer podcast today. I've got Brad here with me again, and we are super excited to wrap up this mini series on how to accelerate the speed of engineering. This is episode three of three. So if you haven't heard the first two, be sure you go back and listen to those two we are covering. I think in total, it's 21 very tactical, practical pieces of advice or things that you can actually do and implement right away to accelerate the speed of engineering. All right, so today's theme for the what seven bullet points we're going to be covering is structural and cultural accelerators that compound over time. The first episode we did in this mini series was mostly about the individual things that the individual contributor can do. And then the second episode was focused more on the team. What are things that the team can do to accelerate the speed of engineering, and today is more of an organizational approach to that same topic of accelerating the speed of engineering. So without further ado, let's dive into it. Brad, anything that you want to touch on before we get started here, let's
Brad Hirayama:get, you know, really clear about what we're trying to talk about here. You know, a lot of people hear about culture and structure, and they think, you know, I'm just individual contributor. What can I do for my organization? But I think it's really important to realize that this topic can be macro. It can talk about an entire business, but it can also go down to the micro level, you know, you and your team, you and the people that sit around you, you and your organization. You know, whatever it is, whatever your situation is, these cultural elements really affect that ecosystem that you are working in. So I think it's important. I think every episode that we've done here is is important. But I think that this is one of the more big picture, important episodes that don't just discount because you're not a leader or you're not one of the decision makers within your group. This can be something that you can affect as well. Absolutely.
Aaron Moncur:Yep, all right. Number One On The List today is to vertically integrate key capabilities, largely to reduce weighting on vendors. Now there are a lot of examples that we could talk about here. This could be something big, like developing your own machining center in your workplace, or something small, like getting a printer so you don't have to rely on outside vendors for 3d printing. But just that one thing that vertical integration makes such a huge difference. Brad, I don't know. Do you have any any practical examples of where you've seen this be true?
Brad Hirayama:Yeah, so this was something that I'm only recently learning how greatly this can affect a business I currently work with, an engineer he started off as a machinist in his career, and he's kind of worked his way from being the machinist to the designer, and now he's the engineer. So he does the whole life cycle. But what we've done is we've kind of structured his time around. He is our machinist, right? So he has all of the internal capabilities now to make us things. And so when I'm talking about being able to design a fixture on Monday, hand him the print Monday afternoon and have something in our hands by Wednesday. That's invaluable, right? 3d printing is great, but what if. It's something that's structural, or it's load bearing, or it needs to be made out of metal. He's our rapid prototyper, you know. So that level of capabilities, having that in house, that saves us a week of time, and in, you know, inevitably, it's, it's saving us cost, right? It's saving us money I don't have to pay, you know, the extra overhead that something like a proto Labs is going to is going to charge me. I don't have to pay for shipping. I really just pay for the material and send the guy home for the afternoon and say, you know, go ahead and machine this for me. But it's something that I've realized has become, you know, such a advantage for an organization like I work in now. You know speed and being as fast as you can, right? That's your ultimate competitive advantage when it comes to being in a startup. And you know being being first to market. And I think to take that one step further, what does being fast mean? Being fast really means, how can you control your critical path, right? How can you control the different aspects of your development life cycle? And I think that this is just, is just one of them. If it's something that you touch all the time, then it makes sense to bring that capabilities in house.
Aaron Moncur:Yeah, excellent. All right, moving on to number two, we've got be hands on by visiting the production floor. And this is all about being physically present with your team, the people who are actually doing the work on the floor. That could be maybe you as a manager being there with your engineers, or you as an engineer or manager, being on the literal factory floor with the workers who are the technicians, the operators who are building things or doing the assembly work or doing the testing work. I remember for a long time, pipeline was completely virtual for probably the first nine years of our existence, we were 100% virtual. Everyone worked out of a home office. We had a small space here in my house. We converted a bedroom to a pipeline workspace, and so if we had to build something, team members would sometimes come over here. But we really didn't have a central space where everyone met. We didn't have an office, right? And then, ironically, as covid started and everyone was leaving offices, that's when we moved into our first office. And I remember one of our he was a contractor for us, and we were just, like, building out this first office space that we had. And this contractor, he just kind of informally approached me, just making small talk, kind of and said, Oh, So Aaron, where, where's your office going to be in this new space? And I was like, what office? I'm not going to have an office. We're I'm just going to be out there with everyone else you know. And like, his assumption was that, oh, the owner of the company is going to have this corner office right where he sits and perches and looks down upon everyone. And like, I had never even considered that, like to me, I don't want to be separated from the rest of my team. I want to be there with them. And like that makes such a huge difference when you're there in person, seeing how things are actually being done, and you can make, you know, corrections or provide guidance in real time, huge lever for accelerating the speed of engineering. If your company helps engineers design, build or manufacture better products, we should talk at PDX, the product development Expo, companies don't just exhibit. They teach practical training right at their booth. Engineers walk away with new skills, and companies build real relationships with the people who use their tools and services. The result is high quality connections built through real technical value pdx 2026 is October 20 and 21st in Phoenix, and booth selection is first come first served. Many are already reserved to learn more about exhibiting. Email us at PDX, at Team pipeline.us,
Brad Hirayama:yeah, I have two points to this, and I think it's, you know, the first one, I've always worked in startups, and so I really haven't experienced the true kind of big company managers are behind doors, you know, type of environment. I think I've always been a part of these roles where, you know, it's like, like, right now I sit right across from my manager and sit, you know, two desks down from. I'm our VP of R and D, and, you know, so if I have a question, if I have a, you know, something that needs a quick decision, I can just stand up and say, Hey you, you know, answer this question for me. And I think that, like you're saying speed, that's, that's really, really powerful to be able to collaborate in that way and have an environment where that type of collaboration is encouraged and it's welcomed, I think is so great to have as a culture, you know. And number two, I really want to tell this story, because I really like this story. So have you heard of how Toyota differentiates their design principles for their Lexus brand.
Aaron Moncur:Have you ever heard of that? No, I don't think so.
Brad Hirayama:So I love this story. There's a there's a really great, like, short podcast series on this, and I think it's called wait and see. And I've listened to it like three or four times. But the Lexus ethos for for design is all of their design engineers have to live the experience before they start designing. And so one of the things that they were, that they were describing in this, in this story, is Lexus was really the first company to pioneer kind of this, this cockpit style of elegance when it came to sitting in the driver's seat, right? And not like the race car type of cockpit, it kind of fits you, but the cockpit style of everything is accessible to you in very short amount of motion. And what that came from is they had a designer for for Lexus, who, when kind of looking at and kind of early prototyping of some of their some of their vehicles said, I don't like the fact that I need to reach in in order to do anything. And that's what pioneered this. Like cockpit style infotainment Center, where everything is within reach, everything can be, you know, changed and manipulated without having to reach or be any type of uncomfortable. But this concept of, you know, really go and see, go and do, be a part of your customer journey or your operator journey, you know that not only are you going to get right the first time right if you're the one who's actually a part of it, but you're really going to be able to understand and empathize where your end customer is is coming from. So I think this is a really powerful lesson that anybody that can learn, you know, get get yourself out from behind your screens, you know, be the person that builds or is talking to the people that are on your manufacturing for it, that's where the greatest learning
Aaron Moncur:is going to be. Yeah, most of the listeners for the being an engineer podcast, we're building hardware, we're not software engineers. For the most part. I think for software, it's less important that you be in person because of the nature of software. I'm not saying it's unimportant. I still think there's value, just from kind of a more like human or empathetic standpoint, to being in person, but maybe less important for software. But we're hardware builders, and it is really hard to effectively manage hardware builds remotely, so get in there, be in person with your with your team. All right. Next one, number three, build trust in psychological safety, so people ask for help and surface problems early. I remember one of the best compliments that I have ever received was from one of our engineers, and he said to me, he said, Aaron, I have worked at jobs where I was not comfortable speaking my mind and sharing critical feedback to my bosses because of fear of judgment or repercussioned. I never feel that way around you. I feel like I can tell you exactly what's on my mind without any filtering, without any fear of judgment or repercussion. And I just thought that was such a wonderful compliment, because that's exactly the kind of culture that we've tried to develop here at Pipeline.
Brad Hirayama:It Hold on. I love that. I've gotten that from you from the day that I met you, Aaron. But I'm really curious, how do you foster that, like, how have you actually built that environment? Part of it, I know. Know, is innate in who you are, right? So that portion of it maybe, you know, okay, maybe that's 50% but the other 50% of it has to be, you know, creating that ecosystem around you that allows people to come in and feel safe and feel, you know, the ability to speak up and ask questions to not feel like they're going to look stupid or judged. You know, how have you done that? How have you really fostered that? I think
Aaron Moncur:it's an aggregate of many, many small situations compounded over time. One thing that I've always been very intentional about is when, when someone comes to me with bad news, I don't berate them, right? I thank them for sharing that bad news. I remember one of our our young engineers had made an expensive mistake, probably a multi $1,000 mistake. Specified the wrong material for something, and it got built out of the wrong material. We had to go back and and remake it. And once he discovered the mistake, he came to me right away, and he told me, and I said, Thank you so much for letting me know. I get it. Mistakes happen. I've been there myself, and you can see the relief on his face right when, when he had that experience with me, and so little experiences like that compounded over time, I think is what adds up to that type of culture. I had another experience just recently where a very, very senior engineer was working on a couple of projects at pipeline, and he he realized that he wasn't going to be able to finish everything on time, two very large projects that he was the principal engineer controls engineer for. And at a certain point, he was like, no matter how hard I work on this, I just don't have enough hours in the day to get both of these things done and meet the customer's deadline. So he approached me and the team, and he didn't say this at the time, but later on, months later, he shared that he was a little nervous because he was newer to the team at that point, and he didn't want to come and be like, Guys, I can't get it done. I need help. You know, I need someone else to step in. And it was not an inexpensive proposition, by the way, that his he did come with a solution, which was great. And his solution was, we need to pull a contractor in. So we ended up having to pay a contractor to do work that we thought we were going to be able to cover just ourselves within the team, which was, was not cheap, right? But when he came to me and the team with that and had laid it out and said, Here are the facts, you know what? What should we do? Nobody was judgmental, like we all understood where he was coming from, we were grateful for at least bringing a potential solution, which we ended up doing. And then months later, we were talking as a team, and he brought up how how much that had meant to him, just the fact that nobody judged him for it. Everyone was supportive and like showed gratitude that he brought a solution to the table. So again, one more example, just because this one just happened. I just heard about this the other day. This was someone who does not work at Pipeline, but a friend of mine, and he recently got a new job at a company, a manufacturing company, and he's in charge of of of a certain area of of the factory, and he noticed that there were some discrepancies in how that area was being actually being managed, and how it's supposed to be managed. And so he'd approach his boss multiple times and he said, Hey, I noticed that, you know the like the protocol, the SOP says, do this, but what's actually happening is not that, are you aware of this? And he'd ask questions about that. Why are we doing it this way? And I know this guy, I'm sure he approached his boss very tactfully about this. He's not the kind of person that would, you know, throw mistakes in other people's face or anything like that. And the response from his boss was awful. His boss would get angry, like, angry with him, you know, like, be like, Why are you bringing this to me? You're not doing a good job. And, like, you're you're not a good employee. And I mean, he was doing exactly what he should be doing, and the boss probably felt threatened, because here, you know, high level, he's in charge of this area, and it's not being managed correctly. So anyway, just like what I was saying earlier, it comes back to these, these individual, they might seem small experiences that compound over time, and in the end, that's, that's how psychological safety is built. Yes. Pipeline now offers procurement of custom machined parts at significantly lower costs without sacrificing speed or quality. We design and build custom machines ourselves, so we consume a lot of precision machined components over the past several years, we developed a proven overseas supply chain to support that work, and in 2025 we successfully piloted that capability with select customers. Now we're opening it up more broadly. If you'd like to see how our prices and lead times compare. Send us a drawing or two for quote, visit team pipeline.us, or message me directly on LinkedIn.
Brad Hirayama:Yeah, you know. And I think that it really goes both ways. And you have you gave a really, really good, both positive and negative example where leadership gave the employee the opportunity to build that trust, right? And then, on the flip side, right, you basically, you know, your, your friend situation, leadership is not giving him, yeah, the opportunity to build that trust, right? And so, you know, it kind of takes, it's a it's a two way street, right? It takes both sides of the equation to build this psychological safety. And as engineers, you know, we're naturally we're curious. We like questions, right? We also don't like to be wrong. We have egos. That's part of being a really good engineer. I think you have to have a level of ego. You have to have kind of this, this bravado to you in order to be a good engineer. But you have to learn how to manage that, you know, and that's part of kind of maturing and growing within your engineering
Aaron Moncur:career, yep. Okay. Number four, this is related to the psychological safety, but it's using informal forums where people feel comfortable raising ideas and concerns. So we all have our formal meetings, right? Like we have a daily huddle that we do at pipeline. We have weekly team meetings. We have a meeting very beginning Mondays every week called Launchpad, where we everyone talks about what they're going to accomplish that week. These are formal settings. I mean, nothing in pipeline is terribly formal, but within the context of pipeline, these are formal forums. It is important to have informal forums as well. I can't remember which guest it was on the podcast, but he used this word, he was British, and he talked about tea times that they have at their company where, like, I guess, literally, they take a break and a couple of people have tea together, right? And they're just talking, you know, they're in the break room chatting, or whatever water cooler conversations you might refer to them as, but having these and they can be intentional, or at least intentionally facilitated, having these informal experiences or interactions where people can be a little bit more loose with with or unstructured with their conversations. I remember that when I worked at the company, prior to starting pipeline, I was I was really into photography, and there was one day that I was at work, at my desk, middle of the day, and I was looking at a photography website, just checking out some photographers work. And the argument could be made that I was, I was doing that on on work time, right? It was like three minutes, probably, that I was on this website, and I had a one on one with my my boss that week, and he brought it up. He said, Hey, I I noticed I walked past your desk the other day that you were looking at this photography website and not doing the work that you were supposed to do. And that made me so angry and like it made me feel untrusted and almost violated, in a way, like, I guess I get where he was coming from, but it did not inspire in me the confidence that that I could just informally take a few minutes off. Now, in this case, yeah, I was looking at a photography website, but what if I had just been chatting with an engineer in the hallway? Contrast that just, I think it was yesterday I was, I was sitting on a couch in the office, and just happened to overhear two of our engineers in our conference room, and they were talking about, think they were talking about real estate, and like a real estate deal that one of them was looking at, or maybe it was a relative that was selling a. Piece of property, you know, I had nothing at all to do with work, and I remember thinking to myself, I am so grateful that my team feels comfortable having completely engineering irrelevant conversations right here in front of me, you know, in the office. And this is where it goes back to the psychological safety, but you have to make people feel safe that they can just take a break and talk informally about whatever that conversation might start out focused on a real estate deal, but it might veer into work afterwards that ends up being an important conversation to have,
Brad Hirayama:yeah, so this is incredibly, I think, a relevant topic to our current kind of workforce state. So there's a lot of companies now that are forcing return to office, right? So I started working right before the pandemic. 2018 was my first real big boy job, and so I got a little bit of taste of what the everyday in the office type of work was like. And then once the pandemic hit, you know, I had a little bit of taste of what work from home every day was like. And I think the key difference, to me is you talk about more of like, informal settings. So informal settings, you're not necessarily in a conference room. There wasn't a set time, so you're not trying to be on time. And everybody's there, everybody's looking at the screen or looking at you, whatever it is, I think in these informal talks also lower the level of stakes in the game, you know, so there's, there's no reason for me to feel like I need to be super professional all the time, or I only can talk about safe topics that I know, that I can actually hold conversations about. And, you know, it just it allows you to be a little bit more loose and a little bit more free with what you what, what you want to talk about. And that's that's when the best ideas come up. That's when you know you can ideate and talk about the podcast that you just listened to, that you just listened to, and you never know how that's going to affect what you're currently
Aaron Moncur:working on? Yeah,
Brad Hirayama:you know, I've been back in office full time now since 20, you know, probably late 2020. I remember having to go through all of these like protocols to get back into the office. But you know, really, I was remote for like, six months, and I couldn't, I couldn't handle it. That's just not how I work. But, but it's for this reason. I think that some of my best ideas and, you know, getting to know people, I think, is so important that being in person really is the only way. Yeah, yeah, okay.
Aaron Moncur:Next one make trust part of onboarding by assigning sponsors or mentors to new team members. I know at pipeline, we have a an onboarding process, a checklist that we go through right to teach people all the new our systems for doing things, our SOPs, or files, storage locations, the technology, all this stuff, and it's kind of a lot to go through. And we have videos, and we have SOPs that people can read and watch, right? But we always assign a mentor to that person so they're not just going through all of this on their own, they have someone there, literally side by side, who's going through all of this with them. So they can ask questions in real time, and it just it gives them a friend right away, right some of the they can turn to and ask questions, whether it be a technical question, something on about a process or or even just like a personal question, or something about the culture, whatever, things like that, that's been really helpful. I think, Brad, I don't know, do you have any any examples like that? You know, I've
Brad Hirayama:never experienced this. I think the closest experience that I've had to this is one of my first jobs coming out of college. They had everybody that was starting during that period of time start on the same day. So you kind of have this like cohort of new employees, and you walk through the employee handbook and all the SOPs and stuff together, but then you get handed off to your manager, and it's kind of kind of just a go. But so this is a really interesting topic to me, because I can see the value. I've just never lived the value. And, you know, I I've been the new hire. I've been the new person. My. Many times. Now, actually, I'm on by 1/4 different company in my career. And, you know, I really do think that that ramp up, depending on the company, can be really steep. And if you don't have anybody to go to, or you don't have somebody that you feel like, you can just say, I have no idea what I'm doing two I can see how that can store everything down like this is an awesome point that I'm going to keep in the back of my mind. So whenever I do onboarding, you know, eventually in my in my career, this is definitely something that I'm going to implement.
Aaron Moncur:I have a bad experience story that I can tell here as well. This is where pipeline did not do a good job of this. There was a new engineer who we had just hired, and at the time, we were just insanely busy and couldn't keep up, which is why we hired another engineer, and even though we have this process of like a mentor, helping the new hire get spooled up, we probably didn't do a great job of it. We gave the new hire. Here are the SOPs. Here are the videos to watch. No one has time to like, sit and hold your hand through this. We didn't phrase it, you know, like that, but we we probably didn't have a person there enough with with this new hire. And now this is an extreme case, and there's no way to know if things would have turned out differently if we had had someone that was like, really there in person walking this new hire through. But after a week, this guy quit. And really, he never really gave me a great reason for why. He just said, it's not, not the right fit. I'm out peace. Sent me an email Monday morning, and like, no advance notice. So again, you know, maybe this would have happened anyway, but it definitely stuck in my mind, the fact that we didn't really do a great job, like onboarding this person, and then he just, he just pieced out,
Brad Hirayama:yeah, that's a great example. I think, you know, really, it's up to the company, you know, to help to build that to build that trust. So, yeah, I haven't had that experience, but, you know, I've definitely been the new guy that's gotten lost in a building on my first day, yeah, because I took a run, a wrong turn, and it would have been nice to have somebody there,
Aaron Moncur:all right, number six build libraries of reusable assets. So these would be things like document templates and CAD models and things like that to accelerate recurring work. Brad, I imagine that in different places you've worked, there have been templates to reference, or, you know, starting CAD models that were whatever, 10% done, 50% done, that you didn't have to start from scratch every time you had somewhere to start, at least. Is that true?
Brad Hirayama:I think that this is the biggest value that you bring to the table as you progress in your career. You know, I think one of the key, kind of, the key principles to my engineering work is to, you know, don't solve the same problem twice. And I think that that's, that's a that's key, because time is of the essence, right? We're talking about speed. We're talking about time. I'll give you a really quick example that I that I just finished working on. So there was a, like a process characterization that needed to be done. And, you know, there was a lot of talk about what we needed to do. And, you know, should we do a doe? Should we do that kind of a full, big study? Does it need to be six sigma and all of that kind of stuff? And, you know, the the in the end, right? No, nothing needed to be that far in the, you know, kind of the technicalities. But what we needed was just a simple process characterization study, study to be done back in my, you know, a couple of years ago, when I was learning process characterization and learning how to do these studies really well, I had written a script in one of these statistical analysis programs. I had written a script that helped me determine the sample size and kind of build the study for me. And this script is something that I've carried with me, and I was able to put in my values, run the script, it spit out everything that I. Need. I was able to then write my protocol, execute the test, write my report, all of that, within a couple of days. And so here I show up, you know, a couple of days later, and say, Okay, here you go. It's done. Can you can you sign off on this? And everybody's like, whoa, right. How did you do that so quickly? How did you know you know what to do? And everything and and it's exactly this. I already had a template. I already had everything pretty much shelled out for me. I needed to put the detail in there, give some thought to how I was going to do things. But it was just execute after that. I wasn't trying to reinvent the wheel. Yeah, and I think I've seen this so many times in so many different aspects of of my career, right? CAD files. You know, nothing. There's really nothing out there that hasn't been designed. There's not too many novel problems nowadays. And so is there something that you can use, open source, on the internet, that you can start from? One of the things that I really like is McMaster has all of their CAD files, right for kind of modeling things like screws. Well, I've taken those CAD files and and cut off the parts that I don't need and then added things that I do need. It's like, well, here you go. You know, I didn't have to reinvent the threading, right? So, you know, it's, it's little tricks like that, that, I think you gather as you go along in your career.
Aaron Moncur:That's a great pro tip with the McMaster. I think a lot of power users use that tip. They download the McMaster file, modify it as needed, and then, you know, they have something they can use. It was funny. We had a CAD club class. We have this volunteer program, CAD club at Pipeline, where we teach middle school and high school students about CAD and engineering and life. And we had CAD club last night. And we have our advanced students who are doing some design challenges right now. And this this term, the the theme I've given to this design challenge is you have to design something that's manufacturable. Because up until now, these students have 3d printed everything, and there's really not been any instruction or focus on design for manufacturability. So whatever the design has to be machinable, that's the rule. And so we were talking about that, and McMaster came up, and I said, Oh yeah, go to McMaster. They were asking me, what's a retaining ring? Another part of the design challenge was use a retaining ring to hold a ball bearing in place. And so they they go to McMaster, and they're looking for a retaining ring and and one of the students notices the download button next to the retaining ring. He says, you can download these models. And he was just blown away, like so excited that he could download all these models from McMaster. It was, it was a cool moment to see that. Because, yeah, as engineers, we just, we all love McMaster because they they give us free CAD models. Yep.
Brad Hirayama:And you know, pretty much every company out there, if you're going to be working with their stuff, they'll send you a STEP file. I think that's the that's the key that I've found, is it never hurts to ask. And a lot of these salespeople, if you say, Hey, I've already ordered 1000 of your thing. I just need a file so I can fixturize it or something within my process, they'll be more than happy to send you a Stewart file. So it never hurts to ask.
Aaron Moncur:And going back to the libraries right of reusable assets we have, we do machine building, and so we have libraries of like machine frames and different robots that we've used in the past, and vision systems that we've used in the past, right? And all these, these components that we don't have to go out and search for the supplier and request a CAD model or download CAD model, download a CAD model, we just we have them already in our in our system, in our file locations, and it's easy to just pull it out and stick it into the model. All right, we're down to our last, our very last, not just the last bullet point of this episode, but the last bullet point of our our three part series here, and that is, define ROI early and manage projects against it, including being willing to pivot or kill projects quickly. Now I don't have a great example of this exactly, but I have an interesting example of why this is important to do, not really engineering related, but it's, it's, it's relatable. So Brad and I recently have started pipeline Media Lab. You've all probably heard about that. We did an episode on it, and I think that I'm a creative trapped in an engineer's body. I say trapped. Like it's a bad thing. It's not, obviously, but I am Creative At Heart, and one of the things that I have really grown to love in the past couple of years is call it video editing, videography, cinematography. I've really gotten into it, and I love it. And I was buying a new tripod recently and looking at all the different tripods out there, and I had this kind of soft budget in mind of what I was willing to spend on this tripod, right? And I found one that seemed to satisfy almost all of the requirements that I had. And it was, it was a little bit more than I wanted to spend. I was like, I don't know. I don't know if I can justify spending that much, right? Like thinking about the ROI, right? If we say buying a tripod was my project, and I had an ROI that I had in mind, I had a budget in mind, and I look at this tripod, I don't know. It's a little bit more than I want to spend. I was just about ready to pull the trigger, and I came across a different tripod, one that I'd never seen before, and it was the most beautiful, sexy Rolls Royce of tripods I had ever come across. It did everything I wanted it to be, and it was really well engineered. I mean, just some like, beautiful design, very, very functional features, does some things that other tripods just can't even hope to do, and it was way, way more than that soft budget I had set. And so this is why it's important to have an ROI and stick to it. As soon as I saw this thing and learned a little bit about it. I was like, here's my credit card. Please take my money. I want this. And like, the there's a difference between wanting something and needing something, right? And really, like, we should be governed by what do I need to have, not what I want to have. And that's where the ROI comes in. If we can't justify the ROI, then it's anyway we should, like, govern it that way. But a want crept in, more importantly than the need. I was like, yeah, here, please take my money. I want this thing so
Unknown:bad, man, that thing better fly or something like that.
Aaron Moncur:Yeah, I won't say how much it was. It was an embarrassing, stupid amount of money. But man, do I love it. Every time I use it, I'm happy well, and you know,
Brad Hirayama:that's that's worth it. Your your return on investment, there is your happiness.
Aaron Moncur:That's true. So different. Why?
Brad Hirayama:Yeah, it was a great investment.
Aaron Moncur:It sounds like thank you for enabling me
Brad Hirayama:on this point. You know, I currently operate in a team that uses the saying, is the juice worth the squeeze, great thing. And I think that a lot of times as engineers, you really, you know, we talked about this, I think in the last episode, in episode two, where, as engineers, you have this idea and vision of what it should be, whether it's a design or a fixture or process, but that's not always what the end result is going to be, And so from the start, if you kind of reframe the way that you're thinking, to really define out is my juice, is my output worth the squeeze, worth the amount of work it's going to take to get that output? You take that time upfront, and you keep asking yourself as you go through, oh, it's going to take me another$10,000 or it's going to take me another three weeks, right? Is that amount of squeeze worth the juice that comes out at the end, you know? And I really like that, that framework. Everybody likes juice. Not everybody has squeezed oranges to get their own orange juice. But keeping that in the back of your mind as part of your planning is the juice worth the squeeze. I think, becomes such a great framework to make sure that your ROI matches that the phase of the company or the
Aaron Moncur:project that you're working on. Yep, we had a project a while back. It wasn't a very big project. It was like 30 grand or something, building this fixture, and we had a younger engineer who was kind of leading it, managing it, and arguably, more than arguably, you know, probably definitely there should have been a little more oversight from from someone else, more senior on the team. Anyway, this this younger engineer, bless his heart. He just wanted to deliver a perfect fixture to this customer. He wanted it to work so well. We have a mission at Pipeline, which is we build equipment that manufacturing and R D teams love to use, not that they tolerate using, but that they love. To use, and he was trying to fulfill that mission. So, you know, kudos to him for that. Nevertheless, he He kept trying to make it better and better and better. And he was like upgrading components on it and using better motors and trying to add functionality that wasn't part of the requirements. And like I said, there was probably not enough oversight from others on the project, but I think we ended up, like, spending twice as much as our budget allowed, which we just had to eat, right? That was all on our dime. So had someone stepped in earlier and been like, Okay, Mr. Engineer who's working on this project, all of these extra bells and whistles that you're putting into this is this, does this fit within the ROI that we as a company have to do this project? And the answer pretty clearly, pretty quickly would have been no, it doesn't. But yeah,
Brad Hirayama:yeah, I think it's really important to remember that killing a project, or saying no to a project, or taking something only so far, that's not failure, right? I think failure, like you're like in your example, is, is funding the round one. Yeah, for too long. Yeah.
Aaron Moncur:Ian mccather and a buddy of mine. He's been on the podcast several times, one of the OG speakers at the original PDX couple years back. Super smart engineer. He posts these, these little like engineering rules on LinkedIn regularly. I can't remember what it's called. It's like Atkins laws of spacecraft design or something like that, but they're really good. And one of them states, I'm paraphrasing, states that there is no justification for making a product one bit better than the requirements call for. And I thought, Oh, that's so good. Because how often do we as engineers want to take one more step, make it just a little bit better, get that much closer to perfection, but the requirements still justify it, and the ROI for it probably doesn't exist. So I think that's such a good a good route. Just another way of saying, Does the is the juice worth the squeeze? Right? Yep, yep. I love that. Okay. Well, that takes us through. The end. We're now at the conclusion of our three part series. I thought this was super fun, and hopefully all of you listeners out there, dear listeners, really were able to learn something of value from this series. Again, this is taken from, you know, over 300 different interviews that we've done on the being an engineer podcast, and some pattern recognition, just pulling out commonly discussed best practices for making engineering better and faster. So we're standing on the shoulders of giants here, and hopefully this is helpful for all of you out in the audience?
Brad Hirayama:Yeah, I'm really curious. You know, we've talked about 21 different points kind of grouped into, kind of the topics, you know, purely for individuals, for teams. Now we're talking about culture, but for all the listeners out there, and Aaron for you as well. If this is something that you know you want to kind of boil it down to, but if you had to kind of pick your favorite, what do you think it would be?
Aaron Moncur:Your favorite point? My favorite? I right or wrong. I might be shortchanging myself, but I always feel like I'm not a superstar engineer when it comes to, like the technical part of engineering, mechanical design, great at that. I can hold my own and compete head on with anyone out there in mechanical design, but I don't do any programming, no software, no controls. Forget about electrical. You want to break something electrical. Bring it to me. I will break it for you. So my skill set is pretty narrow, and as a result, I've, maybe it's just head trash, but I've, I have this like belief, this limiting belief that I'm not that good of an engineer. So all of that, to say, where my mind always goes is like the soft skills, the communication, the trust, building, the culture. And for me, that's probably the most important part, is like all there are all these technical things that you can do, and we've talked about many of them, but, but for me, it usually comes down to the people and just communicating well and making sure people feel trusted and respected and valued. I think that's the most important part. Yep.
Brad Hirayama:Aaron, you know, it's interesting, if you look at the 21 points that we had all the way back to the first one of this series. Not many of them are pure technical like not many of them said, you know, be the best CAD designer. Get your SolidWorks experts license. Yeah, most of these are about soft skills and communication and building trust and building respect. And I think that that is very indicative to the shift that we are seeing in current engineering teams, the old style of of leadership within engineering that says, you know, you just need to be technically sound. You put your head down, you do the work that's given to you. You know, nine, nine to five, and even on home, you know, I think that is that's antiquated. It's not what the current workforce is like. And I think that the quicker that we can make that point known, when it's the reason that we're doing this, but the quicker that we can make that point known, I think the more efficient teams are going to become, and that, in of itself, will speed
Aaron Moncur:up engineering. Amen. Brother, all right, Brad, any last thoughts before we end this wonderful, wonderful, three part series?
Brad Hirayama:I don't think so. I think I had a great time talking about this. I can't wait for our next series and our next topics, but I really want to hear what everybody out there has to say. So leave us a comment, send us an email. But let's talk about this. What speeds up engineering in in your world, whether it's for yourself or for your organization?
Aaron Moncur:Yeah, these episodes, they get published on all of the typical podcast platforms. They go out on YouTube, and we always release a couple of short teasers of the episode on LinkedIn as posts as well. So for sure, LinkedIn and YouTube leave a comment there, reach out to us. We'd love to hear what what was useful for you from these episodes and what you'd like to hear more about, whether that be a topic or a guest or a technology, we want to hear from you, so we look forward to
Brad Hirayama:it. All right, have a good one until next time.
Aaron Moncur:All right. See you, Brad. 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 advanced manufacturing processes, automated machines and custom fixtures, complemented with product design and R and D services. Visit us at Team pipeline.us. To join a vibrant community of engineers online. Visit the wave. Dot, engineer, thank you for listening. Being an engineer has more than 300 episodes, and you don't have to listen to them in order. If you're dealing with a specific challenge right now, there's a good chance we've already interviewed an engineer who's been through it. You can jump around, search by topic and listen to what's most relevant to you. See you on the next episode, you.
