Being an Engineer

S5E35 TJ Strang | How to Accelerate the Speed of Engineering, Episode 1

TJ Strang Season 5 Episode 35

Send us a text

In this first episode of a special series on tools for accelerating engineering, host Aaron Moncur engages in a thought-provoking conversation with TJ Strang, an experienced leader in the medical device industry. Together, they explore the challenges that often hinder engineering projects and share insights on how to overcome them. The discussion covers a wide range of topics, focusing on ways to enhance efficiency, support team development, and improve communication within engineering teams.

Main Topics:

  • Common bottlenecks in engineering projects
  • Balancing help-seeking and independent learning for junior engineers 
  • The role of psychological safety in engineering teams
  • Leadership's impact on engineering project speed
  • Tools and technologies for accelerating engineering
  • Unconventional approaches to expediting engineering processes
  • Optimizing communication for faster engineering

About the guest: TJ Strang, is a distinguished leader in the medical device industry. With a career spanning over two decades at companies like Abbott, and St. Jude Medical, and Acutus Medical, he has led groundbreaking projects in electrophysiology, cardiac rhythm management, and leadless pacemakers. TJ’s expertise in assembling and leading top-tier R&D teams, driving products from concept to market, and overall engineering innovation makes him the perfect guest to start this series. TJ currently serves as VP of Engineering at Atraverse Medical, which is developing cutting-edge left-heart access technologies.

Links:
TJ Strang - 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

Aaron Moncur:

Do you ever work with pneumatic actuators? Our easy pneumatics controller is the easiest way to control air driven motion. I have ever seen the no code programming interface is so easy even I can program it, and that's saying a lot create sophisticated motion in minutes, not weeks, with easy pneumatics controller. Learn more at Team pipeline.us.

TJ Strang:

Sometimes we just we don't want to share everything. And it's kind of like when you start dating somebody, you don't want to just share all your warts and things that are wrong with you. But you know, having the level of comfort that just say, Listen, these are all the these are all the things that are wrong with this project, and these are all the things that are right. And just lay it all out for everybody to know. I have found that level of of transparency is really helpful.

Aaron Moncur:

Hello and welcome to the being an engineer podcast today we kick off our special series on tools for accelerating engineering with TJ Strang, a distinguished leader in the medical device industry with a career spanning over two decades at companies like Abbott St Jude Medical and acutus medical, he has led groundbreaking projects in electrophysiology, cardiac rhythm management and leadless pacemakers. Teaches TJs expertise in assembling and leading top tier R D teams, driving products from concept to market and overall, engineering innovation makes him the perfect guest to start this series. TJ currently serves as VP of Engineering at Atraverse Medical where he and his team are developing cutting edge left heart access technologies. TJ, thank you so much for being on the show today.

TJ Strang:

Thank you, Aaron, thanks. Thanks for the invite.

Aaron Moncur:

Well, I've been super excited to start this series. This is the first episode of the series where all of our questions are focused on, how do we accelerate the speed of engineering? I have this, this personal mission statement, which is, accelerate the speed of engineering, to improve the human experience. And for the past maybe 20 or 30 podcast episodes, I've been asking one question every episode, which is, how, what are some ways that that you the guest, have been able to accelerate the speed of engineering, and I've heard some really great answers. And so that kind of led to the idea, well, why don't we just do a whole series on this? So there will be, I don't know the exact number of episodes is still kind of up in the air, but probably somewhere between four and eight episodes where that's all we talk about is, what are tools? What are methods, mindsets to increase the speed of engineering and get projects done faster. So here we are, episode number one with TJ, before we talk about maybe speeding up engineering processes. TJ, can you share a little bit about what are like, two or three of the most common bottlenecks that you have seen slow engineering down.

TJ Strang:

