Embedded - 305: Humans Have a Terrible Spec Sheet (Repeat)

Episode Date: April 28, 2022

Amanda “w0z” Wozniak spoke with us about her career through biomedical engineering and startups.  Amanda contributed a chapter to Building Open Source Hardware: DIY Manufacturing. (A book we spoke with Alicia Gibb about in #289.) Amanda’s chapter was titled Design Process: How to Get from Nothing to Something. For more information about the companies we discussed, check out Amanda’s LinkedIn page. 

Welcome to Embedded. I am Elysia White, alongside Christopher White. This week, we're going to talk about robotics and biomedical electrical engineering with Amanda Wozniak. Hi, Amanda. Thanks for joining us today. Hi, thanks for having me. Could you tell us about yourself as though I were one of those people who just asked, any relation? Well, no, there's no, I mean, I have an Uncle Steve, but no relation to the Steve Wozniak you're probably thinking of.

Wozniak's actually Polish for Carter. So fairly common. It is. It really is. I'm sorry. Could you introduce yourself? Yes. My name is Amanda Wozniak. It really is. I'm sorry. Could you introduce yourself? Yes.

My name is Amanda Wozniak. I'm a MIT grad and electrical and systems engineer in Boston. All right. Well, since we're going to go through more of your career, I'm going to let it be short this time. All right. Speaking of short, we do Lightning Round where we ask you short questions and want short answers. And if we're behaving we won't ask you how and why and are you sure are you ready yes i am uh if you had your own podcast who would you want to be a guest and what would you ask them i would definitely want to talk to pretty much any theoretical physicist or anyone who's worked in um at nasa

and i would ask them pretty much how effective they are at getting anything done. Because there's just well, the problem space is huge. So there's just probably so many interesting stories there from random things like talking to engineers about bouncing radar off of the inside of test fixtures is really interesting. So I would collect all the war stories from back in the day. Let me write that down. We need to find somebody at NASA. You do. Should we bring back the dinosaurs?

No, but that's because I already have little pet dinosaurs, and I'm happy with them being fairly small and manageable. If they get too big, then, you know, I mean, turkeys are already bad enough. Show title. Should the bomb with vendors detailed be part of open source hardware? Absolutely. Absolutely. Which Sesame Street character best represents you? Probably Grover. Favorite fictional robot? Favorite fictional robot is Red Robot from Diesel Sweeties. And do you have birds or lizards?

I have birds. Two kaijigs. All right. We've completed lightning round. I think we've, yeah, I think that... Congratulations. Thank you. There is no prize. There is. It's unfortunate that you didn't ask why, because Red Robot wants to crush all humans and then finds an Icelandic girlfriend who teaches him how to love. So it's pretty great.

Oh, that is pretty great. All right. Another thing I have to write down. Okay. So you are an electrical engineer. Mm-hmm. And you mentioned MIT. Yep.

Why MIT? Actually, MIT because my best friend in high school put me up to applying. And I didn't figure out why I was really at MIT until about halfway through my junior year. So I, you know, it's like a lot of people in tech, I didn't know what my options were. And like, like a lot of women in my era, I actually like didn't think I could do tech. So I was going to go somewhere else. I didn't actually really know until my friend put me up to apply. And then while I was there, I had the normal freshman and sophomore experience of trying too hard. And then the fact that you're trying to

hold you back. And so it wasn't until my junior year where I was like really frustrated with my lab and I was kicking things in the hallway. And I'm like, why am I even here? And I was like, oh, because they know everything here or someone knows how to do everything or understands things here. And if they don't understand it here, they don't understand it anywhere. So I'm here to learn and to put as much knowledge into my bag as I possibly can. And it was interesting because right after I figured out why MIT, I started getting A's. So that was pretty rad. Yes.

When you're trying too hard, but then you're trying too hard to get grades not to learn. And then you learn and then suddenly your grades go up. Very familiar experience. Yeah. Because it's not about the grades. It was like, oh, if I like basically as a kid, I wanted to be MacGyver when I grew up. Because MacGyver knows everything. Yes. Oh, I'm familiar with that oneyver when I grew up because MacGyver knows everything. Yes. Oh, I'm familiar with that one.

Yes. Yeah. Everything about paperclips. I mean, I literally had the experience as a kid of taking apart a radio because I was ready for my MacGyver moment and I was like eight. And I found a circuit board. I didn't know what it was. I took it to the librarian and I'm like, what is this?

And she's like, I don't know. And I'm like, how am I going to make stuff? And she's like, I don't know. And I'm like, how am I going to make stuff? And she's like, I don't know. And that was my freshman admissions essay. Like, that's why I wanted to go to MIT. I'm like, I want to make things. I want to build things. I want to understand how stuff works.

So... But you stayed at MIT to get a master's instead of going immediately into engineering. Why? I did. Well, because in part, I didn't feel like as an undergrad, I knew enough. I would go to different career fairs. I would go to like talks about from Medtronic and Guidant and things like that. And I'm like, oh my God, I'm not ready to build things. I'm going to kill somebody. I better stay here and learn more and learn as much as I can. But I did have that moment

of I went to my advisor when I was finishing my master's and I asked, um, and my advisor was Jerry Sussman and I asked him, should I get a PhD? And he's like, well, what do you want to do? And I'm like, well, I want to solve problems. And he's like, no, you need to get a job. Cause I was like, I want to solve constrained problems. He's like, do you care what problem? And I'm like, no, just hard problems. And he's like, yeah, get a job. And then he sent me to actually go apply at Analog because, quote, all of their parts always pass data sheet specification. And so you became an applications engineer at Analog Devices. I did, yeah. How did you make the transition from wanting to learn things and being in school to being a working engineer?

Well, for me, it was a series of phases. So I actually put myself through MIT. So I always had to work. And I started off my first job that was not, you know, sort of working at a coffee house was a paid year off at the media lab that I took in order to learn how to do microcontroller development. And when that didn't work out as much as I wanted, it opened up another opportunity for a sort of scholarship in semiconductors. So at the time, it was the dot-com boom, and Intel was sponsoring women in science and engineering. So I took my experience at the Media Lab, I interviewed for this scholarship, and they ended up giving it to me. And Intel sponsored my undergrad and actually covered a year of my master's because

it was three years of tuition or until you graduate, whichever comes first. So I delayed graduating until I'd finished all but two of my MEng classes. And so that also came with co-op. So I started co-oping every summer working for first Intel and then IBM. So it didn't seem like a big transition to go from school to work because I'd already been working at least three months a year on like very directed topics with teams, even though like co-ops are mini projects, you know, you sort of get in the practice of working. And what about the things that an electrical engineer does that they don't teach you in school, like schematics and kitting?

Well, they don't teach you a lot. So I actually, they don't teach you anything about drawings, which if you are making any parts, you need to know about. So there's a whole host of even mechanical things that electrical engineers need to learn about. You don't learn about thermal effects. You don't learn about part tolerancing. You don't learn about component derating. You don't necessarily learn to even read spec sheets. So one of the things that we did in my

analog circuit design class was we actually reverse engineered a data sheet. And this is part of why I was really excited to go to analog devices. But what we were doing is we were trying to reverse a data sheet to understand the characteristics of a bipolar junction transistor. And the whole exercise was, one, to understand component specsmanship. But even at MIT, that kind of exercise was a really weird outlier. Like, the only reason we did the lab that way is because the lecturer happened to have a very practical non-academic background. And so he's like, if you want to build circuits, you know how to do it. You need to know how to do this. And so he actually pulled something from industry into the classroom, which was not typical of a lot of MIT classes, which were much more grounded in like, what's the theoretical, you know theoretical behavior of semiconductor physics?

So I always found that really exciting. And then you only see it when you're in engineering. You also don't learn anything about signal integrity. You don't learn a lot about noise. You don't learn a lot about non-ideal circuits. And it's the same story for electrical that it is for mechanical. Like there's just so much you don't see because in school they're trying to teach you sort of a canonical example. And then it's frustrating when it like I'm the type of person where I would go into lab and I would be very frustrated that my stuff wouldn't work and I would realize it wasn't working because of parasitics. And I would

find all of these ways to engineer around basically the ground truth of the real world as opposed to the ideal circuit design. So there's just so much you don't learn. It's not even practical skills on how to build. It's practical skills on how to understand that you don't see until you have a circuit and you accidentally have it latch up or set on fire or capacitors start screaming and then popping because you have like a standing wave frequency on your power distribution system and literally caps blow up because of a, a, um, excitation mode.

I wish they'd be upfront about that in academics. Like, okay, here's this program and this is what we're teaching you and why I think it would help with frustration because I had similar experiences and it felt like, why are you teaching me this? I don't know how to do

anything. Yeah. I have to wonder sometimes if it's because a lot of the really practical things seem like it's vocational training and vocational training isn't like important enough, but it's so critical actually. Yeah. You come out of school with debts and a big bucket of knowledge that you're, you think, okay, I'm going to spend my whole day doing Fourier analysis. And it turns out you're, you're going to call FFT parentheses. And then you're going to yell at somebody for not having the right one for you. Yeah. Yeah. It's, it's, um, I always, I like, I don't like one of the things when I go back and I talk to like the society for women engineers, um, dinners that occasionally I'll get invited to.

I just always make sure to tell them one engineering is really not intuitive to you. Haven't learned half of what you need to know to feel like you're going to be good at it. And anyone who thinks that they're really good at it is lying and doesn't really understand how their circuit works yet. Um, and then, uh, the next advice is just to get into lab as soon as possible and just start learning about where the failures really are. How did you learn that? Was it mentors at analog devices and your co-ops or? Yeah. How? Well, so a little bit of mentorship and then a strong dose of foolhardiness. Yes.

And being very stubborn. So one of the examples in school we had is we had to build an operational amplifier. And there's some canonical method for finding out the 3 dB point of an amplifier, which is you put in a sine wave. And the 3 dB point is the cutoff frequency where the output amplitude starts to drop. And the textbook way of doing it is everyone everyone um you know just puts in a sine wave and they start sweeping the sine wave until the 3db point they see the amplitude drop by 3db and then

they're like okay that's the 3db point because i'm stubborn i like started sweeping the frequency up and then i started sweeping the frequency down and the 3db point moved and i literally spent probably 20 hours in lab and this is the parasitics example figuring out oh why is this happening oh it's parasitics how do I get around it is there another test method right and just hammering out at it until I found a better way because I was stubborn when I went to analog that same stubbornness kept me in the lab for long hours at which point people would come over and start talking to me about hey what are you are you trying to do? What are you trying to measure? What are you interested in learning? What are you seeing? And then I got a lot of specific informal mentorship, not from my direct

managers, but from technicians, from the other engineers who were also like in the lab pretty late at night, who were the type of folks who, you know, cared about their measurements so much that they hand wound their own inductors as part of their measurement setup. And then I also spent a lot of time with the folks that are considered the support team, like the CAD engineers, just talking to them. And every time they're like, hey, by the way, that's not going to work, I listened. And then they would tell me about why it wasn't going to work. So everything from connector footprints, board stack ups, the whole thing. And so a lot of my mentorship was not from, you know, someone actively trying to teach me, but someone just saying, by the way, you're going to mess up, or actually breaking something and then working on it until I could understand it and fix it.

So just a lot of willingness to spend time in the lab. You've mentioned parasitics twice. Could you explain for the software engineers what that means? Yeah. So parasitics are essentially, and this is why everyone says RF is black magic. Parasitics are things about the physical world that mean a circuit component is never ideal. It's effectively the electrical equivalent of cobwebs and dust everywhere. So, you know, like if you have in your mind, oh, you make a circuit by connecting components, and it's the connection between components that creates behavior. It's just stuff that changes a resistor's value. It's stuff that changes a capacitor's

value. It's stuff that adds a capacitor where you don't expect it. So it's almost like if you were doing auto-generated code, but there were little things that could inject random jump statements or slightly change variable values on you without you being able to catch it in the compiler. Or it's, you know, if you had really bad memory, right? And you set a value and that value was used to calculate things. Imagine that value could shift over time because there was memory degradation. So, you know, one time you call the function and your coefficient is 1.1. And the next time you call a function and that same coefficient is now 1.12. But you're relying on that to be 1.1 all the time.

That's what parasitics are. That sounds horrible. That's where the real world is. It is. You know, the real world is in things like parasitics and tolerances because there's no such thing as a perfect component. Okay, so you read analog and then you worked at Harvard. I did, yeah. What was that? What was that like, or how did that happen? Well, both, both, both. Okay, so, well, the way it happened was actually good luck, bad luck.

So I, you know, was at Intel and IBM and then Analog, and I was working on semiconductors, and I was super excited when I started because semiconductor physics is hard because you can't see the devices you're working on. They're hard to measure. And after a few years, I got really bored and really unhappy because I actually stopped learning. And I was actually at Analog in 2000, I think that was 2008. And I was miserable because I'd already designed a whole bunch of application boards around this part family. Designing boards is much faster than designing integrated circuits, right? So I had written 13 duplicate data sheets and I'm like, I'm not learning anything. I'm unhappy. I'm not growing. And I realized I would rather be working on, I think the way I put it is I would

rather be working on an instrumentation amplifier in the ass end of an MRI than build one more chip for consumer electronics. Because we had all of the engineering power in the world and we were making TVs cheaper. Yeah. Yeah. I felt that. Yeah. And so here's, so that's the, the, the good luck, bad luck part is it was 2008. And everyone knew I was miserable and riding a hedge of burnout. So I got put up for downsizing first. So I got caught in the first wave of layoffs during the financial crisis. But that meant that I got a severance package and extended health insurance.

And so I stopped and then took stock of like, what do I really want to do as an engineer? And I'm like, okay, it's not enough that the technology be challenging, hard and cool. It has to have an application and a reason. So when I was interviewing at Analog Devices and when I was interviewing at like Johns Hopkins Applied Business Club and all of these other places for jobs, everyone made the same joke and I ignored it and I shouldn't have because people give you good feedback. And that joke was, hey, you know, we don't do medical, right? And so I'm like, you know what, maybe I should do medical because clearly like I had this biomedical minor and I told myself at the time, oh, I'm just doing this because it's cool. And I did the usual undergrad thing of the thing you think is cool is not hardcore enough. So you do the hardcore thing

and not the thing you like. And I was looking at jobs at Phillips Medical, Guyton and Medtronic and all sorts of places like that. And then this random thing happened where Harvard was looking for an electrical engineer with a background in biology. So it was like, lol, what? And I applied and I got the job. And so I was employee number like somewhere between 20 and 30 at the Wyss Institute at Harvard when the institute first opened up. And was that research-oriented or practical development? Well, that's the thing. It was practical development. So the charter of the Wyss Institute was effectively, here's $150 million that Harvard matched.

And the goal was to do translational development for research so that it wasn't research for research's sake, which is part of why I ended up not getting a PhD and leaving academia and going to industry. But they needed people from industry to work with the researchers in order to translate their technology across the valley of death. Sometimes I've had a job similar to that where I was working with PhDs or experts and it was my job to translate. I love those jobs. I just adore them. You learn so much and their perspective is so different, right? Like engineers and scientists are not the same at all, not even remotely. And the scientists will spend all their time telling you whatever you want to know, because that's why they're doing what they do, is they love to share the information. Yeah. So in a lot of ways, it's a lot like working with,

you know, cat engineers and machinists again, right? Because they're like, here, let me tell you everything I care about about protein engineering. This is why protein engineering is super cool. Or, hey, let's talk about 3D tissue culture. Oh my God, if only I could have this tool, the research I would do. And I'm like, oh my God, it's super easy to build that tool. Why don't we build that tool for you? How long were you there? I was there for a little under five years. What made you leave?

I left, this is going to sound a little bad, but I was having a conversation with my What made you leave? So there were a few projects in the beginning that took that long to get out to clinical studies that involved a lot of machine design and a lot of system design. And then after that, a lot of activity at the Wyss was pivoting towards, you know, either more small demonstration robotics or, you know, applied biologics. So it was more big R, little d, and I needed a larger development effort, specifically machine development. So, that's how I ended up going to NextStage because I'd actually been working on dialysis-like therapeutic with NextStage as a component integrator. And when the DARPA program that I was managing pivoted to protein coding rather than developing a machine. I was like, well, they're building a machine. I like working with them. I took the engineering project management role for the DARPA grant to work with the next stage engineers, again, because I wanted mentorship for my discipline, not just doing cool research. And so I was like, hey, do you need an engineer? And they're like, yes,

please come over right now. And that's how I ended up at NextAge. At Harvard, had you had much experience with the FDA processes? No, and I was interested in getting it. So when I started at the Wyss Institute, there was a lot of, I want to say almost like research engineers, researchers tend to have naivete about what the real regulatory process looks like. And I wasn't any better because I came from semiconductors. I had no idea. And we hired a few staff engineers, actually, with really strong development backgrounds from regulatory areas. So we had some staff engineers and senior staff engineers with background in doing good manufacturing practice for genetics and human tissue derivatives.

And then there were a couple of engineers that came in from DECA, Dean Kamen's company, who had been used to developing medical devices. And they started talking about what a real sort of development process for regulatory compliance would look like and the difference between what we had at the Wyss and what they were used to. And that led me to actually go seek out trade shows. I think I went to the Biomed Device Boston trade shows and the MDDI trade shows and actually started taking classes on regulatory requirements. And then I was super excited because Nextage did it for real because they were an ISO-compliant company with a device on the market. So I went to Nextage, in fact, to learn about releasing devices and products with the FDA.

And do you think the process is good or do you think it produces busy work? Do you mean the regulatory process in general? The FDA regulatory process. So the interesting thing about the process is it's actually more of a, it's more of a guide really. So very, very Pirates of the Caribbean. So the way ISO 13481 works, which is the quality standard for FDA, is it's more, they tell you that you need to develop your own regulatory and quality process and that you need to make sure you follow your own process. I know an engineer, Zach Mulchano, who actually part of what he does is consults companies setting up their process for the first time. If you set it up wrong, you can create a lot of busy work for yourself.

If you set it up correctly, you can actually streamline a lot of your development effort. The challenge is that the FDA doesn't tell you exactly how to set up your process. They set up guidelines for how the process should work and then mandate that you follow whatever process you think should be best for you. And then once you set up your process, it's very hard to change it. Or if you do change it, you need to requalify. So it's a bit of a chicken and egg. Because if you, again, if you're not good at setting up your own process upfront,

you will create so much pain for yourself down the road. But if you don't have any process at all, it's the wild west of medical devices, which is why I didn't go into medical device engineering right outside of college. So basically they give you a shovel and you dig until you are bored. And then you realize you just have to keep digging because that's what you signed up to do. Pretty much. And the thing is like, humans are bad at process engineering. Yeah. We tend to think that we need a lot more than we actually need. And so you write these processes that are very complex and involve pieces of paper. Yeah. But, and that's because it's hard to, it's hard to legislate judgment.

Yeah. Right. Like it's, you, you're so torn between like what takes judgment and sign off and what takes traceability and then combining those two. Because some people in the, like, the whole idea of a process, of a regulatory process is you don't need every person in the company to have good judgment because the process will catch them and guide them. But you can just, it's a dramatic seesaw of, like, too much process, not enough judgment. And then there's judgment, but now the process can't allow you to have judgment. So it can, yeah, it's definitely, you can, you can dig a very deep hole. And at Nextage, you were shipping a product. Yes. Well, I was working on a product to be shipped. I was working on a new product, not an existing product. Okay.

Did you work through the whole product timeline? I did not. And I'm still so sad about that. Why? Well, because actually the reason why I went to Nextage was to go through the regulatory process from development through verification, validation, and field release. That's a long timeline. So what ended up happening is, for various reasons, the product I was working on was put on hold. And I was like, okay, that's it, I'm done.

And you did some project management for Next Stage. I did. And it's interesting because I didn't do it as a project manager formally. So my role was always principal engineer, not PMT. And yet you did it anyway. I did. Did anybody notice? Oh, they definitely noticed. I ended up running the weekly technical team meetings. Was that sort of, I got this responsibility by default because nobody else was doing it? No, that's a case of like, I really want to get this done

and I see gaps and I'm going to make sure it gets... A little bit, yeah. It's not that no one else was doing it, but have you ever had the challenge of sitting in a room sort of seeing a team struggle and you're like, I could fix this? Yes. Yes. So I, particularly earlier in my career, I had a hair trigger on challenge accepted. You know, and that got me, it got me a good reputation, but that's also part of, you know, what can lead to burnout when you, when you take off, when you bite off more than you can chew. Yeah, when you keep doing it over and over again, definitely.

Yeah. Yeah, so I came in and when you're doing a sort of, when you're doing a full machine design, there are a couple of different, depending on who the long pole is in the program, a couple of different teams can either end up holding the bag or steering the ship. And the system we were working on was highly mechanical, highly electrical, and had a lot of firmware. But what ended up happening is to best unblock the... So the team that would have gotten left holding the bag was firmware. Oh, yeah. I'm familiar with that. Yeah. But I take very responsibly, like,

the reason why firmware would get left holding the bag is actually because of electrical, right? Like, if we don't have the boards designed in time, or we don't give them good requirements, or they don't understand the circuit design or what the intended function is, it's very, very hard to bootstrap firmware and software development without hardware stability. And you don't particularly need a lot of mechanical stability to have electrical-enabled firmware design. So in my classic trend of feeling very responsible, I was like, okay, we need to not let firmware be left holding the bag. And then that's how I actually ended up getting sucked into project management, because it was a lot of prioritization on what gets tested, what gets developed, who gets unblocked first, what do we have to build, what can we test today, etc. Do you have any advice for double Es or anyone looking at that? I mean, you did it because you

wanted to get things done, but sometimes that can lead to burnout as well. Do you wish you'd had training or do you just have any advice for people looking in that situation? Yeah, I mean, one of the things is to really try to understand roles and responsibilities and sort of behavioral organization. But note that much like with parasitics and circuit design, teams never follow an ideal structure. So one of the things and the reason why I was kind of excited to take on project management is, you know, working on component level stuff, I ended up getting very, very bored. And I also realized that you can't get very far in getting stuff done if you're only working on a part. Which isn't the same thing as like, I want to be in charge of everything. It's more realizing you need a lot of people working on a lot of parts to get stuff done.

I think there's a point in many engineers' careers where they finally figure out it's a team sport. Yes. Yeah. And so the thing, yeah. So I don't know how to explain it to someone who hasn't figured out that engineering is a team sport yet. But to folks who have realized it and then they're like, OK, great. So what do I do about this? I ended up taking maybe one two day course on project management. And then I did a whole lot of research into like cognitive neuropsych. Because I'm like, look, I'm going to go, circuits are fine. I can read the spec sheet.

Humans have a terrible spec sheet. Humans in corporate organizations, like they don't even have documentation. And so I started actually studying people in part because I was really, really bad at working with a team. The first time I was like, this is a team sport. I'm going to be in charge of the team. And everyone's like, you are the worst coach ever. And so definitely my advice to engineers would be don't just automatically dismiss what folks are doing over at the business school because they can teach you a lot of really good methods and really good things about people and organizational behavior that you won't know unless you run into a problem face first. So you can choose to either believe that there is some value in the soft skills, or you can learn the hard way and get really demoralized

from learning the hard way. Yeah, that's all very familiar. And you left Next Stage to go to a startup. I did. So we talked a bit about how, you know, if you take on too much responsibility and you continue to do it again and again and again, you can start to get burned out, right? Oh, yeah. Going to a startup is definitely a solution for that. No. So part of part of what I found engaged my need to get it done more than anything else was, in fact, that what I was working on was safety critical. Yeah. And that sort of personal overengagement in this is important. We need to take care of our customers. We need to take care of our patients. This is people's quality of life. You know, this is how

we make a difference was definitely worrying with my ability to be chill enough to be effective at a team sport, right? Because if you, if you ever have someone who's hyper competitive or hyper perfectionistic on your team, it actually skews the dynamic. And I realized that I was not going to care less about working in anything in medical. And I said as my long arc goal, in fact, that once I got the chill I needed, I would go back to working on safety critical systems and high reliability systems. So it was like, okay, I'm going to go to a small company where the focus is a team, but it doesn't, you know, radar engineering, cool, hard, challenging, but it doesn't have that same emotional hook for me that working on medical does. So, you know, when I looked at all

of the things I wanted to do, I realized at this point, I just want to work with a good team and I want to practice my team skills as well as my technical skills. And, uh, but I'm going to put this like burning need to help people on the shelf, because if I can level up in my skillset otherwise, then it'll be much easier to help people in my career in the future. That's an interesting thing to have figured out about yourself that you you took being having applications that were fulfilling to you put too much pressure on your need for perfection yeah it's it's i mean you see a lot of um sort of know yourself documentation and or documentation and then there's this cultural documentation you know uh yeah no it's i'm like the spec sheet we

have for society aka the new york times and atlantic um no so when you you see a lot of folks writing these days about how it's an utter crock of awful that people are told to do what you love. Because doing what you love really intensely leads to profound burnout. And I've been seeing articles like that. And I'm like, why am I getting bitter? And I realized it's like, oh, it's the concept of attachment. This is the thing I hold on to very tightly. It's super important to me. Obviously, I'm not going to have an easy time taking a step back from it.

But the thing is, there are multiple things that lead to engagement and satisfaction. So I like looked across the spectrum of what are things I enjoy that are probably easier for me than I want to save lives. And that's where I came across things like the team dynamic. And it's a milder version of I want to save lives is I want to help other people feel effective. I want my team to be happy. And I want to have enough free time where I'm not constantly worried about, did I do the right thing? Or is this going to fail in five years?

I see that and I understand it. But I have always had the other voice that says, you have to do it because someone may do a worse job. Wow. Yeah. Yeah. No. Isn't that, isn't that full of ego, but yes, for medical devices. Yeah. I mean, so not to, not to flip the mic and be like, where does that voice come from for you? Um, but, uh, I have a, I have a friend, part of, part of what ended up helping me out here is I have a lot of friends who are in the healthcare profession. I have friends who are doctors, who are intensivists, who are nurses. And one of my friends in particular, she's a nurse practitioner. She always cares about helping other people and is like, if I don't show up, who's going to help them. And I got to see her approach burnout and had to counsel her on self-care, right? Like it's the whole thing of, you know, if you want to pour your cup out for others, you need things in your life that fill your cup up. Because the flip side is someone else will do it more poorly is if you burn out, you're going to be even worse than the next person, right? Like if you burn out, you can't be effective.

And the other best piece of advice my undergraduate advisor, Jerry Sussman, ever gave me, and he gave me this advice also when he told me to go get a job, because I listed out like all the things I want to do in my career. And he's like, you know you can do them serially, right? Yes. And I looked at him and I'm like, but you do all these things. And he's like, I am much older than you. And I did not do them all at the same time. You know, so even if someone else might do it badly now, the other thing I try to remind myself is I am not the only person like me.

There are tons of people who want to help people. Yeah. And for better or worse, with that sort of entire digging process that you can get into with the regulatory process, the whole point is that at the end of the day, someone's got to do the accounting on, did you do your work with enough diligence? And while there are things that fall through the net, there's, you know, the whole point of those regulatory mechanisms is they catch mistakes. That is the goal. Yeah. That's the goal. And it does, it does work. So like the other thing I take faith in is, you know, at these different trade shows I've been to, there was a story of a company that had an implanted defibrillator where there was a last manufacturing step that wasn't documented, which caused metal fatigue, which caused the implantation lead to shatter, which led to torn atrium and someone hemorrhaging out in three minutes. And in fact, probably two patients had died right around the time that a new head of regulatory and quality came into the company.

And what ended up being his job for the next year and a half was finding the issue before someone else died, based on the prior reports, finding a way to remove all of the defibrillators from the existing population and then shutting down that division. So even if it doesn't get caught now, there's a chance it gets caught later. And then the other thing about medical that when you work in medical device development, you learn is it's always a numbers game. There's no such thing as creating zero risk. Yeah. When I did FAA and we did flight things, it wasn't, it was never zero risk. You had to

acknowledge the risk. Yeah. And that was, that was one of the hardest things was your system is going to fail. And bad things will happen. The more critical you are, the worse it will be. Yeah. And that acknowledgement's hard. It is. But I think you have to make that same acknowledgement for your career. Right?

There's always going to be risk. There's always going to be problems that you're not going to be there to solve. And at the end of the day, you're a person, not a machine. It's a good thing for people to remember. It's also hard. Yes, it is very hard. Because you just go and go and go. And you're like, oh, only I can do this.

Only I've been here for this. Only I can. And it's A, not true. Yeah. And B, yeah, if you burn out, you won't be there to do it, will you? Nope. And then, but I think it's easy for people to fall into that, particularly for technical folks to fall into that fallacy. In part because I don't know about you, but, and you know, I did this in undergrad as well.

I told myself the reason why i cared about so much about technology was because it was hard but at least it wasn't people you know and and so uh because it seems so pure right it seems so tractable it just is you just have to learn enough and then you can understand and operate the whole universe it's all based on logic and everything should make sense and do exactly what the equations say. Physics is deterministic, right? But there are parasitics. And there's quantum effects.

Physics is a mess. Mental note, don't call your co-workers parasitics. No. Okay, so back to your career. You left medical to go to a startup that was doing industrial robots? No, so Humanics was working on radar engineering system. Sorry, radar for industrial robots. Okay. Okay, so this is like radar in cars, but instead it's radar in robots so they know not to hit each other. It's specifically, they call it microlocation.

So it's millimeter and centimeter scale positioning. So have you seen the new Roomba equivalent lawnmower that came out from iRobot? We are familiar with that. Sorry, we have an iRobot person who comes on pretty often. Yes, we are familiar with lawnmower that came out from iRobot? We are familiar with that. Yes. Sorry, we have an iRobot person who comes on pretty often. Yes, we are familiar with lawnmower. They have a radar ranging fence, right, where you put stakes around the yard, and then the robot can find its way around by measuring its distance to each stake?

Yes. That is pretty much. He didn't tell us that. He told us about the fence. Oh, did he? Okay. Yeah, and the fence is actually based on ultra-wideband radar. I think probably their frequency band is under a gigahertz or around a gigahertz that they send out a chirp. And then there's some time-of-flight measurements that happen between the robot and the fence posts. And then that's how it localizes. So, humatics is a similar but more challenging version of that technology.

But the application is for industrial robotics? Yes. Okay. And since you weren't working on radar, I'm not going to ask you about the power in robotics. But you have been interested in robotics before. Yeah. Yeah. And I ended up doing a lot of like mini robot demos when I was at Harvard in the bio-inspired robotics group and things like that. Because robots are, robots again, you think you can build something and then you build a robot and you're like, I know literally nothing about the problems. But everyone's like, I know literally nothing about the problem space.

But everyone's like, it's so cool we can build robots. And then you look, Atlas fall over. Yes. My goal was an arm that would type for you. Yeah. And it was so much harder than I expected. But you intended that project to be partially a comedy thing. Well, because I shouldn't have chosen a 50 arm and not quality useful but not quality yeah robots are one of these applications where like

there's a common fallacy i run into on teams all the time and it's happened at literally every place i've ever been and i've subscribed to the same fallacy of seems simple right well it seems straightforward and uh robots are one of those simple, right? Well, it seems straightforward. And robots are one of those things where you're like, well, it seems straightforward, you just and then it the tree of the potential problem space is huge. And it's the sort of thing where you make one decision at the beginning of the problem, and you actually prune off the solution, and then you never make your way back to it. Like, and then someone else finds that solution like 10 years later. So robotics is hard.

It's interesting. It's just hilarious and it's tangible, which is one of the reasons I like it. I do like the tangibility of it, the being able to see it happen and to feel the physical nature of it. Yeah. And you get to look like, so the reason why I'm not a computer scientist and I became an electrical engineer is because things that happen in the compiler are not tangible. And sometimes things that happen in the compiler are not even, you can't even interrogate them. You can't even measure it. You don't even know

what happened, right? A miracle occurred and then something ran on the computer. But electrical engineering, it might be hard to instrument, but it's physics and you can instrument physics. Robotics has that same level of like, you have no idea why it just did that thing because there's actually 15 different interacting subsystems that led to this bizarre emergent behavior and then like the arm moves through singularity and slaps something uh and that's why i like it because at the end of the day it's it's a hard it's a hard to interrogate problem but it is still it's still possible to investigate well and you had deep learning into that now and you have hallucinations you have to debug so yeah i'm i am actually like the the black box black box um ml stuff i'm also not a fan of because you definitely cannot cannot instrument it i'm like no but more

of the ml stuff is becoming instrumentable i mean the convolutional neural networks which i learned as a total black box now have oh and this stage should look like this, and if you look at the kernels, they should look like that. Well, yeah, if it's built as a pipeline. But I'm still kind of amazed that you can visualize and debug what used to be black boxes. And so I wonder if we're going to head that way for most of the machine learning things.

They should not have been black boxes. Yeah, I think it, well, it has to be instrument way for most of the machine learning things is they should not have been black boxes yeah i think it well it has to be instrumentable for it to be practical and and applied right because like for example you know you have a background in the faa you know if you can't deterministically prove that something works in a closed form way it can't run on a flight computer right right like flight computers run provable software. Like, logically provable, mathematically provable. So if you don't have a way of instrumenting ML, or at least, like, again, bounding it, right? Like, figuring out what is the tolerance of its answer.

Then it's not going to be deployable in any, you know, the hard, interesting, safety-critical systems. No, we'll just keep putting it on cars. Yeah, cars are... That's the... So, engineering... Hang on, you know what we work on right now, right? It's true. Well, I mean, we're working in research areas.

Uh-huh. Yeah. But I'm, and we have a self-driving car or autopilot-ish car. It's not self-driving. It's not really self-driving. So I really do appreciate all these things. But sometimes I think of they're just insane to even think they could work. Well, I mean, I am a horrible pessimist in this respect, right?

So I actively did not pursue a career in medical originally because I didn't think I would have enough experience as an engineer to not kill someone. Because when I started out, I didn't understand that there's all of these regulatory and reliability processes that you use to validate that something works and to prove that it works within bounds. I knew nothing of that in undergrad. Right. Um, and so as an adult, like I carry that forward, I'm like super skeptical of anyone who's like, it will just work. And I'm like, I'm going to wait for that to break. I think that's a healthy attitude. And I, yeah, I prefer to be wrong about that and just accept that I was wrong than to think that everything's just fine all the time. Yeah. Oh yeah. Pleasantly surprised. Yeah, no, exactly. Like optimism is dangerous in engineering. You need the vision absolutely to drive the work, particularly when the work seems impossible, but at the same time,

you can't get cocky. I'm a long-term optimist and a short-term pessimist. Like, everything's going to break. This will never work this week. It might work in a month if we keep trying. Yeah. So at Humanics, did you do management stuff there? I did. I ended up, I was very adamant when I started that I wanted to be an individual contributor,

again, to free up more of my own personal emotional bandwidth for myself. And almost immediately, I got pulled into managing subcontractors. So I'm like, all right, you know the rules. If I'm going to be managing people, I should be a manager. And that's how I ended up getting promoted to director of electrical and embedded engineering. Did you have to write performance reviews? No. Actually, I don't know if they were even writing performance reviews when I left.

That is one benefit of a startup, for sure. Even if you're in a, quote, management position, the actual management responsibilities are relatively light. But it depends on the drama factor of your startup, right? And now you work at Amazon Robotics. I do. But that's all we're going to say about them, right? Pretty much. I'm a principal engineer there, which is, again, not a management position.

It's an individual contributor position, and it leaves me free to mentor people as much as I want. Do you do tech outside work? I cannot, sadly. I used to, but as part of my current gig, I can't do anything outside of the company. Oh, not even build the pumpkin robots? Oh, you mean tech for fun? Yeah, pumpkin. Oh, yeah. No, I can do. Okay. Yes. Do I do tech outside of work build the pumpkin robots? Yeah, pumpkin. Oh, yeah. No, I can do.

Okay. Yes. Do I do tech outside of work? Pumpkin robots? I don't know. Do I make bristle bots? Actually, I haven't been. So one of the things I find is if I have a job that's related to you have to be careful not to get a job doing what you love.

If I have a job that has me firing on all cylinders, technically, I don't do tech outside of work. And even like, it turns out a lot of I mean, I can't stop being an engineer, right? Like I can't not I anywhere I go into and I look at a thing, I'm immediately like, how is that made? I wonder how much it costs? What was the finishing process? Hey, do you think they build it this way? Right? It just never turns off. But in terms of doing my own tech development, pretty much the last time I did tech outside of work was when I was at Harvard, in part because the research side of things meant I wasn't doing as much engineering design. And so, you know, when I was at Harvard, I did a lot more for open source hardware

and I did like a lot more sort of side consulting gigs and just reverse engineering for fun. Do you think people should do tech outside work? I mean, we talk sometimes about people having portfolios and things they can show off. Is that an important thing when you're hiring? When I hire people, I look less at what they build and I look more at how they think. And are they curious? And are they trying to learn more? Or are they like, I built this thing,

and then I built this thing again, and then I built this thing again, and I have endings. Sometimes having artifacts is a good indication that that person is perpetually curious, but it doesn't have to be. But my interview style is not maybe necessarily traditional. One of the things I've always done is more behavioral interviewing and less things like strict technical coding interviews or answering technically challenging questions, because from my perspective, they never, like I used to get into this fight at Harvard with one of the other hiring engineers where he would ask, you know, people the angular momentum moment of inertia style questions. And I'm like, no one remembers freshman physics that doesn't tell me if they know how to think. But I think what's more important, whether or not you do tech outside of work, is do you have operating margin? So one of the things that and, again, as a younger engineer,

I was like, basically running in sixth gear all the time, right? It's either sixth gear or you're off. And it's really the concept of operating margin and reserve capacity is huge and super important if you actually do want to be able to grow and sort of optimize your own learning and development, even if you work in tech or do tech for fun. So what I mean by that is I have to have time in my week where I'm not working, where I just take a walk and think. And I'm not saying I get enough of that time, but that's my goal is to have enough of that time because that's sort of where a lot of the innovation happens. That's when I figure out, oh, you know, if I do this small thing, it'll have a big effect. Or if I develop this tool, it will result in technical leverage. But if I'm just go, go, go, go, go, both inside of work and outside of work,

I don't have those moments. So I try to begin downtime. I think that's a good idea. It's hard to get the balance. It's also hard to tell people to do portfolios when I certainly didn't do portfolios. And I'm not sure that it is a good idea to do tech outside work if you're working full time and your brain is engaged. Well, so like people only have so much capacity for certain types of cognition in any given time, right? Like I once had a roommate where he was self-employed. so I would get home from work and he would be like, project time! And I was like, no! And then I had to explain to him, I used all my executive function up today on project management. Or I used all of my debugging skills up today trying to figure out what was going on with this thermoelectric subsystem.

And he didn't understand that at all. Yeah. You know, but if you use it all, you have nothing left over. And then, in fact, like these same cognitive resources, this is again like my whole, I'm going to study how people work. Those same cognitive resources are what you use for other executive function tasks like banking or cleaning your room or doing laundry or making dinner. Like if you don't leave yourself left over time, or if you spend it all in one place, you don't have it for any other function until you rest. So I think, you know, the whole like, oh, you should be hustling. And I'm like, this is toxic.

I think like, if anything, I try to tell undergrads like, are you making sure to take time off? Because if you're not giving yourself any downtime, you're sort of, you're stressing yourself out so much, you're not actually able to learn the way you want to learn or perform the way you want to perform. You've talked about burnout and on what we've just been talking about, those two things together. Have you ever thought about quitting tech? Oh, yes. Yes, I have. It's funny because you're really passionate about it and you obviously love it. Why would you think about quitting? Well, so a couple of reasons. I thought about quitting tech actually even at MIT in part because of the hardcore culture, right? Like this sense of you have to be working on the really hard thing, otherwise it doesn't count, which was very pervasive at MIT in the 90s. Like, is what you're

doing real engineering or are you just messing around? And I found that particularly toxic. And it made me feel like, well, what am I doing with my life if I'm not doing the hardest possible thing? Having a good life, maybe? Yeah, you know, that doesn't occur to you usually. I mean, some people do think about that in undergrad, but not most MIT undergrads. And one of the things that helped me with that was actually everything to do with L'Amour Fried and Adafruit, right? Because she grew Adafruit in part because she wanted to make technology accessible to everyone and not have it feel like you had to be elite or hardcore in order to do engineering. So that was amazing to watch. And I'm, you know, grateful every day

for the time I spent, you know, grateful every day for the time I spent, you know, supporting my friend and starting her open source hardware business. And just the fact that it's literally seeing young people engage with electronics and then not having any of that cynicism, like, is just a balm for your soul. So that was like the first time I nearly quit tech. And luckily my friends were like, yeah, I'm not going to take whatever feedback for an answer. And they're like, I'm going to do what I want. And they were like just incredibly, incredible role models. And I'm super lucky to have folks like that in my life. The other time was actually, um, I, you know, through my long corporate arc, I experienced all of the typical sexism that women

experience in tech. And I'm like, man, I can't keep fighting. Maybe I should just quit. Because I'd been dealing with everything from, your daughter's going into engineering, why would she want a man's job? When I went to college, to people literally trying to pat me on the head at work, even though I was a principal engineer. And calling me little lady, right, and I'm like, or going into vendor meetings with a consultant, and then having a conversation with this vendor, at which point they turn around and go, that's a really good question, you must be an engineer. And then I had to literally look at him and say, that's why it says principal engineer on my business card. Right? So I ran into just so much just bull in my career that I'm like, maybe I should quit. And then I, then I did have that moment of, but what about the next person down the road? And I'm like, I can't quit. You know what I'm going to do though? I'm going to stop like gloves off. I'm not dealing with this anymore.

And I got some advice from some women who had been on, you know, CEOs and board of directors and things like that. And they were literally like, for some folks, it would be not, you have to be at the right point to be able to take advice like this. But they literally said, don't take it personally. It's not about you and don't let it hold you back. Right. It's the whole thing of like, if you find a grudge and you hold onto it, um, harboring resentment is like drinking poison and waiting for the other person to die. Yeah. And I'm like, all right, well, I'm going to have to sit with this one for a while. And I sat with it. And one of the, there was a really awesome, and eventually there was payoff, right? Like at one point I was at a recruiting event with a junior engineer at Nextage. We went to Northeastern to recruit.

And the inevitable, like, what is it like being a woman in industry question came up. And she answered before me. And her answer just like made me so happy. She's like, Oh, I'm having a great time. And I'm like, huh? And she's like, cause everyone is terrified of her. And then, you know, so like what ended up happening is between my technical seniority, um, you know, my eventual ability to develop people skills, and sort of like trying to channel my inner Nancy Pelosi. I got good and I just like, just got good enough at being like, you really know, we don't do that here to create a good environment for this other engineer. And so I'm like, Oh, my God,

you can realize change, you literally just have to not care when someone's a sexist asshole. And then you have to look like a phrase my friend used. And I'm like, I internalize this. I'm like, I'm going to wear this like a badge. If someone does something pretty intoxic, and it doesn't have to matter because it's sexist at all. It may be they're being toxic because they're just poorly socialized. Who knows, right? You look at them like Nancy Pelosi would look at you if you didn't use a coaster.

Or I'm like, what would Admiral Grace Hopper do, right? She'd be like, young kids these days, they're real smart. She gives credit away, or she used to when she was still alive, right? So I'm like, you could just be super matter-of-fact and be like, yeah, we don't do that here. If you want to do that, you can take it somewhere else. And when you role model like that, people back you up. And then the culture just improves. That is really good advice.

And I mean, the not internalizing it is really important and very hard. It's really hard. But the we don't do that here is surprisingly effective. It's still scary. Yeah. And, oh, it's still terrifying. And there've been places where I've tried that where I'm like, we don't do that here. And then it turns out they did do that there. Exactly. Exactly. And, and when that happens, right, that's not that you should leave tech. It's that you should leave that job or you should leave that team because it's not worth it. But not all tech is like that.

It's just, there's something about tech where, um, I, and I think it's the myth of the lone inventor, right? And it's the myth of the cowboy and it's the myth that technology is not a team sport. The ninja rockstar. Right. I mean, like I make the joke, I am 10 ninjas, but like literally I am nothing without my team. Right. It doesn't matter how good I am. If I don't have a good team backing me up and if my team doesn't believe me, I'm going to get zero done. Nothing done. I might lie to myself about how much I get done. But if you look at your actual potential versus your realized potential, you're nothing without other people. And anyone who thinks differently is literally deluding themselves and they're wasting opportunity.

So cowboy is basically a swear word in my lexicon. Okay, I have one more question for you before we let you go. Yeah. And maybe it isn't so much a question, but your cowboy as a swear word makes me go back to earlier in the show when you talked about your stubbornness. Do you really consider yourself stubborn? Maybe? I don't know. Like, I'm pretty accommodating.

You know, maybe stubborn isn't the right word, but I'm definitely incorrigible to a degree. I have a lot of conviction about the things I believe to be true. I don't know if that's what stubbornness is, though. I don't know. I just sometimes I don't want to take shenanigans for an answer. It's the closest word I have. Maybe I need to go back and reread the dictionary, though, and find a closer one. I think resilience is the word you're looking for. I'm going to have to think about that one.

Thank you for offering that up. Do you have any thoughts you'd like to leave us with, Amanda? Probably the biggest thing is that the hard things are always, not always worth it, but they're really often worth it. I don't know. I don't think anyone picks up engineering to just sort of coast through. So if you've got anyone out there who's thinking, man, I don't know if I should be doing this. The answer is if you're asking yourself the question, do I belong here? And should I be doing this? Am I good enough? That actually tells you, you care enough and you are good enough. And you just have to give yourself time to figure out what you're going to do to be effective. It's important to just remember we're people,

not just engineers. Engineers are people too. That is great. Thank you for being with us, Amanda. Yeah, thank you for having me. Our guest has been Amanda Wozniak, Principal Systems Engineer at Amazon Robotics. I would also like to thank Alicia Gibb

for connecting Amanda with me. And thank you to our awesome Patreon supporters for Amanda's mic. Special thank you to Interworking Labs for joining at the corporate level. Finally, thank you to Christopher for producing and co-hosting. Oh, wait, not finally. Finally, finally, thank you for listening. You can always contact us at show at embedded or hit the contact link on embedded.fm. And now a quote to leave you with this one from Steve jobs, who I don't always agree with, but this is kind of cool. If you haven't found it yet, keep looking, don't settle as with all matters of the heart. You'll know it when you find

it. And like any great relationship, it just gets better and better as the years roll on. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.