Embedded - 21: The Tent Is Flat and Everyone Is Wet

Episode Date: October 2, 2013

 Rob Mitchell and Elecia discuss management, what they like about project schedules, and lessons learned on the path from engineer to manager.

This is Making Embedded Systems, the show for people who love gadgets. I'm Elysia White, here with Rob Mitchell to talk about lessons learned while transitioning from engineering to management. Hi Rob, thank you for joining me. Thanks for having me on. We're going to talk about becoming a manager. And I wanted to talk to you because, well, you just changed your LinkedIn title this week. Could you give us a brief history of your career? Yeah.

So I sort of have, I don't know if it's quite unconventional, but definitely the hard road sort of started as a technician with an automatic meter reading company, which is now defunct. And moved on to do some Bluetooth stuff. Worked at LeapFrog with you. Worked at Palm for a while. ShotSpotter, also with you. Yeah, we have had a few overlaps, haven't we? And you've gone from tech to super tech to junior EE to digital designer. That's right. Yeah. So, you know, sort of each job slowly climbed up more and more responsibility, more and more technical skill.

As you say, you know, going from tech to super tech to junior engineer had a couple of titles created specifically for me at several companies, which I think has been beneficial for other people, which is good. And then ultimately, you know, sort of culminating in becoming a systems engineer, system architect. And that was for Validus, a little company that I just got their chapter seven letter last week. Yes, I have myself also. Yeah, so Validus was sort of the culmination of bringing together both technical skills and project management and a little bit of people management that I'd been picking up over the years at various companies. And now you're at Lytro. Now I'm at Lytro.

Yep. So I think you had Phil King on and he probably explained it far better than I will. But yeah, so Lytro makes the world's first consumer light field camera, which allows you to take refocusable pictures, which means that once you take a picture, after the fact, you can refocus it on a PC, which is very neat. It is very neat. And it's a neat company to work for, neat technology. I must say I don't understand it very much at all.

As you say, I'm more of a digital background. And so sort of image capture and image manipulation are things that I haven't really focused on in my career. Well, and there's a deep physics thing going on with light rays and weird things that I'm still a little boggled by. We have a whole team that is at least as big as our embedded systems group that just deals with image capture, image quality, and the light field. A bunch of PhDs. A bunch of PhDs, fresh out of school, writing algorithms every day, basically. But you've just spent your first week writing performance reviews, right? I did, yes. That's one of those badges that makes you a real manager.

It is true. I can't deny it at this point. I think on some future podcasts, we'll have a few other managers to talk about engineering and management and transitions. But that's longer term advice. And sometimes the best teachers are the ones who've just gotten through some of the learning hurdles. So what have you learned? What have I learned? I learned that I can't write a review. It's harder than it looks, isn't it? It definitely is, especially I found for the more senior guys, it was definitely tough.

We have a junior guy that's four or five years out of school, and his was pretty easy, right? He has an idea of where he wants to go, and so you just have to lead him along that path, right? And so a lot of it came down to go. And so you just have to lead him along that path. Right. And, and so a lot of it came down to just telling him, telling, writing down, you know, what I could see him doing within our group to, you know, sort of foster his career and go along that path that he wants to do. But with the more senior guys, it really became in my own mind, who am I to tell this person what they are good or not good at, right?

Ah, yes. I managed a guy who I had convinced to leave retirement and come and work for me for a little while. And then I had to do a review for him. And I definitely felt that, you know, that you have no particular goals. You're only here for amusement value. What am I to write in your review? It really should go the other way. Yes. Yeah. Yeah. It was tough. Um, and so, yeah, I found myself being maybe a little too positive, um, with the senior guys. Uh, and so, you know, I had to sort of come back and, and evaluate, you know, do a first draft, um, let it sit for a couple days, and then come back and sort of re-look at what I had written and try to be honest and straightforward in the review rather than just sucking up or wearing kids gloves, right? That kind of thing. So I know for myself,

at least, well, you probably know this too. I'm a fairly straightforward person, fairly honest in when I talk to people and communicate with people. And so, you know, I sort of tried to let myself be that way with these reviews. Which is hard because people's feelings get hurt. I mean, truly hurt for years hurt. And, and everything you write down is critical. I mean, the word that you should have used was impolite instead of jerk tastic. Yeah. That's kind of important, but every, I can see the kid gloves. It's hard to, to be a good analysis and critical criticism, a good criticism that isn't insulting.

