Onboarding New Employees

About this Episode

The panel delves into the challenges and strategies of onboarding new employees to discuss the importance of communication, mentorship, and understanding context. Mike shares a story from his construction days in New Orleans, where he learned the value of being paired with an experienced team member. This buddy system helped him overcome communication barriers and adapt more quickly to his new environment.

Effective onboarding involves more than just providing documentation. While documentation is valuable, it must be up-to-date and supplemented with hands-on guidance and practical experience. The panel advocates for giving new employees context about their tasks and the organization. This can include having them use the software as end-users or working directly with customers to understand the system and its impact better. Regular check-ins and skills clinics are also recommended to help employees stay updated and improve their skills.

Additionally, the podcast highlights the importance of continuous learning and mentorship for all employees, not just new hires. Regular mentor-mentee interactions and collaborative updates to documentation ensure that onboarding remains practical and relevant. The panelists also note the pitfalls to avoid, such as not following through on commitments and assigning unsuitable onboarding buddies.

Transcript:

 MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today [laughs]. With me right now, we've got Justin, Dave, and Matt. We're going to talk about onboarding new employees. It's a tricky problem. I don't know that anybody has it perfect, and I don't think we have it perfect. So, we're going to talk about some ideas, some things that we've seen go well and maybe not so well. I've been remembering onboarding in days past.

I tell a story about the late '90s. I was living in New Orleans doing construction work. We would go in and remodel office space. So, sometimes, we'd tear out everything and then rebuild it. You know, we had teams all over. The company I was working for had teams all over the city doing this. And the team I started on, I started just as a laborer. I was not doing anything fancy to begin with.

But what I remember is a couple of things. The day I started, the foreman I was working with set me up with a partner. His name was also Mike [laughs], and they called him Big Mike. And they sometimes would compare him to George Foreman because they looked similar. He was a big guy. He previously worked out on the oil rigs out in the Gulf of Mexico and a big, strong guy. And we got to be fast friends pretty quickly.

However, the day I started, I had not been living in Louisiana for all that long, and he grew up way out in the Bayou somewhere. And when he started talking to me, I picked up about one word out of three of what he was saying [laughs], maybe. And it was that way for a few days. You know, maybe started out with one word out of three. After a while, I got to two out of three. There's a mix of accents there. If you've got a Southern accent and a heavy French accent...

DAVE: Mm-hmm. The Creole.

MIKE: Plus, there's some African-influenced accent as well, and you mix those all together. And I'm a White guy from farther North [laughs]; I did not pick up very quickly. But we got to be friends. And he was patient [laughs]. He was patient with me. And, actually, after a few months, we'd hung out outside of work. We were actually quite close friends. We've lost touch over the years, but I'd love to get back in touch with him. After the storms they had down there, that drove out a lot of the population. He's probably moved, and I don't know where he's gone.

[laughter]

But there are things about this story that were relevant. First of all, the foreman did a great thing. When he brought me in, he paired me with somebody so that I didn't have to know everything. I just had to be able to ask Mike, and [laughs] we could get some stuff done. The second thing is communication is hard [laughs]. We were speaking the same language, and we still couldn't understand each other. He could probably understand me. I was the one who was struggling [laughs].

But, you know, it took us a while to get things right, and we had to work on it. It had to be an active, active effort, especially on my part, to learn to understand. And working on it worked, though. You know, over time, we got to work really well together. We were frequently called on to get a lot of stuff done because we had more effective partnerships [laughs]. We both had enough carpentry skills that we could get a lot done besides just being laborers.

I lay this out, and it's outside of software engineering. I think a lot of times, it helps to think about something outside of software engineering to lay some context. We bring people in, and we let them loose. And you've got to figure stuff out. You may be talking with somebody [laughs] who has a different background, and he's going to use the same words and mean different things, and you're in an unfamiliar project. There's a lot that has to happen for you to onboard successfully.

And there's a few things that I think make a huge difference to be successful and one of them is that regular communication with somebody. And another is, you know, well, getting that communication, but having a buddy, right? Having that lifeline, I think, are some of the key aspects I've seen be effective in onboarding. I think there's a lot else as well, but there's my story to launch this off. And what do you all think?

MATT: Well, you hit on communication, and while I think, you know, trying to dissect a Creole Cajun dialect is tough, [laughter] there's also communication differences in the same language and dialect. For instance, the four of us all have very different communication styles, and I think being able to pick up on that and how people communicate, and their intent is a very important aspect of that.

JUSTIN: I like how they assigned somebody to you who was already part of the thing. They had, you know, knowledge that they've built up as kind of a veteran working there. And they were able to answer your questions, and you were able to be much more effective because you had somebody to ask questions to, and they had to answer right away. You weren't, like, left alone. "Go do your thing [laughs]."