Yeah and thanks for that intro. And I love this topic. I love the idea of what you know, talking about what we can do to speed up engineering. You know, often I've seen that teams so the teams we work in, I've seen where we have too many too many cooks, too many people on the team, too many decision makers and and I've also seen the reverse, though, that the solo mission, right, the Medal of Honor run the engineer wants to do it all himself or herself. And I think in both situations, we're really not tapping into the power of of the small, dedicated, empowered team. I think that small, meaning like four to six people, is kind of the way to go. And I see when you get too many people on the team, you get to or not enough to really do all the things you need to do. Then, then you really start to slow things down. You know, the other, the other side of that is planning. I think that sometimes getting, I think poor planning, really, by really cause problems with, with with project, project timelines, you know, try to do everything serially, instead of mapping things out and how we can take advantage of natural gaps and and the schedule and do things more in parallel. Sometimes doing just those opportunity cost calculations, you get analysis paralysis, and nobody makes a decision to move forward or. Approve a project. So I think those are the things that that really I've seen in my, my, from my perspective, really just slow down engineering projects.

Aaron Moncur:

Okay, to So to recap, a lack of planning and having either too many or not enough, I guess, having an inappropriate number of people on the team, yeah, yeah. So let's talk about junior engineers. You know, very, very green, brand new engineers maybe don't have a ton of experience and don't know all the tricks of the trade. One way I have seen younger engineers burn a lot of time is when they don't ask for help soon enough. But there is a corollary to that right? Because they have to spend some time trying on their own, or else they're never going to build that, that muscle of just learning how to figure stuff out on their own. So what's, what's the balance there? How do we, how do we accelerate the speed of engineering by asking for help soon enough, but but also give younger engineers a chance to build that muscle figuring things out for themselves.

TJ Strang:

Yeah, that's just an interesting question. You know, I was, and I would say this question doesn't go away with seniority. You know, I was at, I worked at St Jude Medical, which got acquired by Abbott for 17 years, and I felt like there was, really wasn't many questions I didn't know the answer to. And when I, when I changed positions and started to learn about a new part of the business and medical devices that you said you called a muscle, he's exactly right, except this is my asking questions muscle. It was a that was a muscle I hadn't used for a while. And knowing how to ask good questions, there's, there's a bit of a skill there. And I think you call it a balance, and it is, it is always a balance. And the nice thing about, you know, new engineers, something I would always do is, is give them a task that maybe I wouldn't even know the answer to right, or how to do it and and have them go and figure it out. And along the way, they're going to meet new people, they're going to ask they're going to they're going to figure a little bit out on themselves, for themselves. They'll meet new people and ask them questions. And if they come back and ask me, they're they may not get very far. I may not be able to help them very much, but, but you know, if they didn't actually go and ask questions, they they're definitely missing out on some some enrichment, and in their in their time of that company, getting to know the people who do know the answers. But of course, the flip side, as you say, is, is always looming, and I experienced, too, is, how, when do you just put your head down and say, I'm gonna, I'm gonna figure this out. And, and that's a that's a tough balance. One, one thing I learned quickly is, especially when I, when I moved companies, is that you start asking questions from the experts, the experts that you very quickly run into the limit of their understanding, and all of a sudden you realize, oh, this is an area where I can lend some expertise. I can start adding to, to, to the Wikipedia, so to speak, of of the company. So the the other thing I would try to do is say, Listen, you are the expert. You are going to be the expert. So you know you when you prepare to teach you, right? You all you hear you, if you, if you learn something with the idea that you're going to you're gonna have to teach it. You're gonna learn it really good. And so if you you have them, you empower them to be the expert, to be the SME, the subject matter expert, for a particular topic, they will prepare themselves. And maybe you can set them up. We've done this before, where you set them up to present back to the to the team. How did you? How did you? How did you do? What did you find out? Teach us now? What you learned about how to, even if it's Hey, what's the best practice to to put these tolerances on a drawing? You know, go and go and figure that out for us that have been out of school for a long time, so, something like that. So, so those have been some of the strategies I've used. But also I've as as I've become senior and experienced myself, I think that question never really, really goes away.

Aaron Moncur:

That's an important insight. I think you're right. It never really does go away. One of the thoughts I've had on this is there probably is an opportunity to do both, because there's an infinite number of problems that you'll have the opportunity to solve as an engineer. And in my mind, a lot of these problems, there's an answer to them, and someone knows that answer. And so my advice for. Engineers would be if you have someone accessible to you who knows the answer, just ask, get help and get the answer and and move on, you know. But then there are the like the truly R D type problems that that no one really knows the answer to, and that's why it's R and D, because the answer isn't readily available. You can't just go ask a colleague or someone who has more experience. You could maybe ask someone to to give you some suggestions or ideas for how to approach an R and D problem, but no one has that answer, and so those are the the problem, or the the opportunities where you you learn to grow that muscle. So I think that's, that's what I would say, is, if there's someone accessible to you who knows the answer, just go get the answer and move on. If no one knows the answer, then, well, there's the opportunity. You're kind of forced to start building that muscle. And all engineers are going to have both of these situations many, many times over the course of their career.

TJ Strang:

Yeah, yeah. I really like that, you know. And and the idea that they've, you know, I got this a lot in different places, where you go and ask people, and I'll call them the gray beards, but maybe we'll call them gray gray hairs, because they're gonna be men or women who have been there a long time. I've been doing what you're doing, have been in your shoes as a young engineer, and they go, you know, we tried that and didn't work. You know, it can be demotivating, but it's really important that it's that it not be because they, they tried it 20 years ago or 10 years ago, didn't have, you know, the materials, the material the material science, the material background, the FEA, you know, these, just these, these things that are available to us today as engineers that weren't available 10 to 20 years ago. And so it Yeah, that that's one downside of of and I love, there's a lot of great things about having the gray beards around in the company, but it is important for people to to kind of not get disappointed when they say what you're trying to do is impossible.

Aaron Moncur:

It's funny that you say the gray beards. I just before this recording, recorded myself a video doing a demo of something that I'm going to post on LinkedIn next week. But after I looked at the video, I noticed, oh, my goodness, I have a lot more grain my beard than I than I realized from the side of this. Oh, wow, look at all that

TJ Strang:

45 that's why I just, I keep my, you know, I keep my beard short, and I just cut it all off my head. Yeah,

Aaron Moncur:

there you go. I look like I'm 20. If I shave my grease, I have to keep it so people take me seriously. All right, what are one or two tools that you have seen used effectively to fail fast and inexpensively?

TJ Strang:

Yeah, and that idea of failing fast have been, has been, has been in our Alexa con for a while. And you know, I love one, one of a very call it Life changing. That seems a little bit much, but a very important book for me was the book The Lean Startup, and then, and if you haven't read it, or your listeners haven't read it, it's you don't have to be in a, you know, an entrepreneur starting a new company, or whatever. Lead startup is, has some really good principles for any engineer. And the idea is, is, really comes down to a lot of stuff, but it's, it's, the idea is, is to just to just build it. So that's the one thing. So medical devices, typically, a lot of times this can be done. And I get that, you know, if you're building something really big, a jet airplane, a car, you know, some massive, something massive, that might be hard, but just building it, just make it. It's so hard to as an engineer, I run into this all the time where you're trying to explain your idea to to somebody. And, you know, bless their hearts to our marketing friends and and they just don't get it, but then you put it in their hands, and they go, Ah, this is great. When can we have it? You know? It's like, this is what I was telling you about. So the idea of just building it and it, you know? So 3d printers, if you don't, you know, Lydd printers, and having companies invest in that rapid prototyping areas, habit has a we had, we kind of created our little rapid prototyping area that was available for all engineers. But it was had, you know, stuff like modeling clay and pipe cleaners and and, and, you know, masking tape and stuff, you know, it just building a physical widget is going to just be so much faster than sitting down and trying to explain it to to people and then, you know, medical devices is so fun because, and I use the word fun more like it's not fun in that, you know, if we were making an iPhone, we would, you know, Google uses this term dogfooding, right? So. Yes, we would be using the software, the hardware that that we're creating medical devices. We can't, you know, we legally, we can't use it on on people as engineers. You have to be a licensed physician. So your product that you make you love, you slave over at your baby, then you hand it over to the user. So you have to be able to fail fast. You have to get this thing into the hands of somebody else as soon as as fast as possible. So, and there's a lot of ways to do that, but you can, you know, you can make the most awesome, have the that the greatest ideas in your head and plan out, you know, year, two years of product development, but five minutes in the hands of a user is going to tell you more than than you will then you could do in the over the over that same timeframe, in years. So that's, I think that's the, I would say the number one tool is just build it. You know, Nike says just do it. Just Just build it. Just made that's wonderful.