It's hard. Yeah. No, it was really tough. But I got through it. I have a pretty good sort of, I guess, mentor who was my boss and moved up into a higher position, which obviously opened up this opportunity for me here. Um, and so, you know, I can bounce ideas off of him and let him

know, you know, what I was thinking and have him take a look at it. And, uh, and then again, he's pretty straightforward and gives me honest feedback. So, um, so it'll be an interesting journey for sure. Uh, but I think it went okay. I think it'll go okay. I have, uh, you know, sort of time set aside next week to talk to everybody and go through it. And, uh, you know, I feel like that'll probably be a much better sort of forum for me. You know, I tend to talk a lot. That's why you're here. Yes. And choose my words pretty carefully. Right. Um, you know, whereas sometimes when I write it down, it comes across maybe a little bit more abrupt

than it would be if I was talking to somebody conversationally. Well, you like humor, and that's hard to convey in written form. So you haven't yet delivered the reviews? No, not yet. So, yeah um yeah basically as you say i sort of spent this whole week you know sort of sequestered in one of our little private rooms in the in the office trying to write these things out and rack my brain and uh and then you know i'll give it a couple more days you know give it the weekend make sure i don't want to change anything and then send it out to the guys uh early next next week to start going over with them.

Which will be the very interesting part, I think. That'll be a trial by fire for sure. Yes, yeah. So you mentioned you started more along the lines of the systems engineering and the, I don't even know what the right word is. People separate project management, product management, program management. But whatever it is, it's the opposite of people management. It's the scheduly bits.

And I know you did that. You've done that for a couple of companies. Managing the schedule, keeping things moving, asking if you're done yet from all of the other teams. What is that called for you? So, yeah, I mean, the problem is that it's all of those at once and none of those at once sometimes, right? You know, it depends on the company and it depends on who else is there and who's willing to step up. I like to look at it as a product management.

You know, for me, you know, my big goal is shipping product, right? No matter what piece of that product I'm working on. And so, yeah, as you mentioned, you know, I've sort of over the years slowly picked up more and more pieces of that, what I would consider product management, schedule being sort of the most obvious that people think about. It's the deliverable. Sure, right? It's the most visible. It's the deliverable, the milestones. That's how you track keeping on task.

And so it was slowly pick it up over years, right? I was responsible for my own little bit and feeding that up to my manager who then built a bigger schedule out of his team and then fed that up into a bigger one. And then slowly taking more and more pieces of that and moving up in sort of terms of not just being responsible for defining my own little schedule, but how does that feed into the larger project? And then, you know, from, let's say an EE perspective. And then how does that

feed into the larger project from, you know, again, a product perspective where you, as you say, bringing teams together, firmware, software, QA, uh, manufacturing. Um, it also has helped that I've, most of the companies I've worked for have been fairly small. And so I've had to do a lot of that stuff because there was nobody else to do it. Yeah, exactly. So it's sort of, you know, again, trial by fire, you know, or battlefield promotions, however you want to look at it, you know, you sort of, somebody has to do it. And, you know, I think I have a good sort of mind for doing those types of things.

Well, yes, you were a master of Excel before you really started being a technician. That was before you were on the technical path, right? Yeah, well, you know, sort of... I've seen you use a number pad. It was magical. Yeah. So, you know, I mean, a benefit, I guess, of age. You're not that old. Well, exactly, though, right? You know, I mean, I grew up with computers and using computers, right?

So I had a lot of the software background that is used in today's sort of product management before I even got here, right? And then again, it's wanting to learn new things, right? Teaching myself database. You don't really use that a lot, but just going out and learning the tools, you know, learning Gantt charts, for instance, which some people love, some people hate. But, you know, it's just going out

and learning the tools, figuring them out, and how they can integrate into sort of the overall picture and be useful, right? Well, I like the orderliness of it, the Tetris-like neatness of making everything line up at that end date and and i get i don't know maybe it was leapfrog that we shipped so many products and we did it i mean you had to ship in time for christmas or you might as well not never have started yeah and i just maybe i'm a little addicted to shipping things. Yeah, no, I definitely feel the same way, right?

