Think Like an Engineer: First Principles Thinking - UNDEFINED EPISODE 9

[Music] What's up everybody? Welcome back to Undefined Engineering. It's Christian. I'm here with my brother, Patrick, joining me from Colorado. Uh, we got a big one for y'all today. Uh, main topic of this podcast is going to be thinking like an engineer. So, what that entails is, uh, essentially successful engineering thought processes and methodologies that we use to be a successful engineer in the career field that we're in. Um, and that would be covering topics like the goal of an overall engineer, first principles thinking, and questioning your constraints, the black box, black box approach, problem-solving, and in general, thinking is a system. Um, and moving on from there, we'll get into the differences between senior and junior engineering approaches, uh, and get into some examples along the way as well in this podcast. And we'll, uh, also go over challenges for beginner engineers and how you can progress in your career field rapidly. That being said, uh, Patrick, how are you doing?

Doing good. Excited about the topics and diving in and learning more about all them stuff. But the viewer, me too. Learning just as much as the viewer is. Yeah, you know, that's a, this will be a fun one. It'll be an informative one. It'll probably hurt my brain a little bit as we go through it, that's for sure. Uh, before we get started, let's get into our current roles and like, kind of what gives us a little bit of credibility into what we're talking about. That way, people don't think we're just making things up off the top of our head. Um, Patrick, uh, current role and, uh, experience.

Uh, so had a bunch of internship experiences throughout college in manufacturing with like GM, E-controls, Standard Aero, Aerospace, and Automotive. Most recently, I was a design engineer within, uh, within utilities and things like that, and just now transitioning to a new role as a product engineer, uh, working with compressors and things like that.

Nice, nice. Yeah, that's awesome. Uh, I'm currently a senior quality engineer for an autonomous drone manufacturer, uh, covering all low-voltage systems in the aircraft. Uh, before that, I was a quality engineer at Tesla, where I worked on both the Model Y and Cybertruck, covering firmware and low-voltage systems for, uh, each one of those areas. And before that, I was a quality engineer at Toyota, where I was supporting the Sequoia and the Tundra. For that, I'm not going to get into internship experiences, had a few before then. Um, but yeah, that's kind of what, uh, got me here and talking to everybody here today.

Sweet. That being said, you want to dive right into it?

Yeah, let's do it.

Cool, cool. So the first topic I wanted to, uh, talk about is something that kind of Elon made pretty, pretty famous, uh, for engineers tuning into what Tesla was doing, what SpaceX was doing, uh, in the engineering world, and that's first principles engineering. Uh, Patrick, do you have any experience with like, what first principles engineering is?

You've never heard of it?

Okay, cool, cool. Yeah, so, uh, it kind of opened up how I approach problems and, and approached designs as an engineer. Pretty much like as soon as I heard about it coming out of, I think I heard of it when I was in college, but essentially, what first principles engineering is, it's a crucial mindset for problem-solving and innovation in engineering. Uh, and what it does, it essentially forces the, the engineer, uh, to break down complex problems into their, like, most fundamental components and, uh, really understand the core principles and truths that govern, like, a problem.

I'm stupid. I definitely seen that in classes, just haven't heard the term in a long time.

Oh, you've seen that in classes? Yeah. Oh, wow. I, they didn't cover first principles engineering when I was in, in college, but I'm glad to see that that's making its way into the, something else, maybe that's why. But I've definitely seen like the breaking down problems into, yeah, I'm sure, simple parts and things like that. It's touched upon when, like, you study lean manufacturing. So if you take in, like, a lean manufacturing class, I'm sure you've gotten into it. Um, yeah, it's a, it's a big fundamental of design in manufacturing anyways.

