Soft Skills Engineering - Episode 398: Tech lead for contractors and how to detach my ego from my work

Episode Date: March 4, 2024

In this episode, Dave and Jamison answer these questions: How do you mentor a junior-level contractor? My company has been hiring a lot of contractors lately. Sometimes they hire out a full team form the contracting shop to build a particular feature. Other times, it’s an individual developer, but with the same general mandate: implement some specific set of features from our backlog over x number of months, then move on to the next project somewhere else. Generally this happens when we have extra budget that needs to be spent for the year, etc. It works well enough when the contractor is experienced and able to self-direct and focus on just getting the work done; but sometimes the contractor is less-experienced and needs lots of guidance and mentorship. Hiring and mentoring a less-experienced full-time developer is a long term investment. Over time that person will become more productive and hopefully stay with the company long enough to provide a net benefit. But when the person is only contracted for a short time, it seems we’re effectively paying the contracting agency for the opportunity to train their employees for them. As a senior engineer / tech lead, should I devote the same amount of time to mentorship and growth of these contractors, or should I just manage their backlog and make sure they only get assigned tasks that are within their ability to finish before the contract runs out? Hello, I have a really hard time not attaching my identity to my work. I know I’m not supposed to, but i really take pride in what I do and i feel like if I don’t, my performance would take a hit. But where this really bites me is taking it really personally when things go wrong (like when a customer submits a bug report and I find that it was something I wrote, or when I take down prod and have to involve a whole bunch of C suite people to address and post mortem the issue). I understand humans make mistakes but it eats me up so much inside every time. I know all these things but I have a hard time really internalizing them especially when things go south at work. What are some practical ways I can train myself to approach things without emotion?

it takes more than upgrading from a standing desk to a cartwheeling desk to be a great engineer this is episode 398 of the soft skills engineering podcast i'm your host jamison dance i'm your host dave smith soft skills engineering is a weekly advice show about all the non-technical things that go into the technical field of software development and i think i have a specific image in my mind of what a cartwheeling desk is you know those like circus rings where they yeah you kind of like spread your arms and legs out in them and roll around yeah if you're good you somehow don't crush your fingers right no way i don't understand that's that's somehow there's a desk there and then that's a cartwheeling desk that's exactly the image i had except it's mounted inside

one of those like nasa three rings spinning around oh yeah yeah yeah so it's like can you find this bug and not vomit at the same time maybe this maybe this is actually a really good idea it's like it turns out the human brain can find bugs when exposed to different vectors of gravity ah yes it keeps you from getting stuck it helps you think outside the box more exactly when your brain is scrambled if a whole industry of agile consultants can sell their services we can sell this product yeah and we will next episode look out for it this episode is sponsored by red hat compiler an original podcast from one of our favorite companies that explores all tech topics big small and strange we'll hear more about them in the middle of the show but go check out red

hat compiler all right jameson you want to thank our patrons i do i want to thank dan from drone to play chase w norton type hero.dev never is not just a crater on mars flamingo emoji i like chicken i like liver miyamix miyamix please deliver trash panda the computer science book.com valentina datafold santa hopar kenzie dodds i lost my place sorry jenny kim owen chardell craig montland the stochastic parrot patreon.com we're hiring ira chan question mark jonathan king web tau awesome end-to-end testing the unsettling nature of not knowing the content at williamangel.net travis braden canes john grant and cody sale thank you thank you so much we appreciate you and you appreciate us

and that's why we do the thing we just did that's true if you want to join this group who have at times been called illustrious

and if need be can be called upon to do a heist much like a crew um then you can go to

softskills.audio and click support us on patreon any amount will get you an invite to the slack team and more will get you more

and and go find out what it is yeah you'll figure it out Dave, would you like to read our first question? Yes, I would. Let's see here. This comes from Senor Dev with a tilde over the end. Senor Dev, how do you mentor a junior level contractor? My company has been hiring a lot of contractors

lately. Sometimes they hire out a full team from the contracting shop to build a particular feature. Other times it's an individual developer, but with the same general mandate, implement some specific set of features from our backlog over X number of months, then move on to the next project somewhere else. Generally, this happens when we have extra budget that needs to be spent for the year, etc. It works well enough when the contractor is experienced and able to self-direct and focus on just getting the work done, but sometimes the contractor is less experienced and needs lots of guidance and mentorship. Hiring and mentoring a less experienced full-time developer is a long-term investment. Over time, that person will become more productive and

