Soft Skills Engineering - Episode 196: "Offshore resources" and ageist layoffs

Episode Date: February 10, 2020

In this episode, Dave and Jamison answer these questions: Hi, thank you for the great podcast! I work for a software consultancy as a senior product manager. For 5+ years, our team of 40 designers, developers and QA has designed, built, deployed, and operated a large SaaS platform. We are passionate about evolving the product, know the domain well and managed to improve a lot of processes in the client’s company. We go way beyond “just development”. The problem is that the client’s internal staff treats us poorly, especially when it comes to product decisions. As a product manager, I have all the responsibilities of a respective in-house specialist, but almost no power. When I refuse to prioritize a feature that does not make sense based on data and user research, the client’s customer success reps go crazy and escalate it to the CEO. I have seen email threads where internal employees call us “offshore resources”… How can I change this situation? I don’t want to leave this job because I really like the product I am working on, as well as the team. Thank you! Connor asks: “I recent round of layoffs at my company has me thinking about my future as a software engineer. Every layoff I’ve been through, the more tenured employees are the ones let go. I also, generally speaking, haven’t seen a lot of older software engineers (50+) in the companies I have worked for. I love programming, but can I reasonably expect to stay employable in this field for the next forty years?

it takes more than achieving 100 test coverage by not putting any assertions in your test cases to be a great engineer this is soft skills engineering episode 196 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers about non-technical topics such as well not such as removing assertions from your test cases 100% test coverage is technical, but 0% test coverage is soft skills. Defending why you're not going for 100% test coverage is soft skills. Well, depending why you're explicitly going for zero. It's like, can we really know anything in this world?

I'm pretty sure there's a chunk in working effectively with legacy code that actually recommends this as a way to get tests in place. Just the fact that you can run a test, even if it does nothing, The fact that you can instantiate code and do nothing with it is sometimes progress for some systems where they have so many dependencies and are so gnarly to work with. So I guess I'm recommending this. This is an approved strategy. Don't put any insertions.

Just test that your compiler works, I guess. It can build. Yeah. This episode is sponsored by Vetteri. Vetteri is a marketplace to help you find great developer jobs, and you will hear more about them later. we'd like to thank those that are contributing on our patreon that gets them a shout out every single week they are braden canes chris hogan dennis bogdanov iva robotnik john grant louis

santos luke bayliss matthew voidovich nick cantor philip john vacille the agile ventures charity sean sonic the hedgehog sunny tie stanley tactical radio steven armand lee taras haruk ted nugent maple sir vinlock and zach granin thank you so much if you'd like to join them you can go to softskills.audio and click support us on patreon and if you do we'll send you an invite to our slack pod flock where you can join well over 100 folks who have done that and have great conversations every day i just noticed that this list of names is in mostly alphabetical order but not all the way alphabetical and now i am dismayed is there a name for this algorithm this is like mostly lexographical sort it's non-deterministic lexographical

all right oh yeah one more thing we are interested in doing shows at conferences so if you know this is kind of like a reverse cfp you call for conferences instead of a call for presenters if you know of conferences that you think would be interested in having us do a live show there let us know just get in touch you can hit us up on twitter at soft skills eng that might be the best way yeah yeah we'd love to do that so tell us if you know of things just come to jameson's house and knock on the door he'll be there yeah that's true when was the last time i left my oh i left my house yesterday okay all right good job on to the questions okay i shall read our first one this comes from an anonymous listener who says hi thank you for the great podcast you're

welcome anonymous person they go on to say i work for a software consultancy as a senior product manager for five plus years our team of 40 designers developers in qa has design built deployed and operated a large SaaS platform. We are passionate about evolving the product, we know the domain well, and have managed to improve a lot of processes in the client's company. We go way beyond just development. The problem is that the client's internal staff treats us poorly, especially when it comes to product decisions. As a product manager, I have all the responsibilities of a respected in-house specialist, but almost no power. When I refuse to prioritize a feature that does not make sense based on data and user research,

The client's customer success reps go crazy and escalate it to my CEO. I have seen email threads where internal employees call us, quote, offshore resources, dot, dot, dot. Those three dots tell all the story. Yeah. How can I change the situation? I don't want to leave this job because I really like the product I'm working on as well as the team. Thank you. Wow.