And I think WeepFrog is the place that taught it to me, right? You know, when you're working on, as you say, nine, essentially nine products at one time, you know, there's not much room for error. No, and you mentioned you need QA, you need manufacturing, you need, I mean, and once you, you need software to release at a point where it can go into QA and then it can be tested well enough to go on to a masked ROM that you then build a million of, please don't screw that up. Uh, so yeah, it, that lining up definitely gave me a taste for for program managed product management yeah yeah and it was one of the few places i think that that actually built schedules like they should be built which is you have a hard and fast end date that is not moving as you say you know you

need to need to get that code out because it needs to go into manufacturing and it needs to get on shelves for christmas and then you work that back and those are the dates you have to hit, right? I think we've all worked at places where you sort of have a floating schedule, right? You know, where there's a nice to hit end date, but if you miss some of your in-between dates, well, you'll just push that out a little bit. And LeapFrog was by far not that way. Well, there are reasons to do that. Though I spent some time this week with a friend who used to be a software engineer and then moved into management several years ago. And he's a good manager.

He works way too hard, but he takes care of his people and deeply understands the technology of his product and really, truly cares. I'm just talking to him. I'm a little flabbergasted that he's managed to care this much for this long. But he's got very little respect for product management, for planning and schedules, because they're always wrong to him.

It's pointless. And as soon as they're done, quote, they're out of date. I, I'm afraid I did a really poor job of convincing him that this is a useful exercise because in part his company doesn't have an end date. It's got hard technology that needs to go out at some point. What would you have said? I mean, how should I have convinced him? Uh, it's a hard thing to do. I think, um, you know, it's, uh, I don't know how you, honestly, I don't know how you do it without working at a consumer device company or, or, or having worked maybe at a, at a higher system level. Um, but I think what you do is you, you come back and you say, yes, you're right. This is not realistic. How, how, how, how, how do you make it? So, right. You know, how do you, you say, yes, you're right. This is not realistic. How do you make it so, right?

How do you make those dates real and get feedback and talk to people, right? I mean you can't – what it ultimately comes down to is you can't sit up on this pedestal and make this schedule without any background in anything, right? It's an interactive process in my opinion. Um, and so I think that's where a lot of sort of pure product or program managers fail is that to them, they just sit there and make the schedule. Well, and for research oriented companies, which Lytro has been for some time, but it's also a consumer, so it's definitely straddling those two things. Research-oriented companies don't have end dates and they have problems I don't yet know how to solve, so please stop asking me when it will be done yet. Yes. But I think a good program manager can say, well, is this problem small, medium, or hard? And just, you know, plan in some time and hope that you're close, but recognize that the act of scheduling is an act of planning, which is an act of architecture.

And architecture is important to the system. So now I'm, see, I, man, I should have just said all this a few nights ago. Sometimes you just need the right refresher. But yeah, it's true. You know, and there's a certain amount of, you know, sort of keeping the two halves of your house separate, right? You know, as you say, not being dependent on that research project being 100% to ship a product, right? You know, you may call it at 80% or 90% or even 50% good enough to ship product. Good enough to make a difference to the consumer, even though it's not as great as it will be when you're ready to say, I'm done.

Yeah. Yeah. Yeah. Oh, it's, it's a hard line. Um, so engineers get different titles. Uh, if you, if you do the traditional route, which you didn't, uh, you get a junior engineering title when you're fresh out of college, and then engineer, and then senior engineer. And I think getting the senior title is a lot about being able to do this schedule management for a product.

Maybe only for your own small section of a product, but understanding how it all fits together. Do you agree with that, or do you think the senior title is something else? I definitely think you need, uh, you need that to be the most successful you can be as a senior engineer. Um, that being said, you know, there's lots of senior engineers that don't want to worry about that kind of thing and just want to be told, uh, what dates to hit and just focus on the technical stuff. And they're, you know,

it's no less of them for that. That's just their choice. But it's a rare, rare thing, I think, right, that somebody can do that. So yeah, for sure, you know, as you go up, you need to have, you know, you need to be mindful of the overall picture, right? You need to see the big picture, I think. You can no longer hang out with your five functions, making sure that they're perfect. And you have to start thinking how they feed into everything else. I guess that's really it.

