Being an Engineer
Being an Engineer
S5E23 Jim Cuseo | Defining Requirements, Developing MacBook Pro, & Leading Large Engineering Teams
The episode discusses Jim Cuseo's engineering journey and lessons learned over his career. He shares insights on defining requirements, developing complex products, scaling operations, and leading large teams.
Main Topics:
- Defining clear product requirements
- Developing subsystems while considering broader context
- Accelerating engineering through effective processes
- Common mistakes and how to avoid them
- Emerging technologies impacting design
About the guest: Jim Cuseo is a seasoned mechanical engineer whose remarkable career has spanned over two decades, influencing the design of some of the most iconic technology products. James's journey began at the prestigious Massachusetts Institute of Technology and led him through pivotal roles at Ford, Exponent, and MagCanica, where he honed his skills in the motorsport and aerospace sectors. Next, Jim spent over a decade at Apple, where he grew to Director of Mac Product Design, overseeing the development of groundbreaking products such as the 16” MacBook Pro and the iMac with Retina Displays. Currently, he offers his expertise to various companies through his consultancy, Jim Cuseo, LLC, aiding them in scaling operations and enhancing product designs.
Links:
James Cuseo - 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
In my experience, I found that magic products tend to be the result of continually peeling that onion until you really get to the crux of the problem. At which point you now understand it in a way that you can, you can leverage what you've learned in ways to create magical experiences.
Aaron Moncur:Hello, and welcome to the being an engineer Podcast. Today we are delighted to have Jim Cuseo, a seasoned mechanical engineer whose remarkable career has spanned over two decades, influencing the design of some of the most iconic technology products. James's journey began at the prestigious Massachusetts Institute of Technology and lead him through pivotal roles at Ford exponent and mag canica, where he honed his skills in the motorsport and aerospace sectors. Next, Jim spent over a decade at Apple where he grew to Director of Mac product design, overseeing the development of groundbreaking products, such as the MacBook Pro and the iMac with retina displays. Currently, he offers his expertise to various companies through his consultancy James Cuseo LLC, aiding them in scaling operations and enhancing product designs. Jim, thank you so much for joining us today.
James Cuseo:Thank you very much. Thank you for that wonderful intro.
Aaron Moncur:Absolutely. Well, I've been super excited to talk today. You and I met just a few weeks ago, not very long ago, we connected on LinkedIn. And I looked through your profile, and I was so so impressed with everything that you've done. And I just I know for a fact that the listeners are gonna get so much from this episode, just drinking from your your cup of knowledge. So with that, let's start with the question I begin with at every interview, which is what made you decide to become an engineer.
James Cuseo:All right, well, you know, I was the first person my family and I really excel in school. My I came from a long line of mechanics, and, you know, my dad was a laborer worked with his hands his whole life. I was the first to really take a liking to school. So when when I was in high school, I was getting sciences, especially physics. I was faced with being the first first my family to go to college. And I had no idea what I'd study. So a guidance counselor suggested engineering. And I thought, Well, my dad's mechanic had a mechanical engineering sounds like it'll be a good fit. So that's what I did. I chose mechanical engineering. And I almost didn't become a mechanical engineer, because during undergrad, I found my way into a software startup. And I did that for five years concurrently with undergrad. But I eventually decided that, you know, mechanical engineering is my passion. I had really taken a liking for it over those first few years of study, and decided to go back to grad school, which is when I went to MIT and refocus on mechanical engineering. And as you said, I started out in automotive and spent some time in motorsports, and then ended up in consumer electronics sort of by accident. I didn't even realize that Apple hired mechanical engineers, to a friend went to work there. And he told me about his time there. And I was lucky enough to get an interview with his boss and family set for Apple and the rest is history.
Aaron Moncur:Amazing. That's a great, great walk through your journey to becoming an engineer. My father also influenced me in becoming an engineer. I won't go through that because this is your interview, not mine. But it's interesting. How much family has influenced people on this show to become an engineer. I wouldn't have thought that was one of the deciding factors. But it's been a pretty large factor in many, many engineers journey. Speaking of Apple, where you worked, you You led the design of some pretty high profile products, the iMac and MacBook Pro Series. Can you walk us through maybe like one or two of the most challenging either creative and or technical challenges that you faced Well, while managing these products? Sure.
James Cuseo:Well, every program at Apple was challenging in its own way, and Apple generally doesn't take on anything that's too easy. My first big big challenge was the development of the Force Touch trackpad. So trackpads up to that point were relatively simple devices. It was a PC board under a piece of glass and all of that sat on top of a mechanical switch. If you pushed on the trackpad, it would cause that switch to buckle. And that buckling would create both the feeling of a click, and the close the electrical switch that signaled to the computer. Hey, someone just clicked me. The Force Touch trackpad was an attempt to sort of re re architect how a track bed worked. It replaced that mechanical switch with two things, the first being the set of string gauges, which not just measured, did you click me, but How hard are you pressing on the trackpad. And with that, you can do some very interesting things. And then once the trackpad sense that you pressed hard enough to create a click, it actually use what we call the haptic actuator to send an impulse into the trackpad, which gave you the feeling of the click. And the really interesting thing about that was, most people think when you press a trackpad or even a force, touch trackpad, any clicks, it's moving up and down. Because your finger pushes down, your brain feels something and so your brain interprets that as it moving down. All actuality, the force touch trackpads haptic actuator, tugs the trackpad laterally. So it's not moving up and down, but it's moving back and forth. But your brain feels motion. And because of the fact that you are pushing down it thinks oh, that must have just clicked down. But in fact, it's just a trick of, of perception. Anyway, that the trackpad was my first real big challenge at Apple and was super interesting because I get to work with some really smart subject matter experts, people who are experts in the implementation of sensors, people who are experts in the implementation of haptics. And I got my first taste of being a system engineer. You know, most people think the system is something like the computer, and they think of the trackpad as a component. But in fact, the trackpad is a system into a number itself. It's comprised of many different subsystems, some of which I named, right, the strain sensors, the haptic actuator. And all of these have to be integrated by someone. And that was my role as the systems engineer on that program. And it was super interesting, because we initially went down one path, and we had a set of, we had a small method of sensing strain, that worked really well in the lab. But as we begin to scale it, we found that it doesn't repeat every time, any predictable way. And in fact, the sensor behaves differently on day one than it did on day 10, and day 100. And that wouldn't be appropriate for a consumer electronics device, which needs to behave similarly, every day, day in, day out. So that was the first time in my career where we ran into a situation where we had to actually abandon that architecture and start over. And so we took what we learned, and we apply those lessons into a new architecture, which is essentially what we're shipping to this day. That
Aaron Moncur:is fascinating. I guess tangential to that, when you and I first spoke, I remember you talking about how, what's the right phrase here, how detailed Apple really gets in developing some of their products. It's they're not just putting some beautiful industrial design onto crummy technology. The level of thought and consideration that goes into these products, truly is overwhelming. Can you talk, if you have specific examples, great, but even if not just in general about the level of thought and detail that goes into a product at Apple and how maybe that that differs from the level of thought and detail that might go into some other consumer product? Sure.
James Cuseo:I think I might use the phrase peeling the onion. Because we like to think of any problem like an onion, you know, an onion is has multiple layers, you peel the first layer of skin, and there's another layer of skin beneath that and feel that layer of skin and there's maybe another sort of transition layer between the skin in the meat menu to the first layer of the onion and you realize there's multiple layers below that. And a technical problem is a lot like an onion in that sense. You know, you can ask yourself a question and pretty quickly arrive at an answer. But you begin to realize, well, that's not the whole story. And you can go deeper and deeper and deeper and it's until you peel that onion a few layers deep. Sometimes you have to get all the way to the center before you really understand the problem well enough to to do really amazing things with it, you know, and I think my experience, I found that magical products tend to be the result of continually peeling that onion, until you really get to the crux of the problem. At which point you now understand it in a way that you can, you can leverage what you've learned in ways to create magical experiences. Terrific,
Aaron Moncur:thank you. I think I just found the intro to this episode, right there. Well, throughout your career, you've moved into a variety of different leadership roles. Can you? Can you share any strategies that you found to be very effective as you're leading, leading large teams? Yeah, just what what have you learned there?
James Cuseo:Sure. Well, as I reflect on my career, I realized that my success as a leader mostly boils down to the people that I was able to work with. You know, you start by hiring really great people. And then you train them to put you out of a job someday, right? In my experience, when you've trained your people up well, and also, they're ready to take over your job, well, then you probably are ready to take the next job too. So you can all kind of step up together. And, you know, it made me much more likely to succeed, as I took these people who were, you know, really smart, great people. And we all grew together level by level. When you have people around you that you trust, it really allows you to implement a system of what I can't trust, but verify. When you're running a really big organization, 100 people, multiple programs going on in any given time, you know, I had any given time I had upwards of 15 programs, some of those terms, or systems, like the MacBook computer, some of them were the trackpad, you know, those are separate programs, even though the trackpad ends up in the computer, you do think of them as separate programs at various stages. Anyway, when you've got that many things at once, you can't be in all of the details. But it is your responsibility to make sure that everything in your organization ships on time, high quality, etc. So you've got to find a way to route out all of the issues that might exist, that would cause you to you know, miss your miss your goals. And so my strategy was, you meet with your teams on a regular basis, and they bring to you, you know, the current status of things, and you listen and you process, and then you ask, like, three to five questions. And if you get three to five, really solid answers, you're done, the team knows their stuff. You move on to the next your next meeting? If you get a couple of those answers that, you know, again, it's obvious the team really hasn't peeled the onion deep enough, you've asked a question that maybe surprised them or stumped them. Or maybe you've got a, you got to dig deeper in that area. And if if you really don't get any satisfactory answers out of the team, then you realize, well, I got to spend more time with this team, something that I haven't done to set them up for success. So you know, this is an area where need to focus. And so maybe you say I can spend less time with that first team who's obviously got things under control, spend a little more time with this other team over here that needs a little more help. And that help may not be because the team, you know, isn't as good as that. First, he may be that they've got a much more sticky problem. You know, the onions way thicker skin is way thicker. And it's very rare that these questions that I ask, it's that I'm smarter than they are so I can ask hard questions. It's that I'm coming at it from a slightly different perspective. You know, when you're really deep into a problem, you sometimes forget to take a step back and look around. So you don't make a connection that someone with that beginner's mindset. Might might ask, if given all this information, you know, for the first time in a meeting. So, you know, that's the strategy I use pretty successfully at Apple, but But again, it starts with surrounding yourself with great people.
Aaron Moncur:That's a very effective strategy. Like you said, as a high level leader. You can't get into all of the details. It would take way too much time and you just don't have that many hours in a day. But it doesn't take that much time to ask some pointed questions. And like you said, listen to any Evaluate the answers you get back. And that's a very effective way of figuring out where, like you said, maybe we need to peel back the onion layers a little bit further, I love that. I've, you mentioned the focus and kind of stepping back right looking at it at a 50,000 foot level, I've heard that referred to as rubberband focus, which I think that's such a great term to capture that sentiment, right? You stretch way, way, way out. And then the rubber band pulls you way back into the details and then your way back out, but back and forth, kind of as needed. Having a rubber band focus, what what kind of advice might you give to engineers who have come up kind of like you right hands on, but then they want to grow into some leadership? Opportunities? Yes,
James Cuseo:sure. First of all, a bit of a disclaimer here, every organization is different, right? Apple tends to value certain things and leaders with different company may value other things. Like for instance, during my time at Apple, I never felt like I needed an MBA to be successful. In another organization, that would be very important for an engineering leader. So every organization is different, no one is right or wrong. But put them about to say comes from my experience at Apple. The first advice I'd give your ice looking to make the transition is to look for opportunities to understand more and more of your business as early as you can, you may have been given a certain component to own the design of. But that doesn't mean your learning has to stop there. You know, while you are in the midst of a program with everyone else, be curious about what else is going on and learn from, you know, your colleague may have just solved a really challenging technical problem can learn from that. You know, maybe you see that there's a part of the device that needs a little more attention, raise your hand and say I'm willing to take that on. Not necessarily because it helps you grow as an IC. But it'll do that as well. But to be a leader, you really do need a good sense for the whole landscape of whatever project you're working on. So figuring out how you can efficiently gather more and more experience as quickly as possible, will will serve you into a transition of leadership. With one caveat, though, nothing is worse than someone who comes to you asks for more, when they're not doing a great job, the thing that they're primarily responsible for. So first step, you know, make sure your house is in order, and then look for those opportunities to add, you know, a little bit more to your play a little bit more your visibility. So that you can, you can, you know, collect that information. You know, secondly, I'll say that short of specific management training programs, people that are rarely told, we're going to need a manager six months from now. So go learn X, Y, and Z. So you're ready, what generally happens is one of two things. One, a vacancy opens up and you immediately look within your organization for who might be ready. And generally, those people that are ready are those who have collected some experience, you know, along the way. The second scenario is, you see a person, they're super ready for the next thing, not because you told them to, but because they went off and figured it out. And you recognize as a leader, you need to find something for this person. So maybe you find something within your organization, or maybe you find something outside of your organization. But, you know, the it's important to try to put yourself in that position to be recognized when the time arises. Because the thing with leadership is, timing is sometimes a factor. You know, you may, we may need a leader today, but six months from now, we have enough leaders for a while. So you've really need to be in a position to seize the opportunity when it comes available. I'd say you know, I just want to back up for a second makeup making a point earlier due to the fact that you know, meet your needs are sort of naturally arise from within and are often products of their own initiative. I think it's important as leaders we make sure we make sure we don't overlook people who Are wouldn't be really amazing if given the right motivations. So I don't want to sit here and tell people that all on, you know, it's the leaders responsibility to make sure that people who will be good leaders someday know that and are working in the right direction. But it's a two way street, you know, I don't think you should sit back and just wait for someone to say, this will become available six months or X, that's usually not how it works. It's usually a much more dynamic thing. And you need to put yourself position and be ready.
Aaron Moncur:Yeah. Now terrific. Right now you are doing some consulting got your own, your own gig going. And your focus is helping helping companies scale their operations? What are a few of the pitfalls that you commonly see, companies trying to skill up falling into, and one or two ways for how to either avoid or overcome those obstacles?
James Cuseo:Share? So one of the pitfalls that I see in smaller organizations is, is falling into a trap of theme, we don't have time to do that now. And then, you know, thinking that there is going to be time we get to that later. And the reality is, there is never more time later. Later on, you might have a few more people, but genuinely, you know, the work is going to scale the consuming those people too, right? So thinking, well, we'll get to that later, it generally doesn't come to pass, you really have to do is think real hard about, you know, what is your Northstar? And how important is it that we do this thing, if it's important to our company, our brand our business, then we need to figure out a way to make this happen. If it's not important at all, then maybe we shouldn't be thinking about it at all. Right. You know, things like quality things like process, you know, when we might talk about this a little bit, but lots of companies think we're small, we don't need process. They differ I think that small companies can take advantage of you know, one other pitfall that I see small companies startups falling into, is trying to emulate another company or organization away, that's just not appropriate for them. And a great example of this is people who go and try to start a company and become the apple of blank. And thinking, well, especially folks that have been it up, right, oh, I just worked for Apple, I'm gonna go to this other company, or started another company, I'm gonna create the apple of plank, well, Apple can do some of the things they do, because of the massive resources they have, right, the massive years of experience under their belt, the massive amounts of people in region, the operational budgets, etc. So it doesn't make sense, in many cases, for a small organization to try to emulate Apple, especially when it comes to matters, like industrial design, right? You see a lot of people out there trying to execute anodized aluminum products with zero gaps and offsets. And the reality is, if you don't get that perfectly, it doesn't look good. So you're better off not trying, you know, come up with your own design language, one that is appropriate for your company, your operations, you know, the maturity of your operation, and in own that, right to try to emulate somebody else. Yeah, that brings me to like a meta lesson, which is what I left Apple enjoying Mark Forge, which is where I was recently, I realized that I needed to put all my experience in one of three buckets. bucket number one are things that I learned that could could be applied anywhere for Batum. Right, just good sound engineering principles. This concept of peeling the onion is another good one. The second bucket was things that needed to be tweaked to be appropriate for wherever I was now, like there are things I learned about industrial design at Apple, which with the right tweaking, I can go apply that elsewhere. aspects of how you develop a product, you know the product development process itself. for something that with the right tweaks, I can go apply that any company big or small. A third bucket is almost the most important. There are things that I knew I had to leave behind, because they'd only work at Apple. And they would only work at the apple that I was at, during the time that I was there. Meaning that the things we were doing in 2015, wouldn't have worked for Apple in 1995. And they may not work for Apple in 2030, I'm not sure. But you know, those methodologies had their time in place. And those are ones I just have to leave behind. Not forget them, because it's important to, to, to remember to make sure I don't try to emulate those, but just be be comfortable leaving them behind.
Aaron Moncur:If you can share, what's an example of one of these things that you decided to leave behind at Apple.
James Cuseo:So the whining methodology of moving fast during the product development process is the concept of parallel paths, right, let's say you've got a specific widget in it, you might execute that widget in one of three ways. In your traditional way of doing things, you would you like prototype each widget, and you would test each widget, but you would do some extensive analysis and you'd make a decision, we're going to pick widget B, that's the best way to solve this problem today. At a company like Apple, you might decide, well, I don't have the time for that upfront experimentation. So what I'm going to do is I'm going to design and release all three of these things. And, you know, it takes 12 weeks to tool up, you know, a hard tool and get parts off that. So while that's going on, I'm going to do this analysis and testing that I talked about, so that when those parts arrive in the factory, I know I'm going to use option B. But the day I released them, I'm not sure. And so I'm going to order full quantities of option A, B and C, and during the prototype round, then we'd be 1000 of each. And I'm gonna I'm gonna go into this knowing I'm gonna throw away all of two of those buckets. But what that does, it buys me some time, or cost as it comes at financial cost, it costs a lot of money to tool things up. It comes up cost of distraction, right, it's hard for a large team to execute three different designs. But sometimes that's the most efficient way to put that in quotes way of getting to an answer. You know, when efficiency is measured in how soon can I ship the product. Now it's the least efficient when measured by other metrics, but there are times when time per shipment is the most important thing. And budgets are relatively flexible. And you've got some extra headcount to spend on engineering all three options. So maybe that's the choice you use. Like I said, that works well at Apple, it wouldn't work well at a smaller company, where your resources are more focused. Yeah,
Aaron Moncur:I'm guessing what comes into play there is, if you can ship something in August, the amount of revenue you'll receive so far exceeds what you would have quote unquote, saved by taking an extra two, three months into September November timeframe to do more of a linear path, that it just makes sense to spend the extra money up front ship on August and start start generating the revenue.
James Cuseo:Totally. I mean, these these expenditures I was referring to are sometimes you know, on the order of 100 grin, which is a lot of money to a smaller company. But in the context of a computer program, it's a rounding error, especially when you consider that if you can ship it on, you know, May May 1, just in time for back to school purchases. That's going to learn you quite a bit money is compared to shipping and September 1. Were kids who already bought the computer that to bring it in college.
Aaron Moncur:Yeah, right. Okay. Well on that on that topic of product development, what emerging technologies do you think are going to meaningfully impact product design and engineering? I don't know over the next decade or so I look back at the last 1020 years and 3d printing, in my view is kind of the big one that has really changed our industry. Ai, of course, is kind of everywhere right now, that probably has some influence. And there's there's room to grow still in 3d printing for sure. Do you have any specific thoughts on any of those topics, or just completely separate trends or technologies or patterns that might really move the needle for product development engineers?
James Cuseo:Sure. I'm seeing an increase in online collaboration tools for mechanical design, you know, GitHub, in the software space was a tremendous boon of productivity. And seeing companies trying to bring that to the mechanical design space, you know, I design apart, and in real time, you can comment on the features and tell me this face needs to move 50 microns that way, because it interferes, or, you know, you can say this tolerance here is acceptable. And then I can go into my CAD program, in some instances, through implementing this in the CAD programs. It's, it's really going to make design your BS and things of that nature, so much more enjoyable. You know, the days of printing something out in red lining it, you know, are about to change beat me, they have changed for a while, but it's I think it's going to change, adding even faster clip. I think that AI, you mentioned it is going to be a big driver of innovation. But I think it's going to be what I call human in the loop AI, meaning I saw this post on LinkedIn a few months ago, and someone said hardware design is about to get easy. And I thought, I don't think so. Two reasons. One, is when you train your AI up, you need to train it based upon a data set, right. And if that data set is made up of the sum total of things that we've produced over the last 18 years, you're going to get a fair amount of good products, a fair amount of crummy products and a fair amount of average products. And if if you're training your AI to recognize patterns for the most common patterns, you're going to be an average things, right? And so is the AI going to generate just a bunch of average products? Do we want average products, you know, I think when you think of an average product, you think about something that is used for a short amount of time that ends up in a junk drawer like Excel. And that's not the type of product that I'm interested in being part of, I'm interested in being a part of excellent products that have longevity, that deserve, you know, their place in in your, in your, your toolkit, if you will. So I think you know, the way in which we apply AI to hardware design, I think needs to be done very, very thoughtfully. But you know, no doubt, it's going to improve productivity, because there are things that we do as design engineers that just take time, you're dimensioning a drawing, and AI can do most of the dimensioning. And then you can step in and be like, Hey, I like the way it did it here. I'm going to fix that. And you know what it used to take two hours. Now takes 20 minutes. Like I'm ready for that change.
Aaron Moncur:Yeah, yeah, you and me both. Well, let me take a very short break here and share with the listeners that the being an engineer podcast is brought to you by pipeline design and engineering where we don't do pipelines, but do help companies who commercialize hard goods products that are complex or difficult to manufacture. And we do this by developing advanced manufacturing processes, automated machines and custom fixtures complemented with product design, and r&d services. Learn more about us at teen pipeline.us and today we have the absolute pleasure of speaking with Jim Cuseo. Jim, you are obviously a high performing engineer, and engineering leader, and it takes motivation to stay at the top of your game. Can you share a little bit about what motivates you and what what projects or goals that you're most excited about pursuing next?
James Cuseo:Well, I'll start by saying what I look for in in any any job or any You any role in life is to check two boxes. Box number one is am I learning something? Box? Number two is am I having fun? You know, and fun? Does it always look like? A bunch of laughs right? Sometimes it's what we call type two fun, which is, it wasn't fun at the time. But looking back on it, you retro out a lot. And it was a good, good experience. And yeah, that was fun. You know, for a lot of people college was a little bit of type one and a little bit of type two, right? But I asked myself, am I learning and am I having fun, and if those two things are happening in the motivation comes for free, right, because you're just jazzed to, you know, get to the get to work the next day and start digging that problem deeper, or, you know, you forget that you didn't eat lunch that day, because you were so focused on solving a really cool problem. So, you know, at a high level, those are the sorts of things that motivate me, in my personal career and life. So what's motivating me right now is getting, you know, trying to take my career in a slightly different direction, I've spent, I spent a bunch of time to consumer electronics, that was great, I learned a lot. And now I get to spend a couple years doing automation, in the form of additive manufacturing, 3d printing. And that was really cool. And so now I'm trying to figure out, what's the next subject area, that's really going to cause me to, you know, work through lunch, because I forgot, right? And I've sort of told you earlier that I did some programming back in the day, and I'm dusting that off. Because, you know, as we, as we start to employ AI more and more, being the person I am wanting to peel that onion, I want to be able to look under the hood, I want to be able to sort of better understand how these tools work. So that when I go to use them, I am much more aware of their constraints, their weaknesses. So that, you know, better informed user that technology. So he I'm taking a take a Harvard computer science course and follow that up with their, their AI course. And I'm super excited about that in our sort of thing where this morning, I couldn't wait to get out of bed so I can crack open the laptop and take the next, you know, all online class on. Yeah, jazz well learning. She can't tell. I just love to learn.
Aaron Moncur:Now, that's awesome. I love it. I feel the same way. I'm happiest when I'm learning something. And then you get into those states of flow, right? Where like you said, you just forget that you didn't eat lunch or or whatever it is. I have an idea for you that I actually pitch to an investor who's summarily dismissed it, I still think it's a good idea. But you maybe you have the skill set to take this forward. You talked about AI, you talked about programming software background, maybe dusting that off. And you talked about these cloud based collaboration tools, I think it would be really useful for engineering teams to have an AI Design Review Tool, where it doesn't even have to be the most sophisticated design reviews, even checking for things like, hey, this hole doesn't match up with the hole below it, it's off by 30 thousandths of an inch. Is it supposed to be that way? Or you've got an M five screw in this hole. But the threaded hole beneath it is M four Is that intentional? You know, simple things like that, that I still find us overlooking on occasion. I think having an AI that could look through that and identify those types of things would be really very useful for engineering teams.
James Cuseo:I totally agree. And the good news is do people working on this I have met with a cold a couple weeks ago that's taking a step in that direction. And I know of a few people working on generative AI for the 3d modeling space and a couple of my my colleagues are really interested in what they call geometry detection. So being able to see something in CAD, a computer seeing somebody in CAD and recognizing what it is and what what purpose it holds. Yeah, it's actually a really interesting problem. And so, so there are people like you that are looking looking into that already. And I'm super excited for how I'm there for for sure.
Aaron Moncur:Terrific. I love it. Can't wait to see that come out. You have quite a lot of experience with patents. How have You'd been able to identify which technologies? Which designs are worthy of pursuing patents. And then how have you seen patents influenced the landscape of technology sectors?
James Cuseo:Yeah, that's a great question. Patents are kind of interesting, because at the end of the day, patents are really hard to defend successfully. And don't get me wrong. There's tons of examples of it. But, you know, patents are tricky to write well, they're tricking defend, well, they cost a lot of money either way. So as you said earlier, deciding whether or not something deserves a patent isn't super straightforward. You know, of course, you've got to ask yourself, question, is there novelty there? Like have I, I think it's in the definition of a patent, have I uncovered something that is not obvious to someone skilled in the art, you know, and you'll see a lot of patents that seemed kind of obvious. But if you look real deeply at the claims, you realize, like another is a subtle twist tweak to a convention, which, which led to something being patentable. But it's a tremendous amount of time and money to create a pen. And you got to ask yourself, you know, as an inventor, does it make sense? You know, Apple pens, a lot of things. smaller company, and that's because, you know, Apple has big legal teams that can help with that process. But as a smaller team, you know, you really got to think hard, do I want to invest the time and effort into patenting something, when, you know, in many cases, it's patents also sometimes give you the, the hints on how to engineer around them, right, it's right there in the claims. You know, a patent is a big long document, but really, what matters is what is claimed. And that's the crux of patent. And, you know, sometimes you decide as an organization that you don't want to patent something, but instead of going to the different route, which is called trade secret, you're going to patent you are publicly disclosing to the world. Here's what I'm doing and how I'm doing. And by the way, that patent is only, you know, valid in the United States or wherever it is, you happen to apply for one, you can apply in various various geographies. But, you know, it's not necessarily valid everywhere, it's much harder to defend elsewhere as well. So you may decide that rather than patent and and literally tell the world how I'm doing this thing, instead, we're going to keep it trade secret, which of course, you no longer have the protections of the government, should someone else figure out your trade secret. But you also don't have to then disclose that trade secret, because the other side of the patent is it's only good for what 17 years, right? And after that expires, you've disclosed how you're doing something to the world. So it's, you know, it's not obvious. You know, an apple, I was privileged to be a part of many really cool patents. Not as many as some of my colleagues. I've had colleagues that earn hundreds of patents are my at a smaller number. But you know, the ones I do have, I feel really proud about. But ultimately, to me, as an engineer, I don't really care if something is patented, I care if it's out there being used, because what you'll find is a lot of patents are just that, and only that they never actually turned into products. So it's a couple of different ways of looking at him. But certainly there, you know, there are super valuable in certain certain circumstances.
Aaron Moncur:Yeah, you know, as you're speaking about this, I thought of an analogy that may or may not be interesting, but I'll share it anyway. Because I'm the host, and I can say what I want to say. I was thinking about jujitsu, I do Brazilian jujitsu. And I'm a purple belt right now. And sometimes I think to myself, I don't really care that much about the belt, what I really care about is what can I do you know, how well can I defend myself? How well can I progress my self against my component? And I think patents are, in a way kind of similar, like, they're, they're nice. They're a recognition that you've done something important, but at the end of the day, really matters is what you can do, right? Not not how many patents you have against your name. Total tangent there. So getting back to our interview What are a couple of areas that you have commonly seen engineering teams progress slowed by what I'll call unforced errors. So these are not errors that were quote unquote, forced by leadership swooping in and say, Hey, team, instead of this being due in six months, it's now due in two months, and the whole team starts working way faster than they should. And as a result, they start making all these mistakes and errors. That's not what I'm referring to so unforced errors in the course of just your normal development project, what are some areas where you've seen team's progress slow? Because they're, they're just making mistakes? That there's there's no reason they should have made that mistake? Sure.
James Cuseo:I'll give you two examples. And they're they're related in the first example has to do with going back to that sort of the paradigm that on a program on a product like computer, you have multiple subsystems in the computer, right? So you sit down, and you define the requirements for the computer. And let's say your job is to to design the computer, but it's to design the track, right? Well, the first step of your design process should be well, let's look at the definition of the computer. And let's try to intuit from that, or let's try to look verbatim, what aspects of that definition affect me as the owner of the track. But very often, engineers won't even do that. And then they'll get six or eight months down the line. And they'll have the first prototype no good integrated, and they realize that it's not meeting a certain criteria. And they realize, Oh, I missed this requirement, way back here at step one. So that's sort of unforced error. Let's call it one A, one B would be, you can't just look at the requirements of the computer verbatim. But you then need to intuit what do these suggest for the requirements for my particular subsystem. So computers may be a bad example, because there's so many requirements. But if you think of something higher or more simple, maybe the the subject is a little more meaningful, but you know, let's say your high level product has 10 requirements, and, and two of those requirements apply directly to your subcomponent. Well, that's not the only those aren't the only two important things you need to worry about. You need to then create your own, what's called a PRD product requirements document for your subsystem, thoroughly define all of the metrics of success by which you're going to evaluate, have I met my goals, and you won't catch all over them, we all miss sung in, no engineer has ever gone to the end of a program and said, Oh, nope, I thought of everything on day one, that letter will never happen. But it's also equally frequent, that engineers don't sit down in the early stages, and really write down everything that they are trying to achieve. Not just what are they trying to achieve? But how are we going to measure it? And what is our metric of success? You know, if we are going to measure, you know, capacity of the battery, what is the lower threshold below which your battery no longer meets this criteria. So that's one B. And then the second thing is key now that you have these criteria, you prototype a couple of devices, 1020 100 1000, whatever it is, and you've measured your, your metric of success, whatever that was, and you see Krait, all of my measurements are above the line or below the line, whatever the criteria is max or min, right? And you say, my system passes. And you have looked more carefully at it, you realize, yeah, all of my, my dots are above the line. However, 10 of them aren't very far above that. Why? Have I really seen all the variation I might see in mass production. And if I make more of these, I make 10 times 100 times 1000 times more, how likely is it that I start to get some points that are below that line? Just because of the natural distribution of things? Yeah, that's what's called Understanding how much margin you have to target. So when you engineer something, yes, you want to set a target. But during the design phase, you also want to set sort of the design target which is above the actual target by some amount to account for some amount of margin and this month, origin is the methodology which you use to protect yourself from future variation that you can't possibly predict. And I see tons of times you, you get to nearly the final build. And now you're just starting to see things that are out of spec. And you said, what's going on? What's different? Well, the answer is nothing is different. You've just built more, and you've now seen the total variation or more of their creation, that it will exist throughout the lifetime of your product. That's
Aaron Moncur:really good. Okay, one A and one B is really defining and understanding your requirements and how you're going to qualify those requirements. And then number two, building enough of something so you have enough data points to give you a high degree of confidence that you have enough margin meeting, whatever that specification is, those are really great. Thank you. Okay, last question for you. So we talked about unforced errors and things that slow down engineering teams about the opposite what, what are some ways that you've seen to accelerate the speed of engineering, and we're not talking about leadership coming in cracking the whip, telling people to work nights and weekends that we're talking about sustainable, legitimate acceleration, both at kind of an individual contributor level, as well as like a leadership level? What have you seen that works for accelerating engineering projects?
James Cuseo:Well, I think projects where you actually do one A and one B of our previous discussion really well, that accelerates it by virtue of the fact that you now know exactly what you need to engineer. So you don't have to spend a lot of time debating, is this good enough or not? I feel like engineering teams spend a lot of time debating debating whether or not something's get off. Where if you clearly spell that out, you don't have to debate it anymore. Right? There's a number, it's there. Right? And it can be revisited. But not spending too long, you know, informally dwelling on it. Okay, do you have the data say we can't read that spec? Well, let's go have a meeting. And let's go discuss that. And let's reevaluate your proposal. You know, can we change the spec or not? That's what that's one of them. You're good design review methodology. Right? That will, in design reviews, where everyone can learn from each other. You know, we're no one is, no one's there to ascribe blame are no one's here to poke holes in your thing to show how smart they are. But everyone is there to do two things, one, contribute to the goodness of the end product, even though it's not your module, you're going to help your, your your partner make their module better. And to learn from whatever it is they are, right if they made a mistake. And if they did the thing you just talked about where they drilled and tapped a hole for a certain side bolt, but a different bolt is in in the palm? Well, that should be your signal to like, let me go back and double check that humans make mistakes. And then let's take that one step further. Creating checklists, you know, in the absence of the AI that you and I both want to arrive, creating good checklists, which error proof. You can get out human tendencies. Humans will make mistakes, how can we ensure that they don't happen? There's a great book, I think it's called The Checklist Manifesto. And it's all about how checklists have taken air out of things like flying to play and feel the medicine etc. In totally plastic engineering.
Aaron Moncur:I love that book. Yeah. Anyone who hasn't read that book, The Checklist Manifesto? Do so we have so many checklists, not so many we have an appropriate number of checklists at pipeline. And I think it's one of the things that really does keep us on track is having that checklist to go through. Okay, well, Jim, what a delight and a pleasure. This has been thank you so much for sharing your valuable time with us and your immense wisdom and experience in product development and engineering. How can people get in touch with you?
James Cuseo:I on, I'm on LinkedIn, you'll find me there, James Cuseo. That's really the best way, you know, keeps everything efficiently. You will get lost in my spam filter there. Or in my emails to, you know, to the soccer team
Aaron Moncur:Perfect. All right, Jim. Well, thank you so much again for being on the show. Cool.
James Cuseo:Thank you for having me. This was a lot of fun.
Aaron Moncur:I'm Aaron Moncur, founder of pipeline design and engineering. If you liked what you heard today, please share the episode. To learn how your team can leverage our team's expertise developing advanced manufacturing processes, automated machines and custom fixtures complemented with product design and r&d services. Visit us at Team pipeline.us. To join a vibrant community of engineers online visit the wave dot engineer Thank you for listening
