Soft Skills Engineering - Episode 212: Turnover and self-inflicted complexity

Episode Date: June 1, 2020

In this episode, Dave and Jamison answer these questions: I’ve been working at a big software company for two years. Since joining, 10 people have left my team, which is more than 50% of my team. Usually it’s the experienced developers who leave either for a different team, a different role or a different company altogether. The latest departure of a peer who I’ve been looking up to as a brilliant developer has been affecting my mood quite strongly. On one hand, I should be glad that I’m becoming a more pivotal member of the team, having moved up in the “seniority chain”. On the other hand, I’ve always believed the saying: “If you’re the smartest person in the room, then you’re in the wrong room”. Should I be concerned about this turnover rate? Is it considered normal? Why am I feeling different about this last departure than all of the previous ones? I am the tech lead on a team at a large tech company. One of the developers on our team has consistently struggled to meet deadlines and project deliverables. He frequently seems to invent his way into impossibly complex software problems. Additionally, he also seems to lack the ability to focus on a single thread, and tries to tackle diverse kinds of work in parallel. I’ve tried to help mentor and coach him, advising him to stick to one problem at a time and try to raise his hand and has for help before he backs himself into a hermeneutically sealed NP-hard problem — but I haven’t had much success. I wanted to see if you guys had any advice. Thanks a million!!! Actual study showing actual results that we actually linked in the show notes this episode: https://radford.aon.com/insights/infographics/2017/technology/q1-2017-turnover-rates-hiring-sentiment-by-industry-at-us-technology-companies

it takes more than balancing parentheses to be a great engineer this is soft skills engineering episode 212 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers about the non-technical stuff that goes into software development unlike balancing parens i can only balance five parentheses because that's how many i have 10 fingers i just gotta you could say i could balance 10 but i don't know that algorithm there was a hilarious story in our slack community about this topic which is that a group of friends were doing a gift exchange where they could only give gifts that the other people would hate and one of them was taking a class in scheme and so the gift they received

was several printed pages of nothing but parentheses with a single mismatched paren. That's beautiful. It's beautiful. You could, this feels like a really weird targeted Instagram ad I would get or something like that. Like this beautifully framed, printed, just poster of unbalanced parentheses.

Just barely unbalanced. Yeah. People could stare at that for a long time. It's like the Y Combinator, but there's one missing paren so good well it's not what this is about nope should i thank our patrons i think you should okay thank you to the fine folks who are supporting the show at a level where we shout them out every single week thank you to braden canes dennis bogdanov evgeny sladkowski john grant luke bayliss microconfig.io nick hathaway nick cantar philip john basile ryan

real mccoy the agile ventures charity sean stanley tactical radio stephen armand lee taurus haruk travis and bin lock thank you to all those folks and everybody else who has supported the show you help keep us going you help pay for the expenses you help make our day bright yes and if you donate any amount of money by going to soft skills.audio and click support us on patreon we will invite you to our slack cult which is what we call our slack team because it feels weird to call it a team because we don't have uniforms although lots of cults have uniforms yes why have we missed this opportunity yeah it's really tongue-in-cheek though because cults don't say they're cults that's true so we're outing ourselves as not a cult i guess anyways we'll invite you to

the slack thing you can chat with fine folks hear these funny stories firsthand that dave just mentioned about uh balanced parents and i learned stuff i genuinely learned things from reading the discussions that happen in that slack it's really good yeah it's great i want to share a follow-up comment we got from a listener about the episode 209 about being a glue person on a team here i'll just read this ah it says regarding your episode about a glue person i had such a person on my team last year the team had two testers four developers a product owner and a scrum master but since the glue person left we have had fewer conversations and almost no non-work related conversations we had an after work discord channel but a week after the glue person left no one was there to talk

Since then, everyone from our team has transferred to other teams in the company or resigned. Whoa. Whoa. That person was literally holding the team together. Yeah. They were like a foundation person. Yeah. Or really, really good glue. Just like covered in glue. It is weird how changes to groups are not just, I'm trying to think of a way to say this that makes sense. Subtracting a person doesn't just subtract like one proportional amount of like conversation or camaraderie or something. Like they're not, I don't know how to say it they're not linear yes like the group dynamics change quite a bit definitely not one to one like one conversation unit to one person yeah and it could be for better for worse in this case