Aaron Moncur:

Oh, I love that so much, and I agree 100% getting something physical in your hands that you can hold and tactilely interact with, there's just no no nothing else that gives you as much information so quickly so going from like the the hard wear side this tactile, physical prototype that you you hold in your hand, let's switch gears and talked about a little bit about the soft skills of engineering. I think engineering can can be slowed, and even really wonderful ideas can be blocked altogether if team members don't feel psychologically safe enough to really, truly speak their minds, to say what they're thinking without any fear of of recourse or judgment. Can you think of a story or a time where you you

TJ Strang:

Yeah, this is, this is such a great topic for any did something, you said something, maybe you didn't do something that helped an engineer feel safe. And we're talking about psych, psychological safety, not I think we all, pretty much in this society, feel physically safe and and how did that lead to speeding up a project? engineer out there who is also a manager, who wants to be a manager, to build these team, to build your team in a way that allows people the comfort, and, as you say, the safety to to to speak up. And so there was, there's a really good booklet. And it was, it's the Columbia Accident Investigation Board booklet. You You can get it, I think you can only really get it on eBay now, like people's old copies that aren't, they're out of print. But it was, it was the findings of what happened, what led to the Columbia space shuttle disaster, and at its root, it was this idea is that there were engineers who knew of a problem but did not feel confident or safe in sharing their concerns with their engineering managers, with management and so and so NASA did. It had created a lot of formalities and ways people could go and end around to from, from their managers to kind of do second level or third level, kind of bring up their concerns. But that's a really important thing when you're doing medical devices, if, if everybody's like, yes, yes, yes. And you're some you're seeing a risk, and you say, and you're you're in your head, you're saying no to something that, or questioning the safety of something and not bringing it up, that's really, that's really can be a problem. I would say it's still something I I, I try to create the safe space to do that it and number one is just calling it out, and you'll wishing it into, you know, what's the right way to say it, talking it into existence, saying within your team meetings, that it's, it's, you know, it's all of us working together. And sometimes what happens as an engineer is somebody says, hey, what about this? You know, really good idea, but they usually don't say it that way. But I really like that idea. But what about this and this and this and it all of a sudden we go defensive, and as that's my baby, you know, how dare you. And so the idea of loving, loving your idea too much can be a problem. And so we talking about. Out your ideas are good, but don't fall in love with them, because they're going to change, and they're going to be and they need to change. And so what can happen is you have a really strong voice in your engineering team who is always, is always right in their mind, right? It's always right, never, never wrong. And so and and so. Talking to those people directly behind one on one, to making sure they understand how they can be viewed and the group and whatnot has has been, has been helpful to so that those loud voices in the room can be more inviting. I love the idea of, hey, you know, Aaron, you know, what do you think about this? I know you've been, you haven't said anything yet. I really like to get your ideas just and and maybe prepping them ahead of time. If there's somebody who's naturally shy and, you know, we're we all arrive at our engineering, you know, I love just we have our engineering team. Let's call it six people, you know, and we come from, we're all broken in some way, right? We've all have backgrounds. And, you know, of different grown up in different parts of the country or parts of the world. And, you know, some of us are loud, some of them not. Some of us think about things this way and that way and and so letting them know, Hey, I'm, you know, I might, I really want to hear you on one on one. I really want to hear you your comments. We really value, but then doing it in public. Hey, Aaron, I would really, you know what? What do you think about this? And I'd like to get your thoughts, and that might give them the entry to to then speak up.