Yeah, I've had experiences with both. And a lot of how you communicate culture to a new team member is, you know, whoever is introducing you, and whoever your onboarding buddy is, whoever you have the most exposure to, that is how they view the whole company almost. And if you don't have somebody, you know, doing that correctly, you don't have a good communication in not just, you know, knowledge, but also culture, and friendships, and there's a whole bunch of stuff there.

DAVE: But, for me, it's, like, context. There's so much out-of-band stuff you can pick up by, like, a personal interaction, where I was talking with Adam a while back, and I'm like, "I want to pair with you on this problem." And he had been thinking through this problem. And he's like, "Well, I know it's not the login. I know it's not this. I know it's not this conditioning thing. I know it's not this sequence in the system." And I'm like, "Adam, I need you to take me with you to hunt badgers." And he's like, "What do you mean?" And I said, "I don't need you to show me how to shoot the badger once you've found it. I need you to take me through the hills and show me every place you check for badgers. That's what I need."

Because he was thinking, I don't want to show you the login system because that's not going to be the problem, and I don't want to show you the pipeline because that's not...I'm like, no, show me that you checked the login, right? Like, literally, the gift in the box was not what I wanted. I wanted the box, and the wrapper, and [laughter]...right? And all the trappings that went with it.

MIKE: That's interesting. You wanted the box.

DAVE: Mm-hmm.

MIKE: Again, this is a little bit outside of engineering, but it's related to that. You know, you think about math class. You can memorize the rules for solving a problem. And as soon as you forget any one of those or you make one little mistake, you're just completely lost. But if you can have somebody who takes the time to help you understand why you're doing what you're doing...and it takes a lot longer. It absolutely takes a lot longer, and in a classroom setting, that's hard. You know, it's a gifted teacher who can bring everybody to that level, and that's, you know, a difficult thing to do.

But if you can do it, if you can help somebody get deep mastery of why those things are there, you know, teach the intuition and understanding, if somebody gets lost, they can backtrack. You know, you can figure out what you're doing or even come up with your own way of doing things and be creative about it. It completely changes your perception of that problem-solving. We're in a problem-solving industry. That same idea is directly applicable. If you could show somebody this is what you do and, you know, tell them to just do that, it's not very useful at all.

MATT: The journey is just as important as the destination.

JUSTIN: I think, to kind of summarize, if we were to put, like, points on a board about, you know, how do we onboard someone, so, right at the start is, like, choose an onboarding buddy who's going to be very helpful for this person in whatever. And I think that's part of leadership's responsibility, you know, whoever is in charge of onboarding this person, whether it's the tech lead, or the director, or whoever the team lead. So, they need to make that decision of who's going to be this person's onboarding buddy. And then recognize that that's going to take time, and that's real work. And you can't, like, you know, expect them to do the same level of work as they did before, perhaps, because they are, you know, if they're going to do it right, it's going to take time.

MATT: And based on the information we have about these new hires, who is going to be the best fit, not only in experience, but personality type, communication type, those things?

MIKE: That investment can go a long way. If you do your onboarding poorly, then you're going to have somebody who doesn't know what they're doing. And somebody can sit around for months and get very little done. They'd be busy, busy all of that time, and not get very much done because they don't know what they're doing.

DAVE: I can't tell if I feel seen or attacked there, Mike.

[laughter]

MATT: But that's important, right? Encouraging people to ask questions and not just sit and spin their gears, ensuring that they understand the things you're going through and leading them. You know, I could sit and write code for hours and have someone paired with me. But if I'm not ensuring that they're understanding what I'm doing, communicating my thought process of why I'm doing it, I don't feel like I'm really helping them. And they're probably not learning a whole lot during that time, right?

MIKE: One thing about our brains is they don't tend to stay connected to something they're not actively engaged with. You show me somebody who can watch somebody do a detailed technical task for a long period of time, and [chuckles] I'll show you something imaginary [laughter]. It's not the way our brains work.

DAVE: There's a really great experiment that demonstrates this, which is that if you just start reciting numbers at somebody and say, "Memorize this. You don't get to write it down. Just memorize it," we tend to be able to hold about seven numbers. Like, some people are down to five. Some people, as many as nine...can hold this in their working memory. And what we miss is that if you can tie these things together with a story...the people that memorize Pi out to, like, a million places, they have a story that ties all the numbers together, and where you are in the numbers, where you are in the story, and, to them, it's just one story.

And that is the essence of, like, "Oh yeah, you know, sign into this. The database is over here. The server is over there." And I'm like, okay, that's three things that aren't connected [laughs], right? And there's 23 more to go. You better start making a story out of this for me [laughs].