it sounds like it was for worse yeah sometimes when one person leaves the conversation actually improves yeah suddenly everything's great it's the anti-glue instead of it's one person unit better whatever that is yep cool thanks for sharing that yeah you want to read our first question i certainly do this is from an anonymous listener i've been working at a big software company for two years since joining 10 people have left my team which is more than 50 of my team usually it's the experienced developers who leave either for a different team a different role or a different company altogether the latest departure of a peer who i'd been looking up to as a brilliant developer has been affecting my mood quite strongly on one hand i should be glad that i'm

becoming a more pivotal member of the team having moved up in the seniority chain on the other hand I've always believed in the saying, if you're the smartest person in the room, then you're in the wrong room. Should I be concerned about this turnover rate? Is it considered normal? Why am I feeling different about this last departure than all the previous ones? 10 people in two years, more than 50% of my team. Yeah, that does sound like a lot. I'm trying to think through the past two years on my team. I don't know. I can't do math on the air. That sounds like a lot. So I did some research for actual information instead of opinions. And I found a link that we'll put in the show notes now we have to because i said we would okay this is a study by this

radford group that maybe if it means a thing to you you know who they are i don't know i don't know who they are i haven't dug into the sources of the data but they made an infographic so i trust it it says that the average yearly turnover in a software company is 22 percent 15 percent of that is voluntary seven percent is involuntary so voluntary is like you quit involuntary is maybe you die but most likely you get fired like literally hit by a bus yeah or laid off or whatever okay so 50 in two years sounds much higher than well no it doesn't actually sounds normal it's six percent higher than this study from 2017 that i haven't fact checked yeah i mean it's six percentage points but it seems within reason yeah i don't know like you're

in the ballpark plus or minus you're in the ballpark now if it's all senior people there there's a slightly different story there perhaps and this is company-wide instead of team-wide so i don't know maybe it varies from team to team so don't worry about it the end problem solved so so this is like people leaving the company yeah this statistic i quoted but the question asker is talking about some people leave to other teams or change roles and that's they're still in the company right so it's sounds like they could be doing better than the average if if enough people have stayed within the company but just moved to different roles there are some companies that really encourage internal movement like in general companies like it because they think that

it's an escape valve instead of someone quitting they stay at the company and you get to keep all that institutional knowledge but they still get some of the benefits of like change of scenery and right avoid some bad things that happen on their old team or whatever like so companies generally like it when people move around but i feel like i've seen some companies that every six months they'll just like blow up all the teams and scramble everything around like they they have some practices in place to encourage it not just say you can do this if you want there's like a clock that sits next to your desk that's like counting down certain number of months until you have to leave yeah or or like i feel like there's a whole genre of tech adjacent conversation that's

like rumors about big tech companies like rumors about fang companies a friend of mine who worked at google knows a friend who did this thing and then it gets repeated enough times and suddenly becomes enshrined but i've heard that at some of those fang companies engineers are very empowered to switch teams whenever they want they can just basically like go to a different team and start working on that team and it's sort of a i guess an incentive for managers to try and attract engineers instead of like allocate people from the top down so the point of all this is saying like it doesn't seem inherently weird that people would leave the team over a period of time yeah but it can it be a little disconcerting when you see it happen on your own team i think so yeah i

think i feel like i've been in the same situation a few times where there's someone who in my head knows everything they built everything they like this core essential part of the team and they leave and i think how will we function without them yeah sometimes it's also related to relationships i have with them like maybe i really like hanging out with them in every case though things have kind of been okay i mean there's still differences but i found that i often overestimate how essential people are yes to continued operation of a team how irreplaceable they are yeah and and people generally step up and there could be some rocky times but in general i've actually found that most of the time the team ends up better off when there's not this this person carrying all the load

for everybody else oh so you're referring to specifically the case where like a particularly high value team member leaves. Yeah. And I have counterexamples in my head, but most of the examples in my head end up spreading the responsibility out and empowering people to do things that previously were like inadvertently hoarded by this one person. I mean, in my case, obviously I'm a counterexample. Every company I've ever left just went down in flames within days. Several jobs ago, the company that I left, it lasted a few more months, but it drastically changed pretty soon after i left and i felt bad for all the people that were affected but there was a little bit of like a bump to my ego to think i was the cool guy that walked away from the

explosion yeah i dropped my tools and the machine broke down some people just want to watch the world burn yeah is it considered normal so should i be concerned maybe is it considered normal it seems normal ish why am i feeling different yeah that's a question i want to answer why do i feel different about this one i'm trying to think like was the person who left a hollywood celebrity you had some kind of star powered infatuation yeah did you call yourself a stan of that person wait what are you familiar with stan culture dave no oh this is gonna be another regular installment of jameson explains today's youth to dave yes so in the past you could be a fan of somebody you might like tina turner's music or something