Moving forward, like, why first principles engineering matters, right? Uh, so essentially, like, the, the big thing about first principles engineering is it enables, like, you to drive innovative solutions by avoiding conventional con- straints. So, like, another big thing that Elon preached in his companies was always question your constraints. Don't be siloed into, like, a certain set of thinking just because it's always been done in the past. Like, always innovate and always try to do the impossible and find those, like, creative solutions to, to essentially drive, uh, success forward in your company. Um, essentially, like, when you're talking about first principles engineering, there's like four main things that are really, uh, you really want to essentially drive home as you're going through it. And that's, like, identifying your problem, so clearly defining what you're able or what you're trying to solve and breaking it down into, like, manageable components. Uh, deconstructing your problem, so analyzing each component to understand, like, its fundamental principles. Ask, what are your underlying, underlying assumptions? Like, what are the core facts? What actually matters in this situation? Uh, then reconstruct your solution, which is like rebuilding your solution from the ground up, just using fundamental principles, uh, that center around your problem. Uh, and experiment with, like, new approaches and technologies as you're going through it. And then the last step is just testing and iterating. So, like, implementing your solution and testing its effectiveness and doing this as fast as possible. And I think this is something that was tough for me when I got into the engineering world to, like, get used to, especially going from Toyota to Tesla. Toyota was a much more structured problem-solving approach where it was like, uh, essentially the 8Ds, uh, approach to problem-solving that, like, Ford, uh, created that or Toyota built upon, which is like identifying your problem, or identifying your problem, setting your target, like, uh, understanding where the problems occurring, setting or identifying root causes and, like, method of, of the problem happening, setting countermeasures, seeing your countermeasures through, and then, like, identifying the results. Essentially, it's like, big picture of what, uh, the 8D was. Yeah. Any questions on, like, first principles engineering and, like, how you, like, envision it happening in the, like, career field or, like, where you've seen it happen firsthand?

So, just like, in summary, it's just like, get rid of, like, all, like, the unnecessary information and stuff and accomplish tasks as fast as possible while also, like, still having innovative solutions and not just doing things by the book.

Exactly. Yeah, I, I really like first principles engineering because it sets you up with a problem-solving strategy that is centered around, like, Elon's three main core values in, in being successful in, in one of his companies, which is essentially, question your constraints, like, make your requirements less dumb, essentially. Why am I, why am I blanking right now? Uh, question your constraints, design out the part, uh, if possible, or and optimize your processes. So, I really like that, like, first principles engineering kind of gives you a game plan to, like, accomplish those, like, three main goals.

I do like the, the message it sends because I think especially going to big companies, it's, they have a lot of, how you said, like, standardization on how things should be done and solved if things happen because so much things have happened already throughout the company's lifespan. So, it's easy just for, like, other engineers and people to tell you, this is how it's always done, just do it this way instead of coming up with, like, a solution that could improve the whole process.

Yeah, no, that's definitely a huge thing. That's something that people will struggle with going to a big company for sure. Um, is walking in and not being able to change anything, not being able to optimize anything because you're walking into an environment that's so tightly controlled and so constrained that you're essentially having to go through, like, eight levels of approval before you make something happen that's right in front of you. It's, it's sometimes backwards. Uh, and it's what keeps companies like, like Boeing or Lockheed Martin from being able to compete with companies like SpaceX. Um, yeah, I think, I think people also entering the industry would be surprised of how, like, archaic some processes are in these companies, and there will be opportunity to improve processes, like, early on.

Oh, yeah, definitely, dude. That was one of the biggest things that, that, like, hit me in the face when I started getting into the career field, even at Toyota. Like, some of these things you learn in class, um, where it's like, oh, agile manufacturing, lean manufacturing, uh, eliminating waste. You think, like, every company was already doing this, but then you go into a manufacturing environment or any sort of environment and you're like, wow, this, none of the, uh, practices or, or methodologies that we learned to score being utilized here. Like, why isn't that happening? Um, it's pretty crazy.

Yeah, this isn't like manufacturing-based, but my previous job as a design engineer, kind of going with the flow, always trying to find ways to change processes and things. Like, for example, we had just a really, just outdated system of how we shared drawings. We would just email it back and forth. By the time, like, drafting, other, and other engineers got it, there'd be, like, 50 different copies with red lines from 50 different people. Oh, and two weeks of being there, me and the other new hires figured out, oh, there's a cloud server built into the software we use to edit the drawings. So we could all just collaboratively work on the same documents, same time. And they were just amazed by that. I was like, it's just amazing to me that no one could figure that out or even thought of that.

No, exactly. Kind of like a thing of, like, oh, there's opportunity for me to change something, bring it up, and you eliminated 50 steps of traceability. Yeah. Um, that could essentially lead to, like, a major failure. That's, that's good. That's awesome. So, I know, uh, theoretically, like, you don't hear first principles engineering a lot, but, like, when you see a problem in, in real life, like, what, what sort of mindset do you take towards, like, tackling that problem?

Patrick? I freak out.

Is there like a certain meth-? You freak out? You say, I just work here. I think I try to think of as simple as possible because I know, like, engineers, I feel like they tend to overthink things. So I just, while I'm looking at a problem and I'm thinking of, like, possible solutions of how I should approach it, I'm thinking of, like, try to keep those as simple as I possibly can because most of the time, the problems aren't, don't need a mastermind to fix them.