MIKE: You know, that says something, right? Without that story. And it also says something about communication. You know, a lot of the best communicators will dip into stories that don't directly connect to the material they're talking about. But then they'll make the connection like, oh, that's great. That was entertaining. And it's entertaining, sure, but it's a lot more than that. Without that story, you would never have learned the idea in the first place.

It may superficially look like they're just trying to make things fun, but that's really not what...making things fun is not what really good communicators do. What really good communicators do is connect you with the material they're talking with. That could be fun, and it's going to be engaging, but the goal is different. They're not trying to force something to be entertaining. Let's make math fun. No, they actually see the fun in it. They see the story, and they want to share it.

DAVE: I had a co-worker...oh gosh, this was around Y2K. This was a while back. And we were struggling with the inheritance rules. I had some co-workers that didn't understand, like, protected versus private versus public versus, you know, friend was the thing. I blurted out the rules of C++ inheritance in terms of intimate encounters, right? Your children cannot touch your privates. Your friends can touch your privates, right?

I got sent to HR, which is fine; I deserved it. But a week later, I'm typing away at two cubicles over. I hear, "Damn it, Dave!" [laughter] And I'm like, "What?" He's like, "I know the difference between protected and private, you jerk!" and just kept typing. And I'm like, yep, that's in your brain rent-free for the rest of your life [laughs]. I've gotten better at little, you know, more tasteful stories since then. You're all going to remember it now, too.

[laughter]

MIKE: So, reinforcing the point about stories, having to have that connection and the importance of context, the importance of context.

JUSTIN: Related to that story there and onboarding new people, the best places I've seen that do onboarding is where you come in, and you're actually onboarded as a user of whatever system that you are going to be doing, and so you know how the users are using it. And you can see, you know, oh, okay, here I'm a customer service rep, and here's me logging in, and here's me helping a customer, looking up the customer name. And then, here's me looking up their lease number, and their payments, and their history, and things like that. And I can, you know, see there. And here's the customer service rep complaining about something.

And so, you go in, and you spend a day or two just immersing yourself in that system. And then, you come back, and you have a story in your head of how this thing actually works from a front end, and then you can dive into, oh, okay, this is how the app works. And this is what is actually happening, and this is where the data is being stored. And I understand what's going on here. And here's this third party that we're calling, and things like that. So, that right there is key, for me, to understanding, you know, see how our users are using it, and then I can see behind the scenes.

DAVE: There's a fundamental problem in computer science, and I call it the A versus B problem, which is where this system over here, you got A matching up against A, and it works. System B matches up against B, and it works. And you get a bug that comes in. Your trouble ticket is, I did this. I expected A, but I got B. And you're like, okay, should you be getting A, or should you be expecting to get B? Which is the right answer, right? It's like, oh, plus four on the zip code. This piece over here only has room for five digits in the printing label. Don't ever put a plus-four on there. That's a bug, right? Anybody else working with postal codes is going to be like, no, you always want the plus four. Why would you want to throw away data?

One of these is right. But if they don't match, you have to know which one of the two is correct, and it's the context. Seeing a user use it is what, you know, it's like, if this is checked or unchecked, if it's checked, we always do the thing. And if it's unchecked, does that mean we can do the thing, or does it mean that we never do the thing, right? There's that context to it.

MIKE: You know, you talked about sitting in the place of customer service and using the software. I'd take that even further. Some of the most successful onboarding I've seen is when the new person is actively assigned to work with a user of the software. It's not always possible. It depends on the context. But you can have them sit with customer support and help them field calls for a couple of days, or, you know, go out in the field and use the software with the users. You know, actually using that software with real users provides a depth of understanding that I think is almost impossible to get otherwise.

DAVE: I can think of a time when I have been sent to work with the end users that...In 2006, I worked on a system for a year, and I finally got to go sit with the users. And this has happened every time I've sat with users. And I was surprised after a year that this still happened to me. I walked back into the bullpen with my co-workers the next day, and I said, "Guys, we're building the wrong thing." Just half a day with the people using it, and you realize we are going around welding shut every door that you need to access. The way that we're trying to get you in and out of the system is like crawling up and down the chimney. We have built this completely wrong. We need to put a lock on this door and make it swing easily instead of messing up your life, yeah.

MIKE: So, we've talked about a few things: having a buddy [laughs], taking the time to get context, assigning somebody to actually use the software, and, if possible, pairing them with real users. Saying that all of those are important for onboarding. How valuable do y'all think documentation is?