hopefully stay with the company long enough to provide a net benefit. But when the person is only contracted for a short time, it seems we're effectively paying the contracting agency for the opportunity to train their employee for them. As a senior engineer slash tech lead, should I devote the same amount of time to mentorship and growth of these contractors? Or should I just manage their backlog and make sure they only get assigned tasks that are within their ability to finish before the contract runs out? I can tell you, if you're in the United States, legally, you have to, you better not be mentoring them. Or they can claim they're actually employees of your company and then able to receive benefits.

Right, then you owe payroll taxes. Yeah. So if you don't want to mentor them, see if you can find somebody in legal or HR and mention this. Say, hey, we've got these contractors that seem to need a lot of mentoring. So you've been spending a lot of time with them.

Suddenly you don't have a contractor problem. Is that what you're saying? Yes. Yeah, I think so. Yeah. I mean, contracting is sort of like the cold, uncaring face of direct transactional kind of business stuff where you're really supposed to be paying someone for value even much more directly than as an employee, where there's a little bit of kind of responsibility for long term. Mm-hmm. So I feel like I would not want to spend my time where it would not return to me, I guess, even though that feels kind of callous to say that you should not have to train up contractors. You should need to tell them how your specific system works. But if you have to

teach them new skills, then you have hired the wrong contractor. That's a good point. I hadn't thought of that, but it's like you don't really have a mentorship problem here. You actually have a contractor selection problem when the company chooses the wrong people. I mean, one of the advantages of contracting is that, as a buyer anyway, is that you have this supposedly well-trained talent pool to choose from who can get in, get paid, and get out. And if you don't have that because they're not getting the job done, then maybe you should get a discount, I guess, on the contract maybe they should pay you yeah i don't know if a discount is worth it it's what if you make a side away from oh yeah a contractor trainer yeah what if on the side you make you sign an

agreement with the contracting shop to say look i will mentor your people and i promise they will end up better engineers that you can charge more for and get more business at the end but you're gonna have to give me a kickback for all this mentorship i'm doing that sounds so illegal outrageously illegal but that's all i have to say about that i don't know i can't think of anything else yeah i i don't know i i have worked with contractors and not treated them as contractors and nanana it's too late you can't get me i've escaped but it always felt gross to like shun them and just i don't know airmail them like requirements and and look away when they looked me in the eyes and stuff but that is what you're supposed to do technically and with those

folks it was sort of like we all kind of knew the deal and it was they were experienced they were experienced contractors i i knew they weren't gonna take advantage of the situation and it was just going to make them more effective to know more and have more context but i i did not have to teach them how to program. It was just normal team stuff like, I don't know, talk to this person to learn how to debug this specific system or stuff like that. Yeah. And this specific system that only we have at our company that I could never expect a contractor to know about before they joined. Yeah. Yeah. That all sounds really reasonable. And I was kind of thinking the pragmatic answer to this question, like if I was a business owner here, would be to create really

robust onboarding documentation so that you can scale this process because essentially what you have here is a repeating business process that requires a human touch every time it happens and whenever you see a repeating business process it requires a human touch i should make an acronym of that by the way repeating business process that requires a human touch whenever you have one of those you need you need a scalable solution and documentation to me is like the first tool i would reach for is like super robust very comprehensive documentation that explains to them all the ins and outs they need to know so that anytime they reach out to you with a question you've got a url like ready to go in your holster like url to the ducks you know for everything they

ask yeah the acronym is ribbit to heretate eating business problem that that where's the that requires human touch there you go what the r was for the sign of a great acronym is when you you can't pronounce it or remember what it stands for it's like the perfect acronym this is how movements form dave can you imagine i can't i can't pronounce it because i'm unfamiliar with its ways but soon i will become a convert right after you are inducted then ribbit will flow off the tongue you'll hear it at conference venues echoing in the halls of coffee shops in silicon valley it is i'll tell you it is exhausting to have a revolving door of people that you need to help

ramp up on stuff come in and go come in and go and this is actually one of the main reasons not main, but it was a secondary reason that I left one of the large tech companies was that we had so many people and we were hiring constantly and I would meet with people and they had no interest in getting to know me at all, but I was responsible for ramping them up, getting them to productive. And then I would never see them again. And it wasn't that I was like their onboarding buddy per se. It was just like, even just interacting with other teams, which is kind reminiscent of what this question asker is asking and boy did it wear me down i just it it felt like my the human part of my humanity was gone all i had left was the itty from the cold metallic