Yeah, exactly. And I think that hits on the first principles engineering aspect, like, make it as simple as possible, don't overcomplicate things. Um, it's so easy to, to start over-constraining and over-inflating your problem into something that just doesn't make sense. It's kind of like when you're in a meeting and you start the meeting with one subject and then you start rabbit-holing and you start solving problems that have no relation to, like, what, what y'all started the meeting in the first place. Um, it's kind of like that. That's, it's easy to get down that rabbit hole and snowball, uh, into something that just essentially doesn't matter.

Yeah, super important to, like, understand your scope and not just, yeah, rabbit hole out of it, like you said. Yeah. But in terms of, like, actually solving a problem that's in front of you, is there, do you have, like, any defined method that you try to, to stick to when you, when you approach a problem? Like, do you have a standardized way of, like, looking at something, or is it free-flowing and, and constantly changing?

Kind of more free-flowing. I wouldn't say it's like, have a standardized way. I know there are probably standardized methodologies to go about solving a problem, but I just kind of free-flow, go with the flow.

Go with the flow. Yeah. I mean, that, that I've definitely done that a lot of times in the past, actually. I still do that all the time. Um, but there is one method that I've kind of like stuck to and gelled with really well, and it's called the black box approach. So, essentially, what the black box approach is, it's a certain problem-solving method, um, of analyzing systems by, like, focusing solely on its inputs and outputs. So, essentially, let's say, like, you're given a problem and you don't know, like, any of the interactions of the system with the problem, but you know what's going into the system and what's outputting the system. You don't necessarily need to know all the complex interactions of that system, uh, as long as you can identify, like, what your key inputs are, what your key outputs are, and then you can essentially create, like, a design of experiments to solve that problem. That's essentially in a black box because you don't really know what's happening internal to the system itself. And I found that that's helped me out so.

Is that, yeah, a lot. So, is that like to alleviate, because I know like during, like, previous experiences, I get overwhelmed sometimes because I feel like to solve a certain issue, you have to be like, a super expert on whatever process you're looking at. So, is that to, like, alleviate that?

Yeah, so you don't have to know everything. Yeah, it's essentially a great start. Like, say you're, you're a new engineer, you're a junior engineer, you're not a subject matter expert of, like, the thing you're working on. Um, it's a way for you to start the problem-solving process and contribute, uh, starting from, like, a high level versus actually being in the weeds of, like, what's going on in that system. And it's something that I relied upon heavily when I first started. Um, it's essentially like an internal structure or work. Like, it's a way for you to analyze the internal structure without considering, like, the things that are in that internal structure straight off the start, which is really nice. Um, and like leading into that, it's a way to, like, start thinking of things as an overall system versus, like, individual components, uh, which is something that's going to benefit every engineer, uh, later on, especially, like, individual product designers. Um, if you develop your product while thinking of it as a system, then it makes it a whole lot easier to integrate and scale moving forward in the future.

Is it like a, I don't know if you have one on top of your head or something like an example of, like, a black box time you would use it or you used it?

