S5E40 Tony Dietz | How to Accelerate the Speed of Engineering, Episode 4

In the fourth episode of How to Accelerate the Speed of Engineering, host Aaron Moncur interviews Tony Dietz. . Tony emphasized the importance of clear communication, focusing on objectives, deadlines, and effort levels. Dietz shared examples from his diverse background, including a NASA wind tunnel project and a cost-effective earplug test using a $7 heating pad. He highlighted the value of field interaction with customers and using simple tools like Lego for prototyping. Dietz also stressed the need for daily team meetings to maintain focus and address roadblocks. He warned against rushing critical tasks without proper analysis, citing a failed superconducting cable test as an example.

Main Topics Covered:

• Communication and Bottlenecks in Engineering Projects
• Ignoring the Customer and Tools for Failure
• Creating Psychologically Safe Environments
• Cross-Disciplinary Communication and Documentation
• Introducing New Technologies and Tools
• Unconventional Approaches and Field Interaction
• Lessons from Failed Attempts to Accelerate Engineering
• Key Factors in Accelerating Engineering

About the guest: Tony Dietz is the President of Paxauris, where he leads the development of innovative hearing protection products. With over 30 years of experience, he previously worked at Creare, leading R&D projects in advanced airdrop technology and cryogenic systems, and at NASA Ames as a Senior Research Scientist. Earlier, he served as an Engineering Officer in the Royal Australian Air Force. Tony holds a Ph.D. in Mechanical Engineering from the University of Oxford and a Bachelor’s in Aeronautical Engineering from the University of Sydney.

Links:
Tony Dietz - 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

Chapters

• 0:00 Communication and Bottlenecks in Engineering Projects
• 8:24 Ignoring the Customer and Tools for Failure
• 12:56 Creating Psychologically Safe Environments
• 18:41 Cross-Disciplinary Communication and Documentation
• 23:13 Introducing New Technologies and Tools
• 31:13 Unconventional Approaches and Field Interaction
• 36:20 Lessons from Failed Attempts to Accelerate Engineering
• 41:52 Key Factors in Accelerating Engineering
• 44:04 Conclusion and Contact Information

Transcript

Tony Dietz: 0:00

That's one of the themes I'd like to pull out of here, is is hustling and focus the question you're trying to answer. Try to get to that question as quickly as you can. And you can always backfill the details later, but if you can get a quick look at the answer, that'll often get you 90% of the way there. And then you can redirect your efforts if you need to, or take a different path.

Aaron Moncur: 0:33

Hello and welcome to the being an engineer podcast today, we are thrilled to be speaking with Tony Dietz, who is the president of Paxauris, where he leads the development of innovative hearing protection products. With over 30 years of experience, he previously worked at Creare, leading R&D project in advanced AirDrop technology and cryogenic systems, and at NASA Ames as a Senior Research Scientist earlier he served as an engineering officer in the Royal Australian Air Force. Tony holds a PhD in mechanical engineering from the University of Oxford, and a bachelor's in aeronautical engineering from the University of Sydney. Tony, thank you so much for joining us today.

Tony Dietz: 1:20

Thank you, Aaron, pleased to be here.

Aaron Moncur: 1:22

Well, this is episode number four of an ongoing series about how to accelerate the speed of engineering, and I've been really excited to talk with you about this. I think we've got some great questions to go through, and it's going to be beneficial for everyone who's listening all the engineers out there who just want to get things done faster, cut through the busy work and get to results. So before we get into how do we speed things up, let's maybe talk for just a minute or two about what are some of the things that you have seen slow engineering projects down unnecessarily.

Tony Dietz: 1:56