Aaron Moncur:

I think that's huge. Yeah, I think a lot of this comes from leadership, and so for a leader in a room, just to specifically reach out to one individual, hey, I haven't heard you say much. What? What ideas do you have about this? So I'd love to hear your thoughts. I think that kind of invitation could be very powerful. I have a good friend of mine, Joel Williams, who was on the show quite a while back. He gave he talked about McDonald's ideas, and I thought this was such a cool way to think about it. He's been a leader in business and manufacturing companies for a long time. And he says occasionally they'll go to lunch as a group, you know, the whole team. They'll go out to lunch somewhere. And inevitably, the question is, okay, where are we going to go? What? Where? Where are we going to eat? And if, if no one seems, if people seem reluctant to share their ideas about where they're going to eat, of course, this is kind of a silly example, focused on a restaurant, right? But it's directly applicable to life threatening decisions that are being made as part of a medical device development project. So if people seem reluctant to to give an answer and share their thoughts, he'll he'll blurt out, oh, we should go to McDonald's, and he'll be serious about it, or at least he'll appear to be serious about it. And after that, the whole team is thinking, wow, I thought my restaurant idea was bad. But here the leaders suggesting we go to McDonald's. I could do better than that. Okay, here's my idea. Let's How about this place. And I thought it was such a great philosophy. You know, for the leader to be, I don't know, vulnerable is quite the right term. Maybe even manipulative could be, but not, not, not maliciously manipulative, but putting something out there that clearly is not a great idea to make other people feel safe. Oh, well, if the leader put on an idea that bad, I can do better than that. Okay, here's, here's my idea. I thought that was a really cool approach to it.

TJ Strang:

Yeah, that's funny. Yeah. I really, really like that idea of almost being self, self deprecating as a man, a little bit,

Aaron Moncur:

yeah, yeah, right, yeah. All right. Well, speaking of leadership, obviously it does play a significant role in accelerating or decelerating engineering projects. Can you think of a story where, whether it's you directly, you've been a leader in the engineering space for a long time now, or someone else you know, or something you observed, but a story where where leadership affected the speed of engineering, whether it was speeding it up or or slowing it down.

TJ Strang:

Um, you know, I, I, I think the number one, well, I think leadership can really play an important role in empowering the team. So I've seen, I've seen situations where we're on a team, you know, a core team, and and, and some people on the team are able to make a decision. They gotta, they gotta consult with their their manager, and I get it on the big decisions, that's very that's important get alignment. But it was everything. It was every, every decision. And come to. Find out that that was kind of that particular manager had not empowered their direct reports to make any decision. And they, all of them, and it, you know, really showed, and they were good engineers, and it was, I think it really just, just showed some for that particular manager, they were a little bit self conscious of their team and being able to not make a mistake and that it would reflect poorly on them. And so I get that, but you know, that really was a painful experience on the flip side, you know, having a team, I would say, in our the in the early days of St Jude Medical, we had many opportunities to operate, almost within a like a startup, within a company where a small group of us were able to operate almost autonomous, autonomously to get a project done. And we were really successful at very quickly. You know, we came in, actually, a bunch of us were hired at the same time to and we really came in and and moved the whole company set up portfolio of products from kind of what was viewed as sort of the, the worst products, the third place, in a in a in a three horse race, to to the to the best products out there. And we were able to do that in about a year and a half, and to really turn the ship around. And, you know, all of us went on to, you know, different parts of the business, and took a little bit with of that with us as we as we went. But that there was about two years or so, maybe three, where we did some really amazing things. Even looking back now 15 years removed, we did some amazing things in a very short period of time, some some very industry changing products that were able to be launched in that little in that little segment of time. And it just, it just goes to you just empower a small group of people and step aside and let them and let them roll. It's amazing what can be done.

Aaron Moncur:

Give them a purpose, give them the tools, the resources, and then let them do their thing.

TJ Strang:

Yep, yep, exactly.

Aaron Moncur:

That's That's wonderful. All right. Well, let me take a short break here. 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 and 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 have the privilege of speaking with TJ Strang, TJ, what are, what are some of the best practices that your teams have implemented to ensure smooth collaboration in cross functional teams.

TJ Strang:

Number wise, join the team early. So, you know, it's like, when you, when you pack, I've got kids, and you pack up the car, and then you're ready to go on a on a trip. You know, we just did this earlier this week, you know? We loaded everybody up in the car. We went on a little vacation up up north and and, you know, someone's got a if you've got to make a stop along the way, it's just like, it just ruins your momentum. And adding a team member to the middle of a team is like making a stop. It's like pulling off the freeway, you know, driving through the the the residential areas, and then you gotta, you know, from the teams, you have to stop. It's not just, Hey, welcome to the team. It's, let's review, if you know, let's review the, all the decisions we made up to now, possibly questioning those, those things. So if you know we're eventually going to be manufacturing this thing in house, let's get those manufacturing people should be there from from day one. And I know most companies don't operate that way. They're going to come in maybe a month or two before it gets transferred over manufacturing. But I love having, man, when those manufacturing guys are there from day one and helping us do concurrent engineering, helping us do making decisions for DFM before the design's frozen. I mean, that's that's gold, right there.

Aaron Moncur:

That's great, terrific answer. We find the same to be true. There was a time when we would bring our controls engineer into a. Project, kind of after the mechanical design was done. Right now, we're starting to order things and build things, and we learned pretty quickly that it was so much more effective to have him be a part of the design story, the design conversation, you know, really from the beginning. So agreed 100% on that one. Has there ever been an experience where you introduced new technologies or even new tools, whether they were software tools or hardware tools, that significantly reduced engineering time?

TJ Strang:

Yes, yeah. So, yeah. So we started to adopt FEA in medical devices, many it's been around for a long time and many forms, but I had an engineer on my team who was very adept at running FEA simulations and along the about the same time so we were, we were kind of trying together, him and I were trying to sell, sell it as a service, not not sell monetarily, but just say, Hey, we've made some hardware and software investments. We have license, you know, licenses seats to to run some FEA simulations. We can help you set up on your teams, and we look kind of broadly across the organization, who could make use of FEA. And it took a while. It took us a while to really gain some momentum there. And I would say at times, I was like, you know, this is this isn't worth it takes too much time and too much know how to set up these, these cases as FEA simulations to make really make it, make it work, right, and my money maybe better spent elsewhere. But we stopped. We stuck with it, fortunately, because it really ended up being an amazing time saver for for for many things so and the other, the other side of it is the FDA has really pushed the use of FEA. They actually pushing it instead of doing, say, like, like animal studies, or what we call preclinical studies in animals and stuff like that, to do, to do things in FEA instead, interesting and so. So there's a whole group of people and companies working on what we call the digital twin, which is like a from the ground up, mechanical, electrical human body, you know, so mapping all the every single muscle tissue, the way the oriented, the way the electrical heartbeat and twists and all that stuff so and that's where we're going. And of course, that wasn't around 10 quite like that 10 years ago, but it was enough that we could do some really neat things, modeling how we were working on pacemaker leads and how the lead would flex inside of a heart, and how much stress and strain was being developed on all of these components. And also, you know, we were trying to design, I mentioned DFM, but, you know, we were trying to design things that were really easy to assemble. So we started to look at, you know, stat fits, instead of, like welding and crimping and everything. And so we had a great time designing these things in FDA, where you could, you know, push and so something's flexing, and then you, you, you know, snaps into into place and locks. And then how much force it would take to to pull these things apart, you know, we would, you we would have had to have done hundreds of different iterations with, you know, a couple 1000s of an inch here, a couple 1000s of inch there, to figure out how these things would what's the strongest form of all these pieces going together? And FEA was able to do that in in a day or two. It was, it was, it was pretty amazing, a tool. By the time we, I was, I was starting to wind down and leave at Abbott. Was, was was FEA was really leading to some and still is. I keep in touch with some of those people that are running it, but it's a real it's a really fantastic tool that continues to to save time.