JUSTIN: I wouldn't want to dive into documentation to start off with. I'd want to go to those other things first. Because documentation is great. I love documentation, but without the context, I don't know if that documentation is dated. I don't know if it's, you know, even applicable for the system I'm on. And so, without that context or without asking my buddy, it's almost worse than having no documentation [laughs]. You could be looking, like I said, at outdated stuff, or you could be doing stuff like that.

But later on, when I'm more experienced in the system, I love documentation because I have the context there, and I'm just looking for details, or maybe some other stuff when I already, you know, have a good, solid base of everything. So, yes, documentation, but I don't want to push a bunch of documentation at somebody who just started yesterday and say, "Read all this [laughs]," so...

DAVE: If it's a part of the system that is very static, very stable, and we've been using it for five years, then yeah, hand you a piece of documentation that says, "Start here. When you're done, you will have this. Here's the steps." And that's kind of fun sometimes where you hand that to them and say, "We're trying to improve this documentation. Please go through this. And as soon as you get stuck or lost, come find me, and we'll fix the documentation." That's a lot of fun.

And, again, there's a trick to that, which is now they're engaged looking for the problems in the documentation. And now they're paying attention to the system. Instead of "Memorize these seven things and plug them in," it's like, "Okay, I'm in step three. I don't have access to Postgres. What should I do?" right? "Oh, let me add that step."

MIKE: You know, I think we all wished we had perfect documentation. But documentation is a lot of work, both to create initially and to keep up to date. And I'm not complaining about documentation. You know, any documentation is almost necessarily out of date unless you keep it in lockstep with your changes. Unless any changes to documentation go out exactly with any changes to your software, it's going to be out of date kind of the moment it's written.

So, it feels like there has to be another layer, either you put a huge amount of effort into your documentation, which I think is unpalatable for a lot of organizations because the work is hard; it's expensive, or you have some system outside of the documentation to communicate some of that knowledge. And that's hard. That's a tricky balancing act. Because there's probably things in the documentation that somebody is going to forget to tell you.

So, to ask another question, I asked about documentation: how do you avoid those gaps? And we've talked about the value of partnering with somebody. What happens if you never happen to walk by that hole in the ground? You say, "Don't step in that." [laughter] How do you avoid that? What are some things you can do to avoid some of those gaps in knowledge?

JUSTIN: Document. Oh, wait [laughter]. Find it out and document it. I like what you said, though, when you have your mentor there, and you have your new onboarding checklist, you know, to get permissions for all the things and to get all your environment set up. If you're both doing it together and then you update anything that's missing or, you know, common missteps on that onboarding document or series of onboarding documents, usually, that's really helpful, and it kind of updates itself as you onboard new people. And that way, you aren't dealing with an onboarding document that was last updated in 2021.

So, I don't know if that answers your question exactly, but that, you know, goes back to having your mentor and you going through it together and updating anything that you find is missing.

MATT: And things change, right? Something that was relevant even as recent as, let's use our company for an example, five months ago isn't relevant today, right? Because we're doing a lot of things differently. So, if we can make these things a living document and adjust as we go, and maybe we find a better way to do something that we have documented or a different way that's more efficient, then we can update it and keep that document living. And it provides a lot of value for the next person coming through the line.

MIKE: So, we've got another item in our checklist here [laughs]. Have the new person work with their mentor to update the documentation as they go so that it does become that living document as they're using it. One thing...I still think that sometimes you miss those things, the things that you didn't think to document that everybody just knows. One thing that I've seen among people who've been really successful, a lot of times, they'll say, "The time I learned the most was when I didn't have anybody else to help me, and I had to do it on my own."

And [chuckles] maybe they're at a job where they're the only engineer, or they took over DevOps. You know, whatever the case may be, a lot of times it's when [chuckles] somebody had to take care of things themselves, and there's nobody else to go to. You have to figure it out. And, boy, that burns [inaudible 22:22] your brain.

MATT: Trial by fire.

MIKE: But, you know, we don't want to lay everybody off once a month just to give somebody a chance to do that. That's not a good way [laughs] to run a company. So, we're not going to do that. So, I think that setting up some sort of environment that gives people an opportunity to learn and more of a sandbox is really useful. One thing I've seen for security training that was extremely helpful is we rotated weeks. And every week, somebody would add an insecurity to the application from the OWASP Top 10. And then, the rest of the team, knowing that there was that kind of vulnerability in the app, would look for it and try to exploit it.

JUSTIN: In production?

MIKE: No.

MATT: No.

[laughter]

JUSTIN: Okay.

MATT: No.

[laughter]

MIKE: We built a...We built a...

DAVE: So, they're playing. They're just not playing for keeps.

JUSTIN: Yeah. I was like --