Yeah. Thanks, Aaron. These are, I think, very worthwhile questions and a great goal. I've had a varied background as you as you saw, experience as a as a research scientist, but also as a flight test engineer, and then as a researcher development engineer, and now in the entrepreneurial startup community. And each one of those, I think brings a very different perspective, but also there's some common themes which which run through. So I'm going to pull from all of that in our discussion, hopefully wonderful to get to your question bottlenecks. I think the big one is communication. I think always communication is key, and that's one where I've seen really smooth and speed up the process, but also slow things down. And so when I'm kind of onboarding or briefing new engineers, I always tell them, like at the beginning of a project, any job, communication is critical, and you always have to ask for three things. You know, one is the objective of the job, the second is the timing or the deadline you need to meet, and the third is level of effort, and that's sometimes what's missed in the communication. You know, there you may be asking someone to do something you think will take them an hour and they set off for a week or a month long task, because you haven't communicated the level of effort you want from them. And that's important. And then it's also important as that job gets communicated to people working for the engineer, that they also communicate those three things, what the what the task is, what the timing is, and what the level of effort that they want, and then keep the loop going. Keep the loop going down to the people you're tasking and up to the person who tasked you. And that's also critical, and that's usually where a job falls over, as if that loops broken and someone's not reporting back. And and I always tell my engineers, don't assume, because you gave some a deadline that they're going to keep to it. And then call them up on the day that products do or you expect to get your component from the supplier, and then they say, oh, you know, it's not going to be ready for another month. And you said, Well, you know, we agreed on this deadline, and they're saying, well, things change, so you have to be the squeaky wheel. You have to be always in the loop. You have to be the one that they know, oh, we got to make sure we need this deadline, because he's been on the phone to us every week telling us how important it is, so we won't let his job slide. And I have a good example of that from my time at NASA. I was building a wind tunnel. And I went to the kind of welding shop where they were making the contraction. That's the big open face at the start of the wind tunnel, which, you know, sucks the air in. And they said, When do you need this buy and just, just new in America? And so I said, about a. Fortnight, it'd be fine. And then I give Fortnite means two weeks in Australian or English. But I came back to the two weeks later, and I said, Oh, how's how's it going? And they said, I haven't started yet. And I said, But you agreed on a fortnight? And they said, Yeah, we didn't know what that meant, so we just ignored So that was such a good story. It was poor communication either way in that case, but then it took me another two weeks to get my wind tunnel. So wow, that was on me.

Aaron Moncur: 5:33

Wonderful story.

Tony Dietz: 5:36

So that's what I say. Don't just assume I you know, that people are keeping to it. I had a couple of others, I think of like bottlenecks. One is, is overworking the problem, and that comes back to that level of effort of communication, often, often, you know, you'll give a new engineer a task and they're so gung ho that they'll just work it to the nth degree, and that'll slow the job down. But that also happens to more senior engineers as well. Then that's one of the themes I'd like to pull out of here, is is hustling and focus. You know, the question you're trying to answer. Try to get to that question as quickly as you can, and you can always backfill the details later, but if you can get a quick look at the answer, that'll often get you 90% of the way there. And then you can redirect your efforts if you need to, or take a different path. But if you, if you've like, dotted all the I's and crossed all the T's and built this wonderful foundation, when you haven't even looked at at the thing, you know that you're trying to achieve that that can be a big problem. And we, we had an example of this just just last week. I i was my company is developing a new type of earplug. It's a inflatable earplug, which is easier to fit and more comfortable. And we're looking at the Australian standards, the testing would need to do to get it qualified in Australia. And they include this heat soak. It's like a 50 degree seed. So it's like 120 F for 16 hours, between five and 15% humidity. And then you do your test now that that is not included in any of the American regulatory testing we've done. And so I tasked my junior engineer to go and get us, you know, tell us we're going to pass this test before we go off to the regulatory testing and spend a whole lot of money to find out something we hadn't seen. So I checked within, checked with him the next day. And he's, he's, he says, Well, how much can we spend on this? Because he's priced out all these incubators. And he says, you know, like, the cheapest I found is about five grand. They go up to 10 grand. And I just looked at him, and we live in Phoenix, it's 100 degrees outside, and about 10% humidity. I just came in from the garage. Let's put the ear plug in a cooler in the garage, and we we brainstormed a little bit further, and he came with a great idea of adding a $5 heating pad used for lizards and aquariums. And we got the test done for $7 and the results ready the next day. So that's a good example of what what do you need, and how quickly can you get there?

Aaron Moncur: 8:24

I can already tell this is going to be a fantastic episode. These are wonderful, wonderful examples. They ring so true for me. Just music to my ears, you're fine about the Fortnite. Oh yeah, go ahead. Go ahead. Oh,

Tony Dietz: 8:39

Sorry, I was cutting you off, but my final one is, ignore. Don't ignore the customer. And I'm sure that's, that's one that you can relate to. But so many times, if we're developing something, but we haven't asked, you know, run a field trial with customers, or got out and talk to the end users, then, you know, well, just develop the wrong thing, and you can't even trust your contract or the person tasking you. You really need to talk to the end users, who are your your true customers, and make sure you understand what what they want.

Aaron Moncur: 9:12

Yeah, excellent. What? What are some tools that you have used to fail fast and fail inexpensively.

Tony Dietz: 9:27