Yeah, so I can go over an example that I used in my, my previous role. Let me try at Tesla. Let me try not to, uh, give any sort of confidential, confidential information away, but there was a situation, let's say with a car, no specific model, um, where a driver would do something and essentially they'd get an alert on their screen. Let's say, completely made-up example, they'd press the brake, right? Essentially, they press the brake and an alert would pop up on their screen that they lose voltage somewhere in the system. Um, in this situation, I know exactly what my inputs are. So, let's say they have the car, uh, in drive. Doesn't happen when it's in reverse, or let's say, no, let's just say it happens when the car is in drive, reverse, and parked. They press the brake and they get an alert on the screen, right? So I know my output is getting an alert for low voltage somewhere in the system. So, essentially, I don't know anything about the internal structure of this. I just know my inputs and outputs. So I base my experiment off of what my inputs and outputs are. So, like, since I know these are my inputs, I'll look at essentially whatever system-level drawing or whatever system-level information I could find that's associated with these inputs and then I would tie them to the output I'm seeing. So, let's say, like, when they're pressing the brakes, okay, I trace that brake line, uh, through the car itself, and, uh, I find that when that brake line is pressed, a bunch of different lights go off in the car, right? So, like, you have your tail light, uh, your upper tail light, you have your left and right tail lights, um, and I see that when I press that brake, those things are physically interacting. So I'll go to those three things and essentially say, okay, this is part of my output now too. Um, so I'll do a design of experiments of, like, disconnecting each one of those outputs. If I disconnect each one of those outputs, do I still get the alert on the screen when I give my input? Um, and let's say I go through three of them. I find that when I disconnect the right tail light, the, the, uh, information on the screen goes away. So, like, there's no indication for low voltage. All right, okay. So from that right tail light, how can I signal trace that in a way to see, like, how it interacts with my input from the brake? Uh, then I put that all together and I see when I press my brake, um, it, it essentially activates a power line that runs next to the right tail light line. Uh, so I see that they're physically close to each other. So here, what I want to do is when I press the brake, I should probe that line and see if there's any sort of, uh, interaction happening when I, when I press the brake. So I, I press the brake, I probe the line, and let's say I see voltage drop, uh, from 12 volts to 9 volts, and it, that's enough to trigger an alert, right? Um, from there, I'm like, okay, why is this happening? So, essentially, from there, I would switch to, like, an oscilloscope and I monitor that, that signal on the line itself, and I see, oh, when I press the brake and the voltage drops, I see a lot of interference in that line. And essentially, from there, I could be like, okay, since I'm seeing a lot of interference, there's probably a lot of EMI going through this line. Um, and then I essentially, I'll, I'll check to see what the source of the, the EMI is and see if I can isolate it to, like, a light that's pulling too much current or, or a, um, I misspoke. So I'll swap the tail light, see if it works right. Um, I swap in the tail light, and the system, or the problem goes away. So then, using, like, my black box technique, I've gone through my inputs, I've gone through my outputs, I've seen how they've interacted by doing a design of experiment versus comparing my inputs and outputs, and I was able to, like, localize the issue to a tail light, right? So, so from, yeah, from what I got from that, it's, so it's basically saving your time by saying, hey, you don't need to be, you don't need to become familiar with the whole system. Start with the inputs and outputs, and you can follow the trace as you go along.

Exactly. So instead of wasting time with the whole system, just doing the inputs and outputs, you immediately focus on a smaller set of systems and just trace it.

Exactly. And I know if I was, like, a newer engineer hopping into that situation, I'd be like, well, I get an alert for voltage dropping here, but I have no idea, like, how the whole, whole car works. Like, do I need to figure out how, how the car works from a, from a high-level perspective and start driving down through every single, like, low-voltage system on the car? No, you just need to, uh, you just need to, um, essentially think about and worry about the things that are directly influencing, like, what's going on at a, at a, at a high level, which is, yeah, something I appreciate. And that would have been, that would have been good to know because, yeah, I'm one of those that gets like overwhelmed. I'm like, do I need to become an expert of this whole freaking thing to answer this, to do this project or task? And you'll find, like, that black box approach, I mean, it's helped me even at work right now. I, I ran into a situation like two days ago where I was working with a couple of electronics design engineers, and we were dealing with an issue in prototyping. And essentially, since, like, the electronics design engineer saw a failure with one of our controllers, and since they're so invested in the, the design because, like, they're the owner of that design, they've created the whole thing, they immediately, like, started diving into, like, very granular circuits and systems on, on the board to see, like, what, what's going on here. They started probing random places to see if they were getting voltage and, uh, uh, voltage anywhere. And I was like, hey, let's take a step back. Um, when, like, when we're considering this controller, let's, let's draw, let's draw a line around the controller itself and see what exactly is failing. What are our inputs to this area? I see that, like, a load switch needs to be initiated for this separate part of the system to get power. Well, what does, what does a load switch need to initiate? Well, the controller itself has to be updated with the proper firmware. And it was like a situation where the controller itself just wasn't flashed to the correct firmware, but the design engineer, like, started deep diving and probing the system and getting really granular with it before they considered it from a high level.

I, that also brings up the importance of having, like, cold eye reviews or, like, someone outside, not familiar with stuff, giving their input just to keep, yeah, the high level and try to keep it as simple as possible from their perspective and everything.

Yeah, exactly. Um, that's a huge thing. Cold eye reviews, man. You, you'll never know how simple of a mistake you're making until someone that's unrelated to it at all comes in and is like, why are you doing it that way? That that doesn't make sense.

Yeah. Have you ever ran into that situation in your career yet? I know it's still pretty early for you, but like, if you're ever dealing with a problem, are you like, man, why are we, let's take a step back?

Yeah, and some of, like, the higher-level engineers would be talking about stuff and they just, like, there'd be issues with regulator systems or, like, why, why isn't this working? And it's like, uh, like, some, some of the issues would be like, oh, this pipe, you inputted the wrong diameter on this pipe, but they were considering, like, all, like, the, the temperature differences and all that stuff and all the thermal properties. I was like, oh, that pipe, just, that pipe on that drawing, you put two inches, should be three. That's why it's not doing it in the simulation. You put the wrong size. So, like, nice. It's as simple as that.