MATT: I believe, Justin, this goes back to when you first came aboard. I remember I was doing the OWASP Top 10. Prior to that, the trainings were an application that Mike actually had hosted on his AWS instance called Insecurity. And then, we moved over to the Juice Shop when I took over. But prior to the Juice Shop, it was this Insecurity app that we did exercises on.

JUSTIN: Oh, that's really cool.

MIKE: The thing about that is when you're introducing the vulnerability, you had to understand it well enough to break the code [inaudible 23:54] to it. And sometimes that's harder than it sounds. Like, the frame will fight you [laughs]. And it's hard to get that in there. And so, you really learn to understand the guardrails and how you can break through them. And then, from the flip side, it's fun for other people to try to figure out what it is you've broken. The teams I work with doing that learn...They universally said they learned more about security working through those exercises than they did in years of trainings because that hands-on makes a huge difference.

DAVE: It makes it alive.

MATT: Yeah, I mean, try adding the SQL injection to Ruby on Rails ActiveRecord. It's not easy.

[laughter]

MIKE: It's not. It's possible, but very difficult [laughs] [inaudible 24:45]

MATT: Yeah, you have to try to make that vulnerability.

DAVE: And you can tell when somebody's up against that because they'll start saying oddly specific things like, "How do I serialize a lambda to the database?" [laughter] Yeah, yeah, whatever you need that for, stop it.

[laughter]

MATT: But, you know, something that maybe I want to touch on just for a second, we were talking about the documentation and the living document. Another thing that this does is, you know, the reason we hire people is because we want to hire smart, good people who are going to provide benefit, right? Hopefully, we're hiring people who are smarter than us and better than us at our job.

MIKE: Probably, yeah.

MATT: So, it also provides them the opportunity to give their insight on the things we do. And they may have a different viewpoint on something like patterns or generally things we do that they may have done differently, and we've never really thought about doing in a way that they have. And it opens that conversation, and it gives us an opportunity to not only help them onboard but to improve our systems as well.

MIKE: I can think of a few cases where a capable person came on, and during the onboarding, they're like, "Well, you know, your test suite is running kind of slowly. What if you..." and, you know, fill in the blank. And, like, "No, that's a good idea. Why don't you try that?" And they did. And now everything works better.

DAVE: We brought somebody on a while back. And a couple of months ago, in architecture, they were like, "Yeah, we've mostly got the database in memory now, and everything is, like, so much faster." I'm like, I'm really glad this guy's here.

[laughter]

MATT: Yeah. And they're going to feel really good about their new job, right? Like, they came on immediately adding value. That's really fulfilling, and it's going to give them a really positive outlook on the [inaudible 26:45]

JUSTIN: I'm glad you mentioned that, Matt. One of the things is to give them a small task or something that they can be successful at in a small amount of time and have them do that thing such that they know the system end to end, whether it's, like, fix a small bug, or here is a small, new feature. Those types of things you could probably do. As a tech lead, you could probably do that in an hour or two. But as a new engineer in a new team, you can give this to them and say, "Okay, here it is. Here is our process. And here's how you do everything. Work with your mentor on solving this issue. Here's something that you could be successful at. Go for it."

MATT: Yeah. Quick wins are important, right? Going back to when I started with the company, it was...I came on, and I was told, "Well, we're expecting you to provide lift within two weeks."

JUSTIN: [laughs]

MATT: I said, "Okay." And then COVID hit. [chuckles] And I got sent to work from home with no training, and it was a little rough, you know. But something that did, for me, was make me really work to provide that lift because I had a goal. And I wanted to say, "Hey, you guys need to see that I'm going to provide value, and I'm going to do it quickly." And it gave me that motivation. So, yeah, I totally agree; giving someone tasks early that they can get in and have a win that's a really big morale boost.

DAVE: I worked at a shop where the development process was you shepherded your PR all the way to production, even if you were on another team, or if you were collaborating across the building. If you submitted a PR, you had to...and that meant deploying somebody else's server, which meant that everybody's deploy process had to be pretty well documented and sort of...like, if somebody else could not deploy your service, you had to stop and improve your documentation and your process, which I think was a pretty great thing. But I sat down on day one, and my mentor said, "We need to have you deploying to production by tomorrow night." And I'm like, "Oh."

They walk me through everything on that first day. And he's like, "Okay." And he pointed me at the...we've got a board here at Acima we call the Scooby Snack board, I think, which is basically just tiny, little things that somebody new could just pick up, fix it, and ship it, right? And it was that. They had a board of, like, tiny, little tasks that somebody could do.