Many, many tools. Often it's whatever's at hand and and this trying to find the quick answer. You know, the good example was that ear plug in a cooler and the garage. Use, use. What's there? One surprising one I have used a few times is Lego. Often, if I'm designing a mechanism or trying to to get a quick answer to a problem, you can build something out of Lego, or use a Lego robot or something like that to get you to the answer. And so sometimes you'll be working through. The lab, and you'll see all this high tech equipment, and you'll see this little Lego machine running, and that was just the quickest way to get to the job. And having coached Middle School Lego League robotics teams, I'm surprised how much you could do with Lego, but that's also possibly the tool I know. But for example, we we have NL, NL lab here a sound booth where we do testing of our earplugs. And so we wanted to fire off a status pistol in there to get loud impulse sounds so we could measure the how the earplug works. And so I was trying to figure out how we could remotely activate the status pistol, because we wanted to close up the sound booth thing and then not be exposed to the to the noise ourselves while we're doing multiple firings. And it turned out the easiest way was just to get the little Lego robot drive the Legos on a mechanism which pulled the trigger, and then we could Bluetooth into the robot. And now we had a remote firing mechanism for our status pistols.

Aaron Moncur: 11:07

That's fantastic. It reminds me of, are you familiar with the cooking style sous vide?

Tony Dietz: 11:15

No, no.

Aaron Moncur: 11:16

It's where you warm water up to whatever final temperature that you want your meat cooked at, maybe it's 150 degrees or 140 degrees, whatever, but it's this just kind of circulating bath of of heated water. And so you cook your meat in there, usually in a airtight, not a Ziploc bag, but like a vacuum sealed bag, so the water doesn't actually touch the meat that you're cooking, but you leave it in there for a long time, three hours, four hours, five hours. So the meat very slowly comes up to temperature, but then it just sits at that temperature. And so you get a very, very even and accurately cooked piece of meat, and then you can throw it on the grill for 30 seconds, you know. And kind of CharBroil the outsides for that nice, nice crust, but the there's a tool that is sold. It's fairly inexpensive, maybe$100 for one of these soothed, I don't know, call it a wand, and it kind of hangs off the side of a pot, and there's a heating coil, heating element on the bottom, and there's a little pump that that circulates water, and it does a really great job of, you know, bringing fluid up to a temperature and holding it there. I mean, it's not like an industrial piece of equipment by any means, but for $100 it's a great solution to do this. And we've, we've actually used that and some testing that we've had to do, you know, maybe, like you're a junior engineer, you go out and you look for an industrial solution. Well, the cheapest one's $3,000 right? Well, let's take this sous vide one to just stick it in, and$100 later, great, done. So I just, I love all the things that you're saying.

Tony Dietz: 12:50

So, so true. And that's another mantra, is buy to build. And if someone's already done all this development and reduced it to practice and scaled it, we can benefit from that?

Aaron Moncur: 13:01

Absolutely. Yeah. One of the areas where I have seen engineering slowed is when engineers don't feel psychologically safe to speak their minds and to share what they're really thinking, whether it's a concern or maybe an idea about how to do something better. What? How have you been able to create environments where your team feels really safe, to to be a little vulnerable and and share their ideas?

Tony Dietz: 13:34

Yeah, that's a that's a really great point, and I think very important. At my previous job, I was the new engineer supervisor, so I would onboard all the new engineers. And I think that onboarding the new engineers is a key part of that, making sure that they understand the expectations of the organization, how to operate in it. We would give them a list of 10 commandments for new engineers so that they wouldn't, you know, they'd know how to fit in the culture and not not do the stupid new engineer things everyone does. I think that's important. I think buddying someone up when they start is really important so they know a safe person they could go to to ask all those questions. Another key one is I think something good, which we've, we've done here, is to have environments where numerous feel they can ask those, those questions. And so, for instance, one thing I noticed coming from England, Australia to America, was the lack of tea time. This is another theme I have for productivity. But in in England and Australia, there is rigid tea time at 10am and 3pm every day and whatever. Group you're working in. It, be it a military unit, be it a laboratory or a research group, everyone would come together for tea in the tea room, and you'd have, you'd have the commander there, all the way down to the most junior engineers. And that was always a very relaxed environment, where if you had a question, say, for the Group Captain, you could go up and say, Oh, sir, I had this thing I was wanting to ask you without having to go into his room standard attention, salute him, interrupt what he's doing and ask your dumb question. So making those environments is important, and I found in in the States, you have to be intentional about making those environments, because it doesn't happen organically through tea time. So we've at this startup company which which we have now, we've intentionally tried to create that situation where the interns or the junior engineers can interact with the senior engineers and ask their questions without feeling like they're interrupting them or imposing on them. So we now have a, you know, a 930 stand up every morning for 15 minutes, just where we all talk about what we're doing that day, and if anything's blocking us, and if anyone has any questions and that often, then will flow into more detailed conversations. And I think that's just creating that environment where it's not a very official meeting or something, but you can get your questions answered as important tea time.