Yeah, this is hard. Maybe you should just move offshore and make it real. so a software consultancy 40 people for five years building a sas platform i'm just thinking like how much money does this cost that's a large dollar amount this you must be doing a great job yeah to be worth it either that or their client is just enormous you know huge company yeah yeah this is really hard there are these structural relationships in play that affect how you work together this is hard enough in internal companies that are large where teams are big enough and far enough away that they don't interact very much things can get kind of weird and adversarial or

just problems caused by exceeding dunbar's number but when you have the fact that you're like not part of the group in this way when you're from a separate consultancy seems like it's exacerbating the potential for bad behavior that's already there like this tension between products and and people who want things from product is real and exists everywhere but the fact that like product is a different company that they might see as lower status really yeah really makes this tricky i like how you dropped the word dunbar numbers so casually oh that was like well you were like nice weather today i've read a lot of twitter threads i'm a well-educated man well-versed in the ways of twitter threads that summarize books that summarize research

dunbar's number is from this researcher who looked into group dynamics i'm pretty sure and his name was dunbar and he basically came up with a number of people that interact well together it's kind of like the number of close connections you can maintain and it's 150 i think there's some other research that kind of shifts that up and down a little bit wait that's really big dunbar's number yeah did you think it was gonna be smaller i thought it was gonna be like three no no no this is for like how big of a let's see okay i'll do the thing i do which is look at wikipedia suggested cognitive limit to the number of people with whom one can maintain stable social relationships relationships in which an individual knows who each person is

and how each person relates to every other person okay so it's basically like the number at which you can look at people as people and not as abstractions or or like part of a team that you don't know very well or something like that. And what is the number? 150. 150. Seriously. That's what he said.

Other people say other things, but they're all kind of in that order of magnitude. 100 to 200-ish. Good heavens. I can't remember why I said that, though. What did I say about Dunbar's number? Well, first of all, you were very smooth with it. So I just want to say kudos to you. Thank you.

Kudos to you. Thank you. I've been thinking about it lately. That's why. You're just waiting for this moment. that you were saying when a team grows so i think what you're saying is there are structural relationships that inhibit these people from really understanding you as a human being and it wasn't so much that that dunbar's number is at play here but that there are structural

barriers yeah well i mean i think the fact that they have a consultant group with with 40 people indicates the company is probably pretty large like i would be i would assume that the company is much larger than 40 people otherwise that would be oh yeah okay yes i think there's a lot of people and it's likely that you're dealing with large groups that are larger than dunbar's number which means it's going to be hard to relate to them as people and instead you have to relate to them with abstractions and they relate to you as abstractions and it's easier to say like this team of strangers is a bunch of dummies than like this person that i know is a dummy right especially when you start throwing around labels like quote offshore resources which is apparently what they've

been called yeah okay yeah that's that's oil right like oil is oil oil buried treasure i'm thinking of things that are offshore resources the buried treasure is an offshore resource that is so true the great old ones that live in the depths davy jones is an offshore resource yeah okay why am i laughing at this okay i don't know because it's really funny because i'm so funny you are i mean you're obviously brilliant dropping words like dunbar's number and then following it up with this joke like effortless comedy man oh yes ah this show is finally a monument to my ego okay so what is what does our listener do to improve this situation Yeah, like I think you hit it on the head when you identify these structural relationship barriers. And we're using the term structural here because there's literally a company boundary between them, right, which creates a power dynamic where the customer has all the power and you have to do what they say.

And I think that the only way to break that down is to establish interpersonal relationships with the individuals on the other side of the team so that they can start thinking of you, or sorry, on the other side of the company boundary. So they can start thinking of you as a person. And then when you oppose one of their ideas, they can, instead of just kind of throwing a tantrum, which is how I interpret this, a little bit of a tantrum, they can actually engage you in it and discuss it. Yeah. This interaction of the client's customer success reps escalating to the CEO? I mean, there's also a chance if you really know your stuff. So the question asker mentioned, we have this data and user research, and that's how I determine my