The difficulty had nothing to do with changing this one thing on the website. The difficulty was I got to figure out how to deploy this to production and make sure that I haven't taken anything out and make sure that it all still works. And yeah, being able to focus laser tight on I got to write this. I got to get it through review. I got to get, you know, all the things super, like, clarity. And anytime I got spun off into the weeds, I had that story of, I have to deploy. What is stopping me from getting back on track to that? And that's my next obstacle to solve.

MATT: Yeah. Then you have some purpose. And I don't know about you guys, but everyone in this group today has a lot of experience and years behind us, right? But to this day...

DAVE: It's kind of an old guy podcast today, isn't it?

[laughter]

MATT: To this day, when I start somewhere new, there's some nerves involved. No matter how experienced you are, there are some nerves involved. And I think helping people get those wins early alleviates those nerves and gives them some confidence, and then you can really see productivity out of people once they have some confidence.

DAVE: How do we onboard people continuously? What can we do to onboard Matt, or Mike, or Dave on the new stuff that's coming through or the way we're doing stuff next?

MATT: That's a great question. And I could have used a little bit recently [laughter]. For those listening, I have moved my role here at the company. And there are a lot of things that I'm doing now that some of that continuous onboarding really would have helped.

MIKE: Let me answer that question with a question. Would we expect the process to be any different than it would be for a new hire?

DAVE: I think we do because if we bring you on board to a new thing, we don't sit you down and walk you through all the setup of everything and talk you through, like, you know, "Here's the lunchroom, here's..." it's more like, "There's the database; there's the cluster; there's the deploy. Let me know if you need anything." And, generally, if we're seeing you're...and not even senior. A lot of people that have been, you know, done this more than once or twice know what it's like to be abandoned in the middle of a desert and go, "Okay, let's start walking." You know, a lot of times, we just drop you into a target-rich environment and say, "Good luck."

MIKE: You say a lot of times that happens. And just because somebody can doesn't mean that that's necessarily the best way [inaudible 31:37] about continuous improvement, and not that I've thought about this. I'm thinking out loud here based on the question. What if everybody had a dedicated mentor that when they want to give them a, you know if you wanted to add a question, you knew that you had that person who was there to help you and who is going to give you opportunities on a regular basis to go stretch and do something you hadn't done before. Maybe spend some time pairing with you, or maybe you have periodic times when you go, and you work out on the floor, you know, you go and actually...software. All these things we've talked about, I don't see any reason why they would not provide value ten years in.

MATT: I really, really like that idea. And sorry, Mike, you got stuck with me because I just kind of use you for that all the time.

[laughter]

MIKE: Well, good [laughs].

MATT: Yeah, you know, I was lucky enough to end up on your team. And now that I have ended up in management and you are a director, I lean on you all the time. And I greatly appreciate your support in that. But having someone that you can go to and just ask those questions and will walk you through the things that you've never done it's invaluable.

DAVE: I'm kind of in scan mode. I'm like, how best to refine this? Yeah, I'm just thinking about, like, what I'm going to do on Monday, right? It's like, who do I need to be mentoring? Who do I need to mentor me on some things? Yeah.

MIKE: That's exactly what you got me thinking as well. Like, what can I be doing in my role today to make that effective for the people I'm working with? Maybe I can find somebody to latch onto and say, "Hey [chuckles]. Will you be my buddy and help me out here?"

DAVE: Yeah. And kind of related to this, sometimes it's like, okay, you decide this is what we're going to do. And then, you kind of have to trust the process a little bit, right? It's like we used to do...here at Acima, we used to do skills clinic every single day for like an hour. And it was fantastic. And the skills on the team went just through the roof, and then, you know, COVID hit. And business priorities and things got, you know, rougher, and attendance in skills clinic is way, way down.

I was talking with Tad. He's running them right now. I've had lunch with him today, and I was talking with him about that, and I'm like, "You know what? I have not been trusting the skills clinic process, and I have not been going to skills clinic. I need to start going to skills clinic just for the process of taking time to sharpen and being able to share with other people while sharpening." It's like, "Oh, hey, you know, we're doing SQL right now. You can do this with a sub-query. Have you tried doing it with a window function?" And, you know, people around the table going, "You can do that?" "Let me show you something." Yeah.

MATT: Well, and regardless of how many years of experience we have, everybody has something to offer, and everybody sees things from a little bit different perspective. So, I've learned so many things from what we have labeled as, like, juniors because they're thinking about things differently than I do, you know. I've done the same things for so many years that sometimes you get a little bit tunnel-visioned, and you don't look at things from a different viewpoint. And they really help along those lines and open up your eyes really, right?

JUSTIN: Help keep your skills fresh.

MATT: Yeah, absolutely.