Aaron Moncur: 16:29

This is the first time I have ever heard Tea Time recommended as an engineering productivity tool. Absolutely it's a productivity I love it. Yeah. Okay, great. 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, we're privileged today to be speaking with Tony Dietz. I almost feel like I should call you sir Tony Dietz, I don't know, just the English, Australian the Royal Army and and you're so knowledgeable, clearly. But we'll stick with Tony for now, I guess,

Tony Dietz: 17:34

to wait for the night to come through.

Aaron Moncur: 17:37

It's probably not far off. Not right, just a little longer. All right when you have and maybe, I'm sure it is the case right now at Paxauris, working in cross disciplinary environments, what are some best practices that your teams have implemented to facilitate not just communication, but communication between different, you know, across different functions. You know, electrical engineers to mechanical engineers to software engineers, etc.

Tony Dietz: 18:18

Yeah, that's a with us. It's we're a small startup, so we're three of three to five engineers, and so those cross disciplinary communications are have not really been such an issue, because you can just go and talk to the person. The meetings I talked about are a good forum to do that. Where that's been, I think the most challenging has been when we're working with consultants, outside groups. Often that is where those those problems fall over, and it's usually in, in specifications, requirements and documentation. One of our big I think, challenges has been adequate documentation. You know, as a startup, want to work with one outside company then another, and there's through the pandemic, there was a lot of change over of personnel, where you get someone up to speed, and then that leave, and you have to bring another person up to speed, so making sure all that documentation is captured and something that might make sense to you in a meeting three months later or six months later, you've forgotten completely why we had to design the antenna this way, or why we couldn't, you know, use a button here, or some of these, these kind of questions. So we started just trying to capture that information when it happened in a big design specification documents, and then a whole bunch of other documents, which we then keep as living documents and continually update. And that has been a huge, huge help. And that's also I found in previous things, if something. It's outside your expertise, and someone explains it to you, and you make a decision, write it down, and write down why, and then you'll be able to refer back to that. How do you

Aaron Moncur: 20:10

organize those notes? One of the challenges I've found is maybe something gets written down, but then we have I'll be a little vulnerable right now. We have lots of SOPs at pipeline, and we every week we have a team meeting. Well, we have several, but in one of these team meetings, there's an engineer who is assigned to pick one of the SOPs and not read verbatim through the whole thing, but just remind everyone that it exists because they're enough of them out there that we just we don't remember all of them, and more often than I care, to admit the SOP or the standard that's shared is out of date somehow. So that's one problem, but, but then we've completely forgotten that this, this SOP, even exists. Have you found any any good ways to help people remember, like, where the right documentation, where, where those notes are kept?

Tony Dietz: 21:20

Yeah, we're still struggling with that. Currently, we've tried a few different different ways. Our current approach is we're organizing it by product. It was by project before we work in Microsoft Teams, which is really a institutional platform. It's not, not great for startups. You need a dedicated IT person to understand even the thing often, but we, we've, we've picked certain aspects of that, and by organizing the teams around products, then a lot of the knowledge can be captured in that channel, or in that particular team, the communications, and that makes it easy to find things. It's important the thing that you're storing all the information is searchable, so that you can search keywords. And that's where, coming to a few very large documents, we're just dumping all the data, it's then searchable, and even though it might be 100 pages long, we can find the bit we're looking for. Yeah, so I think that's important, and then we don't use you can drown in operating procedures, like if, if no one remembers it, and and you it's out of date, then it's probably not that valuable if it's not being used, you know, often. So I do, I do have procedures, but therefore workflows, like accounting, billing, things that you do monthly or weekly that you need, but often on the engineering side, because we're a startup company where we're trying to be lean and and fluid and adaptable, and we don't want to be tied down in bureaucracy. Yeah,

Aaron Moncur: 22:59

I think if I had to do over again, I would, I would not create a new SOP every time something new happened, wait, wait until it happens a dozen times, and then create an SOP or something like that. All right, what has there ever been an experience where you've introduced either a new technology or a new tool that somehow has significantly increased the speed of engineering.

Tony Dietz: 23:27