The senior engineer doesn't get tasks assigned to them so much as they go out and find them. Yep, that's right. They know what needs to be done next, which to me means you need to understand enough about the system and the schedule to see what is highest priority for next or what will be the highest priority for after this stuff is done.

Absolutely, yeah. You know, there's definitely the knowing what to do aspect of things. And as you say, you know, almost perfectly, right? You know, that comes from understanding the whole system. um and i i found that that's you know sort of again for me personally that's that's what's put me to where i am now right you know i mean i have a uh my ability to see that bigger picture is probably better than my technical ability. Um, and so. Because you, you did the engineering, but then fairly quickly you became a systems engineer and that's led to more program

management and that's, it's the systems part, seeing all of it. Yeah. Yeah. You write good block diagrams too. I like that. And you've been doing schedule management for a couple of years, but only people management for a little while. How is that transition going? Um, it's going pretty well. Um, it was, uh, you know, as I said, it's sort of, uh, not sure where my opinion matters yet. right? Especially with the senior guys. You know, the schedule stuff, it's no different, right? You know, I was already doing that essentially. And so that just feels like a natural, you know, sort of progression from my opinion being important to my opinion, quote unquote, being law now, right? In some respects.

I think you're going to be eating those words next week. Probably. I'm sure. But yeah, definitely the people side of it, you know, um, you know, I'm trying to, to sort of foster a conversational sort of style, right? You know, talk to the guys, you know, basically transition from how I was as an engineer and add the sort of being in charge part of that without throwing it in their faces, essentially. And we'll see how it goes. So far, I notice I have a proclivity for micromanaging. It's hard. It is hard. And I think a little bit of it comes from sort of having a dual role of being an individual contributor and then moving into management at the same company with essentially overlap, right? And so I still feel like the system is my baby right yeah i was going to

ask is is is are the micromanagement parts more related to the pieces you gave up to do more management or is it the other parts of the system that you're new to that you need to investigate further and so you feel like you're you're spending a lot of time looking over people's shoulders a little bit of both, actually. So yeah, there was definitely an aspect of, you know, I didn't need to worry about that as much because somebody else had it. And I know that person and I know they're good and I know they have it. And now I do have to worry about it, right? You know, I do have to make sure that it's getting done and it's getting, you know, the

schedule is getting met. And that your engineers don't get lost in shiny objects. Yes. Yeah. Where before, if you got lost in shiny objects, that was okay. Somebody would come and remind you. Now you have to put the shiny objects on a shelf. It's so sad. Yeah. So, um, so it'll be all right, I think. I think I'm cognizant of what issues I will have and what sort of deficiencies I'll have as a manager and hopefully keep tabs on them going forward so that they don't become a problem. Because there's nothing worse than a manager that micromanages, right? Nobody likes that, right? We've they don't become a problem because there's nothing worse than, you know, a manager that micromanages, right? You know, everybody, nobody likes that, right? We've all been there. We've all had managers that do it and it just doesn't work out, right? You know, at some point your manager needs to trust that you're going to get the job done. But there is a time of acclimation when a manager is new that they have to they have to actually build this multiplier like if you say it takes you a day to do something then when I put it into my schedule

depending on how well I know you I could put in a day or two weeks and have some confidence that one of those is correct and you do need to spend a little bit of time getting to know people from that aspect of, of when I ask you to take, do a project, how long do you say it takes and how long does it actually take? And there are software words for that and they don't matter at all, but it's the multiplier. Yeah. Yeah, for sure. And, uh, you know, not to keep going back to Right. Um, and so, uh, definitely here, I think that type of thing will be much easier transition. You know, I already know the guys I've been working with them for nine months. Uh, I know their work style. I know what that multiplier is going to be for each individual person. And, you know,

hopefully I can take those lessons learned here where it's maybe a little easier. Because you do have trust and you do have confidence and you have your boss who's a mentor, but you've worked with Phil a number of times and you can be pretty sure that he'll take you out for sushi and smack you around if you need it. Yes. Yeah. I've already had that conversation with him a couple of times. It's, of towing that line between giving me a friendly heads up as a friend and sort of doing what I say. Yeah, exactly. And so I sort of, as I mentioned to my boss, before I could have friendly banter, again, I'm pretty honest, pretty straightforward. You know, before I could say, hey, why aren't you getting your job