Aaron Moncur:

That's great one. I was really fascinated listening to you talk about how there are groups out there who are developing models of the entire human body, not just the soft tissues, but like the electrical impulses going throughout the body. That is fascinating. I I wasn't aware that such high fidelity. I don't know if they're out there right now or if it's just they're being worked on, but I didn't even know that that was a thing like being worked on. It makes total sense, though, with the prevalence of FDA these days, that we would have better models to use them in.

TJ Strang:

Yeah, I would say, I mean, Dassault systems is a company doing a lot of a lot of work on others, others that was, they've actually. Presented at a lot of the bioengineering conferences their work, and the FDA has really pushed for it as well.

Aaron Moncur:

Interesting, very, very interesting. Wow. Okay, how about any Have there ever been any unconventional approaches that you've taken to expediting an engineering process?

TJ Strang:

On unusual transparency is what else call it unusual transparency? I mean, it's sometimes we're just afraid. And, you know, I've been a program manager and many times, and sometimes we just, we don't want to share everything. And it's kind of like, you know, when you start dating somebody, you don't want to just share all your warts and things that are wrong with you. But, you know, having the level of comfort that just say, Listen, these are all the these are all the things that are wrong with this project, and these are all the things that are right. And just lay it all out for everybody to know that I've, I have found that that level of of transparency, the unusual transparency, is really helpful. You don't get surprises. You don't get people that today, I didn't, I didn't know this was a problem. And and then you got to backtrack. I call them. I call them grenades, you know, sometimes, sometimes people in meetings will sort of lob the grenade, hey, this failed that test, you know, and say, Okay, we'll meet next week. You know, it's like, wait, wait, What? What? What happened? What failed? What are you talking about? And so there are no no, you know, grenades in our, in our, in our meetings. And and, you know, decisions can be made documented really quickly, if issues can be just brought up and talked about, not wait for the next for the next team meeting, or the next big report out, or whatever. It's just yeah, be transparent.

Aaron Moncur:

Yeah, yeah. We have, we have some philosophies, or we call them our tenants that are hung on the wall here at pipeline, and one of them is, take what's on the inside, put it on the outside and talk about it. And just just the other week, actually, we had a great experience where one of our engineers was working on a project for a customer, and the customer had been adamant about, I won't get into the details of it, but they wanted the design to be a certain way, and they hadn't communicated very clearly why they wanted it to be a certain way, but they were very adamant, right? There was no question that this is how they wanted it to be. And so one of our engineers was trying and trying and trying, just couldn't find a way to get it into the configuration that this customer wanted. And he was getting really frustrated, understandably, because what they wanted, it just it wasn't the right approach, you know, and he was trying to fit a square peg into a round hole, kind of thing. And the customer kept saying, No, I want it this way. I want it this way. And so eventually I got an email from him. And actually, I had reached out and said something like, Hey, I know this project has been kind of stressful, and it's been hard to get exactly what the customers is wanting. How are you doing? Like, how is your stress level? And he says, well, take what's on the inside, put it on the outside. Here it is. And he just kind of laid it out, kind of vented over email with me, and I thought it was just wonderful. And later on, we we talked, and he said I wasn't sure if I should send that email because, like, I just needed to kind of vent a little bit, and I wasn't sure how you would how you would take that, but I'm glad that I did. And then that opened up some doors for communication, and ultimately led to a conversation with the customer where we pushed back a little bit and suggested, Hey, are we don't understand exactly why you want it this way, but here are the trade offs, and it's going to cost a lot more money, and it's probably not going to work as well. And anyway, it worked out pretty well all because he, he he, he was, felt comfortable enough to take what's on the inside, put it on the outside, that radical transparency, right? Like, like you're talking about, he just kind of laid it all out there.

TJ Strang:

Yeah, I love that. I love that saying as well. Yeah, that really captures the spirit.

Aaron Moncur:

All right, let's see. How about tools for communication. Have you found any specific tools that have allowed you to optimize or speed up communication between team members that led to faster timelines on our project?