priorities. Like there is a chance that if you can clearly communicate how you prioritize that escalating to the CEO ends up reflecting well on you, because instead of it being like someone whining that you won't do what they say, you can use it as an opportunity to explain, here's how we prioritize and this is the data we use and this is these are the metrics we're looking at here's the user research we have to back it up yeah and like you're paying the bills so at the end of the day if you really want us to ignore this that's fine but but we would prefer to make decisions based on this information we have yeah i love that i love how you just completely paint them into a corner it's like if you would like us to ignore all of this objective research and

data we can do that because you have the money they're just like uh yes i would like you to do that i mean customer success reps getting worked up presumably they're worked up because of some customer issue so i guess that's another input and you shouldn't ignore it so maybe there's an opportunity here to get ahead of that like like this is kind of like the same thing you said but collaborate more with them and use them as input along with this user research and data you have like i don't know customer pain through customer success reps is is also potential input yeah It's a data point. You know, I just realized I was in a relationship like this where we were a contractor for the U.S. government.

And we had full-time U.S. government employees that were paying the bills and ultimately were in the shoes of the customer success rep in this story. And we were the other company on the other side of that. And we had to walk a very careful balance beam where, on the one hand, we wanted to always build up capital, like political capital with these folks to make sure that they knew that we were on top of things. and we were competent and capable but also once in a while they would just play the customer card and say do this and even if we opposed the idea yeah we would just once in a while have to suck it up and do it and it was all in the interest of preserving the long-term relationship and it worked great like probably 90 at the time they deferred to our judgment and we really had a seat at the table but once in a while you know they would just kind of put their foot down and we

would just have to suck it up and do it because that was the nature of the relationship so you're saying it's kind of the cost of of being in this client customer relationship yeah this is it the more we talk about this the more this sounds like the balancing the customer relationship with with what you think is right it sounds like even more of a product problem like this is this is the problem of product is how you balance all these competing priorities and voices and motivations and stuff and you you have like extra tricky things added in there but it all feels sort of like the same problem of you say i have all the responsibilities but almost no power like product owners often don't have any power that's true they're not the ones doing the actual work so

i mean it depends on it changes from org to org there are some orgs where product is kind of kind of runs the show these are kind of producty problems the biggest wrinkle here is this lack of respect and treating you as second class citizens i don't think that's a normal juggling all these different priorities as a normal product thing but that doesn't feel yeah good or normal yeah that just takes what is already in my opinion the hardest job in product development and makes it even harder so how do you approach that because that might be causing some of these other problems as well if they if they don't respect you you come with all this data and they're like yeah but you're just the offshore resource so all you know is buried treasure you know the salty taste

of yeah clams or something get back on your pirate ship yeah yeah i mean what do you do and i think once in a while like i said before i think once in a while you just have to suck it up and do what they say to maintain the relationship and then other times you got to push back and boy that is that requires judgment skill yeah pushing back is is scary in most situations but especially when you're pushing back against it's not even your employer it's someone who's who's like deciding yeah we'll pay you this week yeah exactly i mean yeah i just keep returning back to the old reliable sports movie metaphors like there's always some moment of like either a protagonist or a coach or somebody who the group doesn't respect and they have to win respect somehow how do they do

it like take a bullet or something shared adversity sometimes happens yeah taking a bullet has been known to happen. Yeah, I don't know. That seems like the harder problem to solve here is it's not just the product issues and the client relationship. It's like they're seen as these second class citizens. Well, maybe the problem here is that these customer success managers don't actually feel listened to. And so maybe it's kind of endemic and it just manifests as a blow up every once in a while. And so maybe you need like a regular check-in with these folks where you sit down with them and let them form a cohort of people that give input to the product regularly so that they always know that their voice is heard and they know why you're choosing what

you're choosing to prioritize. That makes sense. I think also what you could do is what I do whenever someone doesn't respect me, which is I get down on my knees and I cry and I say, please respect me. I beg you. And then usually that works really well. they say okay i respect you now i thought you were going to say you dropped like obscure scientific paper references to earn their respect no that's how you earn my respect oh i gotta step up my game then yeah yeah so maybe maybe they're upset by this what they see is a lack of communication or something but i mean it's it's hard because it's inherent in this relationship with you as a vendor that you're not as much a part of the team as full-time employees. And