done? Ha ha ha. Now it's why aren't you getting your job done? Hmm. It's a slightly different intonation, you know, between the, being engineer and manager. And so I think actually for my team, it's probably just as hard for them with this transition as it is for me, right? Oh, I think so. I mean, Phil was your boss at least one position, maybe two. And now you are his boss. And as an engineer, he's easy. He's up front with his expectations and he does good work.

But the inversion, man, that's got to be odd. It is a little odd. But I think, to his credit, he said a number of times that this is the path he sees me on. Me too. If I haven't said that, I totally agree. Uh, and, and, you know, I think a large part of it is, uh, you know, is, is thanks to him. You know, I have worked at with him at several companies. Um, and you have had the freedom when you were a technician even to jump in and do other things because your manager never said, no, no, get back to soldering.

Yes. Your manager would say, anything you want. Yes. Take over my job as much as you want. I'll go home a little earlier tonight. And that's a good thing. Exactly. Yes. So, so yeah, it's, it is definitely interesting. And, you know, as I, as I sort of said, you know, it's, it's it's that slight shift in relationship. I mean, before I could give him grief for missing something or sitting in the lab all day. Just joshing and joking and playing.

Yes, and now it's not. I think I can offer you some consolation there. It will be like this for about six months when you establish your roles entirely. But think back to my manager at LeapFrog. He was fun. He was totally hilarious to work for. And he could tease me like that.

But it was because we didn't do this role inversion. He was always the manager. So it will come back. You just need to set the boundaries for a little while. And then you can start crossing them. Certainly. I bet Phil has a few problems with you

doing management, even of him. And there are just some people who like the nitty gritty of engineering and some who actually like management. Which side are you on? Or is it too soon to tell? Probably too soon to tell. Certainly, I enjoy being an engineer.

I enjoy shipping products. But not just shipping product, right? I tend to tell people when I go into an interview or go to a new company that there's two things I look for. It's good people and neat product. Yes, I totally agree. And the company itself almost doesn't matter at that point. Right. And so, um, you know, as an engineer with those two things in mind, it makes for a very fun, exciting and rewarding, um, environment. And so, uh, But that needn't change with being a manager versus an engineer. It doesn't. Um, and you know, I still see myself sort of going for those smaller to medium-sized companies

where my input is going to be more than just make sure these people are on task, right? You know, a lot of the managers I've had have been more than willing to step in, roll up their sleeves, and do work. Because they all have this engineering background, right? There's all but maybe one that I've worked with have come up through the ranks. And, you know, you don't entirely lose it, you just, it fades to the background more, right? So yeah, I'll definitely miss it. But I think my sort of skill set and attitude is much more suited for product management.

And in small companies, that oftentimes equates to being a manager. And so I'm definitely looking forward to, you know, sort of making this my career going forward and sort of giving it the old college try, so to speak, right? Do you think you'll ever go back to engineering? Probably not as an individual contributor. If I go back to any level, it will still be at that sort of system architecture level.

Yeah, that makes a lot of sense. Do you have a plan for the next five years career-wise? Well, hopefully it involves an IPO and not having to work again, but I think we all hope for that. You know, I haven't thought about it too much. Well, you just are changing. I mean, if you said, I plan on being a director-level manager in three years,

I would be a little shocked. Having just switched, saying, I'm going to get good at being a manager. I can totally see that. Yeah. And so I've thought about it. And, and, you know, I've thought about more in terms of where would I like to see myself being a manager versus, you know, sort of, what do I want to do? And that's a little easier, I think, in my mind to sort of assess and look at. And so, you know, I like smaller companies, I like those companies where I have a say, I have a ability to influence both the company, and more importantly, the product in a meaningful way. And so, uh,

you know, I think that that, those types of opportunities will be where I will look and, and hopefully grow, uh, going forward. But, you know, there's, there's probably no possible way I could ever be a manager, director, VP at someplace like HP, you know, it's just, um, it's not for me. I mean, HP, HP, I did a little bit of management there, um, very early in my career and they had a horrific barbaric process that many other companies have in which they did rankings. And you had to actually say, I mean, it's easy to say this person's good. This person needs work. That person is just excellent and you shouldn't bother them. Just get out of their way. But then there were, you actually had to say this person is better than that person. This person