TJ Strang:

Yeah, so, and this was a little bit of we're we're talking about. But you know, I love being co located with my engineers, and even as a manager, I I want to be nearby, and I want my team to be near each other and and if the team is cross functional, I want those, those people, if they're, you know, not in R D, they're in quality or regulatory. Or operations, or whatever, wherever they are, to sit, want them all physically together. It's amazing how much more work it's done. It's been a challenge. It was a challenge during covid. We did as good as we could have done. We did much better than I thought we were going to do. But man, the efficiency of sitting together, being able to turn your head left or right, ask questions and and I think teams work really well together when you do that. And I'll just plug you mentioned, you know, going out to lunch one time, you know, going out to lunch as a team, just team buildings, really, I found just just so when you realize people are sometimes people just think they're maybe at odds or fighting against each other a little bit. But do you realize, hey, we're, we're all for all friends. I can, I can challenge your your idea a little bit, and you know, I'm not, I'm not challenging you as a person, and that that's so important as a team to promote communication where I can just, hey, I have a here's my concern about that bond, or that design of that weld, or something that's a that's a really powerful thing to have. I really like there were people that and I need to do more of this. But I really love when the schedule is, like, blown up to five times its size, and put on the put on the wall, and just said this, this is the schedule. This is where we are. This is what we have left to do. I love things like that. It just helps put everybody on the same page and so, so yeah, just that physicality of being by each other, being able to see the same schedule, being able to talk to each other regularly.

Aaron Moncur:

Yeah, and I'll add to that, especially if you're in a leadership position, being there with your team, you might not be making the all of the engineering decisions, the day to day, nitty gritty engineering decisions, but just being co located with your team and being able to observe the interactions between your team members is so important. There have been times when I've I haven't been part of the conversation at all. I've just been there quietly observing, and it's not like, you know, hovering over them, watching, turning my head back and forth as different people. I was just at my desk, doing my thing, and kind of overhearing conversations, and you pick up on things that, oh, I'm not sure about that, right? And then 20 minutes later, you approach one of the desks. Oh, hey, what you know? I heard something about this mentioned. Well, tell me more about that. What do you think about trying it this way? So I think that's huge. Well, TJ, wow. This has been great. Lots of really fantastic insights and and experiences shared. I think let's, let's do one more question, and then we'll kind of wrap this up here. So accelerating the speed of engineering, I think this, I think we'd all agree that it involves many different factors we've we've talked about a lot of them already. If you had to choose just one, just one thing that you feel most significantly facilitates faster engineering, what would that be?

TJ Strang:

I kind of, we kind of talked about the power of teams, the power of the small, empowered team. So the giving them, giving a team of, I mean four to six people, the power to make decisions and and with a you like you added up with a purpose and let them and let them go. I think that's why we see so much success out of startups, is when everybody's on the same page, marching to the same same thing. We're not we're not getting pulled in a startup, you're not getting pulled a lot of different directions. It's everybody's got the the arrow pointed in the same direction. It's really amazing. And if you look back, I love stories about the Apollo program and the Mercury program and, you know, and those are larger teams, but they're broken into small teams and and just what you can get done when you are empowered to do so. And when you all have the arrow pointing in the same direction, it's, I mean, it's, it's miraculous. You can, you can accomplish miracles.

Aaron Moncur:

Yeah, yep, I love it. What a great answer. Great way to finish up our our podcast episode today. TJ, thank you again. So much for being here. How can people get in touch with you, if they want to reach out and maybe get some advice from you, or just network?

TJ Strang:

Yeah, I think LinkedIn is probably the best place to look for me. I'm at a company called Atraverse now. Right now, we're just started doing we just started our we just launched. Our first product just a couple of weeks ago, and we're excited about that, but LinkedIn, I'd love to accept all incoming connection requests and love to love to get to know people

Aaron Moncur:

Wonderful. Well. TJ, thank you again. So much for being on the podcast today.

TJ Strang:

Thanks for having me.

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.

People on this episode