So I think our daily meetings has been been one that we currently, has made a big difference to the productivity of our team. We started off with just weekly planning meetings, then we added a second meeting, and then we went to this daily stand up. And I got that idea from talking to a couple of other teams who are working remotely, and especially in the software development area. We tried adding some of the tasking which they use in software development, but but found just that that daily check in with the with the team was was super important. It made everyone focused on what they're doing, and also it helped them to address any roadblocks they were having. And that daily basis is good because it, you know, it sets everyone up for the day, and then make sure their product through the day. And then it also adds this element of, well, I can't say the same thing I was doing yesterday.

Aaron Moncur: 24:30

Accountability. There's a little, little

Tony Dietz: 24:32

element of accountability to keep you moving forward. Yeah, that's a procedural thing. In terms of specific tools. Probably the biggest thing that that's happened through my career is as the rapid prototyping that that's really come so far along as of as I've been in developing different products. And so even in the last three years, we you out here. Plugs are made from silicone. So we use injection molded liquid silicone rubber to make the parts those molds, even if you're using single cavity, small run number molds, they're still going to cost you a couple of grand and two weeks to a month to make. And so just two, three years ago, they introduced the capability to print silicone parts. And so that for us was a game changer, because all of a sudden we could be turning around our designs in days and and weeks instead of months. And so that was, was a real, a really helpful thing, another tool that I introduced into the work we're doing. So we develop earplugs, and we make small changes to our design, and then we need to measure the effect. And because an earplug interfaces with the human body. Then the way you measure whether an earplugs working is you play a sound for a person. They then, like a hearing test, they note when they can hear the sound at the threshold, put the earplug in, play the sound again louder, they note it again. And now you've got a measure of the attenuation, and you have to do this across the frequency range, so at eight different frequencies, takes about 15 minutes to run this test, and then you need to run it with maybe 10 to 20 subjects to take into account human variability, so that test can take a week. And then you get your answer of whether your design has has made a difference or not, and the standard deviations are huge. There was shocking to me when I went from the world of aerospace, where we're dealing with safety factors of 1.2 and standard deviations in our tests of of you know, in the percents you test a human, and suddenly your standard deviation is 50% on the me, and you just, how can you, how can you develop something when your thing you're testing on is so variable, like whether they had a cup of coffee that morning or got a, you know, bad night's sleep, or completely changed the results, or whether they went to a rock on, yeah. So what we developed was a biofidelic head model, which we printed. We got a scan, an MRI scan, of a human's head. We segmented out the skull. We 3d printed the skull. We then put a brain simulant in there, and molded the outer tissue, including the ear canals, and we put little microphones where the eardrum is. And now we had this, this head, which was a repeatable test platform, and that was a game changer. We could then make it small, design, change, test its its effect on the head, and then repeat that, and the head always gave the same data so that that that's another example of it's not just the procedure, but the test, the validation approach,

Aaron Moncur: 28:03

is also very important. Purpose built tools, is what I'm hearing there, if you were to generalize it, yeah, we work with a lot of motors and pneumatics here, and we found that it was taking us a long time to build a new circuit every time we wanted to control a motor for a simple test, you know, not not for production, but just to test something, develop a new process in the lab. And we had a variety of different methods of doing this, and Arduino, or some, maybe even a cheap PLC lab view right there, a variety of methods that we tried. And finally, we just, we just built, kind of a general purpose controller that's really, really flexible and doesn't require any coding knowledge. It's just a drag and drop. It's not lab view. It's, it's actually a product we were we have productized this because it has changed so significantly how we control motors and pneumatics, and it's so much easier and so much faster. And so that's an example of a kind of a purpose built tool that we did internally, which is significantly increased our efficiency in that area. Yeah,

Tony Dietz: 29:21

that's a good point, because if you identify where your real inefficiency is, then often you can solve that with with a tool that will then pay, pay you back 10 100 fold. An example of that is we were, we were doing a flight test on an F 18. There was a loads test back when I was in the Australian Air Force, and I was in in charge of of the as the test director of of the flight loads testing. And we'd taken an aircraft and we'd covered it in strain gages that had maybe 200 strain gages on it, and then the test pilots were flying it through these loading conditions. And there. Flying daily. And so they would go out fly land, and we would end up with an hour's worth of data from 200 strain gages to review before the next flight, which was the next day. And so we found during the test series, we were just falling behind, to the point where we were maybe a week behind the testing. And then if we identified a bad Gage, it had the potential to have invalidated all the testing done. Yeah. And if you think of the cost of flying a jet for, you know, an hour a day that that was running into the potential millions of dollars. So we were pretty stressed out about and, yeah. And so what I did before the next series of tests was I wrote a program that then would, first of all, I had the plane before every flight do what we called a phasing maneuver. So he would just do repeated like a pull up a pushover roll, left roll, right bank turns to exercise all the strain gages with repeatable maneuvers. And then I wrote a program which just compared the strain gage peaks and averages for that maneuver from flight to flight. And then instead of checking each Gage for the whole test, we would just run down this list and see if anything had changed, and it would then notify us if there was a 20% change in any gage from that maneuver. And so then beautiful went from being, you know, eight hours of work to analyze a flight to 10 minutes. And that was a game changer as well.