that's one of the advantages. Like if they go through budget cuts, it's a lot easier to say, hey, we're not going to use this consulting company than to lay off somebody. So I don't know how you get around that. I don't know. This is hard. Well, question answered. I don't know. I don't know. I think you're probably right. There's probably something around clearer communication. Would you ever bring up directly the fact that, hey, it feels like we're not respected and that makes it hard to do good work? I don't think so. I don't think so. I mean, respect is earned and it's not earned by telling someone that you're not respecting me. Yeah. Like, oh, sorry. My bad. Okay. Now I do. Now I do. Let me just reach over here and flip

the respect switch to the on position. Okay. I think one thing to learn here that doesn't help you is that if you're in the other situation, if you're working with vendors or consultants or contractors or something i think it can be easy to fall into this trap of saying like oh they're just the vendors or the consultants or whatever and to be aware of that that that's a they're real people that you have a real relationship with and if if you feel like they are second class citizens they know it and they feel it too so yeah all right i have one last idea and then we can wrap this one up sure next time you kill one of their feature requests just tell them you killed it but tell them look we had a very nice funeral here are the flowers people said more

people came than we thought and they said some very nice things about your feature but it's dead give them its corpse as a memento tack get get the feature request taxidermied mount it in a nice plaque perfect okay now now the question is answered all right hey jameson before we go on to our next question did you hear that one of our slack community members just got a new dev job with a fifty thousand dollar raise yeah that was wild they used a service called veteri veteri matches developers with employers based on what you want like your location salary requirements and technologies you want to work with yeah so i actually signed up myself and within a week they sent me a job opportunity the hiring manager wrote

me a very nice note and the salary was actually amazing i was pretty impressed i don't know i'm a pretty big fan of my current job search process which is quitting my job and then asking strangers on twitter if they know anyone hiring for cobalt okay so once you sign up for bettery you actually get a dedicated consultant assigned to help you tweak your profile and find the opportunities you're interested in and the best part is you get those pesky salary requirements out of the way early in the process no more going through the whole interview process only to find out that your expectations are way off another thing i like is that there's no coding test to get started and as much as i love balancing binary trees on a whiteboard under time pressure that's a pretty

cool thing if you're thinking of taking the soft skills engineering advice of quitting your job you should check out veteri go to veteri.com soft skills to sign up that's v-e-t-t-e-r-y.com soft skills and if you use that link you'll help support the show and if you get a job through Vetteri, you get 300 bucks. Thank you so much to Vetteri for sponsoring the show. I will read the next question. This is from a listener named Connor. Connor asks, a recent round of layoffs at my company has me thinking about my future as a software engineer. Every layoff I've been through, the more tenured employees are the ones let go. I also, generally speaking, haven't seen a lot of older software engineers,

50 plus, in the companies I have worked for. I love programming, but can I reasonably expect to stay employable in this field for the next 40 years ah wait 50 plus 40 years is connor 10 have we been replaced by 10 year olds oh no that's the next wave they're gonna start teaching computer science in elementary school oh no i'm so out of touch i was feeling old and out of touch because i don't understand gatsby but this is helping also so there's a couple yeah there's like layoffs and ageism together two great ingredients in a sad stew oh man yeah i've seen the i've only been through one round of layoffs but i saw the opposite where

the most the most recent hires were let go oh and the idea was like they have less context and they're still getting up to speed more and i don't know it'll be more impactful to let go the most experienced people but this was at a startup and the oldest developer was like 28 or something okay this ancient curmudgeon who is so wise and experienced had kids that spoke english They could actually speak, yeah. Yeah, whoa, wise elder. So yeah, it sounds like if there are rounds of layoffs, that's probably a much bigger company,

much more established. Yeah, it could be. I've been through remarkably few layoffs in my career. Let's see, been working full-time for 17 years and the only layoff I've experienced was when I was an intern before that time. So yeah, I don't have a lot of experience with layoffs, but I have had this, I had the same concern when I was in the very beginning of my career as a