Yeah. Yeah, just requires, because I feel like when you're so ingrained into a project or system, like, it's, it's easy to just think it could, it's the most catastrophic error that's happening, so you're like, trying to really figure it out, but it could be something, yeah, really simple.

That's another thing too, like, a big thing I found with design engineers is, I don't want to call and say like every design engineer does this. I don't think every design engineer does this, but I mean, even myself, not being a design engineer, I've been guilty of this, uh, is only considering my, like, my commodity at a local level versus a system level. Um, so, like, essentially, as an engineer, you'd want to consider, and I know a lot of people do this already, but you'd want to consider your, your design as a system versus as a local product. So you'd want to ensure, like, you have a comprehensive understanding of how different components interact and impact one another, even if those components aren't directly related with, like, what you're designing. So, like, a holistic approach like this essentially prevents sub-optimization, uh, where improvements to, like, individual components might inadvertently create inefficiencies or conflict, uh, elsewhere, like, in a system. That's smart.

Yeah. Um, I feel like, like, essentially, it just leads to a more cohesive, uh, and effective solution that addresses, like, from the root cause, versus a design engineer, like, creating a solution that impacts somewhere else. And not only that, when you consider, like, the system as a whole, you'll be able to scale your product better. And that's something that, um, a lot of people need to realize when they're designing for manufacturing, especially, like, a big manufacturing system.

No, I've definitely seen that and just, yeah, people not considering systems.

Yeah. Speaking of that, I feel like we could get into an engineering example and see how a junior engineer would approach a problem versus a senior engineer. Kind of am biased because I made this example, so I've had time to think about it a little bit. But Patrick, let's, uh, let's see how you would approach this problem. So, let's get moving with an example. Go ahead and share my screen here. Alrighty. Can you see that right?

Yeah.

Cool, cool. All right, so let's say you're a design engineer for a company who produces modular go-karts. And in this modular go-kart, you have a rear car, a mid-car, and a front car module that's swappable and secured together by a metal interconnect bulkhead that is inserted before you mate the car modules. So, essentially, you can see how we have this split into three sections, right? So let's say at this split area, there's a metal bulkhead that the rear module and the mid-car module essentially mount to. So that's like what's holding the modules together, right? Um, you own the entire design of the mid-car module. So you, Patrick, are the owner of the mid-car module design. So you are responsible for everything that's in that mid-car. And your company is currently in build prototyping. You experience a problem installing three controllers that are individually installed to the structure of the mid-car near where the rear car and mid-car connect. So that's the situation, right? Any questions on that?

Nope.

Cool. So the problem itself, you are unable to install three controllers to their mounting brackets that you designed due to two factors. There's hole misalignment between the controller and the bracket. You can see here I have a controller, generic controller that I pulled offline, and a bracket, generic bracket. These two aren't necessarily linked. Uh, I just wanted to show you a picture of, like, what essentially, uh, the possible scenario is. So these three holes are not aligning with these three holes. They're essentially winking. Um, and let's say during your prototype process, your solution is, you have to drill out both holes and get a larger fastener to make this fit. Fit. And not only this, you have difficulty seeing the inside of your structure when you're mounting this, this controller to this bracket. Now, this mounting bracket, per your design, comes installed on the structure from a supplier. How would you approach this problem?

Feel like the simplest way would to begin with the drawings, tolerances. So look at the drawings for the bracket at the controller casing, uh, verify the datums make sense. They're rigid datums and not fluid, to make sure the positions don't move around when you mess with different things. And then make sure, yeah, just make sure the positioning of the holes match up in the max tolerances doesn't take it outside the max range and things like that would be my first guess on how to first approach it.

Yeah, and I'm sure you'd, like, not only that, I know, uh, you'd want to verify, like, the supplier's sending you conforming parts. So you confirm, like, the, the, yeah, the controller and the brackets are to, like, your specified design.

Yeah, so, yeah, let's say you did that and they are in tolerance per your design. Uh, you essentially said you'd move forward with, like, a tolerance stack-up and see if any of those positional call-outs or or size call-outs were conflicting in any way. Okay. And if that were the case, you'd move forward with, like, fixing the tolerance call-outs for this, right? Going through the whole process of changing the tolerances and the drawings and all the documentation that requires and things like that.

Nice. Um, and for, like, the issue with difficulty seeing, you're, you're assuming, like, once you have the, the, uh, tolerance defined and everything's in spec, it'll just become easier to install because everything's just fitting together. All right, hopefully.