Aaron Moncur: 31:34

That's huge, brilliant. That's great. How about has there been anything unconventional that that you can think of that, you know, some approach you took to expediting engineering processes. I mean that example you shared earlier, of sticking your product in a cooler in the Phoenix garage with a heating pad. That's a great example. But anything else like that, just kind of unconventional attempts. Yeah,

Tony Dietz: 32:06

like that. The Legos is a good word, too.

Aaron Moncur: 32:09

That is a good one. Yeah,

Tony Dietz: 32:10

I want one unconventional thing. Maybe it's unconventional, maybe not that I like to do is get my engineers into the field, get them interacting with the either the end user or the customer, because I think that really gives them a better feel for the problem that they're trying to solve, if you understand where it's going to be used. And engineers tend to, you know, love being head down solving the problem, but they also are good at distilling data and understanding the issues. So if you get them out into the field, interacting with the end users, they come away with a very different perspective and a bigger picture, which I think helps them on that task. And an example of that is we were doing a computational fluid dynamics model of a of a skydiver, so a person in freefall, and this was for the army, because they were having this issue where parachutes would deploy and then burble a bit. It was called hesitation before that open and if they get caught in in a particularly challenging wake from the from the skydiver or the parachutist, then it may not open at all, which you can imagine, is a bit disconcerting for the parachutist. So we, we developed this model to try and identify if certain gear configurations made bad wakes, and we were validating it by testing the parachutes in a vertical wind tunnel and and I wanted my engineers to all go in the wind tunnel so that they could see, kind of how varying your arms and things around would affect the forces on your body, and get a little bit of an understanding of How the model that they're developing interacted with the wind and the free stream, and we did a risk review, and it was, it was knocked down by the the powers that be in the company, because they said, we can't afford to have engineers in a wind tunnel breaking their neck or something. But this, you know, their kids birthday parties in these wind tunnels. And I thought, I thought the risk was fairly low compared to benefit for the engineers actually getting to experience the thing they're trying to model. Because you could spend a lot of time in your in your computer, but there's nothing like understanding the real world so that you are so you can answer those questions like, I've spent a week modeling my little finger, but maybe the fingers don't even matter, right? Because it's just big hand movements.

Aaron Moncur: 34:51

We build a lot of one off machines, custom one off machines, and our team is. Huge to begin with. We do have a technician who does a lot of the assembly work, but we also have our engineers directly involved in doing assembly work, and we've had not a lot, but maybe a little bit of criticism here and there from a customer, saying, Why are you paying an engineer to be out here doing assembly work? And my response to that is always the same as what you're saying. I mean, if we were building 100 of these things or 1000 of these things, I would agree it doesn't make sense to have an engineer out there doing assembly work, but we're building one or maybe two of these things, and it never goes together, right the first time, right? There are always things that just don't fit, quiet or this mechanism didn't work the way we thought it was going to. And having the engineer there in real time building what he or she designed is so effective because they can just right away figure out how to solve that, as opposed to, well, some maybe, if you have a technician who just does assembly, maybe they, you know, put some duct tape on it and think it's fine, and then it breaks in the field. And nobody wants that. Now, it's a much bigger issue, but we found that to be really effective for one off builds, right again, not for production things. But I

Tony Dietz: 36:16

agree. I absolutely agree, and that also gives a nice communication between the engineer and the technician, yeah, and that feedback will be very important to the to the next design. Yeah,

Aaron Moncur: 36:30

yeah, yep. Absolutely. Have you ever? Have you learned any lessons from projects where maybe there was an attempt to accelerate engineering that backfired.

Tony Dietz: 36:44

Oh, yeah, of course, some bad ones that haunt me to this day.

Aaron Moncur: 36:55

Any that you're comfortable sharing, yeah. Well,

Tony Dietz: 36:59