robot heart yes that's all that was left it was so rough so i feel this and i think over time i would eventually get demotivated and I would stop really investing in getting these people up to speed. Now, having said that, I work with a team of contractors who are more like permanent contractor. The only reason they're contracting is because they're not in the United States and we are not incorporated there and we do hire through an agency, but they are like long-term, multi-year people. So we treat them like team members, unless the IRS asks, at which point They are definitely just contractors. We treat them exactly as required by all laws and yeah.

But in my heart, and only in my heart and not on my tax returns, in my heart, they are friends and people that I love, who I pick up at the airport when they come to visit and who I invest just tons of effort into. But I got to tell you, if they were changing faces every two weeks because they were in and out i would have a really hard time doing what i do i'm kind of imagining like the grizzled war veteran who's who just is used to seeing these rookies come in and get chewed up and spit out they're like i don't have time to learn your names you won't even be here tomorrow and yeah sort of the the vibe i have so you need to get you need to get crack special forces if we're

continuing this metaphor okay that you don't have to take care of because they're just they're just good and they do things they're just good yeah yeah they don't need you to get to know them and learn the names of their kids yeah yeah remember their faces etc exactly yeah i i mean i do think i would express if this is slowing you down it's possible they this could be slowing you down overall that the value you get out of this person is less than the time spent trying to train them and that means the company is spending money to slow you down it's not even just that you're slowing down yeah i would i would give that feedback and say hey like i'd rather have no contractor than this just short time with a with a pretty junior person that you pay for and don't

get anything out of and i can i can attest from personal experience that engineering management responds very swiftly when you say things like i'd rather pay this person to sit and do nothing than to need my hand-holding constantly because now I'm only getting half my work done and they're not getting any work done and creating problems. I actually said those words once. No, I didn't say them.

I had a coworker who said those words to our CTO at a previous company. And this is after weeks of me trying to complain. You know, I don't know what I said or if I said it very clearly, but we had a couple of contractors like this. They needed tons of hand-holding and when they did finally ship work,

it just created more bugs that we had to go clean up. And so I was like, I complained about this to my CTO, but he did nothing. And then weeks later, one of my more experienced coworkers went to the CTO and said, hey, listen, can we change our policy to just pay this contractor to sit at the computer but not actually contribute any code? It would make our lives easier. And literally the next day, the contract was terminated. And I was like, whoa, those are the magic words. oh yeah so now you know the magic words yeah just say those um i use them wisely one thing in this question that stood out to me was that it works well when the contractor is experienced and able to self-direct i'm like okay great that tells me that you've actually got a pool of people who are

capable of being excellent contractors but what that also tells me is that when you do occasionally pick up the person whose skills don't line up with the job requirements, you can actually point to a baseline of good performance and say, hey, this person doesn't meet the normal standard of quality that we expect from your contracting agency. So please swap them out for someone who does. And maybe that needs to become part of your process is there's a little bit of an assessment period, what I think our European friends would call a probation, but not really like a probation. But the same principle where you say, let's give this person a week on the job to see how they do. And after a week, we'd like an opportunity to formally decline continuing

have them on the project. Yeah. Well, have we answered the question? I think so. And I'm just glad I survived without being ousted as the bad contractor in the podcast. Well, I spent a lot of work training you up, Dave. It's true. You've really invested in me. Hey, Jameson, we've been talking about this podcast from Red Hat called Compiler. I guess people might think we're kind of obsessed with it, and we are. What do you want to tell people about it today? I want to tell them about a new episode I just listened to from Compiler called Warning Signs, which is about some red flags or disasters or bad things that have happened in people's careers, which in some ways is the subject of this show. So it felt like it was

very synergistic. I don't know. There's something about hearing like a good prod is destroyed story that warms my heart. You particularly like those. I love them. Yeah. And the compiler is good at storytelling about engineering. I think that's one of my favorite things about it. Yeah. And let's not miss this opportunity to say how much better they are than us at production quality. if we keep saying it then it becomes like a we're doing we're doing bad production ironically i know we know it's bad and we choose to because we're cool i think that's how it works right but seriously if you want to listen to a podcast about software development from people who

actually know what they're doing and sound great and tell good stories red hat compiler is the podcast for you yep go check it out all right should i read our next question please do this is from an anonymous listener who says hello i have a really hard time not attaching my identity to my work i know i'm not supposed to but i really take pride in what i do and i feel like if i don't my performance would take a hit but where this really bites me is taking it really personally when things go wrong like when a customer submits a bug report and i find it was something that i wrote or when i take down prod and have to involve a whole bunch of c-suite people to address and post-mortem the issue i understand humans make mistakes but it eats me up so much inside every