developer. I was looking around and saying, where are all the 50 plus engineers? And I thought about that a lot. And I came to a different conclusion than what I think Connor is asking, which is, you know, Connor's concerned that they all either like burn out or get laid off and can't be reemployed. I've come to a different conclusion though, which is that the industry was and still is growing at the bottom and what i mean by that is that all new engineers tend to be young you know the vast majority of them they're obviously second career switchers and stuff like that they are very small i think as a proportion of the total incoming engineers so by definition less tenured folks because the industry is growing and only growing at the bottom

outnumber more tenured folks and i don't think that the 50 plus folks are necessarily leaving the industry but they just get outnumbered by the new entrance yeah huh that's really interesting i feel like that's something we could study if we were dedicated or smart or in any way qualified to study but instead hey why don't one of you listeners go get a phd in sociology or answer that question for us that's a really interesting theory i mean there's also there are like escape valves at the top i guess so it's not only that there's more people coming in who are younger i think the longer you're in the industry the more likely the more opportunities you have to move into management and some percentage of people take those so there's

like people leaving to go into management yep or like forestry preservation i don't know some totally other different career maybe maybe the answer is programming is so lucrative that by the time you're 50 you're retired yeah everyone retires yeah so they just don't need to work anymore they're all they all go offshore they're all retired yeah they become offshore resources on yachts living in yeah living on their yachts yeah i don't i don't think i have i i will say that i think i think it depends where you work okay there there are different cultures and companies that kind of carefully or through accident attract different demographics and my impression is that larger more established tech companies might be places that have larger

percentages or proportions of older developers yes i've seen that i think i think the calculus this changes a lot where I imagine I would be attracted more to stability than risk and new shiny like if I'm 50 I'm not going to be like all right time to risk it all on this 22 year old startup idea sure you need what I can provide and I'm sure this equity will work out can I reasonably expect to stay employable in this field for the next 40 years I think the answer to that is yeah if you want to like there is so much to learn forever like the the field is both growing and very large like if you just sat down to learn all of the current state of the art of software it would take you longer than your life and there's more getting added to it so i i think

like is there enough to do yeah and also in terms of the demographics that i think that almost not almost i think it makes more experienced developers more valuable if if the proportions are changing so that the field is getting younger that there are more inexperienced people like the the leverage that you have as a experienced tenured developer is higher now where you have a lot more people to influence and there's a lot more folks to share your hard one wisdom with yeah i definitely have experienced that i mean not to discount ageism like that's a thing i'm i'm sure that looking old makes it harder to get hired at some places yes definitely i think that definitely happens but i i would suspect that it is not the number one cause

of why you don't see as many 50 year old developers as you do 20 year old developers or 25 year old developers huh yeah i think one thing i've seen i am not 50 but even in my career is the importance of keeping up to date this is kind of a cliche i guess but i'll say it anyways where the field changes. So there's some chunk of experience you have that crosses, that is broadly applicable no matter the current technology stack. But there's also a large chunk of knowledge

that is very tool specific. And that's the stuff that goes away pretty frequently and that needs to be refreshed a lot. So I think if you keep up the skill of refreshing that knowledge while you're accumulating this broad, kind of longer lasting knowledge around like architecture and practices

and kind of how to be generally effective, that's probably helpful for keeping your career going long-term. And soft skills. Don't forget soft skills. Especially soft skills. Yeah. I just remember this feeling of learning like my second tech stack where I learned the first tech stack

and it felt like in some ways it came easily because everything was new and I just learned like, yeah, this is the way it is. But learning the second one felt way harder because I was fighting against this knowledge that I already had, kind of like trying to throw away stuff I already knew. I think if you can keep that skill up

so it's easy to keep up to date with new stuff and also get real good at soft skills, like Dave said. All right, so the answer is yes, but I'll tell you for sure in a few years when I get there. Like what, like 20 years in your case? Yeah, 20-ish years. Call us back in 20 years. We'll still be going.

The show will still be going. We will. Yeah, there will still be questions. all right have we answered the question yeah i think so good luck connor what can people do if they want their own questions answered go to softskills.audio and click the ask a question button thank you so much to everyone who has done that there are so many and we love them you are the lifeblood of the show if you want to support the show go rate us on itunes or stitcher or wherever you listen to podcasts what can people do if they want to support the show

they can also go to softskills.audio and support us on patreon and give us money to pay for the show and life. All right. Thank you so much for listening. We'll catch you next week.