Sweet. Yeah, that's interesting. So, uh, now, school me.

No, I'm not necessarily gonna school you. I'm just gonna come at it from a different approach because, like, there's many approaches you can take to solve this problem. Um, but my approach, like, when I look at this and touching on the topics that we talked about in this podcast so far, is like, when you think about it from, uh, first principles engineering approach, um, let's say, like, question your constraints. Uh, when you think of your, like, whole system, what exactly are you needing from this mid-car module, uh, in terms of, like, uh, how these controllers are are set in here? Like, what you're needing is, you need your controllers to be set in your mid-car module, and you need to ensure that, like, they're robust, they're able to be mounted, and they're able to have, like, that connectivity between modules, right? So that's, like, your top-level constraint here that you want to stick towards or definition that you want to stick towards. Now, when I see this problem, I see we're having issues with hole misalignment to a bracket, and we're having issues seeing this installation process. So I can see there's three controllers here. Um, now, when I think about this from, like, a manufacturability perspective, I'm like, okay, when we move forward to manufacturing and start scaling, um, there's going to be an operator that has to individually mount three controllers into the mid-car before this mid-car can move forward in the process. Um, but when I think about my constraints, all I, like, from a high level, the only thing we need is for the controllers to be in the mid-car. So we mentioned that there was a bulkhead that connects the rear car module and the mid-car module. Is there a way we can design out the part, essentially design out this bracket, and optimize how fast we can install this controller? So my immediate thought would be, since we're in prototyping stage and we're not in mass manufacturing, we can experiment with direct mounting all three controllers to the bulkhead and sliding the bulkhead in at one point. So an operator, uh, essentially has a lot more visibility, uh, into what he's, uh, into where he's fastening the controller because the controller, or the bulkhead, is outside of the car, right? Um, so you can mount your three controllers to a bulkhead and slide the bulkhead in and use that as a structural, uh, mount, like a structural component that's also able to mount controllers. So you can speed up your manufacturing process while designing out a part. Um, if you just add the capability to the bulkhead to be able to mount controllers. I know that might be a little, oh, like, of course, you'd have to experiment with it, but that's something you could look at in this situation. Since you're the design engineer and you own the design of these parts.

What's the, what's the first thing you brought up? First principles engineering.

First principles engineering. So I feel like that kind of highlighted, or like, your approach kind of highlighted that, and my initial answer, which is check tolerances, like a direct solution to that problem.

Yeah, but yours was like, because you can either fix the problem directly, or you can innovate the system to eliminate the issue also.

Yeah, exactly. And that's like, kind of the whole point of, like, taking a first principles engineering approach, uh, to problem-solving. Um, and I think that's like something that will be super helpful moving forward. And that kind of, that kind of also touched on what we were talking about with, like, a systematic approach to, to, to problem-solving. Like, think of your, think of it as a system, uh, where design engineers will see a problem and try to solve that problem at the local level, without thinking about, like, how their solutions could affect an, an overall system, which is, which is a key thing that we kind of wanted to highlight in this podcast. And I'm glad we went through this, this example. Um, yeah, does that kind of make sense, like, that that approach or that solution, or you like, nah, nah, we should just, we should just widen the tolerances and have them install it individually?

Yeah, widen the tolerances and go home. Or tighten the tolerances, I mean.

Yeah. But I guess that kind of, not to call you out or anything, Patrick, I'm not calling you out at all with this, but that highlights, like, the difference between a senior engineer's approach and, like, a junior engineer's approach to, to, like, solving a problem, right?

Yeah. Um, and I'm not saying, like, one's bad and one's good. Uh, I just think one comes with just a little bit more experience, uh, in the workforce and, uh, yeah. How was that? Was that a,

No, that's good. I wish I would have came up with that.

No, it's fine. But like, stemming off of that, I guess we can go into, like, challenges for beginner engineers. So, uh, um, as engineers are, like, entering the workforce, I mean, we went through a specific example where we could see that a beginner engineer may, may experience more adversity and, like, problem-solving versus someone with more experience. But as you've entered the workforce, what would you say, like, some big challenges you've faced as a beginner and engineer are? And that could, that doesn't have to be, like, specific challenges, it could be things like confidence, or, or,