I think the important thing that I've learned is this accelerate, but you also have to think of the consequences of acceleration. So there's a bang for the buck balance here. And so you need to go slow where the consequences of failure are high, and then you could go faster when the consequences are less. And so that that that's drilled into the flight test community. Obviously, where you're testing aircraft and you're pushing the edge of the envelope, you the consequences are fairly catastrophic. And so you the approach is called incremental testing, where, if you know there's a limit, you're trying to approach or approach it very slowly, bit by bit, so that you don't suddenly have a structural failure or a Deep Stall they weren't predicting or something like that. And in in my career where I did that wrong, well, not in the flight test, thank God. But I was testing a superconducting power transmission line. This was a cable which we are developing for hybrid electric aircraft. It's an enabling technology, because if you have a aircraft, this is where the jet engines are running a generator, and then you've got electric motors distributed along the wing. And so it has a lot of advantages from a efficiency point of view, but the copper cables, because of the amount of power you're trying to transmit from the generator to the motors is prohibitive. But if you can make superconducting transmission cables, then the weight goes way down, and it becomes possible. And also the technology would be great if we could get it to work for say, powering the east coast from Arizona or America from Australia, a DC superconducting power transmission line can send power very long distances without the losses or the phases going out of whack. So that's what we are working on. We'd spent two years building the rig, because it has to be cryogenically cooled to about around this one was running at 15 Kelvin, so very, very cold, and so we had a lot of insulation. It was all in vacuum. And we'd run out of money. We'd run out of time, or at the end of the project, we needed to hit our goal, which was, I think we need to send 10 kilo amps through this cable. And so we had a call. We'd be calling it for two days. You know, where I'm now in the situation, wearing an overrun, and it's Friday afternoon. We're sitting at five kilo amps. And I'm like, Okay, let's go for it. We can hit our target here. And we went to eight kilo amps. And so like, Let's go for 10 and and the joint went resistive, and you put till 10 kilo amps through a resistive joint, and the whole thing just melted. But. Like, and then, of course, you know, extra funding came through, and we got an extension, but I'd blown, I'd blown the system. That's, that's what I look back and said, I should have taken a deep breath, stepped away, analyzed the data, taken the incremental approach, but the like Golden Apple was hanging there, and I just

Aaron Moncur: 40:28

was that, was that an unforced error, or is that just an example of of, sometimes you don't really know, and you take a risk, and sometimes it pays off, and sometimes it doesn't. And there's an element of luck in it.

Tony Dietz: 40:44

It was unforced in that if we'd stopped analyze the data, we would have seen that joint going resistive, the hit was there. If we'd analyzed the data closely enough, and so pushing on without taking that step, that was the mistake. So I'd say it was an idea we could have, could have recovered. Well, it's,

Aaron Moncur: 41:05

it's great that you can at least identify exactly what, what the mistake was, what you specifically, what you could have done differently, as opposed to shoot it blew up. But I'm not really sure what lesson to take from this. That's a win, right there, right

Tony Dietz: 41:20

and, and my other lesson is, you know, you have to kind of sometimes drown out the noise of schedules and and deliverables and targets and and focus on on the task at hand. Because, as a manager, that's hard to do because you've got all these other pressures on you. But if, if you let those that win you can, it could cost you a big setback. Yeah, yeah.

Aaron Moncur: 41:43

Well, as we've discussed all this clearly, there are many factors that contribute to being able to accelerate the speed of engineering, and this is a completely unfair question. I'll put that out there right away. But if you had to choose one that you felt was the most important factor. What? What do you think that would be?

Tony Dietz: 42:08

I think for me, it's, it's back where we started, the hustle. You know, know the question you're trying to answer, try to get the fastest hustle towards getting that answer. That answer as fast as you can, and then you can always go back and backfill, backfill the details. Another challenge is, is knowing that you're asking the right question. Yeah, when you know the question, then hustle to the answer as fast as you can. That that time and time again is has helped me ask the right question by answering many wrong ones beforehand.

Aaron Moncur: 42:48

Yeah, okay, so get to an answer as quickly as you can, even if it's not the perfect process to get to the perfect answer, but maybe if you get 80% of that answer, that's enough, and you probably did it in 20%

Tony Dietz: 43:01

of the time, exactly, and then you can iterate to improve your solution. Yeah, based on customer feedback,

Aaron Moncur: 43:10

right? I have a friend who is on the podcast a little while ago, Chris Julian. He likes to say, maximize goals or maximize shots on goal, which I think is just another way of

Tony Dietz: 43:22

absolutely go. Said, I like that. Yeah.

Aaron Moncur: 43:27

All right. Well, Tony, what what a privilege it's been to get to know you a little bit and hear all of your wonderful, wonderful insights and wisdom about methods and protocols for accelerating the speed of engineering. Thank you so much for being on the show with me today. How can people get in touch with you? Oh,