DAVE: And you can be with somebody who's very, very junior, and they are probably thinking, there's nothing I can teach this guy. But what they don't know is that you're sat there going, if I don't learn anything from you, it's because I've failed as a student. I'm going to watch you until I learn something. And, invariably, I learn something amazing when I do that.

I worked with a girl who, halfway through the discussion, I found out she was a lawyer. She was a junior programmer. She had passed the bar in Colorado. And I'm like, "Why are you in here and not practicing law?" She's like, "Because I hate law. I don't want to do law. I want to be a programmer." And I'm like, "Okay." And sure enough, that afternoon, we're typing along, and something came by. It was like TCPA or something like that, and I'm like, "A or B?" And she was like, "It's B. It's B. A is against the law. Do B."

[laughter]

DAVE: I'm like, "Oh, okay."

[laughter]

MATT: Yeah. We had a contractor who was also practicing, the attorney, in a different country. But...

DAVE: Yeah, somebody who shows up with that, you know, they can think.

MATT: Yep. Again, everybody has something to offer, and we all have something to learn.

JUSTIN: So, I got a couple of really quick, rapid-fire questions. One that I've noticed was really good was as a, you know, a person leader, the manager is, like, having regular check-ins with your new employee, like, at the start, especially. Those would probably be, you know, weekly, that sort of thing at least. And then, of course, like, a big lunch meeting to introduce everybody at a restaurant, or something like that, celebrate the onboarding, but also, you know, weekly check-ins. And then, what are you guys' thoughts on a 30, 60, 90-day plan, like creating one for your new employees? Is that something that works for engineers, or is that something that is mainly something that exists outside the engineering world?

DAVE: I've only ever seen it done once, and when it was done, it was every bit as awkward as we all thought it would be. And it was profoundly effective, and I have missed it ever since.

[laughter]

JUSTIN: Wow. That did not go in the direction I thought it would go. I was like, [vocalization].

DAVE: Yap. It was with the first time I ever saw a manager who felt that being a manager was a full-time job and required him to study and learn management. And so, he was literally learning things like, when you have your one-on-one meeting, you have to quickly triage the meeting into, are they looking for training? Are they looking to just check in? Or are they melting down, and they need to vent? Because you have to handle those very, very differently. And if you try to go and fix and train when they're venting, it's going to go horribly. I'm like, I never had thought about that. And this particular person would come and say, "Hey, we need to go do our one-on-one."

And it was just...I'm like, this is awkward. This is dorky. "Okay, Carl, fine." And they'd get up...and we'd go to lunch, and it would start awkward. And then, five minutes in, we're just chatting, shooting the breeze. And we're talking architecture and where does the team go. And I grew a lot. And this was 10-12 years ago. It was kind of middle of my career. And my skills leapfrogged every single month.

That was the first place where I put on, as my personal goals, to lose weight or to be able to run a mile under a certain time. And Carl was very, very proud of me when I put that on because he basically...I said, "If I do good cardio, I'm going to think more clearly, and I'm going to be more effective as a programmer." And he's like, "I think that's a fantastic goal. Put it down. Let me know what your time is in 30 days."

MATT: Interesting. I like that.

MIKE: I think we have rightly done so, talked about things that work well. One final question I want to ask is, is there anything that poisons the process? Is there anything that makes it just work terribly? To maybe illustrate the opposite, right? You know, as to what you can do well.

MATT: Yes, not following through. That's key, right? As people get busy, people get sidetracked, things like that, I think it's extremely important to follow through on the things that you promise to deliver, and not only is that relevant for onboarding. I think it's relevant just in business, in life, et cetera. But, you know, let's say I'm onboarding someone, and I say, "Okay, next week, I'm going to spend two days with you going through x," and I get sidetracked. I don't follow through. That's a really big failure on my part and, letting them down and not giving them the room to succeed. So, I --

DAVE: And it's critical. It's critical at that time, too, right?

MATT: Yeah.

DAVE: Because that one failure is 100% of their interactions with you to date and that set the direction that they're going to expect everything from them. You could never miss again, and they'll always wonder, is this the time that he's not going to follow through?

MATT: Yep. You paint that picture.

JUSTIN: One thing I've seen is when they've chosen the wrong person to be the onboarding buddy. And if they choose someone who is bitter about their current position or is not optimistic, it kind of can make that new person follow that persuasion, which is probably not what you want. So, --

DAVE: It's important to distinguish between bitterness and pessimistic, I think, maybe. Because I've worked with a programmer who just he was very much, like, leave me alone, don't, you know, da da da da. And the onboarding was basically...Our boss, I remember on day one, the very first thing she said was, "That's Terrence's office. Stay off his radar. He likes to fire new guys." I'm like, "Whoa, okay!"

JUSTIN: [laughs]