I think the biggest thing is like, like imposter syndrome and like knowing, like you worked hard, you're like supposed to be there. So, like, a lot of times you're just in rooms with, like, really veteran or senior engineers, and you feel like, oh, I don't want to give my input because they, whatever input I have, they definitely know already. But a lot of times, that's not the case. It's like, they hired you and want new people to bring fresh eyes on things. Yeah, because like, how you said, it's like, you're so ingrained into something, you could forget the very simple things. So it's kind of that having the confidence to, like, speak your mind and know you have, like, the necessary skills and knowledge to contribute is probably one of the, the big things. I think internship experience really helped with that because I think that kind of is what pushed me over. That was my first internship experience, just throwing me in and being like, okay, speak to all the engineers you need, all the technicians on the floor that you need. That was like daunting going up to, like, 40-year-old men with seeing this little kid there, like, what project are you doing?

Yeah, I agree. Um, yeah, you kind of hit the nail on the head there. I think a big challenge for me as a beginner engineer, uh, uh, was not understanding cross-functional teams. So, like, since I didn't know what all these other engineer teams were doing, it made me have no confidence in, like, what I was doing myself because I didn't want to, like, propose solutions or, or contribute, contribute in meetings because, like, I didn't know if what I was saying made no sense to another team or it was, like, stupid to someone else in the room. Um, and I think that's, like, that's a tough thing to get over, especially at the beginning. Um, and if you're in, like, siloed into a role that is so standardized that you don't get, like, that face-to-face or, or partner-to-partner communication where it's like, you're going through document communication, it's really hard to build upon that and, and get past that hurdle. Uh, yeah, as an engineer, I think. And not only that, like, when you start, you're definitely not a subject matter expert of what you're, yeah, you're over. So that's, like, another thing that kind of hurts your confidence a little bit and makes you not want to, to take the leap and put your foot out there.

Yeah, I think something I'm still struggling with or still trying to do, especially in this new role, thought about to start, is like, your learning and growth is in your own hands. So, like, you need to put yourself out there, you need to ask questions. You need to, if something doesn't make sense, it's your, it's on you to go meet with other teams, understand what people are doing, how what you're doing relates to what other people are doing. And, like, because you're going to have co-workers and bosses that are super receptive to you, like, they want to teach you everything. Oh, this is the best employee ever, I want them to learn everything, I'm so proud of them. You're also going to have people that are like, I just want to go home, I'm here just to make my money, I want to go home, stop asking me questions. Yeah, definitely. So, like, it's to have the confidence and, like, it's in your own hands to learn. And if you want to learn, you're gonna learn, even despite what anyone tells you or, or acts toward you at work or anything, you know? So I think it's, like, important to not get discouraged if you do have that co-worker or boss that isn't so gung-ho about teaching you or, yeah, teaching you things and stuff.

Yeah, I agree completely. Um, now speaking on that, like, we've went through a couple challenges, but, um, to, like, close out the final chapter of this, this podcast, how can a junior engineer or a new engineer in the workforce progress rapidly? Um, and I feel like there's a few key things that a new engineer can focus on to better streamline their development. What are some things that you think could help in this situation? And I'll come from it at it from, like, my perspective of, kind of, like, going through this process.

I'm gonna speak on, kind of, what I just said, like, the attitude portion of it. It's like, you got to have the attitude that you do want to progress and things like that and reach out to people and learn as much as you can. Um, I think that's, like, the most important thing because there's, there's going to be days or weeks or even, like, you don't get a lot of opportunity to learn out things or you're super busy and swamped. It's just always, if you don't have anything to do, or if you're, like, learning about a system, like, really want to learn it, like, be doing something you want to learn more about. Hopefully, hopefully you can be in that situation.

I agree. Like, attitude is huge. Um, if you're in a, if you're in a role and you're content, um, like, you'll be, you'll be there forever. Just staying content. Being said, like, what you said, that the attitude, seeking those, those uncomfortable situations. Like, the more you become uncomfortable, the more you'll be, you, the more you'll be comfortable, uh, moving forward. And, um, yeah, I think a way to get there is to, like, really put yourself out there and approach problems using, like, the methodologies we talked about today. Uh, I feel like that's a good way to, uh, uh, really take those first steps and, uh, focus on, like, becoming a subject matter expert. And to do that, you have to put yourself out there. You can't just take things as they come. And I think, like, knowing what you want out of your career is really important. So, like, you know, some people just don't want to be heavy into their career, they want to do it and then go home and do stuff they like, and that's fine. But other people also, they want to excel as fast as possible. So, like, I think, like, Christian, you're, like, a really good example of that side of excelling as fast as possible and things like that because, like, your experience is insane and where you are now. And I feel like, like, if you started at Toyota, you could very well, like, just still be there and not, like, had all this crazy experience. And that's fine if that's, like, you. It's just important to, like, know what you want out of it.