okay nowadays being a fan is over you have to be a stan there is a eminem song where there's a character named stan who is like a crazy obsessed fan i think i haven't listened to the song in forever maybe murders them i don't know but he's like creepily obsessed with with eminem okay and that name stan rhymes with fan and kind of became co-opted to like obsessive fandom of somebody okay so like i don't know ariana grande has people who stan her it's a verb and a noun right of course of course it is and like k-pop stans they they exist people who just like love k-pop or love certain k-pop groups like is it considered a negative thing to say i'm a stan of so-and-so no it's it's like it's showing your devotion to that it's like this is how much i like it

sometimes people use it ironically too to say like standing these pickles i got from this jar or something i don't know not ironically who even knows what irony means i don't know what that word means you're not alone they use it hyperbolically but that's a that's a common form of interacting with celebrity today and so to bring it back to the podcast soft skills engineering where we talk about all the non-technical parts of your technical job yeah perhaps you are a stan of this person ah oh got it way to bring it back now the circle is complete yeah dave knows more about youth culture thank you i'm a big stan of what you just said uh i really want to hear i want to be a fly on the wall when you use this in a conversation with your daughters oh yeah don't

worry i've got i've got several teenagers who will be quite happy with my i'm sure accurate usage of their lexicon boy honey i really stand this grade you got on your on your music exam or something like that like okay i'll let you know how that goes anyway yes so maybe you were a big stan of this person i mean obviously you were yeah yeah i mean if you worked with beyonce and then beyonce left to a different company it would be understandable that that would affect you a lot boy you can't say understandable without stan i'm thinking that this might have less to do with the person who departed and more to do with the seniority vacuum that you're staring down right now that that is like about to engulf you it's

like all these senior folks have left and i'm starting to feel kind of heavyweight like all these folks that i used to depend on every day now it's me so they the question asker explicitly mentioned that if you're the smartest person in the room then you're in the wrong room that feels to me like they're not worried about can i handle the weight of being looked to for ideas or answers and more like am i learning if i am now pretty senior on this team i have no more mentors continue to develop yeah yeah i've found that my career often goes in cycles and there are kind of distinct phases where maybe i really gel with a particular person or particular team and then they leave or the team changes or something and then i work with other people and it's it's not

horrible or anything but it's just like oh this isn't quite the same as that previous phase but it's not always like that it's not every single second i've ever spent at a job i felt like oh there there's this brilliant mentor that i get along with really well and and just feel like i'm constantly learning from them but i think i learned stuff from those periods too it's just different things yeah you learn stuff from your own direct experience usually by making mistakes yeah exactly yeah like if you can't go ask a smart person what they would do in this situation then you get to figure it out yourself and yeah like you said dave you might mess it up but you'll certainly learn stuff you certainly will so you might have just entered a new phase of your

of your tenure there on that team you may have entered your chrysalis now yeah soon you'll be a butterfly before you were a grub it's the beauty of uh yeah why do why do we always talk about like caterpillar to chrysalis to butterfly why don't we talk more about maggots turning into flies that's the beautiful transformation that i want it's so beautiful the circle of life larva to mosquito larva developer to mosquito developer replaced junior and senior i think i think in this kind of a situation there is a temptation to kind of chicken little which is a reference that means run around like the sky is falling because all these people are jumping ship like the rats are

swimming away from the sinking cruise ship meanwhile you're left to rearrange the deck chairs on the titanic i don't think that's necessarily the case here you know there's I don't know. It's hard to say, but I would probably reach out to some of the folks who have left and try to get a sense for why they left this team. That's particularly easy if they're still in the company and they're willing to share with you. Actually, it's just as easy sometimes if they're out of the company and sometimes they'll be more honest in that situation. But I would probably lean into this newfound autonomy and say, look, I am becoming the senior person that these other folks can depend on. Now I'm going to flex these muscles and learn

how to be the person that more junior people need and having just been i'm going to assume having just been a junior person and more junior you are very well poised to empathize with these people and help them out so i think this is this is an opportunity in disguise it's also an opportunity to kind of try out some of your ideas that may have been harder to to do when there were other people that had a lot of seniority there yeah it's not i've even seen this where it's not like people will say no if you say hey can we do this thing it's just there's just like not room in the team's collective mind to consider trying ways of oh words please edit that out there's there's not room in the team's collective brain to consider other ideas if if they're just like really anchored