contributes more to the bottom line than that person. And that's hard, especially for the people who are the communicators, the facilitators who don't necessarily produce a whole bunch of stuff, but they help everybody else produce a bunch of stuff. And at HP, I had trouble, trouble achieving the rank that those people deserved because their efforts were hidden from other managers. You don't have to do ranking yet, do you? No, thankfully, uh, uh, Lytro does not, uh, use a ranking system at the moment. So, uh, one of the sort of benefits of being a small company, I think, um, I, it's a tough problem to have, right? Um, you know, I think I, I'm glad that I don't have to do it here. I think it would have been an almost impossible task for me, especially, you know, not just being new and being fresh as a manager, but making that transition from, quote unquote, being one of the guys to being a manager.

Right. And, you know, again again it was hard enough writing the review use much less if i had to rank people so uh so thankfully i didn't have to do that um it is hard yeah and as you say i mean uh you know there's plenty of great engineers uh that engineers that don't produce visible work, but that are integral to a corporation or a company or a team even. And it would be very hard to sort of rank that person, you know, in terms of just pure output of work. Yeah. Yeah, it is.

And that was an unpleasant. So we've, we've talked that your path to management hasn't been standard. You didn't do the university thing, get the BS, get a job, maybe an MS and, and that it's been different. How was it? How was it difficult? How was it better? Um, yeah, well, so, I mean, it took more time for sure than, than most other people would have taken, I think. I don't think so. We're about the same age. And, and while I was a little early in my management, many of my other co cohort in my age group definitely haven't done much more management than you have. So I don't know that it's, it may have seemed like a long time.

Maybe so. Maybe that's it. And, you know, I always had a habit of sort of proving myself. And I think that's one reason why I did sort of, I guess, move up quickly, if you want to put it that way, right? And was able to move through the ranks is because I went into every job with the attitude that I can do the work as well or better than somebody with a BS or an MS. And I think it showed and it, you know, it allowed me to take on more and more responsibility. You know, again, as much as I wanted in some respects, as you said, you know, if, you know, if I did something that was my manager's responsibility, he got the kick out of work early, right? So... And our managers never really mind. Exactly, right? So, and engineers were like that too. You know, any engineer you talk to is almost certainly willing to give you work if you want work.

Most of the engineers, especially the ones we've worked with in common, have not only been willing to give up their work, they've been willing to give up their time to do teaching. Yes. And that's, I mean, that's, we've both been really lucky in that case. Yeah. So I'd say a lot of it is also sort of just luck on my part, right? You know, I've, I've been lucky, um, to work at very good companies, uh, with very good, um, engineers, uh, colleagues, um, managers, uh, that have been willing to do that mentoring, that have been willing to give me that chance and, you know, have sort of helped foster my career as much as I have. And so I think that was, you know, sort of the hard part was, you know, sort of getting to that point myself, right?

Getting to that point where, you know, deciding of getting to that point myself, right? Getting to that point where, you know, deciding that I needed to take those opportunities and, you know, that it wasn't just going to come to me, for instance. You know, I, if I wanted to be an engineer, I had to go out and I had to do it and I had to seek that help and I had to take that help when it was handed to me and move up, right? So, yeah. Well, not everybody gets those opportunities. That is true. Oftentimes, taking a few of them gets you more and being enthusiastic about them and not necessarily grateful, but utilizing them because it does take more time to offer those opportunities.

And so if an engineer or technician or, gosh, any of the people who have ever worked for me showed an interest in doing more, I've always been willing to give them more because you light the fire of being excited about products and gadgets and engineering. And yes, if you want more of my time to get you to do more stuff, I'm okay with that. Do you think you'll be able to do that for future people? I hope so. Um, you know, I sort of got an opportunity now with a sort of junior guy. Um, and so I, you know, I, I sort of continuously think back to, you know, how did the engineers, you know, sort of how did the engineers foster me coming up and keep that in my mind to do it here. So pass along the mentorship. forward. Because I've made, you know, many good friends, good colleagues. And it shows in the fact

that, you know, many of us have worked together at multiple companies at this point, right? The valley is so small sometimes. It is. You know, but I think it comes from that sort of, you know, relationship that, you know, one is going to take opportunities that another gives and another is going to give those opportunities to anyone that's seeking it. And it fosters a really good bond and a very good sort of working relationship