Exactly. Like, it's okay not to be a heavy career person. Um, of course, you still want to be good at your job and, you know, like, what you do, but, um, it's important to know, yeah, know what you want out of it because if you want to excel, you're going to excel. It's just you choosing that you want to do that and putting in the work to learn everything and stuff like that and learn as much as you can as quickly as you can.

That's very true. Yep. Yeah, no, definitely. And, uh, I guess, like, to add some, kind of, closing remarks on, on, kind of, how you can accelerate as fast as possible, I know some two things I really focused on, um, when I started that kind of hit me in the face, like, with out of nowhere, um, was understanding cross-functional team responsibilities as soon as possible. Like, the faster you can understand what the entire business is doing as a whole, the, the quicker you'll be able to make, like, those super informed and super educated decisions as to what you're doing and have the confidence to be able to do it. Um, and the last one, I think one of the biggest ones to me, to be honest, and something that I kind of struggled with at the beginning, is adapting your solutions toward business objectives. So, like, as an engineer for a certain team, let's say you're in quality, let's say you're in manufacturing, let's say you're on design or NPI, it's easy to make your solutions tailored toward the success of your individual team. And what I mean by that is, like, a solution that works for your team and pushes your, your individual goal as an NPI engineer forward may not be something that makes the most sense for the company as a whole. So, as an engineer, it's your duty to find what makes sense for the business that you're contributing to. Um, and that's something that was kind of tough for me at the beginning, like, as a quality engineer. Um, there's many, there's many situations where something that makes sense, uh, for me and makes sense for my role, uh, directly conflicts with, like, what the business needs. And I feel like it's on me as an engineer to find the best balance of that in the business. Um, so the sooner you start adapting your solutions to, like, what the business needs, the, the faster you'll rise up in your career. And you may be put in situations where, like, you're directly conflicting with what your direct supervisor may think, but it's all about, like, knowing in your core what's you believe is the best for the business and, uh, sticking to your guns and having the confidence to do it.

So, yeah, I think one more thing is, like, that I struggled with also early on is just, like, you know, graduating and, like, finishing engineering is such, like, a big relief. It's easy to fall into, like, you get your first job and have the mentality of, like, oh, I'm just happy to be here. Like, the job market's so bad, I'm just happy to finally have work. I think something you said, I don't even know if you said it or if, like, I don't know, but, like, kind of, like, think of everything you do day-to-day is like justifying your, you're justifying, like, your worth and your pay, stuff like that. Kind of.

Oh, yeah, I did say this. So, like, I think that mentality is because I struggled with that a little bit. Like, the first few weeks I was working, I was like, I'm just happy to be here. They don't expect anything out of me. But I think it's better to, it kind of helps you propel forward of, like, okay, how I spent this much time doing this this week, how did this benefit the company? How this, like, justify my role? If someone came to me was like, why are you here? I can answer them, like, confidently, like, I do this, this for the company. Like, feel confident, like, if you left, like, it'd be hard to replace you, basically. Like, make yourself irreplaceable.

Definitely. Yeah, I, I remember talking to you about this. Um, yeah, something I, I, like, try to, to go by is, as an engineer, try to contribute to, to the company at least double what your salary is. That way, if you're ever in a situation where, like, layoffs are happening or, or management has to pick between their highest performing contributors and their lowest performing contributors, or like, people are being, uh, considered for raises, they know, oh, Christian contributes at least double what we're paying him. Um, so we should, he should always be in a safe place, or we should always consider him for, for a promotional increase. And if you go by, like, that mentality every day, uh, then you'll be set up for success. You'll, you'll be able to spearhead any issue that comes your way, and you'll always be motivated, even in the face of, like, adversity. So, yeah, that's a big one.

Dang, I'm glad you, I'm glad you remember that because that, that's a big one for me too, that I try and stick to every day.

Cool. Anything else you wanted to touch on this?

I've said my piece.

Nice. All right, sweet. So I hope everybody enjoyed this, uh, this podcast. I hope everybody was able to get a more in-depth understanding on, like, what it is to think like an engineer and, uh, steer towards those successful engineering thought processes and methodologies. Um, and as a retrospective, just in case, like, your goal as an engineer, uh, you essentially want to be a subject matter expert and steer your business towards excellence. Um, and to do that, you can use methodologies like first principles thinking and questioning your constraints, the black box approach, and thinking of problems as an overall system. Um, and really challenge, like, your, your preconceived notions as to what you think is a successful solution for problems. Um, so, yeah, Patrick, if that's it, then, uh, everybody, thanks for tuning in, and we'll see y'all next week.

[Music]

[Music]