time i know all these things but i have a hard time really internalizing them especially when things go south at work what are some practical ways i can train myself to approach things without emotion uh yes taking the the human element out again yeah yeah yeah we just we just covered that you gotta grind it off sandblast it off by having a rotating door of co-workers for years just embrace the meaninglessness of your work and stop caring about anything just wake up i it's interesting that you say that because i was just thinking about a co-worker um at a previous job we were kind of uh we're just chatting one time and both said that

part of what we were struggling with is that it was hard to care because of some some attributes of the environment that we worked in but caring was part of our part of what we were good at and if we didn't care then we would be bad like we weren't good enough at the job without caring to make up for it yeah so we were wrestling with the same a similar problem of like if i just don't care then what i'm not gonna do is as good of work that's a good point that's really interesting um i'm also we never solved that yeah i don't know neither of us work there anymore i think so oh wow that is a solution in one way so you're saying find a place that what makes it easier to care that yeah it's easier to to care yes oh wait now i know what

company you're talking about and i felt the same way about a company i left at around the same time it's hard to care because we didn't have we couldn't it was hard to make big impact because the company was so huge yeah is that your situation too uh yeah yeah that's certainly part of it part of it yeah um i i'm also a heavy carer maybe you could call me a care bear i don't know use the label you want but you're more of a care panda which is a kind of bear oh shoot a care kangaroo i think was the word you were looking for yeah yeah and i i have a way of uh dealing with this kind of situation as well which is that you know i take a lot of pride in the work I do. And, and I actually do tie my ego and my sense of self-worth to the quality of the work

that I do. You know, a lot of people say, don't do that. But I think what they really mean is don't get so tied up in the details of your work, like the way you indent your code and like, that's your identity. It's like, no, no, no, no. Put your identity, put yourself sense of self-worth in the value that you produce for the purposes that you produce them for the users who use your stuff. Make it about them and their outcomes. Great. Okay. So what do you do when things go really wrong? Like when you wrote a bug or you took down production and now you have to go in front of a bunch of leaders and tell them that you took down production. Well, here's what I do. I double down on the caring thing. And I say, all right, I care so deeply about this. I'm going to

show you that when I make a mistake, I produce the absolute best post-mortem documents you have ever seen. I uncover every stone. I talk about every eventuality. I write a four-page FAQ that no one will read, but they'll look at and go, holy crap, this guy's thorough. And I give people- With a three-page summary of the FAQ. Exactly. And I show people my caring through my response to my mistakes. And I got to tell you, I actually had lunch with a former CEO of mine just a few months ago, who I worked with for a couple of years. And one of the things he remembered the most about working for me was these incident reports that I would write after something went wrong. And I'm like, look, he knew I was

responsible for this stuff. I was the head of engineering at the company. And so, he loved how transparent I was, how I would list every mistake I made and what I'm going to do to fix it and just all like the graphs and the diagnosis and what was the customer experience during this time. So, I really doubled down on it and it paid dividends. He was super appreciative of that. I think I was going in a similar direction as you went with the post-mortem piece where if if you wallow in the the failure and the missed expectations and what everyone will think of you that's that's no good that'll send you to a bad place but this is a a great opportunity to learn stuff and that's something you hear a lot in kind of reliability culture safety cultures like kind

of resilience engineering that space they they geek out over stuff breaking because then you get understand how things actually work right so you've uncovered a failure in the system or in the model that people have of the system so one way that you can maybe get over this a little bit is say like awesome i get to learn something to learn something about myself i don't know i i wasn't careful enough with this bug and why wasn't i and dig into that and figure out what what could you do better next time so it's like a chance to get some lessons and i think if you show that That's what you were talking about, Dave. If you show you're not just going to be groveling, apologizing for it, you're going to fix it and get better. I think that anyone worth working for will be pumped about that response to something going wrong. Totally. Totally. Yeah. I don't know. I can't think of a better answer than that, which is when you mess up, which is inevitable, then just double down on how much you care and the pride you take in recovering from the mess up.

So at first, I thought you were going to say, when you talked about it before, I thought you were going to say double down on how it wasn't actually a mistake. Just don't admit. No, prod is up. The database has not been deleted. I don't know what you're talking about. Yeah, it's all there. I see all of the data. I know you can't look at my screen.

Yeah, no. You're looking at staging. No, I'm not. That's a good point. And actually, this is a little bit of a problem I've observed in others. I mean, obviously not me and no one listening to this podcast or you, Jameson, whatever. Isn't it wild how easy it is to see how others have lots of problems? Oh, yeah.