with two engineers. There's a reciprocity to the process. And the engineers that I've worked with, who I wouldn't necessarily work with again, were the ones who didn't take the opportunities. So I think you are lucky. You've been given some great opportunities, but it goes the other way too.

You took them and that was lucky for the people who got to give them to you. Yeah. Uh, so what would you tell Rob of five or 10 years ago to make this whole process easier? I mean, you have been lucky. It's, it's maybe you just say,

do what you did or would you say something else? Uh, yeah. So, so some of it is, is sort of keep your head down, right. And, and do what you're or would you say something else? Yeah, so some of it is sort of keep your head down, right? And do what you're doing. You know, I think that's good advice for any engineer. You know, work hard at something.

Be straightforward. Yeah, be as good as your ability, right? Don't slouch. Don't, you know, it doesn't mean you're not going to be the rock star, right? There's always going to be a better rock star than you are. But be as good as you can be. Be diligent. You know, be honest. And so, yeah, I definitely, you know, sort of tell myself that and tell myself that there is a reward because oftentimes it didn't feel very rewarding right you know oftentimes it felt like um drudgery right you know because you do sort of saddle yourself with other work you do get into those um areas where you're over your head and your manager's already gone home because he figured you were going to take care exactly and so you have nobody to ask you have nobody to talk to and and you know many times i've i've felt

that uh you know i was i was the one that was causing a program slowdown or a product slowdown or something along those lines and and so you know you go back and tell yourself that yes you're going to feel that way but no it's not all on your shoulders, right? Everybody feels that way sometimes. Absolutely. And it's true sometimes. It is true sometimes. And that's not the worst thing in the world. There always has to be a longest tent pole.

Otherwise, the tent is flat and everybody's wet. Yes. And you need to make mistakes, right? I mean, you don't really learn by always being right because then you don't know what the opposite is. But 10 years ago, you know, I wish I would have got my BS degree. I think that would have opened more doors and afforded me a few more opportunities

that I didn't have to sort of scramble for. Yeah. And, you know, but by five years, you know, five years ago, me, I just said that degree doesn't matter. Still get it if you can, but, uh, networking, um, and fostering these sort of relationships are far more important, uh, than any education you could ever have. Right. You know, I mean, this is again, presuming you have the technical ability, right? Um, you know, I've, most of my opportunities have come from knowing somebody and them knowing that I do good work and that we work together well as a team. And at that point,

my, whether I have a degree or not, it doesn't matter. Very cool. And I think we'll wrap it up with that because it's a good place. You've been listening to me talk with Rob Mitchell about being an engineer and turning into a manager. Rob, do you have any last words?

I just wanted to say thanks for having me on. It's always a pleasure and I'm glad to be a little part of your empire again. Your media empire that you're creating here. Actually, that is another question I wanted to ask you. Have you ever introduced yourself to a stranger as a manager?

I haven't yet. Be prepared for the mental dissonance. It was quite a shock because I'm so used to, I mean, even now I introduce myself as an engineer. I signed up to go to a conference as press. I'm going to have to say I am a writer or an author. Yes, yes, I wrote a book, but still that's not how I introduce myself. I am an author. Yes, yes, I wrote a book. But still, that's not how I introduce myself. I am an engineer. And when I go to this conference as press and introduce myself as a writer for EE Times

or a podcaster for Making Embedded Systems, I'm just going to be like, and I have no clothes on. Because that's what it's going to feel like. Because I'm not going to be able to say, yeah, I am an embedded systems engineer. And it's going to be weird. So good'm not going to be able to say, yeah, I am an embedded systems engineer and it's going to be weird. So good luck with that. Start mentally preparing now. Yeah, I'm sure it will be a weird feeling, right?

You know, sort of, as you say, losing your roots, maybe, right? Yeah. Well, Rob, thank you for being on the show. I really appreciate it. Yeah, thanks for having me. I'd also like to thank Christopher White for producing this, making us sound good and keeping us on track. And thank you for listening. Please send comments, suggestions, or questions to us via email, show at embedded.fm, or hit the contact link on embedded.fm. Now, something to ponder, which really gets to the root of management

versus engineering. Do you know that there are people out there who watch the Roadrunner cartoons and think Wile E. Coyote is the villain and the Roadrunner is the hero? It's crazy, but true.