by a few senior people who think this is the right way to do things or don't even see a problem that you might identify right dave you said reach out to all these people that have left the team if they don't tell you then it might be you if nobody tells you why they left the team they say oh no reason you know other opportunities yes to work with not you exactly well have we answered it i think so good luck yep best of luck dave please read our next question okay this comes from an anonymous listener who says i am the tech lead on a team at a large tech company one of the developers on our team has consistently struggled to meet deadlines and project deliverables he frequently seems to invent his way into impossibly complex

software problems additionally he also seems to lack the ability to focus on a single thread and tries to tackle diverse kinds of work in parallel i've tried to help mentor and coach him advising him to stick to one problem at a time and try to raise his hand and ask for help before he backs himself into a hermetically sealed np hard problem but i haven't had much success i wanted to see if you had any advice thanks a million so okay time for me to talk about things i don't know on the podcast np complete is like isn't that some class of problems can be reduced to oh no it's the wrong show it's been so long since i talked about this it's very simple it's the class of problems that can be reduced to inverting a binary search tree on a whiteboard

in an interview context aha so there's something about like reducing problems to other problems that proves that they're also np complete yes this person has the opposite problem where they can reduce like p problems to np problems they can reduce like move this button around to like solve this traveling salesperson yeah yep so you have to find automatically the optimal way of placing this button by visiting all the different dom nodes in the best order or something like that that's right oh my gosh knapsack is the knapsack problem np complete or np hard i i don't remember i don't think so oh man i'm just remembering like cs 235 it's been a very long time yes yeah well sounds like they might be doing some resume driven development

oh actually maybe not this is this might be like thesis driven development puzzle usually resume driven development is more focused on like buzzwords and yeah yeah specific technologies than like what is the coolest most researchy way i can solve this this is like entertainment driven development yeah like yeah i know binary search might work but what about trinary search i just can't stop thinking about trinary search trees those are sort of like bee trees i guess right man i'm so out of my depth here i feel like i need to go crack open a book now so i can i can make sensible jokes about computer science topics instead of not sensible jokes about computer science topics have a nice weekend oh you know i will now so i'm assuming

that this person is relatively junior these feel like taken together these feel like problems of seniority like lack of focus on a single thing combined with like getting really rabbit hold into hard ways of solving problems that don't necessarily require those hard ways does that seem reasonable to you that they might be more junior oh yeah for sure quite possible so one answer is like time just they just suffer through the the consequences of getting rabbit hold on it's not just rabbit hold rabbit hold is like focused on a thing yeah they're like whack-a-mole hold it's the squirrel or the dogs in the movie up distracted by looking for squirrels yeah squirrel but if they were like inventing robots for each new squirrel they saw because they don't

just run over there they're like now i will craft the perfect technically complicated and very labor intensive solution for squirrel and then they go and like do another one yeah that's exactly right i think we have two problems here in my not so professional opinion i would diagnose two syndromes the first one is over engineering where you take simple problems and and find very complex solutions for them which some engineers just love to do and the other one is distraction which is not exercising discipline in staying away from other problems until you've solved the problem in front of you and combined oh scary do you tackle them in a certain order do you feel like one is worse than the other how do you handle both of them well i think the distraction problem is

probably the easier one to tackle because that can be done with yeah habits and just little mechanisms or maybe with a check-in process where you know and frankly this is something your manager is probably very aware of. Seeing that this person's having a hard time delivering, they're going shallow into many problems, but not going deeply enough into any one problem. And that will probably manifest in the form of weak delivery numbers or lower than expected output. And it's your manager's job to coach people through this. But over-engineering is harder. It is much harder, I think, to address when a person has a tendency to do that. Oh, man. I mean, almost the best thing you can hope for is to point out to them that there is a simpler

solution to the problem. But even then, I don't know if that helps them to jump to the simpler solutions in the future. It's also one person's over-engineering is another person's engineering. True. There can be a lot of context for what over-engineering is. And if you're relatively junior, maybe you've heard that like, I don't know, there's certain class of problems can exist, but you don't have the context to know that it only occurs in these like very complex systems under these really intense traffic loads and you just think like my little i don't know hello world echo server now has to handle back pressure or something right right so some of it could be well intentioned but based on maybe lacking some of the context or some of the constraints