I mean, this is all about your friends and your co-workers. Anyone who listens to this podcast knows that this is mostly about other people. And it is tempting when you care deeply and take pride in your work. It is tempting to sweep issues under the rug or hide your mistakes. but I assure you that the same heart that takes great pride in doing good work will be offended and crushed by hiding that and oh man it's just not a good plan it basically leads to a world of insecurity where you feel insecure you're not confident you always worry that someone's going to out you honestly it's kind of a path to imposter syndrome you know

it's kind of imposter syndrome is actually kind of reinforced by hiding things about yourself that you don't want other people to know and when you instead you put your your mistakes out on display for everyone it's one of life's great paradoxes but boy does it build confidence it really does it's done so for me it's also so much easier to not have to pretend like things are fine when they're not yeah like all the living a lie like what details did i say to who and when yeah keeping my story straight yeah don't recommend it yeah because people will find out And then if you thought people disliked you for making mistakes before, wait until they find out that you made mistakes and covered it up. It's like the heinous.

Cover up is worse than the crime. Isn't that a saying sometimes? Oh, 100%. It almost doesn't matter what the crime is if you covered it up. Yeah. Then you lie to the FBI about the crime and then that's how they get you. That reminds me of a, oh, what was the guy's name? Was it Norm MacDonald?

Not Norm MacDonald. The comedian who passed away a few years ago. Oh, yeah. Norm MacDonald. Norm MacDonald did pass away a few years ago. That was him. I'm not going to say the joke on the air. It's not the most appropriate joke, but if you want to go look at it, it's exactly in the same theme of the cover-up is worse than the crime. Yeah. I thought what was bad about it was the hypocrisy. And he's like, I thought it

was the crime. It was honestly a real slap in the face for me. I was like, oh yeah, we get so caught up in this cover-up thing. And it's like, what if you murdered someone? What's worse, the murder or the cover-up like probably the murder like in this case yeah probably not the hypocrisy of pretending like you didn't murder someone exactly what a hypocrite i mean if he had killed him and got away with it and then not lied about it you know then maybe i'd be okay with it but the fact that he lied about it an honest murderer oh man a straight shooter at least he's true to himself yes uh don't be that guy i guess don't don't i mean the thing is uh when you are going to eventually murder your production systems but it'll be manslaughter

because it's unintentional and the sooner you come clean about it the better off you'll be and the hypocrisy is worse in this case it actually is it actually is yes so true yeah you you are unlikely to get fired for deleting prod you're way more likely to get fired for deleting prod and not telling someone because you were scared that you would get in trouble oh yeah so true and you are way more likely to feel good about yourself for doing an excellent job with a post-mortem the same level of intensity of an excellence you deliver when you write your code apply that to the post-mortem you're not just a code writer and And I think maybe this is the thing the question asker needs to hear, is that writing code

is just one tool in your engineering tool belt of delivering value to your users. And there are many, many other tools you need to get good at. And one of them is writing postmortems, process improvement so these kinds of things can't happen in the future, large scale fixes, systems thinking to fixes to prevent mistakes like this. all of these things will actually produce so much value and sometimes there's no code involved sometimes you just write a bunch of jira tickets for other people to fix stuff yeah and now you're on your way to management a life of jira ticket excellence yes all right have we answered the

question well i think so good luck best of luck i'll say it again it's good that you care because yeah it it it can make your work feel more meaningful so this is the problem is a consequence of you caring and and caring can be good that's right it's a blessing and a curse yeah all right what could people do if they want their own questions answered dave if you care enough to get your question answered and you want to just test us to the limit go to soft skills.audio and submit the most challenging question you can think of maybe you want us to live calculate the one millionth digit of pi we'll do it just put it in that form and we will eventually do it you can leave as much personally identifying information as you want or as little as you want we love

getting your questions every week and this forum actually doubles as a feedback form this is a function of us being too lazy to create a separate form you can go fill out the ask a question form and don't ask a question tell us how we did answering your question and we'd like to read some of those on the air we only occasionally get these and i think it's because most people listen to one episode and then never, ever come back again. But if you do happen to leave feedback, we'll read it. We love hearing how things went. Sometimes people write in with answers from years ago and say, here's how it went. Once in a very rare while, they say it went exactly like you said. And most of the time they have amazing catastrophic stories of doom and bad luck,

which is also really fun to read about. So please share. Yes. Thank you. Thank you so much for listening. We will catch you next week. We'll be right back.