Tony Dietz: 43:49

well, we were Paxauris That's P, A, X, A, U, R, I, S, and you can go to our website. We have a newsletter, which you could subscribe to to find out what we're doing. Our company is making a new type of earplug for hearing protection, and actually, for anyone who wants quiet, our motto is a better way to quiet, and Paxauris itself is Latin for peaceful ear. And now earplugs are super cool. We've been funded by the Army and the Navy to develop them. It's a fluid, inflatable ear plug, so you stick it in your ear, and you push a bulb, it inflates there with a nice, soft, secure, acoustic seal. And we think it's going to revelize, revolutionize the way people enjoy their lives in quiet.

Aaron Moncur: 44:38

That just makes so much sense to me, that's an inflatable earplug, right? It just naturally conforms to the contour of your ear and organically creates a seal that makes

Tony Dietz: 44:52

it in, push the bulb and it inflates brilliant. I'm just showing Aaron here. You can't see this the folks. On podcast, they'll have

Aaron Moncur: 45:02

to go to your website, pexorus, and check that out for themselves. Now, are you selling this to is this just like a commercial product you mentioned the army? Or can you know anyone go out and buy one of these?

Tony Dietz: 45:16

We're taking pre orders now. Actually, when the new website goes live next week, we'll be taking pre orders, but right now, we're in in kind of the pilot study phase, so we're testing them with the Navy and with some industrial early adopters, and pretty soon with the Phoenix police force, and just to get the get customer feedback before we scale. And that's the next part is, is, right now we're, you know, at that low volume where we can't bring the price down yet, but in the next six months, we'll be scaling, or even three months, we'll be scaling up our manufacturing so that we'll be able to sell them in volume to consumers.

Aaron Moncur: 45:57

Super exciting. Now this is a passive noise cancelation, not active? Is that accurate?

Tony Dietz: 46:04

Yeah, we have the earplugs passive. We also have a hearable which is an electronic device. It's also relies on passive hearing protection, but it actually measures the amount of noise inside your ear canal, so you know your actual noise dose. And it has the transparent here through so it's, you can still hear your environment for situational awareness and communications. But if there's a loud sound like a gunshot or explosion or jet taking off, it'll it'll reduce the the hearth to safe levels.

Aaron Moncur: 46:36

Okay, just for a point of reference here, how? Does the Paxauris earplug compare against something like like Apple AirPods pro with active noise cancelation.

Tony Dietz: 46:50

In terms of attenuation, they're they're similar. However, the AirPod Pro will give you the noise reduction works up to the sound hits a certain level where the airport broke. Can't overdrive it anymore. I can't cancel it. And beyond that, the sound could become damaging. Whereas the passive noise reduction is independent of the sound level, and our Fit is much better. You know, 50% of people, I mean, a few studies have shown if you've got an ear that works for the airport, probably that's great. If you don't, then the seal which you're getting may not be as as as good, whereas, yeah, fluid seal works for the for a broader range of people.

Aaron Moncur: 47:37

Yeah, that's a huge deal that that seal, that just naturally form fits to your own anatomy.

Tony Dietz: 47:43

That's why you get the airport pros or anything they'll come with, you know, eight or 10 different tips to try to get one that fits. And some folks it just, I'm one of them. I just can't get it to fit.

Aaron Moncur: 47:57

So it sounds like the the Paxauris earplugs. I'm sure they're useful for, you know, any environment where you want to attenuate noise. It sounds like they might be especially useful for environments. They're, they're especially loud because there's, there's no real limit to, you know, the like Max decibel level that it can reduce that noise, right?

Tony Dietz: 48:24

Yeah, it'll always give you 3030 decibels or 26 decibels, no matter what the level. But the real advantage is, is that it's consistent. So a foam tip, you know, could give you anywhere from 10 to 30 decibels, depending on the fit, whereas, whereas our Fit is more repeatable amongst different people, because we get a consistent fit. And the other is just how easy it is to put it in and out, like, if you if you're finding you need to put your plugs in and out a lot during the day, then now ours is a good solution.

Aaron Moncur: 49:00

Great, wonderful. Well, Tony, thank you again so much for being on the podcast. What a delight getting to know you.

Tony Dietz: 49:08

Yeah, thanks for doing this. Aaron, I think wonderful questions. You've obviously put a lot of thought into this, and I think it's a it's a worthy goal to increase the speed of engineering safely and efficiently.

Aaron Moncur: 49:21

Thank you very much. Tony. I appreciate it very kind of you to say 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. You.