DAVE: And it was a government contractor. You could play that kind of politics and kind of stuff. And that was really, really good advice. And I didn't follow it, and exactly what she told me would happen to me happened to me at the next layoff [laughter]. It didn't make me bitter. It didn't affect my attitude. It wasn't office politics. It was office sociology. It was just, you know, be aware. That's a live wire. If you plug it into the power system, it'll run the whole city, but if you lick it, it's going to ruin your day. And so...

JUSTIN: [laughs]

DAVE: And she wasn't bitter. She loved the company. She loved her job. But she was very, very realistic about, like, that's awesome, and that's garbage and, you know --

MATT: Pragmatist.

DAVE: Pragmatic. Pragmatism. Yeah, that's exactly it. If it works, it's true. That's pragmatism. If it works, it's true.

[laughter]

MATT: But yeah, we definitely want to avoid people poisoning the well, right? Because it does, it carries over, and it kind of just...it spreads as well.

MIKE: We've talked before about psychological safety. You're bringing somebody in. It's not just code. And this is a critical thing. Software engineering, even somebody who's just starting and they're going to be writing a lot of code, they likely will not spend most of their day writing code, at least not every day. Software engineering is a lot of things that aren't code. It is a group endeavor. And you cannot build large projects effectively in isolation. It doesn't work that way. So, you're not just getting somebody to understand a codebase. You're helping somebody understand and build a culture. And you can't forget that it's more than one thing you're building.

DAVE: And I think I've mentioned this before: my favorite epiphany that I took away from skills clinic is that we think of development as a process where the developer is in the box, and we take a problem, and we put a problem in the box, and the solution comes out of the box. And that's not a programming career at all. The box is where the effort takes place, and we take a programmer at a problem and we put them in the box. And what you get out is a solution and a smarter programmer.

And if you focus on investing in that programmer, they're going to grow, and they're going to get smarter. And if you focus only on just product, product, product, product, product, some people will thrive, and some people they just miss...and it's just bad luck. It's not that they're not, you know, good or hardworking. It's that they got so focused on optimizing the process that they end up...it's like not stopping to sharpen the saw, right? You get so busy creating the output that you never increase your ability to create output.

MATT: I wanted to make a Beyond Thunderdome reference there, Dave. Two men enter, one man leaves.

[laughter]

DAVE: Right. That's right. Two problems enter, one solution leaves. I like it. I like it.

MIKE: To come back to a story, several years ago, I was riding bikes with my kids. And my oldest son was pulling somebody [laughs], one of my other kids. And he was back behind. And he was really having a hard time keeping up, which is unusual for him because of who he is [laughs]; I'll say that. He usually does not have a hard time keeping up. I usually have a hard time keeping up with him.

So [laughs], he was just dragging, and he said, "Man, maybe I'm tired today." But he was just trying to muscle through it, and muscle through it, and muscle through it, and muscle through it." Finally, he said, "Can we take a break?" And he looked, and the bike he was pulling, you know, the trailer he was pulling, the tire was completely flat. So, he'd been, like, dragging a plow [laughs] through and was riding [inaudible 44:31] for miles [laughs].

DAVE: Just pulling [inaudible 44:33] the whole time.

MIKE: Yeah. If you don't take that time to look and make sure your tools are in good order and keep things going, you maybe can muscle through it for a while, but it's not going to work the long term.

DAVE: Tying it back to earlier, that's all about the hunting badgers, right? It's like the great thing that can come out of that is not, oh, I needed to fix the tire. The takeaway is sometimes I should stop and check my equipment. And that's the [laughter] aha moment of it. And that's the difference between having a good job and making a whole career, right? It's like that. You'll come back to that.

MATT: Instead of fixing the flat, prevent the flat.

DAVE: Or just be aware that --

MIKE: Be aware.

DAVE: You know, check your equipment, yeah.

MIKE: Sometimes flats happen [laughs], and you got to be aware of that.

JUSTIN: I think from a security point, the guy that thwarted the recent attack that was going to be on one of the base systems in Linux was checking his equipment because, all of a sudden, part of it was, like, going slower, and it was just a fraction of a second slower or something like that. But he went in and, like, discovered the bad code because he was checking his equipment.

DAVE: I've never believed so strongly in the a billion eyes makes all bugs shallow [laughter] from Linus Torvalds from the '90s. I'm like, okay, I believe you now, Linus, so...

JUSTIN: [laughs]

MIKE: Any other final words?

DAVE: Be good to each other. Do code reviews.

MATT: Yeah, right. [laughter] Our interactions are always a pleasure.

JUSTIN: Gentlemen, it has been a pleasure. Yeah, thank you.

MATT: Yes.