Being an Engineer
Being an Engineer
S5E42 Brad Hirayama | How to Accelerate the Speed of Engineering, Episode 6
This is a continuation in our ongoing series about How to Accelerate the Speed of Engineering. The discussion covers topics such as the importance of planning and execution, balancing problem-solving and asking for help, the role of checklists, the impact of leadership and team culture, effective communication and collaboration, risk management and building relationships, and lessons learned from past challenges.
Main Topics:
- The balance between speeding up projects and avoiding unforced errors
- The use of tools like Notion and Loom to improve productivity and efficiency
- The role of leadership in building a strong team culture
- Approaches to risk management and the value of building relationships
- Lessons learned from implementing new processes and tools
About the guest: Brad Hirayama is an experienced engineer and program manager specializing in medical devices, with a focus on new product development (NPD), biomedical devices, and process validation. Currently a Staff Engineer, he drives innovation in electrophysiology (EP) products. Brad's background includes roles at Abbott and NuVera Medical, where he contributed to the development of catheters and other vascular technologies. He has expertise in design thinking, FDA compliance, and leadership, all while embodying a passion for connecting people and technologies in impactful ways.
Links:
Brad Hirayama - LinkedIn
About Being An Engineer
The Being An Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.
The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us
Do you want to automate but don't have time to develop the skill set, try our Easy Motion hardware and software bundle. It's like T slot extrusions or automation programming. The functional elements are already built for you. All you need to do is connect them together to create fast, easy and endlessly customizable motion solutions. Learn more at Team pipeline.us.
Brad Hirayama:When you talk about speed, you talk about optimization and efficiency, the worst thing that you can do is create a barrier that they have to jump over.
Aaron Moncur:Hello and welcome to the being an engineer podcast today, we're speaking with Brad Hirayama, who is an experienced engineer and program manager specializing in medical devices with a focus on new product development or NPD pilot manufacturing and design process validation. Currently a staff engineer at synaptic medical Brad drives innovation in electrophysiology products. Brad's background includes roles at Abbott and Johnson and Johnson, where he contributed to the development of catheters and other vascular technologies. His experience in biomedical device design, design, control, methodology and leadership, all while embodying a passion for connecting people and technologies in impactful ways. Brad, welcome to the being an engineer podcast.
Brad Hirayama:Super excited to be here. Thank you for having me.
Aaron Moncur:Well, I echo your comments. Super excited to be here for a couple of reasons. One, my company has done quite a lot of work with catheters, including EP catheters, so it's cool to talk with someone in the industry who's actually developing the devices. Typically, we're more on the the like testing and manufacturing side of that equation. And the other reason is, I hope you're okay with me mentioning this. We're both from Hawaii, and it's it's not super common that I get a chance to talk with someone from from back home, so this is just a huge treat for me.
Brad Hirayama:Yeah, no. And Aaron, I 100% love the connection. We are both from Hawaii, the island boys, we, you know, really like to support each other. So thank you for reaching out. I'm really excited to be here. Can't wait to dive into this topic today.
Aaron Moncur:Absolutely, it's too bad we're not here in person. I could have brought some spam Musa bees for after the recording. But perhaps another time.
Brad Hirayama:Yeah, maybe another time.
Aaron Moncur:All right. Well, this is a continuation in our ongoing series about how to accelerate the speed of engineering. So let's get into that before we get into, you know, I'm kind of of the opinion, actually, I'm I go back and forth on this. On one hand, I feel like there, there are opportunities to speed up projects. On the other hand, sometimes, I feel like every project kind of inherently has its schedule, and all we can really do, as opposed to accelerating, accelerating that schedule is, is just not screw it up, is not, not, not imbue it with unforced errors. So I don't know exactly which one I believe more. Maybe it's it can't really be both, because it's almost one or the other. Anyway, there, are things that we do as engineers, on occasion, unfortunately, that slow projects down, as opposed to looking for ways to speed them up. Can you talk a little bit? What are some things that you have seen in the past where projects have been slowed down due to unforced errors, things that you know there were just mistakes. Call them mistakes.
Brad Hirayama:Yeah. So, you know, I think a lot of this comes down to how do you start the project, how do you make that initial plan, and how can you make that plan robust enough to make sure that you are executing consistently towards that, that end goal, one of the things that I I just I love the saying right now, but the saying of slow is smooth and smooth is fast. I think that it really makes sense whenever you're approaching a project or a new our new problem, to really take that time to slow down at the beginning and allow the organic kind of project timelines to play themselves out, but to also give that a second look to make sure that you know you identify the bottlenecks and the risks up front that you clearly define out your scope, so that you know you don't have a. Bunch of scope creep in the middle of the project, and actually, on the other side, make sure that your scope is defined and robust enough that you don't have to add requirements when you're at the middle of that project. I really do believe that you plan first, you plan robustly, and then you execute. You know, you're really going to have this kind of smooth, complete project. You know, you're not going to have too many robots, not not saying you're not going to have issues, but if you plan up front, those issues will come up. You'll be ready to take them on, and you'll be able to, you know, figure it out. Execute. Move on.
Aaron Moncur:Yeah, I think planning is super important. Just like you said. One example that comes to mind, a small example here is I like to plan out my week, usually like Sunday afternoon or maybe Monday morning before I really start on the week's work, I'll take an hour or so and I'll just plan out what do I need to accomplish this week? And then I'll put those things in my calendar. And so by the end of that hour, my calendar is mostly full, and not necessarily full with like meetings that other people have scheduled with me. Some of those are meetings other people have scheduled with me, but I'd say at least half, maybe more than half, are times that I have intentionally reserved for myself to accomplish these things that I know I need to get done. So I've found that planning out my week in that manner and putting those items in my calendar really makes the process so much smoother, and I actually accomplish the things that I know I need to accomplish, because at the beginning of every day, I'm not asking myself, hmm, what should I be doing today? It's already there right in front of me, and all I have to do is execute, execute, execute, check those boxes all right, I'm done now, ready for the next day,
Brad Hirayama:Right? You know? And we're going to touch on this topic, I think, a little bit later on. But I do believe that speed to speed to information, or speed to being able to get started and actually be doing things is such a valuable time saving skill that if you can implement things like you're saying for yourself, where you plan out your week, you know, you plan the heads down time, you plan the prototyping time, it really, it doesn't allow you to have, kind of the deer in the headlights. I don't know what to do. Everything's such high priority. What do I do right now? You've taken away that guessing time, and you've you've just allowed yourself to to execute. And that's just like, what in in an hour on a Sunday afternoon? You know, it's, it's not that much time in the grand scheme of things, and it just allows you to continue to push forward.
Aaron Moncur:Yeah, yeah, that hour probably saves me eight hours, and helps me ensure I get things done that maybe I wouldn't have had I not taken the time to intentionally plan that out. Has there ever been an experience that you've had, or maybe use a you've observed where an engineer was working on something, maybe an r, d task, maybe developing some new process, maybe working through some equations, whatever, and you or whatever engineer you may have observed just got stuck. And because we're engineers, we love solving problems, right? That's why we became engineers. We like to solve problems this this engineer just keeps, keeps battling against this problem, keeps trying to figure it out, but just isn't really making progress, and it ends up taking a lot longer than he or she should have to make progress and just move on to the next thing. Have you ever seen or experienced that kind of situation, and what do you think is the right balance for spending that time yourself, to try to figure it out, to build that figure it out muscle, versus just asking someone else, hey, I'm stuck here. I'm pretty sure you know how to do this. Can you just show me what to do here, and so I can get the answer and move on. What's the balance between those two extremes?
Brad Hirayama:Yeah, you know, it's, uh, interesting. My career, I started off at at a very, very large company with with Abbott, uh, moved into, you know, a recently acquired group, so they really operated still like a startup. And then here I am at us at a startup. So my answer, if you had asked me five years ago, would be completely different than than what it is now. I feel like the need, you know, the figure it out muscle is how you called it. I really think that that is one of the most important things for any engineer to really, really work over and over and over again that figure it out muscle, however, is it's kind of a two fold, you know, like how muscles have the fast twitch and the slow twitch, I think the figure it out muscle, it ultimately boils down to become. Mean your gut instinct. And that gut instinct that you build through your experience allows you to to have kind of the the internal conversation with yourself when you are starting to get to that roadblock or starting to hit a wall and not understanding which way to go, whether you do continue to spin your wheels and really dive down this path and try to figure it out yourself, or is it time to ask somebody else for help, or try to find that resource that can give you the answer quickly? Now I will say this. I do believe that these things can be had in parallel. Whether you're in a startup, and, you know, you really don't have subject matter experts around you, or you're in a big company and there's subject matter experts just sitting waiting to answer your questions. I think it all really comes down to how you ask your questions. You know, asking questions not, you know, open ended questions, not I don't know what's going on. I don't I don't know what to do. I don't know what to do next, but asking very pointed questions, questions of, you know, something along the lines of, like, I tried this, I can't figure out how to do that. And in the grand scheme of things, this is really important to what I'm trying to accomplish, because really allows you to learn, but also allows the other person, the subject matter expert, to give you more than just an answer. You know, I like to tell any of the younger engineers that I, that I work with, always try to ask, why? Never just accept. You know, go left, try to understand that underlying. Well, why do you say to go left? And it's really important to building your gut instinct to understand kind of that underlying, why? So, you know, to to kind of bring it back and answer it's, it's hard to kind of pinpoint a exact answer to this, this question. I think it comes down a lot to the situation, and it requires the engineer to kind of have that situational awareness. But really, you know, if you can teach yourself to proactively seek the information, through better questions, through trying to find kind of that underlying reasoning behind decisions. You know, I think that helps you really make an informed decision as you're going forward.
Aaron Moncur:Yeah, I really like the bit about context that you mentioned, and, like, it probably depends. Are you in a big company with tons of SMEs who can just help you out, or are you in a small company where there aren't so many resources? And then the idea of asking very specific, intentional questions, not just, I don't know how to do this. Can you show me? I think that's a that's a big deal. Great insight on that question. Let's talk about checklists. There's a wonderful book that was written called The Checklist Manifesto by Atul Gawande, I believe was. His name is the physician author, and he talks about checklists and how important they are to being successful in any project. And he goes through a couple common environments where checklists are often used. He talks about like the flight checklist. He goes into the construction industry where, apparently they have just mountains of checklists, and he highlighted the fact that the medical industry where he serves did not have many checklists. And he actually became a pioneer, and kind of introduced checklists to the medical industry, which I thought was was really cool. But as as an engineer, are there any checklists that you have used and found to be particularly useful in different phases of engineering, just to make sure that correct actions are being taken?
Brad Hirayama:Yeah, so that's really interesting that you say that because in the medical device like design world, the FDA has a very clear checklist that you have to follow. You know, once you get to the process of submitting your PMA or 510, K approval, you know, if you if you haven't checked some of the boxes, you're not going to get anywhere. So, you know, I think it's very interesting, and I'm definitely going to take that down and probably read that book right after this. But you know, to kind of get back to the question the FDA, I've been a part of medical device my entire career, so I've been more and more familiar with the checklist needed to get to the point where you know you are ready to claim. Claim that your device is safe, it's effective, and it does exactly what you're claiming that it's that it's going to do. And that design control methodology, I think, is the checklist that I use for myself, not just in the design of medical devices, but really in the implementation and innovation for for anything, it can be applied to anything. So if you think of kind of the waterfall of of what this what this checklist is, it starts with requirements. So even if you're looking at just a process, or what is the input of the process and what is the output of the process, what does this actually need to do, right? That's the first step. The second step, after you go through your iterations and your process, is, how do I prove that what I'm outputting is exactly what I need to output? And then you know after that, how do I believe that the testing and the numbers and the data that I'm collecting is true, you know, and after you've met all of that, you kind of have this, this assurance that you've, you know, completely met your your your needs, whether it's a user or a process needs, whatever It is, you've completely met your needs. You can trust your your data, and you know that you've created a robust device process, whatever it's going to be. And as you move to the next step, you know you have this, this, this really concrete way of saying, I've completed this, and now it's time for me to move on.
Aaron Moncur:Yeah, that's great. As you were talking about the checklist for FDA user needs, technical requirements, design, verification, all that. It made me think of a checklist that we implemented many years ago. So there was a time, I will admit, when even though our drawings, from the standpoint of having all the correct dimensions and tolerances, was was thorough and accurate, we'd often miss little things like we forgot to put a note or call out the right material or put the part number in the drawing, or something like that. And so we created a checklist for ourselves, and it had think we initially, we created a pretty comprehensive checklist that had dozens of different items make sure that this is true in the drawing, this is true in the drawing. And it was kind of a lot. And so we went through it, kind of filtered out some of them, and identified, like the 10 or 11 most common mistakes that we were making, emissions that we were made making, and we implemented that. And then from that point on, whenever we had to make a drawing, the engineer in charge of that drawing would just put a little check in these boxes. Yep, I got that, I got that. I got that. And, man, it was incredible to see how quickly our drawings became really, very thoroughly complete, and our customers noticed as well. Because this, I think one of the issues that led to this checklist with a customer of ours, they're like, Hey, you guys need to work on your drawings a little bit. There's some omissions in here, but it was so powerful, you know, just having this checklist to make sure that all the right things get done.
Brad Hirayama:Standardizing your process is always, I think, the way to go, you know, especially when you're dealing with with customers or vendors or clients, you know, it's a, you know, keeping that quality of work, I think, is really, really important. So awesome to hear that.
Aaron Moncur:Yeah, so you've, you've been in a leadership role, and I'm curious what, what to what extent do you think that leadership affects the ability of a team to accelerate the speed of engineering? Do you have any, any stories or experiences that you can share where either leadership sped up, or, heaven forbid, maybe slow down the engineering process.
Brad Hirayama:Yeah, you know, leadership is everything. I think that great leaders have the ability to engage, they have the ability to rally people together. They have the ability to motivate a really diverse set of individuals, and, you know, place them in the in the right roles in order for for them to excel and and help, kind of the collective achieve. You know, I think, I firmly, firmly believe that leadership is about culture. I think that a good leader is able to embody and define a team style. And that team style is not something that is, you know, just just kind of a word on a board or a saying, you know, that said. Every once in a while, I think it's something that can be identified both internally to the team, but the best leaders are able to make it where it's identifiable externally to the to the to the team as well. You know, I'll give an example. So I was, I was a part of a group with, I think one of the best leaders that I've ever worked with. You know, he is another boy from the island, and he incorporates a lot of, I think what we grew up with in our culture into building this team. And you know, in this in this team, everything was about, how can we make the team better? How can we continue to help each other to succeed, you know? And this team, you know, we worked long hours together, but we also laughed together. We celebrated together. We triaged problems together, you know? And I think what is, what did? What did this do? This allowed for a place where individual team members could take slightly bigger chances, slightly bigger risks, because we knew that we had some, some buddy, some team member, a group of people that we could fall back on. And that really sped up. It really, really accelerated our development timelines. It, you know, really attributed to accomplishing so much in such little, little amount of time. And this was all built by the leader. It was personified by the team. And everybody bought into it, you know? And when you talk about accelerating engineering, I think if you don't have a good leader, you don't have somebody who can build and kind of embody this culture, you're not going to be able to even get to the finish line, because there's going to be so many little roadblocks that you're going to have to get get over.
Aaron Moncur:Yeah, absolutely. There's a member of our team, one of the engineers here, who shared with me a month or two ago that he was he was out somewhere, can't remember where, and a friend of his asked him this question. And he said, Hmm, it was kind of a loaded question, as I recall. And he says, Well, hold on, let me run it through my filters before I give you my answer. And this individual was like, your filters, what? What does that? What do you mean, your filters. And he kind of thought about it for a second, and he says, Well, I guess I've never, like verbally, explicitly talked about this, but I have all these filters depending on the context of the situation. I have these filters that my response goes through to make sure it's appropriate, and I'm comfortable sharing my answer with who I'm around. So he says that he just has all these filters, like layers and layers of filters that that he goes through. And what was so wonderful was that he shared this in the context of a meeting we had a pipeline about our culture and how to try and kind of codify the culture that we've built here. And he says, you know, here at Pipeline, I just I feel psychologically safe enough that I have far fewer filters here. There just aren't that many filters that my answers go through before I express them openly to the rest of the team. And I thought, wow, how wonderful that is. And in the same meeting, another engineer shared an experience where he was at a customer of ours, and he was in a design review at this customer's facility. It was just him from our team, and everyone else there was was on the customer's team, and the project lead, who was kind of leading this meeting, asked a question, and one of the engineers that was present, expressed an answer, and the the project lead kind of just shut it down right away. No, no, no, we're not going to do that. Didn't really talk about why, or explore a little bit about, you know, tell me a little bit more about where this, this thought or this idea comes from. It was just, no, we're not going to do that. Move on to the next. All right, who else has got an idea? And the engineer from our team, who was there as part of the design review, and kind of witnessing this situation unfold, immediately thought to himself, oh, that's how things are here. Well, I'm not going to share what I think, because I don't want to get shut down like that. And man, those two examples were in such stark contrast to me at that the ability for team members to feel psychologically safe enough to express what they're really thinking, wow, that is a huge, huge factor in accelerating the speed of engineering, because otherwise you just don't. Get the best ideas
Brad Hirayama:right. And, you know, it really stacks upon each other, right? Like you said, you know that leader, you know, shutting down that idea. You know, the next time that they go into the design review, who's going to speak up and who's going to speak their mind and, and, you know, how, how does that just affect everybody else in the room? So, you know, it sounds like you've created a really, really great culture at pipeline. And I, I applaud, I applaud you for that. I think that leaders make everything they can. They can make a company, they can destroy a company. And it's really, really, really important to, you know, for leaders to, you know, basically, find their style. And when an engineer is coming into a team or interviewing, it's important to understand and know the leader style, because that is who you're going to be work with. That is, that is the group that you are going to be working with and the culture that you're going to have to fit into.
Aaron Moncur:Yeah. Yeah. Team members don't quit the company. They quit the manager. Yep. Well, let me take a very short break here and share with everyone that the being an engineer podcast is brought to you by pipeline design and engineering, where we don't design pipelines, but we do help companies develop advanced manufacturing processes, automated machines and custom fixtures, complemented with product design and R D services. Learn more at Team pipeline.us The podcast is also sponsored by the wave, an online platform of free tools, education and community for engineers, Learn more at the wave dot engineer, and today, we are privileged to be speaking with Brad Hirayama, Brad, what, what are some of the best practices that your teams have implemented to maximize The chances of smooth collaboration, specifically in cross functional teams.
Brad Hirayama:Yeah, so I think I alluded to this a little bit beforehand, but in a very general sense, I always like to push for easy and centralized access to data, data being documents, CAD files, test data, you know, I think I've always used, you know, like a, like a SharePoint, you know, currently we're using SharePoint, Microsoft Teams, you know, kind of building out that document library, which can get a little bit clunky, you know, a little bit messy, if you're not the one that's building it out. Sometimes it's really difficult to find a document or, you know, remember which folder to go to. So something that I've recently adopted, something that I really, really like, is I've started to use notion. And I've started to use notion, not so much as a repository, like a, like a SharePoint, but notion becomes my landing page. So when we are, you know, looking at multiple streams of work that are all feeding into one project, I have really, really pushed for having one source where you can go, you know that you can find the information, or you know that you can at least be led to where the information is from this landing page, notion, you know, I've just started to really dive into some of the more advanced features, so using things like notion AI, notion AI, I'm not Like sponsored or anything, but I really like the fact that notion, AI, you know, allows you to, kind of, you know, give it a give it a prompt, right? I'm looking for the document repository for x, and it will go and it'll just highlight it for you. Hey, this is, this is what this person put, you know, and it's just, it's just saving you time. I'm not scrolling through a bunch of pages. I'm not clicking a bunch of times trying to find things. It just saves you time. And I I've implemented the use of notion for very simple project management. I've used it very, very heavily with doing like, if there's a bunch of purchase orders that are kind of landing at different periods of time, and they all feed into each other, and there's these interdependencies. I like to just aggregate that into one notion sheet, and that notion sheet builds out this little Gantt chart. So if we ever need to, hey, remind me when this part is coming in. I'm not sitting there for 10 minutes digging through emails, and then, okay, I'll get back to you, right? It's just, it's speed to information. And I really think that, especially when you talk cross functional, that speed to information is huge, because the what matters to me might not matter to the next group, right? And so if I'm only really focused on, okay, what? Is going to matter to the design engineers, but not what you know focused on what matters to the quality engineers. If quality goes and asks me a question, and I have to take a bunch of time to try to find the answer, right, that lag of information is really going to just slow everything down. So I've, I've really liked integrating notion into everything that I'm doing. I I have started using it in my personal life as well, you know, I've gotten my wife to sign up for it, you know, we're, we're kind of using it as our own little family planner notes, you know, you know, all of those types of things. So I think it's a really powerful tool. And I think I've just scraped the surface of the capabilities, but I'm I'm loving learning about it.
Aaron Moncur:I love hearing about new tools like that. You know, something concrete, tactical notion, right? Just go out and check out notions. Start using it and and actually, you are the second person in recent history that has suggested using notion within engineering. So I really need to go check it out. I haven't used it. I I'm aware of the name, and that's about it. So all right, this is my prompt to really go check it out and see how we can implement that. So thank you for bringing it up, everyone's going to think, oh, notion sponsoring this episode. No, in fact, they are not. Neither of us, to my knowledge, are being paid or influenced in any way, shape or form, by notion. But it sounds like from multiple sources now I'm hearing this is a useful tool to start using.
Brad Hirayama:And I think the barrier to entry is very low, and I think that's one of the big, very attractive draws to me is I was able to download it, and I picked up a lot of the features very, very quickly. I've also taught some of, you know, the more senior kind of not so tech savvy engineers that I, that I work with, I've taught them to not only create pages, but utilize some of the AI features, some of the like prompting features, you know, so they're not trying to search for for buttons. And that's really been successful for us and you know, and it saves us time, right? I'm not having to sit there and try to figure out some computer issue with somebody. A lot of times we're just doing everything in notion, and everything is being kind of created in a similar fashion.
Aaron Moncur:If you're getting some of the older, less tech savvy engineers to use notion, that's a commanding testimonial right there. Very cool. Let's talk about risk management. How do you approach risk management when trying to accelerate a project? And is there an example you can share where taking a like a calculated risk led to a faster or more successful outcome?
Brad Hirayama:Yeah, I think risk. Risk needs to be identified and addressed up front. And you know, risk management is twofold. The first part of risk management is understanding your own and your team's appetite for risk. Are you in a really risk adverse group that you know maybe isn't going to go with the slightly cheaper but first time supplier, let's say, or are you in a group that is, you know, pretty risk happy and speed is the most important thing. So if your timeline or your lead time is, is way below others. We're going with you, no matter what you know, that's kind of the first thing that you need to gage for yourself, but also for the entirety of the group that you're working in and who's leading your group, and kind of what their risk appetite is. And then the second whole part of it is, you know, approaching risk management as kind of a I like to think of it more as like a relationship building type of thing. When I think of risk management, the biggest risks that I deal with on a day to day basis are all of my external vendors, suppliers, those, those types of things, and mostly it's because I can't control them, right? I think internal risks are a lot easier to control. I can ask for help. I can, you know, maybe bring in a consultant or something like that, internally, but externally. When I'm placing a PO, I'm kind of putting the trust into the hands of the vendor and just saying, here's a bunch of money. You said you're going to give to me in four weeks. Okay, here, you know, go. So I like to approach risk as a really heavy relationship building activity. And I'll give you a quick example of this. So we, we. We have one critical supplier that that we're working with for our, one of the projects that I'm on, and this supplier, you know, it's a very niche market that we are buying from. So there's not, like, you know, 100,000 people that that we could go to, really, it's a really small, specialized, niche market. And I had the opportunity, before we placed the PO to really get to know the sales engineer and kind of the engineering team, and talk to them about not only their technology, but their industry. I got to meet with them face to face. I got to kind of, you know, build more of a rapport with with that group. When it came time to us actually placing the big, expensive Po, one thing that did come up is the sales engineer, kind of on the side said, Look, you know, I've been in this industry for a while, and I've been hearing whispers that the most well known everybody goes to supplier for this product is going to end of life the skew that you want in like two to three years. Not official yet, but it's likely to happen. And what he said is, well, internally, they've been doing a lot of testing with this other guy, little bit newer, not super established, not a huge name, but similar in quality, in in you know, everything that it needs to do is very similar to the to the big guy. And he said, I really think that if you're going to have kind of a, you know, a long, lasting product that you don't want to have to go through multiple design validations for, I really suggest that you consider this smaller, newer player that's not going to end of life their product, you know, and the relationship that I, that I built with him, the trust that I built with him, the ability for you know, the decision there was right? Do I take the risk? Right? This is going to be a calculated risk for us. Might not benefit us in the short term, but definitely will benefit us in the long term. It was the relationship that I built with him that really allowed me to take this, this risk, and make it a good, calculated risk. We ended up going with the smaller player. We haven't had problems, and I, you know, and it did come out about it's probably about eight months after that, the big company, end of life, their their skew, we would have had to go through this whole scrambling process of finding something new and redoing validations. But you know, it's it's really that relationship that I built with him that allowed me to take a calculated risk, and though it didn't necessarily affect anything in the near term, in the long term, it's going to pay off dividends to us.
Aaron Moncur:What a wonderful example. That was what I took from that was building relationships, building relationships of trust mitigates risk, which I think is deeply insightful and not something that I've heard anyone else say, but now that you say it, it makes so much sense in terms of mitigating risk. I mean, if you're relying on people to do things, who do you trust the most? It's the people that you know and have these relationships of trust with, right? I'm going to trust my brother to do something a lot more than I'm going to trust some stranger off the street, because I know my brother and I don't know this stranger. So the idea of building these relationships of trust, wow, I'm really grateful that you shared it in that way, because I don't think I've really thought of it in that in that sense before.
Brad Hirayama:And it and it extends, you know, past the the external, you know, vendor relationships. It extends to, you know, getting to know your co workers, building that good relationship. When you talk about management of risk and accelerating engineer, accelerating engineering, you know, who's the go to, right? Who do you know and who can you trust to solve a problem, solve a problem right? Solve a public solve a problem in you know, reasonable amount of time. Those are the people that you build good, good relationships with. And I think it's, it's really, really important to always keep that in mind and keep that at the forefront of, you know, your kind of your plan as you enter a new team, or, you know, you start to build out a team.
Aaron Moncur:Have there been any situations you can share where you maybe you took. A risk, or you tried to implement some tool or strategy to accelerate the speed of a project, and it just backfired. You know, ended up taking more time than you thought it would. And what can we learn? What can we all learn from that?
Brad Hirayama:So, something, something that I was thinking about here, you know, try to implement a tool, or kind of a time of trying to fight for, I think what I thought was right in terms of kind of management, risk, risk management, those types of things I was in an organization. I'm not going to name which job, you know, we kind of talked through which job. But this organization, you know, was really new to complex assemblies, complex bombs, you know, having devices with a lot of inter interdependencies and, you know, just kind of the the understanding of the downstream effects of what could happen say, if you change a part, and you don't look at how is that going to affect the assembly. You know, that was something new to that organization that I was in. So I fought really hard to implement a really robust PDM and like a part database management. So we were using the SolidWorks PDM at the time, but to implement that into their QMS system, and to force everybody, not just the R and D team, but the manufacturing team and the quality team to understand how the PDM works, and what can that do for, you know, keeping quality metrics all the way through the production lifecycle. You know, this, this, I think, in as I'm talking about it, this sounds normal. I think everybody knows the value of a PDM. And I think anybody who's worked in SolidWorks or worked in CAD understands the value of a PDM. The hard part that made this, I wouldn't say, a failure, but it slowed things down in terms of our development was getting the understanding outside of the engineers, so getting the quality engineers to understand why you know you have to check out a part before you make a make a change, or if you want to redline something, you don't do it in Adobe PDF. You do it in the proper channels. It it really, I, I didn't do that as well as I should disseminate, kind of the information of why we need to do this. That caused some issues. There was some hiccups along the way. And, you know, I think that really slowed us, slowed us down, not kind of being upfront and kind of just assuming that everybody understood. And, you know, in the end, I think it all, it all worked out. We kind of all came back. And, you know, the PDM is a very, you know, understandably good resource to have, but that speed bump in the middle of everything, kind of backlogged everything had we had to go through this whole remediation effort because somebody decided to redline in Adobe and not redline, you know, via the right the right co process channels and everything.
Aaron Moncur:Do you think that, if you had it to do over again, did it come down to just people needed more training, or what were the lessons learned? What would you have done differently?
Brad Hirayama:Yeah, so upfront training would have been number one. I think I would have explained what a PDM. I would have started from the beginning, not with the R D engineering team, because I think we all knew exactly where, you know the the why behind it, but every other functional group that we were interacting with, I would have started from the beginning and tried to, like, almost sell it as a brand new thing, right? This is why we use PDM. This is why we need PDM. This is why doing something outside of kind of the normal process is going to affect the downstream product. So definitely upfront training and just, you know, a better, I think, holistic definition of what are we trying to do? Why are we doing it? And if you don't follow it, how does that affect us? You know, the downstream,
Aaron Moncur:yeah, yeah. Sounds like a little bit of almost sales and marketing, right? Selling the idea of PDM to those who are going to be using it, a little bit of PDM focused marketing there, which really are just. Forms of communication, which is a perfect segue into the next question here, which is, are there other specific tools or processes that you have used to facilitate better communication within your teams?
Brad Hirayama:Yeah, so I think I'm going to go back to the, to the same kind of theme, you know, with the, you know, we're talking about kind of speed to information, you know, I, I like to really push for this organized manner of keeping documentation, you couple that with really meticulous note taking and the kind of setting the standard that you are documenting everything, whether it's a decision, a design review meeting, you know, a we quoted from this vendor. We didn't go with the vendor because x, just writing that one line in a central, you know, central space can save you time down the line when somebody says, Oh, why don't? Why didn't we go with vendor X? You can say, well, you know, here's the reason, you know, this is the quote that we had. This is the reason that we didn't go with them again. It's, it's, you know, you talk about optimization, right? Efficiency. Optimization and efficiency means that you're not spending the time searching for an old email, or you're not spending the time, you know, saying, I don't really remember. Maybe we should go through the process again. I really try to tell myself, and I tell everybody else that I work with that, you know, that extra 30 seconds of writing something down or taking that note, or even dragging the PDF off of, you know, like a PDF quote off of an email into this folder on our SharePoint, or notion, you know, that save that'll save us time down the line. That could save us, you know, five minutes, but that could also save us weeks, months down the line, in the in the development process, you know. And I really think that if you can really push for that speed to information being the norm in your group, you're going to find that efficiency just shoots through the roof, because everybody is going to be able to be on the same page faster. Everybody's going to be able to find information faster. Everybody's going to be able to understand the why you made certain decisions, or you chose to go with vendor a versus render vendor B faster, right? And that, in of itself, is going to speed up your development process.
Aaron Moncur:Yeah? Yeah. I think inherently in certain organizations, there is a fear or a reluctance to bias towards giving the team access to everything, or access to most everything, and certainly there are some instances where it's appropriate not to share information, right? Like, we don't want everyone's salary to be public because that could get awkward things like that. Although I know there are some companies who even, who even do that, to get to that extreme, I've always been of the mindset that I'd rather share and give access to information than not. There have been a few times where, for example, we have SharePoint also, and we've got a sales site and the SharePoint and we've got a marketing site. And originally we thought, you know, the engineers, they don't need access to sales or or marketing, so let's just not give them access to those folders, because they don't need it. And of course, not too long later, there was some project where we wanted an engineer to go into the marketing folder and look at something or create some content there, and they didn't have access to it. So then we had to stop what we're doing and go, hey, send an email to our admin. Hey, can you give this person access to the and it just is like, Well, why don't we just do this from the beginning, like we didn't really save anything. We lost time doing this. So what? It made sense at the time, because, at least we thought it did. Because, well, they're engineers, like, we're just, why? Why give access to things that they're never going to use? Right? We thought we were being efficient, but really it backfired, and now just everyone has access to all the different sites, which has been a lot more efficient. Another thing I thought about was, Are you familiar with the tool, loom, loom videos?
Brad Hirayama:No, I haven't heard of it.
Aaron Moncur:Okay, so you gave me notion. I'm gonna give you loom, loom. Loom is, I think, one of the best communication and productivity tools that I have found in recent history, and it makes it just really, really stupid easy to do a screen recording. And you might think, what's the big deal? Screen Recording? Who cares? Right? I'm telling you I use loom all the time, and it has saved me so much time just last literally, last night, an engineer on our team sent me an email with it was several paragraphs long, outlining some things that he was looking for, questions for which he needed answers right on our project, and I could have spent, I think pretty easily, 20 to 30 minutes writing out responses to all of these things. Instead, I turned on loom, and within a met, literally a matter of seconds, I was recording. I was so his email was right there on my screen, and I was just talking through to different points, right? Took me five minutes. I was done out of there, and loom has transcription built into it. So if you want to search for certain texts, you could do that as well. And I saved myself probably 15 to 25 minutes just with that one example. And I've used it for so many different things, design reviews, some kind of IT help creating little, short tutorials that I'm sending to engineers. This is how you do this thing. It's been a huge productivity tool for me. So loom is that's, that's a big one that I'm going to put out there for accelerating communication.
Brad Hirayama:Awesome. Yeah, I'm going to, I'm going to take a look at that that that sounds like a really, really helpful tool, especially when you're, you know, if you're the one that's building out the SharePoint, let's say, you know, you know where everything is, and you know where all the clicks are, but sometimes it's hard to verbalize that for everybody, right? So, yeah, I definitely, I'm going to take a, take a definite Look at that. Hey, so I wanted to add one more thing to you, so, the, so, the story that you told about, you know, the the engineer needing access, and then you have to kind of spend the time trying to get access. I'm also a big believer that engineering is about momentum. So you know, when you have this centralized, you know, information kind of pipeline, when you get to the point where, hey, I need you to do this, and they know exactly where to go, they still have the momentum, and they're able to run with it immediately. I think that's a really, really important point to make, is, you know, when you talk about speed, you talk about optimization and efficiency, the worst thing that you can do is create a barrier that they have to jump over, right? So you know this, this share of information. Sure, there are things that need to be kept secret for good reason, but why not give everybody all the information that they need? They never use it. They never look at it. That's okay. But in the off chance that they do need to look at that marketing document or slide or something, you know they're not going to lose the momentum.
Aaron Moncur:Absolutely, that's a great way to think about it. Is momentum, right? How do we not impede momentum? How do we remove obstacles before they become obstacles? All right? Well, Brad, what a treat. This has been wonderful, wonderful conversation. You shared some really important, deeply insightful bits of wisdom. Thank you for being with us today and allowing us to document all of that wonderful knowledge that's in your brain and put it into this repository that engineers can access any time. How can people get in touch with you?
Brad Hirayama:Aaron, thank you for having me. This was very exciting. I love talking about these things. I'm on LinkedIn. Search for me on LinkedIn. I love to connect with people. Send me a direct message if you have any questions or you just want to have a conversation. I really like to make connections. I really like to learn from other people. And, you know, learn from various backgrounds and various perspectives. So outside of engineering, you know, if you have any any other topics that you want to talk about, feel free. I am open ears. And like I said, I love to make connections. I love to have conversations.
Aaron Moncur:Excellent. Brad, thank you so much for being on the podcast today.
Brad Hirayama:No thank you.
Aaron Moncur: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&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.
