Embedded - 529: The Narwhal Looked Amazing

Episode Date: July 9, 2026

Chris Svec returns to the show to discuss the messy, non-linear realities of engineering management and onboarding new college graduates. We explore why companies should bother hiring fresh grads in the first place, how to prevent junior developers from going dark when they get stuck, and why admitting ignorance publicly is an absolute workplace superpower. Along the way, we dive into managing genius firmware engineering hires, battling technical debt and software entropy, and why your development team shouldn't communicate solely through pull request comments. Chris Svec is the Director of Embedded Software Engineering at Insulet. If you're looking for an experienced leadership or management thought partner to help scale your development team, Chris Svec offers private coaching and consulting. You can reach him directly at the email given in the show (or hit the contact link and we'll forward your message along). RECOMMENDED BOOKS FOR ENGINEERING MANAGERS & TECH LEADS The Manager's Path by Camille Fournier – A guide for navigating tech leadership and managing engineering teams. Resilient Management by Lara Hogan – A book dedicated to the human side of engineering management. SOFTWARE ARCHITECTURE & EMBEDDED SYSTEMS RESOURCES A Philosophy of Software Design by John Ousterhout – A high-level philosophical perspective on software engineering and architecture. The Pragmatic Programmer by Andrew Hunt and David Thomas – A classic text on software development best practices. Joel on Software by Joel Spolsky – Insights on software development methodologies and managing tech teams. Making Embedded Systems by Elecia White – A comprehensive guide to firmware design patterns and embedded architecture. Embedded for Everyone by Nathan Jones – A curated repository of accessible embedded system learning resources. EDUCATIONAL PROGRAMMING GAMES Shenzhen I.O. by Zachtronics – An interactive puzzle game for learning assembly programming. Typer Shark! Deluxe – A classic game to improve typing speed and precision for developers. MENTIONS AND EPISODE CONTEXT Embedded.fm blog post: Resilience is a Skill and Embedded Skills Tree  The "Meow Meow Beans" episode from the TV show Community (season 5, episode 8), see a snippet. All Systems Red by Martha Wells – The sci-fi novel featured in today's closing quote If you want to dive into Svec's previous appearances on the podcast, be sure to check out: 78: Happy Cows (His very first appearance, discussing empathy in software development) 250: Yolo Snarf (All about version control, gitflow, and D&D) 297: Mice to Do My Bidding (Focusing on attentional focus and workflow psychological tricks) 402: We Are a Lazy Species (Software schedule estimation alongside Philip Johnston) 436: 20 GOTO 10 (Discussing modern kids' programming languages and the longevity of the Joel Test) Transcript 

Welcome to Embedded. I am Elysio White alongside Christopher White. I'm happy to say that Chris Feck has returned to talk with us about training up new engineering hires. And if you think we're going to stay on that topic, welcome newcomer. You've clearly never listened to the show. How are we going to talk about another movie? I guess not. We can talk about Wimbledon.

We can talk about World Cup. Actually, I haven't been watching as much World Cup as Wimbledon, but any of these topics. All right. You have joined us. Welcome. Welcome. Welcome. Glad. Good to talk to you both again. We know you because we've actually met you in person. Amazing. Could you tell us about yourself as if we had never met you and we were just meeting you, I don't know, on the train to Palo Alto? Why would I be going there? He would. Okay. At first I'd probably say, can I have my wallet back, please? But then I would say, You said I could inspect it.

I'm Chris Speck, director of embedded software engineering at Insulate. Insulate, we make a tubeless insulin pump for people with type 1 and type 2 diabetes to help people who have diabetes to live better and to simplify their lives. I've spent somehow 25 years now in hardware and software, and I basically love all things embedded systems. You know, I've been friends with you two forever. And over the last 10 years, I've really focused more on how to build and grow embedded systems teams,

kind of more about the psychology and the sociology about how we work together and a little less on the technology. But yeah, that's my elevator pitch for the subway, not subway. I've actually never ridden the transport in the big. Cal train, Cal train. Cal train? Train. It's a train. It's an actual train.

That one's a train. There's Bart, which is the metro kind of thing, the Cal train, which is a train train. Weirdly, we're off topic already. Already. Very on brand and off topic. That's a holiday. And you used to work for IRobot?

I did. I spent 11 long and good years at Irobot. And then I've done chip design before, then various embedded systems within chip companies, and then outside of chip companies, have done more embedded systems lately. And, you know, I spent the last couple years at a medical device company. I've never done med device.

So I've spent the last couple of years learning how to spell FDA and what that brings with it, the responsibility and the process and everything with it as well. And I don't think we really need to do this, but just for crossing T's and dotting eyes, you're not talking for Insulate as part of this podcast. This is all just you. That is a great. That is a great reminder. Yep, I'm not speaking for anyone other than myself, just my personal self.

I don't speak for any company past, present, or future. Thank you for that legal reminder. Well, all right. Forecloses a lot there. Okay, so let's get to Lightning Round. All right, and I'm going to flip this. I've got some Lightning Round questions for you, and this is the relationship test edition of Lightning Round.

So I'm going to ask you questions for each other. So, Alicia, you have to tell me what do you think Chris would answer and vice versa? So Alicia, you're going first. You should keep in mind. I edit this podcast. That's true. I look forward to hearing how this ends up. So Alicia, if Chris had to play a rock gig with one piece of drum equipment, what one piece of drum equipment?

Like he gets a one bass drum, he gets a snare drum, he gets a high hat, one symbol. He only gets one. What would he play with? A snare. All right. And if he gets two, what would he play with two pieces? What would his second piece be? A snare and a drumstick.

Oh, drumstick. drumstick. I think a drumstick. I think a drumstick was included. No, I like it. I like it. I like where she's going with that. Bonus points.

Bonus points for that one. Chris, if you could insert like a lightning sound here to show that she gets the bonus points, that would be great. All right. Chris, you have to answer for Alicia, mountain or valley fold. I mean,

they're equivalent if you turn the paper upside. Mountain fold. Obviously. I'll see, obviously. Alicia, for Chris. A. AI via the terminal or via a web interface?

No AI. No AI. All right. Chris for Alicia, PID or Common Filter? PID. Chris is really getting into this. I can tell. Alicia for Chris, Gettie Lee or Neil Pert.

Neil Pert. Neil Pert. Pirt. Pirt. Chris, what is the right pronunciation of his last name? Peart. Pirt. Okay.

Pirt. Chris, what is Alicia's favorite sea creature? Octopus. Octopus. All right. And this is the last. Well, it changes depending on what she's read about recently. Could be a nudibunk.

Could be a narwhal. Could be a narwhal. Gosh, there's so many options. I saw some passport. Some friend got a new passport recently, and there was a narwhal on. I think it might have been Canada's passport. Canadian passport. How do we get Canadian citizenship?

I just want the passport. Just the narwhal looked amazing. All right. Last question for each of you. Elysia, if Chris had to use only Rust or only code with AI for a year, which would he choose? Oh, it doesn't matter. If those were his only two options, he would just go into the forest and not use any code. Okay, okay. Easy enough.

Chris, if Elysia had to have an LED blinking in her office for a year, but she'd be paid, let's say, $10 million at the end of it. Would she do it? No. No, absolutely no. All right. All right. That's, thus concludes lightning round.

Thank you for playing. That's very good. Okay. I have called you here together to talk about new college grads. And to some extent, this show is ideally going to help some new college grads as they acclimate to industry from school. But I will,

want to take it from the other side is, is you're a manager, I've been managing folks. What is your strategy when you hire a new college grad? They get there, there's the first two weeks, which is special. You know, they get their computer. They learn about 401Ks. They get the fire hose of information that's culture and the tasks they're supposed to work on. And there's just this incredible period of learning. I don't care about that so much because that's just you have to do all that. It's the how do you develop someone from being a new college grad, bright potential, smart person, lots of knowledge into being an engineer who can work on their own. Great question. The default question I've started asking myself and asking my team and having people ask, regardless of what we're doing at work lately, is what problem are we trying to solve? Because engineers, we love coming up with solutions without understanding the problem first. I mean, humans do this all the time. But I think engineers are really good at saying, oh, look, I made something and now where can I find somewhere to use it instead of stepping back and saying, what problem are we trying to solve? And so I, I

would say the problem here is, you know, you're saying, hey, we got a new hire, new college grad, you know, a relatively, you know, junior person, maybe they've interned, maybe not. And that's, that's the situation we find ourselves in. The way I'd ask the question, what problem are we trying to solve? You've, you've answered some of it. You've said, you know, we ignoring the first two weeks, but how do we get them to be able to be understanding enough to do pull requests and so on? I would go one step further and say, you know, do. we have a goal of saying in six months we want them to be able to be on the team, on a scrum team, or on a project team, and reasonably independent? Or is it in three months we want them to do that?

Or in six months, we want them to have researched this new area for our project we're giving them. And so I would step back and say, for this particular human in, you know, this new hire, what do we want them to be able to do in six months? And, you know, we don't have to answer that here, obviously that's specific to whoever you're onboarding. But that, I think you need to keep that in your mind as the hiring manager and as the team absorbing this new person so that you make sure that they're heading in the specific direction you want them to have as opposed to, well, just throw them at the code base and let's see what comes out the other end.

Does that make sense? Yeah, but it wasn't what I was going for at all. All right. Yes, we definitely need that. What is this person need to do in this instance? six months. But I wanted to talk more about the teaching them to be a senior engineer, to not have to be told what they're going to work on next, but to be able to see the system as a system and say, oh, that's what the next important thing is. And I don't think it's a six

month journey, at least a year, probably five. And I don't know how, I don't want it to be particularly company related. I'm going back to when I started, of course, and I went to HP long before HP and Compact did their thing. H.P. Way had just come out, come out. It was the old HP. I joined as a cohort. They hired hundreds of new grads, and in my building, there were like 40 of us. Chris, you were kind of part of a cohort as well. No? No, I don't think so. Cisco wasn't that big at that time. I don't remember too many other. I mean, there were a couple, but it wasn't like HP where they've, yeah, they've got, you probably had meetings with, All the new people, right, or something like, they didn't do that.

Only once or twice. Yeah, no, I was just a new person on a team. But I did feel like HP had this idea that you should help the new college grads, the new people to the team to become senior engineers, to not just have that be a side effect of seeing too many problems and developing cynicism. Got it, got it. So to, yeah, okay, so then the problem, the problem you're trying to solve, I'll bring it back to me here, bring it back to my question. The problem you're trying to solve here is not the specifics of, you know, what this person is going to do even in the one two-year timeframe, but instead, how do I start with a, you know, new hire, fresh out of college person? And in five years, how do I have somebody who is senior who can go on independently and figure out what problems to solve, you know, who can sort of, you know, who can sort of, you know,

make schedules and figure out what are the risky elements, what should be due first, kind of learn the judgment and taste that goes along with the senior engineer. Is that a little, is that a little what you're thinking? Yes. And if I can do that for three people, then I can promote the person who's currently in the senior position and they can do my job and I can retire to an island. Fantastic. Yeah, putting yourself out of work is always a good goal.

I love that. So I have a few general thoughts. I know that, you know, we talked about this a little bit before the show. but I can, I'll just launch into them and, you know, obviously interrupt, we can, we can, we can dissect them as, as we go here. But there's a couple, couple things that I think you need to do to, like, really get a new hire sort of, I'm going to use the word empowered. And I kind of don't like that word, but the default for a new hire is to come into your company, scared and quiet and with imposter syndrome. and there's a phrase going dark. And when a new hire comes in, and if they're too scared to ask questions, if they are too scared to appear ignorant,

and if they don't feel like they can ask what they perceive as dumb questions or be perceived as someone who doesn't know something they should know, you're going to shut them down. And you're setting that up for failure it that way. So the single best skill and behavior, I think, to have as a new hire or anyone who's new into a team is the willingness to ask questions is to admit ignorance. I actually think it's like it's a superpower to be able to admit ignorance publicly. And so as you on board a new hire, I am explicit with people who I hire and who I work with who are junior and say, hey, you are not going to know a lot of stuff here. You are going to be confused. You're going to be frustrated because it seems like why.

You know, why is this so hard to learn? The working world is not designed like a class with a well-worn syllabus that, you know, okay, we teach you thing A, we teach you thing B, and that leads to thing C. Like, the working world is just not like that. Now, as a hiring manager, it would be great to set up the scaffolding for the new hire. And that's, I think, Alicia, that's kind of what you're trying to do here. But it's hard, it's tough. It's not going to be linear. It's going to be a very non-linear journey and setting up the expectations.

for the new hire of the day, you're going to be confused. That's fine. Please ask questions. Like the biggest danger for a new hire is if they go dark for a week or two or three. You don't hear for them. They don't hear from you. And they're just toiling away in confusion and sadness. And they don't get anything done and everyone loses.

So I'll stop there. Any comments on that? Am I going on the right track for what you're thinking here, Alicia? I mean, I really want it to be from the tech leader or new manager perspective, which is to flip around what you said, you really need to praise new hires for asking questions, even though it may be interrupting what you're doing, even though it may be irritating because why didn't they just read it? I spent so long writing a wiki that now is 1,000 pages.

Asking questions is good, especially in the beginning. Yes. If they lose that, they're going to end up dark. Yes. 100%. 100%. And yeah, actually, what you said is right. What I would like is a year-long course on moving from being a junior engineer

to being solid in your engineering practice. And maybe it's an hour meeting and two hours a week of homework. I don't. And it would, of course, have to be per company. per project. But there is a lot of commonality and embedded on what you should expect. And asking questions, praising people for asking questions is definitely one of the things that we need to do and we need to model.

I really try to do that where I'm like, yeah, okay, there's this part of this project I'm working on that I don't understand well. And so I'm totally willing to ask completely stupid questions. because I find it is probably a good thing for people to realize that I don't know everything and that I am happy asking questions. And I am also happy not knowing everything. Yes. And you're happy doing it publicly so that everyone around you can see that, hey, Alicia doesn't know everything,

even though she's a guru, she's got a podcast, she's got a, you know, successful company, and she's written the book on Embedded Systems. If someone like you can say, hey, how does that work? I don't get it. Can you explain that again? That is huge. That is such a great example. So again, totally, totally great with that. So in the list of things managers should think about is model the behavior. I mean, that should always be what you do. But modeling the questioning behavior is a really good one. Yes, and not just for the manager themselves, but, you know, the cranky old, you know, the cranky old timer on the team who is, it might be predisposed to saying RTFM kid, you know,

I wrote it there for you, maybe have a talk with the whole team and say, hey, look, this person hasn't worked for 20 years. This person hasn't been in our code base for five years or even five minutes. And they're going to be confused because, you know, code is not self-documented as much as we'd like it to be. And so have patience, try to remember what it was like when you were, you know, 22 and new to everything so that everyone can model that. And then publicly praise people on your team, or public or private.

to you, especially the senior people, say, hey, I'm really, you know, thank you for asking that question in that public forum. Again, admitting ignorance publicly is superpower. I've, I've saved up like a bunch of questions. Can I, do you want me to derail? Yeah. Do you have a direction after this? I'm sure you do, but I don't want to, I don't want to screw it all up. I, it's, it's all good. I want to go back to a fundamental question, which you all have not answered. Why hire new grads? If this takes all this extra work and there's people out there who are seasoned, and I'm being devil's advocate, people out there who already know how to do all this stuff, why not just find somebody who's five years out of college or 10 years out of college and hire them?

Why hire a new grad which takes extra work and they're just going to leave after three years to go to a new startup? Because of keep. Are they? Sometimes. I mean, does the amount of effort to train them cost money? I'm not saying you shouldn't. I just want to know from the company's perspective, from a company's perspective, what is the benefit of hiring a new grad? Cost is one thing. A, you know, zero years experience costs less than five years experience,

costs less than 10 years experience, and so on. That's not always true depending on how quickly salaries are changing in a market, but that's generally true. additionally, especially... But are you getting what you pay for? Because the productivity might be a third of a five-year... But you're training them the way you want them to be trained.

That's fine. So, yes. They may not bring in bad habits that have been learned elsewhere. You know, newer people to the industry also bring in newer skills and newer ways of thinking and some new ideas that they learned in college or from their friends or whatever because they're not set in their ways after doing something for 25 years.

They have never heard of IAR or Kyle. And when they see IA.R. Kyle, they say, hey, have you heard of this thing called GCC or VS code or cursor? Literally anything. So that's a very real, real. New tools. VI. VIM? Have you heard of VIM? Have you heard of VIM?

Edline. I love it. I love it. Okay. There's more on that. Oh, there's definitely more. They're not cynical. And they don't.

Wait a minute. They don't. You went to school with me. I went to school with you, yes. You've always been cynical. They don't bring in the no is always the first answer. They often bring in an excitement and a joy that if we can nurture that, the whole industry becomes more fun. There's a couple of good company side answers too, especially for a larger company.

something that a global HR team will look for and or an HR kind of the organizational structure side of things is you you don't want to you want a team that is built up of people of a variety of everything so diversity is good just in general diversity of background diversity of gender diversity of all the things is good because you get different different inputs, different experiences, different eyes on things. And one of those is skill level. You know, the inexperienced person is going to have very different observations on something

than the person who's been doing this for 30 years. There's more of a beginner's mind. And so there's some of that. In addition, some HR departments will simply say, you've got to have, you've got to have like a bell curve of kind of staffing levels. You know, if you have only, if you have 20 people on your team and they're all senior, then that is not super healthy. You need some really senior people and you need some junior people and you need some people in the middle.

And so some companies will actually say when you hire, you have to keep in mind what your kind of seniority distribution looks like. And again, you know, they do that for a variety of reasons. But some of the good part of that is just getting the diversity of thought and experience. Another thing is, and this is a little bit even tricky to talk about, but, you know, someone who is junior, someone who is learning. is going to be able to do some of the work that maybe, I'm going to call it grunt work. I'm not meaning to demean the work, all, you know, assuming that you are only making sort of real work that actually is useful work that needs to be done. Then, you know what, there's some work that needs to be done for every project that hasn't

been automated yet. Having someone who's new, who hasn't done it before, is a better use of the company's money than having someone who, whose time and energy and budget should be focused on higher leverage, higher value things. And so having someone who's junior to do, I'll say some of the grunt work, is maybe better than more valuable to the company than someone who's been doing this for 30 years. Going back to the diversity, I think you can find more diversity in college students than you can in engineering.

And if you have a good plan for helping them grow, maybe we can add diversity to the whole industry. That is fantastic. to you look around anyone who's had, you know, the average 20-year experience embedded systems person looks a lot like me, right? It's a middle-aged white dude who grew up in tech. And if you just want to have that for your company, then I guess that's what you can do. But yeah, if you want to get more diverse anything, you got to look outside of that. Do you train everyone on dealing with new grads? You talk about these things like talking to the senior people who might

be a little disgruntled or not wanting to deal with newbies. And is that kind of an individual thing where you pull Gary from QA aside and say, look, you got to talk to Sarah and be nice to her. She's a new grad. And then stop acting like your normal self or what? Or is there like a plan? Okay, here's the team that sets the team down. We have new grads. Here's how we want to bring them up. it's all formal. I mean, I think you do it with the whole team. I think, I think this, if you're buying into anything that we're saying here, and if you think that, okay, yeah, let's encourage the new hire to ask these questions and

let's reward, let's reward curiosity instead of punishing it. Then I think, honestly, even if you didn't have a new hire, you should do this with your team. Because I guarantee there's people in your team who are scared to ask questions because they don't want to look dumb, even if you never hire anybody again. And so I think there's value to sort of saying, hey, everybody, let's put our ego aside a little bit, and let's all be a little bit more, a little quicker to admit our ignorance internally. Oh, and by the way, we've got a new hire coming who is going to have imposter syndrome out the wazoo and really needs us to encourage curiosity.

I could see having a new hire being excused for having that meeting and talking about it. But in general, no, a new hire does not mean that I would have a meeting that says be nice to the new hire. I would go to Gary, grumpy old Gary, and say, would you like to mentor so-and-so? And when they say, no, I am much too grumpy, I am a carmudgeon, then you say, well, could you at least be nice to her? You know? That sounds like E.Or, I'd just like to point out. There's only so many voices. No, it was a good voice.

It took me right to the right personality. I've got a very good visual picture of that or a mental picture of that. One of the things when I was new was nobody sat me down and said, hey, it's okay to make mistakes. That's what code reviews for. That's what the source control system's for. Don't hover over the enter key on your PR for an hour sweating before pushing the button just because you're so nervous about merging something. Nobody told me that. So I spent a lot of time like, yeah, in that mode, like, oh boy.

And my code was god-awful in my first two years. I thought you were going to say your code was perfect as a result. No, no, no. Orthoginals are the issue of me being nervous to commit it. It was still bad, but I didn't, and I think that was good because Cisco gave me permission to put bad code in, I guess. But, yeah, I mean, do you sit down and say to the new grad, look, you're going to have imposter syndrome. This is a new experience. It's okay to make mistakes.

Everyone here has made mistakes. Everyone here makes mistakes on a monthly weekly basis. You will make mistakes. And nobody's going to yell at you unless you push to production on Friday night. And even then, we should have systems that keep us from doing that instead of allowing it to do that. Yes, I, yes. So, you know, getting into kind of more tactical stuff, I think we've been sort of like bigger picture. So what I like to do is to assign a buddy to every new hire.

And that buddy is somebody who cannot be the manager, should not be like, the line of reporting. Ideally, it's like one or two or three levels kind of above the new hire, seniority-wise. And that buddy should be there. The manager should also say this, but the buddy should then say, hey, look, you're going to make mistakes. Here's two bugs that I pushed to production in the last six months. Like, here's how we found them. Here's how we fixed them. And like, no one's getting fired over. No one's getting yelled at. You know, we might do a retro. how can we avoid that kind of bug in the future? But not a big deal.

If you're a general principle that I think I try to do, and actually I need to follow up with somebody at work, I just remembered about this, is that do like a, you know, people who companies do lunch and learns for, hey, I learned this new topic. Here's how a PID works. Here's how Claude does this neat thing.

Here's this new embedded systems chip that I found that has a cool peripheral, blah, blah. But something else you should do lunch and learns about is bug. Hey, here's this bug. We found it only in the wild in the world. And here is how we tracked it down. Here's the debugging techniques we use. Here's how we fixed it.

And here's some ways we'll try to make it never happen again. So that people can see that the person who wrote the bug and then hopefully they're also the person who found the bug can, you know, they have lived to code another day. You know, they're not punished. You know, there's to what the joke is, right? There's two phases to programming, right? There's debugging and there's bugging. and those are the only two phases. And so, you know, if you're not debugging, then you're bugging.

And that's kind of a joke. It's very tongue-in-cheek, but setting that expectation is good. The other thing about having a buddy there is I would have the buddy sit with the new hire, and the buddy's working on the task of their own. And so the buddy should be thinking out loud as they're working through the task. And then saying, you know, saying, okay, I have a new task. This Jira ticket is to go and implement. some new little feature.

You know, here's how can I think of it. Here's how the system works. Do you have any questions? They're going back and having a conversation with the new hire, showing them how they're actively thinking through the feature or the bug or whatever it is they're working on. And then, like, have the new hire sit there and maybe they code together. Maybe they do a little bit of pair programming. What do you think of this?

What do you think of that? And then actually show them as they put the PR up. and then, you know, their PR won't be perfect. So hopefully other people on the team then do pull request comments and then show the new hire that, oh, look, you know, Gary over there, he actually found this giant hole in what I implemented. Good for Gary. Glad he caught that.

And then let's fix it together. So that the new hire can see an example of someone getting, you know, active comments on their PR and see, okay, it's okay. It's okay to not be perfect. That's part of what the PR is for, you know, pull requests are for catching. errors and they're also for having everyone learn about the system. So does that answer some of what you were talking about there? I think so.

Yeah. Yeah, no. It's a question of formality. Like how much is there a, this is our company process for the new grad on the new grad side and on the team side. And it sounds like it's a mix of things, which is appropriate and probably depends on the company and the size of your company if your team is three people. No, you probably don't need a new grad hiring process that everyone follows.

If you're HP with a cohort, then I suspect HP had a binder with 8,000 pages and contingency plans for, you know, every sort of failure. Yeah, okay. Well, I have one more thing, but I think I will hold it for later because it's a kind of a shift. So thinking about this, I am thinking, we have. had some new people added to my team and they're pretty junior and I'm having a good time trying to make sure that they understand that what they're going through is totally normal. The ignorance is not their fault. It's just their turn and we all go through this and we all start to understand more.

and what I really haven't been able to articulate to them is that there is often a loneliness in this. And Specta said, parapsychic said, parapshramming, I don't, we can't do that right now. We actually need them to be working on their own things, and so the more senior engineers are trying to mentor them through PRs, and we're all kind of frantically doing things for a little while, and it will get better.

But the idea that we need to tell them, it's okay to make mistakes, is so important. And I don't think I've done that enough. I have tried to say you did a good job on this, but I don't think I have let them know that a few times I've said, it's okay if it goes wrong. Just let me know and we'll entangle it together. But I definitely am trying to let them make the mistakes and not. stress about it just to show them that yeah it's fine we can figure it out go ahead do the merch if it if it goes bad let me know right away and and i'll come clean it up nice that's a great that's a great attitude about

that yeah so if you so your your position is like look we're going a million miles an hour we've got a you know an investor demo we have something so we can't quite do a full you know pair programming or have them sit down so what what i like to do there and honestly you know, eight hours a day of pair programming is not typical. And that's not what I would, that's not even what I was saying. But if you really don't have that much bandwidth to do, then at a minimum, a bare minimum, what I say is that, all right, you know, you have a clear thing. Here is a ticket for you, new hire, you know, work on this thing.

And then what you do is you say, I will meet with you every day for an hour. And, you know, 9 a.m. or whatever, have a regular time. And after 10 a.m. So 10 a.m. to 5 p.m. you're working on your own. You know, here is the Slack channel to ask any questions. Here are the three people who you can bug about it. Here is, you know, the weekly team meeting about it, come to the standups, you know,

invite them to all of that stuff. So they're part of the team. Here's the people to bug about it. But they have a, they have a time limited window. You know, you have seven hours to work. Write down every question that you have and then that you don't get answered for some reason. And then we'll talk about it during tomorrow morning's one hour one-on-one. And like, I expect you to have questions.

expect some of these things to be confusing. I expect you to write bugs. And this is the way we learn. You know, what did you say a minute ago? Lisa, you said, ignorance is not their fault. It's their turn. I actually wrote that down because I love that. Like it's their turn to go through this process.

This is the natural process. There's, yeah, I love that. Hey, and all of us go through it every time we switch projects turns out, you know, you may have more experience, but every time you're faced with a company, you know, if you come into a company or a project that's been going for a while, there's a lot of code. There's a lot of thought that's been put into it, design. And every time it's like, wow, I don't understand this. I don't understand these choices.

None of this makes sense. And after six months of working on it, you're like, oh, this is how this works. And this is why this was, you know, I think that's experienced that we have over and over and over in our career. And it's good to kind of not only say. it's your turn, but it's going to be your turn throughout your career. Over and over again. Just get used to it.

Well, actually, so, yeah, I love that, Chris. That didn't even occur to me, but, like, I'm going to plus one that and then say that, like, the act of walking to something being ignorant, being a beginner, and figuring things out, that is a skill, that is a muscle. That is not an inborn trait. None of us are good at being beginners, you know, out of the box, right? And so, especially in the software engineering context, learning how to learn how to learn. learn learning how to onboard yourself, learning how to ask questions. That is a skill that, like you said, Chris, you're going to do that until you retire. And hopefully after you retire, too, because hopefully you stay active learning new things as well. And so I love that. That's an

extra motivation for both your current team. Like, hey, everybody, we can all remember that we have to learn how to learn. And so the new hire knows that, oh yeah, this frustration that I'm feeling that I will feel, this ignorance, this kind of being lost feeling, that is a, that is expected and then pushing through that literally develops the mental muscle of a skill that will serve you for the rest of your career. Literally building mental muscle is not a grammatically accurate phrase, I don't think, but I'm going to go with it. I'm reminded of a blog post I wrote that I am still very proud of that's called resilience is a skill. And I don't know if you remember it's back, but... The title rings a bell, but yeah,

I can imagine what it's about, but please go. What is it? We had a listener write in about how they really were hating some of their non-technical classes. And we're thinking about just, I don't remember entirely, but we're thinking about dropping them and getting rid of school because why did you have to take writing or business or whatever, accounting? And my response was, yeah, you have to practice sitting there. You have to practice being resilient to the things you don't want to do, to being to failing.

And this is an example of where one of those times where you can thoughtfully consider, how do I make this palatable? How do I make this okay? I have to do it. do you make the effort to figure out how you would teach this better? Do you make the effort to just get through it, power through it, be done? How do you build the skill of going through? Instead of constantly trying to go around whatever the problem is,

sometimes you just have to go through. and whatever you use to push through is a muscle. It's a skill that you build. It isn't a one and done. It's like ignorance and learning. This is something you're going to have to continue to do. If you can make it easier for yourself, do so. If you don't make it easier for yourself at some point,

you will find an obstacle and there won't be a way around and you'll be stuck. and that's no good. So start taking on those obstacles as though they are learning experiences. I love that. I love that. Yeah, that definitely rings a bell. Now I remember reading that. But yeah, that is fantastic.

Before we move on, as a corollary to the ignorance thing and feeling lost and maybe having the feeling like this is overwhelming, there is an instinct, and I have it sometimes. And I think a lot of new people who come out of school and feel very smart. or maybe they succeeded in school. They're in a company. They mistake that feeling of being lost or not understanding things forward. This hasn't been done right.

Yes, the story of the new college grad who suggested that maybe if the company made more revenue, it would be more successful. Well, I mean, that's what? I don't know if it's apocryphal. It was a tweet, but yes, there was the story of the new college graduate who was just like, well, why don't we just make more money?

And then we will be more successful. And everybody's looking at him like... Yes, I mean, that's an extreme example. But I was thinking more of like, this code is crap, I can't understand it. Right. Or mistaking a large project complexity for spaghetti code or... I mean, sometimes you're right. Sometimes after three years, the code isn't great.

But that's what happens after three years of... I'm going to use my favorite word of creeding things. and bug fixes and demands from management and changes and things. Code gets worse the longer it's been worked on just in terms of... Entropy is real. But that's a fact of development. And we all have to fight against that. But that doesn't mean you get to come in and mistake your...

Wow, this is hard to understand. I'm lost for we should just start over. Or you did a terrible job, you guys. I'm the new smart kid. that that that that is one way to make the senior people not help as much well and that's that's not just for junior people of course for any new hire into a team like you know the first thing let's rewrite it in rust right let's this this is garbage if only we would have done it the smart way you people are dumb and so there's yeah hopefully as people get longer in their careers they i i i maybe you can't even learn this until you spent five years in a code base that you have helped to accrete, to contribute to the accretion. I'm not sure what the grammar is here. But until you've been part of that and you look back and you're like,

I'm not a dumb person, but we're here because we're here. And rewriting the system isn't something we can tackle today. So how do I make progress? Maybe the progress is to rewrite part of it or to add modularity to some part of it or to encapsulate some part of it. That might be the right answer. But usually the answer isn't, I'm new here. I understand that you all are dumb or that this is a dumb way to do things.

Therefore, let's change it. That's never, that's never a good way to do. No, it isn't, but it's a common, it's a common defense mechanism. Yeah. I've felt that way. I've even been right once or twice. How do we feel that way and still have imposter syndrome? Well, like this code is crap.

I'm crap. I can be right it broader. I can rewrite it better. I don't, but yeah. Well, I think, you know, I think part of the solution is too, is to give people a sense that, yes, there's always problems in code bases. They're big, they're complex machines built by many people, and everything's a compromise. But while you're working in the code, try to leave things better than when you found them. That doesn't mean rewrite

whole swaths, but if you see something while you're working on a bug that's not related to your bug, fix it, open a new PR, open a new ticket for it, you know, take some initiative to, oh, that looks that looks like something that I could clean up. It doesn't have to be a big thing. Pick up the litter. Yeah, exactly. Pick up, pick up the litter where you see. Even if it's just a typo and a comment, you know, anything like that. Yep.

It can be done in a PR that has nothing to do with it because it's trivial. Or if you see somebody out, they didn't check null on this function. Throw that in there and just add some extra checking, add some extra error handling, add some logging if you're missing it, you know. Stuff like that is really helpful. And that's, you know, pushing back at the entropy instead of starting from, scratch and building another complex system, which in five years, you as the new person will be a senior and the new person will come in and say, this is crap.

Well, it's funny because it seems I've been at my new company for two years now. I just passed two years at Insulate. And, you know, coming in, I'm not writing any of the code. It's only been two years? Huh. It's only been two years? It's only been two years like two weeks ago or one week ago or something like that. It's time flies.

but, you know, as the new pretty, you know, I'm a director, right? So, like, that's pretty senior. And I've been writing code for, you know, a long time. Now I'm not writing code here, but I'm trying to understand the code. And coming in, there's a lot of things I see as a seasoned person saying, huh, why do we do that? I don't understand how we do that. And so instead of coming in and saying, I don't understand why you're doing this,

is not the same as this is dumb, right? So if you're curious, instead of accusing, then that will help. you know, not make people math and it will actually help you learn the code base faster. So, you know, whether you're a new hire or someone who's been doing this for 20 years, come in and say, hey, I see that we're doing blah, blah, blah, like, how did we get here? Can someone explain? Normally, there's going to be people who will say, oh, my gosh, yeah, we don't like it like that. But here's, you know, here's how it used to be.

Here's how we try to change it. And then we had to meet, you know, the deadline. And they changed, you know, they changed the scope on us at the last. minute. So we did it this way. And you know what? We should create a, you know, a ticket to go fix that next quarter. Okay. And so you, you haven't actually changed any code, but you've got the story behind it. You've got a little more of the history behind the team. You've been seen as somebody who's not accusing, but instead you're wanting to understand the code. And maybe then you remind the team that, oh, yeah, we could actually improve this thing, you know, in the future. And so you're not coming across

as like a know-it-all or someone who's hating on the new code. Instead, you're, you know, Hey, help me get to know the code. I feel like you two are both reading my PRs. I mean, one of them recently said, I was very clear, I pushed needs modification, not because I'm unhappy with you or the code. It's because there's something we don't, we're not seeing eye to eye on. And it may be me. So let's just talk about a couple of these issues.

And there was another one where I was like, you don't have to check null every time. If this is null, the whole file has. is just self-destructed. Should I use rest? I mean, they're... Sorry, sorry. They're getter-setters on what would be a class in C++. And so we pass and never mind.

Yeah, that's a great learning opportunity, right? Because you come out of school, you're defensive, you're defensive programming meaning. And so, yeah, that's fantastic. I check null every single time. I'm at the entry to every function, I check all, all the memory spaces for null. I loop through all of RAM and create a list of things that are zero, and then I log it to flash.

I just assert if there's, if any byte is zero in all of RAM or flash, then I just assert. Guys are mean. Yeah. My code is, well, my code has no bugs. Like, there's no failures because it doesn't, it doesn't run. So it's actually quite perfect. Don't do that. The, oh, I just, I just, I had something, I had something probably uniquely brilliant to say,

but I just forgot. I forgot it with my stupid thought. Okay, please. You're a director. You're not a manager anymore. You're managing managers. I want to be able to develop some of the people who have potential for management. And so what I wanted this talk about, what I wanted this podcast to be about, was not necessarily what we should do, either as new hires or as mentors for new college grads.

but what we should be teaching our managers and our tech leads about how they should be handling new college grads. And you talked about, you know, have a buddy. Okay, yes, we tell our new manager, make sure that the new person has a mentor. And it can't be you because you're in their management structure. So who do you want to have a manager? Or who do you want to be their buddy? who can balance your time and their time and blah, blah, blah. Do you have any advice for how to train a new manager to help a new college grant?

This is sort of a meta question. Yeah, yeah, yeah, this is, you've gone up one level. You know, have them think through. So the point isn't just getting, you know, one person from, point A to point B, right? The point is, how do we create a team that can onboard new people? How do we change the culture of our team to be one that accepts new people, accepts ignorance, rewards, you know, rewards curiosity? And so ask them like, hey, how do you think the team would do with a new hire who is ignorant? Who on the team could you trust to be a mentor? And if the

answer is no one, then what are you going to do about that? You know, as one of the stepping, stepping aside a little bit, you know, as you talk about promoting people, you know, your associate software engineer, or your senior, your staff, or your principal, one of the things that you usually need to demonstrate as you go sort of up, up the ranks of seniority is mentoring, is coaching, is helping others develop themselves. And so are you as a manager, or I guess, make sure as a manager that as you're thinking about, hmm, is, you know, is Jill, is she ready for the promotion to senior? One of the things is, can she mentor?

Like, is she ready for promotion to principal? Can she mentor mentors? Can she, you know, has she demonstrated that? And if the answer is no, then as a manager, your job is to give them that opportunity of mentoring, managing co-ops, interns, new hires, that kind of a thing. That answers a small part of your question, Alicia. Not very much of it, though. I mean, you're giving them the opportunity, but you could give me the opportunity to fly a jet,

and it would go badly. You have to give them more than the opportunity. You have to give them the tools. And so my question is, what are the tools that we can give to people to help them be better mentors, better managers, better leaders? Yeah. So I wish I had a better set of tools. I've got a few books, so I tend to learn from books.

I love reading as a hobby, and I love reading about leadership, you know, management, people, tech, all that kind of stuff. So Camille Fornier's manager path, yes. We recommend that one all the time. 100%. Resilient Management by Laura Hogan, which is L-A-R-A-H-O-G-A-N, Resilient Management, is an excellent book that's about the human side of engineering management. Honestly, it pairs really well with manager's path by Camille. And so, like, those two books are my first things that I, that I recommend. You know, I, I have learned this by osmosis and by, you know, having a manager who demonstrated something.

So I don't have, I don't have a specific tool set other than having conversations like what we're having right now. Have these with your managers. Have these with your mentors. Have these, like, what, what do you think, you know, putting, we talked about, you know, building resilience as a skill. Like you need to face some pressure and you need to face, you know, things you don't want to do or you need to face the ignorance of something you don't know about and you need to learn how to learn. I think that with management barring any really good training class or something like that, you know, you need to present to your managers or to your staff, hey, how do you think we should we should onboard new people? How do we make curiosity, a rewardable, you know, a rewardable skill? How do we do these things?

By having people think through it on their own, they're going to own it more. they're going to have to think through it. Then you can suggest a couple of books here, a couple of blogs, you know, go out into the internet, see what the internet has to say about it. They will probably come up with things you don't think about, and they will own it more. They will internalize it more instead of like, all right, Elisa gave me a checklist.

I guess I'll follow the checklist. That's a little bit of a wishy-washy answer. If I had a really good training regimen, I'd probably just suggest that. Of course, yes, this training regimen works. Make it your own. lacking that, ask them how they would go about it and hope that the mental exercise of considering it gives them better tools than if they just went and did it. I mean, that's true for most engineering. Don't just go off and write the code.

Tell me how you're going to write the code. And it doesn't really matter if I'm listening at that point because that process of telling me how you're going to do it is what is going to build the actual. good code. Right. And then after you've done it, sit down, so you, the manager, sit down with them and say, okay, what did you do with a mentor or with a mentee or whatever? And then how did that go? Yeah. I mean, I'm not usually that direct. It's like, are you happy with that as direct as I get on that? But yeah. Sure. I guess I'm thinking, you know, as a director, if I have a manager who works for me and then they have a new hire, you know, every week, you know, in our weekly one-on-one, so I manage, I'll say, hey, how is, you know, how is Jill doing? How is, how is her project?

What have you given her? Who's her mentor? How's that going? And so you kind of check in. And then they will hopefully say, oh, actually, you know, they got, they got distracted by doing XYZ. And okay, cool. So how are you handling that? You know, and you're also trying to model to your managers, to your team. Failing is just fine. You know, making mistakes. People are going to go off track. And whether it's writing a bug in the code or whether it's giving someone poor instruction or letting them go on their own, long without checking in and finding out they were confused for a week without talking to anybody. Okay, there's a learning opportunity. How do we not do that again? Yep. Don't get mad. It's just not worth it. Get even.

Nope. No, that's what? No. I do still wish I had a list, a book, a month club of new college grads. Here are the books. Here are the skills. I mean, I've seen the skills trees. That's okay, kind of.

Pragmatic Programmer is another book that has, I only read the older edition. I haven't actually read the 20th anniversary edition, but Pragmatic Programmer had a lot of something like how to think like a senior engineer kind of stuff. I'd be interested if listeners of the show, if they could, I'm going to give you email now, but like if people have seen anything that helps them think more along these lines, whether it's a new manager or whether it's how to, you know, how to manage new hires or even. the book club that New Hires can go through, is there a book that was particularly helpful? Yeah, I mean, those would be great. Another book, hang on, let me find out in my bookshelf, whereas it's called A Philosophy of Software Design by Jonathan,

I can't read it, John Osterhout. And we'll find a link afterwards. But that book is a very philosophical book about software engineering, software architecture. It's very high level, though. It's nothing super specific. the guy is a, I think he's a Stanford professor, but he's also worked in industry some. And so having a new hire, new college grad or not go through that with a team or with a few people,

also gives you a chance to talk about, hey, what did you think about that? What did you agree with or what did you disagree with? And so there's some of the more technical books like that, like Pragmatic Programmer or this philosophy of software design that can give you some of the technical discussion that you might. might be able to learn with. Joel Spolsky, who is a super, super prominent blogger, and he was the co-founder of Stack Overflow. But he wrote a couple of books that were based on blog posts of his, and it was written in the early 2000s. A lot of it is kind of dated right now, just in terms of the thinking. But he was very good at writing about how software should be developed. And those

might make good book clubs just in terms of saying, how should you, you know, organize your day? How should you keep distraction free? Why should you never rewrite a project or rewrite a piece of software in a completely different language? And his answers aren't always correct, but they get people thinking about how to manage people, how to manage tech, how to do that kind of thing. So those are a couple suggestions. They may be good, they may be bad, but things that I have found helpful in the past that might be good reading material, supplemental material. For the skill side, I guess I'm supposed to plug my book, but yeah, making a better systems. Wee.

Yeah, and you did. I'll plug that a little more here. You did ask, I think, hey, what is a training program to get somebody from zero to five, you know, from junior to senior? And your book, Making a Better System, second edition, is a very good, broad and specific enough, look at like, hey, if, If a new hire goes through that, they will be exposed to like 90% of what we do every day in embedded systems. And, you know, finding resources like that, put someone through that, have them do some little projects if you can. Put a cohort of people through that kind of a thing. So, like, I mean, you've done was it, class pert, Alicia?

So, I mean, you've literally put together that curriculum before. Would you recommend that for companies and for people to put their people through? Well, classpert isn't doing your. classes yet. I have been thinking about open sourcing some of that, but I'm not ready yet. My book was definitely designed for that, okay, I know a little bit of hardware or a little bit of software. Now, how do I become an engineer who thinks about design? But in the short term, the skills trees are helpful. Nathan Jones has embedded for everyone, which goes through a whole bunch of different places that he's found things.

It doesn't always have to be books. I mean, I like books. I agree with you. Reading for fun. Reading for professional development, great. But, you know, the repository for my book has a bunch of games. And I find myself really suggesting those to people who aren't readers. You want to know more about assembly?

Great. Shenzhen, I.O. You want to be a better typist, type or don't let, I don't want to read or I find these things boring hold you back because there's probably a way to make it fun. But yeah, I mean, there's so many good books.

And it changes all the time. It's hard to suggest Spolsky and the pragmatic programmer, we went through it in the Embedded FM Slack recently. I kind of didn't like the new edition.

There were a lot of additions that, I don't know, maybe I just didn't like it. I remember liking it before. Yeah. But I wasn't at a point in my career where I needed it. Right. Right. I mean, it could be that the additions in the addition were not, you know, not something you found helpful.

You're just in a different place than you were 20 years ago or whatever. Yeah. I mean, all these are true. the oh yeah i want to get back to one thing because i wrote this down earlier and i wanted to it was about the prs thing we were talking about so alicia i'm sorry for going back to this but you were saying that you would intentionally block a PR and you would say like you know it's not it's not because you're a bad person but you would say it's because i want to address this question or it's because i want to do this thing you know and that's that's normal and that's fine

something that i would say i see teams falling into is that they communicate only via typing in stuff to a PR. Not a good idea. And that is not a good idea. It's fine. It's very good to put your technical thoughts in there. But at some point, if you're like, hey, maybe I disagree with the way this is being implemented or maybe I have more fundamental questions about this, just grab a quick meeting.

Just grab a quick, like ad hoc. Hey, can we have a Zoom call or can we get together in the office for 15 minutes? Because if I'm just hammering at you with text saying, this looks like a bug, have you thought about this? if you thought about that, it's really easy for text communication to be understood as, like, being attacked, you think my code sucks, therefore you think I suck. And instead, all I'm actually thinking is, hey, you know, did you think about this? I'm worried about the implementation because of blah, blah, blah. And I can communicate that in a much more friendly way and less aggressive way by talking to you,

because you can hear me saying, did you think about this with a question mark at the end, instead of an accusation that you are a bad software engineer? So if you find yourself thinking through, you know, or making a few too many, you know, what about this? What about that? I have a problem with this. Jump on a call, grab a person in a conference room and just have a quick face-to-face because that's going to be so much less likely to be misconstrued as aggressive or negative than anything in typing. I mean, I do type chat a lot, but I will take it off the PR. I do it in whatever slack or chat method we have. where I will be less formal and all that. But I recently did PR with a new college person, and I shared my screen because I wanted to show what I meant.

And they didn't know about the files changed tab. There you go. And it's like, oh, right. Why do I expect you to be able to, I mean, there's a lot happening on the PR page. Files change should be the second tap after conversation. I think they've got that wrong in the user interface. Being able to just show that was enough for the person to go off and handle a whole bunch of things.

And yeah, that would have been 9,000 back-and-forth types. And it was basically 30 seconds of, oh, I didn't even know that was. there, which is the thing with the new college grads we need to be aware of. Is there going to be a lot of, oh, I didn't know that was there, sorts of problems. Because they come in, for the first time they're learning about 401Ks. They don't know what you do. They don't know how to be in a professional team like this. they don't know how to necessarily understand that their skill level is not professional yet.

And they can be intimidated easily. Sometimes you just have to, you know, okay, you know, it doesn't really matter what's wrong. Let's just sit down and chat for a second. That approachability has always been really hard for me. Yeah, we're usually a bunch of introverts. or we're not known for our dazzling social skills. But, yeah, that's a good reminder that, yeah, you're coming in. You don't know all these things.

And it's a good reminder. Like, I always think it's funny when I'm explaining something kind of complicated to someone newer that, like, oh, my gosh, our industry, our field is so confusing. There's so many little tiny gotchas that are not obvious at all, like the UI on the PRs, right? Like, oh, yeah, if you don't know that. there's a second tab there that has these things, which isn't exactly shouting out at you. Because, by the way, you've never seen a PR interface like that before. It's got 4,000 visual elements on it. How do you know which ones to click on?

But yeah, this is confusing stuff. So it's kind of humbling even as a senior person to realize, oh, my gosh, I've learned a lot over the years. And I've learned it because patient people showed me things along the way or I've stumbled along things. And so have that patience and grace for the newcomers who are, showing up. Chris, you had a question you want to come back to. Mm-hmm. So we've been talking about how to help new grads who are feeling ignorant or confused or

maybe confused that they're confused, maybe they don't know that they don't know things, all that stuff, and preparing your team for that and all that stuff. How do you prepare your team for the new grads who come in and just are that good? And they're right. And they're not saying rewrite it and rest. They're raising good points and arguing with senior people, and they're right. This has happened once or twice, my experience. And I think it's more difficult to deal with than the people who need a lot of handholding.

Why? Because senior people don't like it. That's not. You can argue with the senior people. They're wrong. but it is a management problem. Yes, and I've had a few of those folks, and they are such a joy. The chaos they can create is just so fun.

Okay. I'll see your answer is just to step back and laugh. Let's see how this plays out. I mean, I think it's like anything else there, it's a balance. You know, we try to be data-driven as engineers, we lie and we tell ourselves that we are, it's a meritocracy and we will always, scientists, which we are not. Scientists, that's right, we will always believe in the data.

And, you know, we're not, we're not that analytical. We're not that, I'm biased. There's an entire industry that has outsourced its work to a random number generators. True, true, true, true. Yeah, back when, back when determinism was a thing, right? But, you know, I think there is a coaching opportunity for the new hire to say, hey, like, let's remember, everyone has biases. You know, you're challenging them. You're challenging people's worldviews, which is fine.

Can you identify what is the pain point and what does your idea solve? If people can agree that, hey, here's a pain point. Here's something that solves that pain. Then that's the only way you're going to move. You're going to change minds. Right. And then you get to say, let's say this person has a hundred ideas that are the absolute correct things, like objectively. Let's say everyone even agrees. These are the hundred things we need to change. You can't change 100 things overnight. Like there is a, an organization, a team, a code base. There is a capacity for change, which is sort of intrinsic to the organization. You know, Facebook has the famous phrase, I don't know if they use it anymore, but, you know, move fast and break things. So if you were in an organization that you live by the phrase, move fast, and break things, then, you know, you can see a new hire being successful going in and like ripping stuff up. And as long as they're not breaking too much, the mantra is break things.

So it's perfectly fine. If, for instance, you work in an FDA regulated industry where breaking things means that you literally kill people, maybe you can't do that. And maybe your organizational capacity for change is smaller, is lesser over a year because it takes more inertia, are more checking. There's more horrible consequences if you get it wrong. So as a as a leader, as a senior engineer in the team, as a new hire, everyone has work to do to understand, you know, what's the pain point, does this solve the pain point? What's the right time to do a change like this if ever? And how do we organize around that? And there's a lot of ego and that like that's all psychology and sociology and very little technology there. So that's the fun part about being a leader.

If you're someone who thinks, ooh, that's an interesting challenge, then maybe you should be a manager. If you're someone who's like, nope, I do not want to ever even have this conversation and I'm physically uncomfortable listening to a podcast about it, you know, maybe you don't want to be a manager someday. But that's the fun stuff. That's the stuff where it's like, okay, okay. Let's figure out how we could make this happen in a good and sustainable way. To be slightly more serious. what that person that super genius new kid needs is the system level view that includes the people. What they need actually is management training.

Oh, you're going to take some. I am going to take your best shiny new genius kid and I'm going to make them into a manager. Isn't that awful? It is. I don't agree with it. So I have two thoughts. I have two thoughts here. Two thoughts here.

One is it something I forgot to add later. I actually put this in the outline, but I totally forgot it. Is that what I do with every new hire, whether they're a manager, new college grad, whatever, is that we used to. Insulate was already doing this when I got here. And I'm definitely stealing this for the rest of my life. But we make a list of who else your new hire should talk to in the company. And make sure it's a broad list of people within the engineering. software, other software engineers for the embedded software, the iOS software engineer, the Android

software engineer, the systems engineers, the EEs, the product managers, the program managers, the scrum masters. And their job for their first month is to talk to these 18 people and to basically say, what do you do here? Please tell me about your job. Tell me about your background. Tell me about what are the challenges the geo. What's the hardest part about your job? And what you're doing is two things. So at least you just, you're talking about like it's the people side of things kind of kicked me to remember this, is that you're meeting people, you're building relationships, you're learning who else you can talk to about things, and you're learning that, oh, my little embedded software part of the company is 5% of what

actually goes on here. And you're building sort of the systems knowledge. Now, you also can build the systems knowledge by actually learning how the entire system works, but this is a good, easy on-ramp to, okay, here's the 18 people you've got to talk to. You're going to learn something about 18 different people in systems and things along the way. And so that is fantastic. The second thing, I actually forgot we even had this. At Iroba, this guy, Justin Shriver, fantastic engineer, fantastic engineering manager, he actually created a kind of a boot camp. I think it was called like tech lead boot camp. And Justin, I'm trying to remember the agenda he had for, but it was basically a two or three day thing that was.

for people who wanted to be tech leads. And it had, you know, a two-hour session on what does a program manager do? Like, how does schedules work? What does? And then, like, two hours on what does a test lead do? Two hours on what does a dev lead do? Two hours on what does actually getting a manufacturing build for the factory look like? Basically, it was a several-day program on here is an overview of what going through the whole

life cycle of a program looks like. And so people got kind of a quick look. at all of the different people and decisions and schedules and, you know, go-no-go conversations that mattered in a program that gave people the context for what it takes to actually ship software besides just writing a bit of C-code, updating a unit test, and pushing it to Bitbucket, if that makes sense. So that is possible. I wish I thought of that earlier today because I'd answer some of the question here. Because you could have looked at those slides and just done this podcast yourself?

Exactly. Why would have just sent those to you? And then you wouldn't have, no one would have to listen to me. prattle on for an hour here. You also had another thing in the list that we were going to talk about, and that's to have each new hire add to the stuff to know as a new hire page and edit it ruthlessly so that you don't end up with a thousand little bits, but you do, the new hires build the on-ramp for the next person. Exactly, exactly, because they're going to trip over all the stuff that wasn't clear from the last person, and they're going to hopefully fix it.

And that way it stays updated as your tools change and as your, you know, your instructions on how to get into Slack change the new hire editset plus by encouraging them and really like forcing them to edit this communal wiki page or Confluence page or whatever you have, the documentation. It also gets them kind of owning it more, right? They're not just a newcomer who's like, I don't know what's going on, but instead they're helping to train the next person. And that's that's ownership, that's empowerment. There's that word again. and that's engaging like, okay, I belong here. I'm helping to make things better. And even if I haven't committed the best new feature yet,

I'm helping myself and I'm helping other new hires to kind of get through this. Do you think new hires really need that much more praise than everybody else? I don't think so. I honestly, I think we all, I don't want to be like, oh, everyone needs a trophy every 15 minutes. but I think that we all should think about thanking each other more, just in general, and saying, hey, you did a really good job in that presentation. How you did this?

Hey, you did that. Not in a performative way, not because I think you need praise. And if Alicia doesn't get 17 praises every week, she will be grumpy. But instead, like, looking around and thinking, you know, I want to work in a place where good things are recognized. And when I see one of my people deliver a presentation that was really clear, I should tell them, hey, that was really clear. You know, you, you took something that was confusing and you made it clear. Or, hey, that was a really insightful question. And just doing little things like that and having that become sort of a habit for everybody, like, there's no downside there.

And again, I'm not saying this is performative that you must do 17 of these a week else your fragile ego will be crushed. Instead, I'm saying, I'd rather work in a place where people like, hey, you know, Jill helped me this week. Shout out to her. On some programs that we have internally here, we have. actually have a shout-out channel that is a channel that is dedicated to, you know, shout-out to Christian Alicia. You know, they went above and beyond this week, and they did this thing. And it can be a little thing, it can be a big thing, but it's normalizing the public thinking of each other.

I'm sorry, I just remind me of something from college where I was the Usenet, Usenet administrator. And so I would create local mud dot whatever groups on Usenet. And kids, if you don't know what Usenet was, look it up. It was something from the time of dinosaurs. Basically, it was social media. We invented social media and then you all forgot about it. Anyway, one of the groups we created was mud. Because you had to have a flame group for every top-level group domain.

So we had mud dot flame, and people used to argue and yell at each other and call each other names on that all the time. One of the CS professors hated this. He could not stand it. And so he made me. God rest his soul, Professor Keller. He made me create an alternate group called Muddott kudos, where people could say nice things about each other.

And at the time, we all thought this was ridiculous, and it was ridiculous. Now I have more sympathy toward the notion, toward the impulse there, but mud dot kudos was empty. Which only made it worse. No, but nobody ever posted on muddusts to kudos. Yeah. Anyway, that just remind me of that, the Slack kudos group, which I think is a good idea,

and I think people in companies would use it more. People in the college probably would not respond to it as well. Yeah, that's kind of tough. That's kind of tough. At IRobot, we had a kudos thing in Slack, and one of our tools team people created, and basically it was a Slack command where you could just like Slack. You could give someone kudos, and you would say kudos to Chris for doing X, Y, And it would actually, we could argue whether this was good or not.

But what that would do then is that would increment your kudos. Oh, no, no, no, no, no, no, no, no, no, no, no. You can't make it a competition. No meow meo beans. No, but the thing, the thing about the meow beans, the thing about the, like, it actually, somehow it actually worked, like in this culture, we ran it for a number of years. Now, the company went bankrupt. Those are not related.

Those are not related. But it actually, what ended up happening is the, the few people at the top of the pairmen, you were like, those really are the most. most helpful people. And like looking, look like, I can, I remember who those humans are. You know, John Dorwich, for instance, like, oh my gosh, that guy was super smart and he was, he was always helping everybody. And he deservedly was at the top of the kudos list. Yeah. Because darn it, like, he was that helpful. And by by elevating that behavior, I think we made, we helped encourage the culture to be one of helping. You know, we didn't, we didn't give raises based on it. No one was

penalized if they didn't get enough kudos. That kind of. kind of a thing. It was, we internally, I think, handled it well. The culture was coming from a good place anyway. And I could absolutely see that being weaponized and being a horrible, horrible thing. So the people on the top of the list did not get their own conference room and did not get to sit in there and drink out of goblets while wearing togas. Not that I know of no. No. That's probably fun. We'll link to the episode in question that I'm referring to of a show. Community. Good show. I wrote down yellow. I didn't expect UsNet or Miam Ya Beans to come up on this show.

But Flame Wars, people were bad to each other on the internet before. People were bad to each other on the internet the instant the internet occurred. It's true. It's just the way we are. People are also wonderful to each other in the internet sometimes. Like in the Embedded FM podcast Slack group. Occasionally. Pretty good place.

I'm happy with it. It is a pretty good place. Like I remember when you started it publicly, I was, thinking like, ooh, how is this going to go? A bunch of randos on the internet. But it is actually perhaps like uniformly just a good place for people to ask questions, express ignorance and get questions answered and kind of have a good time. And you got some cute pictures of dogs on there sometimes too. It's kind of a win-win. Svec, you are, you're employed at insulate and you are thinking about doing a little bit of

side consulting. Yeah, yeah. Thanks. Thanks for that wonderful for me. But yeah, I've done, I've done some leadership and management consulting for smaller companies, from medium companies, just for individuals. And as hopefully you can tell, I like by this podcast episode, I love thinking about this stuff. And again, the psychology and the sociology of teams and getting them to think better, you know, getting your particular team to figure out the context of how you can be more effective, more, you know, more whatever, is something that I've really gotten more excited about and got more interested in, especially in the last five to ten years. So I've worked with a couple of companies. I am working with a couple

companies doing a little bit of kind of coaching, you know, whether you call it leadership consulting or leadership or management coaching, words that kind of describe the same thing. But if you're interested in having a thought partner, even just like a rubber duck to bounce things off of to someone who has, you know, obviously I don't know you, I don't know your company, but someone to bounce things off of and give you some ideas and just talk about things with, you know, reach out to me. I love having these conversations. I love helping people. You know, I've been, I've made enough mistakes that I've learned a few things. And I always have more to learn. We all do. And if you're interested in having these

conversations for yourself in your career or for your company or group, please reach out to me. I'd love to talk. You know, get in touch with me at svec. At chrisvec.com. you know, the spelling of that will be in the show notes. And spec is just SVEC. It's a terrible name, but this is pretty unique. It's a fine name, but I have to spell it every time I ever say it, you know. Oh, yeah. Complaint to me about how your name is spelled.

What's that, Alicia or Aleccia is one of my favorite. Aleccia. I want to start calling you that. I think every guest who comes in the show needs to call you Alecia. me L. That's the ancient Greek pronunciation. Alecia or the cindarin. As fact, do you have any thoughts you'd like to leave us with?

Just to recap the thing I've said a few times here is admitting ignorance publicly is literally a superpower. And if you can do that, especially if you're a senior, especially if you're someone in a position of influence, authority, power, whatever in your company, being seen as someone who can say, huh, I don't get that. I don't understand that. can you please explain it to me? That will help encourage everyone to see that,

oh, we all got to be learning. We all got to be admitting it. Totally fine to not know something. And because if you don't admit, you don't know something, you'll never learn it. So that's my, that's my spiel there. Our guest has been Chris Feck, director of embedded software at Insulate.

He does some management leader coaching consulting. If you want to talk to him, It's spec at chrisfeck.com And we will not have a link in the show notes, but if you contact us, I can pass it along. Thank you, Chris, for joining us again, and it was lovely to talk to you. Yeah, thanks.

Always fun. Always fun. Thank you both. Also, thank you for filling it at the last minute. Oh, I didn't realize I was a felon. Well, in that case, I take it all back. All right, then. A felon?

A felon. A felon. He's finally admitting it. It's court ordered. Thank you to Christopher for producing and co-hosting. Thank you to our Patreon Slack group for, I don't know, being kind of cool. Thank you for listening. And you can always contact us at a show at embedded.fm or hit the contact link on Embedded FM.

And I'll quote to leave you with. This one's kind of long. I could have become a mass murderer after I hacked my governor module. But then I realized I could access the combined feed of entertainment channels carried on the company satellites. It had been well over 35,000 hours or so since then, while still not much murdering, but probably, I don't know, a little under 35,000 hours of movies, serials, books, plays, and music consumed. As a heartless killing machine, I was a terrible failure. That is from Martha Wells All System Red.

she was on the show and of course we didn't talk much about technology just about fun you know,