yeah that might be one way of tackling this over engineering is saying like here are the properties that need to exist in the solution when you're done. And here are the ones that don't. It doesn't need to be resilient to like Europe going offline or something like that. But maybe it does, you know? And it's like, let's be clear about that. And I think in my career,

I could probably be accused of under-engineering most of the time. Like I lean towards simpler solutions that don't address future problems. And what that means is that a lot of times my software fails when new situations come about. But the funny thing is what I have seen from over-engineered solutions is that that software also fails because all of the things that actually happen to make the software fail are the things that they didn't anticipate anyway. And all the things that they did anticipate and engineered for never happened.

So anyway, the point is all software fails. It is hard to predict the real world. Yeah. Yeah. That's the part where I wonder if just time will grizzle this person, will make them realize that all this extra effort they spent on optimizing the assembly for the sorting algorithm didn't help them when, I don't know, somebody messed up the certificates in front of their site and it went down. Yeah, I think if you are this person's mentor, I think it is actually a great idea to do a retrospective on the last year of their engineering contributions and pull up code that they wrote and say, okay, you designed this system and you built this complex class interface so that it could be extensible. How many times was it extended? Just make them answer the question.

And sometimes they'll be like, well, zero times. and then ask the question, how much simpler would this have been if we had built a non-extensible solution because we didn't see a need for extensibility at the time? And just make them answer that question. Yeah. Questions can be really powerful ways to drive long-term thinking changes in people. Don't you think so, Jameson? Question mark. I'm sorry. I wasn't paying attention until you asked the question. hmm i mean yeah to me like one of the benefits i feel like i'm going in circles because i keep saying they need to just do more things but one of the benefits of experience is hopefully some

insight into when it makes sense to invest more and and harden things a little bit more and when you can get by on something quicker and it just really feels like they don't have that yet yeah six one problem in time try and raise his hand and ask for help yeah it seems like the problem is that they don't this this person on the team doesn't recognize even when they're doing this it's not just that they know like oh i'm gonna handle every single edge case or make this super extensible and customizable it's that they don't recognize that they're getting sucked down this this path right maybe maybe it's the same solution for both problems though i was gonna say that when you were talking about um this this problem of doing a whole bunch of work at once slowly

kind of parallelizing yourself too much one solution to that is have or or have more guidance or oversight on delivery and more regular check-ins and and more clear expectations on what you will be working on when and i think that sort of helps take care of the issue around over engineering as well by just adding some constraints say hey you don't have time to like make this super extensible class framework yeah because this is when we expect it to be done and and that might help it feels gross to say because you're kind of just like turning the screws on them to say hey i'm going to pressure you so you don't have time to think but maybe instead of saying you don't have time to think you frame it as you have time to think up front about the implementation cost of

the thing you're you're thinking of doing and think like does this match with the constraints or expectations. Yeah. The other thing I was thinking on this topic is I wonder if the reason this person is getting distracted onto many projects at the same time is because they're encountering blockers. And rather than pushing through the blocker or raising their hand and asking for help, like I'm latching onto that phrase raising his hand. And rather than raising his hand for help with the blocker, he's saying, okay, I'm just going to set that aside and work on something else until it gets blocked. And then before you know it, you've accumulated a pile of like five projects that are all stuck you just rotate through them as one of them gets blocked

yeah and then yeah i have seen that happen before yeah i mean it's it's fun to go work on things where you can actually make progress and it sucks to go and like un unstick blockers because usually blockers mean i have to reach out to some other team or i have to get buy-in from some leader or i have to write some documentation like things you know things that are not as fun as cranking out the rockstar code yeah and maybe that's what's happening i mean you could impose a limit on work in progress that's the thing that teams do sometimes on their process because for the reason you described like it's it's really wasteful to have a ton of work in progress at the same time you're not getting any value from it you get value from when you deliver stuff so maybe yeah maybe

that's another alternative yeah isn't that the kind of the kanban thing yeah kind of the heart of the kanban all right well did we answer the question indubitably okay great undoubtedly great what can people do if they are blocked at work and want to go ask us a question instead of making progress they can go to soft skills audio click ask a question if you find any bugs on that page then you're now blocked from asking a question and you have another task which is to fix the bugs you can give as much or as little detail as you want we will get to all of your questions eventually before the heat death of the universe yes we really appreciate it they keep the show going please share the show with folks if you like it too we we we like talking about this stuff but

we also like knowing that other people enjoy it too yeah all right we'll catch you next week