Soft Skills Engineering - Episode 364: EMs doing technical tasks and too soft?

Episode Date: July 10, 2023

In this episode, Dave and Jamison answer these questions: Do you think an EM should only be involved with management tasks, and let the members handle the technical stuff, or should they have some technical expertise to manage things like architecture reviews or handle urgent incidents? Hello! Love the show, thank you both for all the knowledge. I discovered this podcast when I was struggling as a newbie who was learning on the job at a tech firm two years ago. By applying your advice for fellow listeners to my own situations, I now find myself a well-regarded senior frontend engineer in fintech. I’ve noticed that a big reason for this is my communication, organizational, and soft skills (English major and former operations manager). What really sets me apart is my effective and friendly collaboration with junior devs, tech leads, and product managers alike. As I work towards becoming a principal engineer, should I lean into extending and displaying these aforementioned skills, or are they actually “time sucks” since they are more fitting of a managerial track?

it takes more than feeding your git history into an llm to write your annual performance review self-assessment to be a great engineer this is soft skills engineering episode 364 i am your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers who just don't want to write their self-assessment the lengths we will go to it is painful i've never written one and thought that was easy that was fun and satisfying yeah i feel like i quickly and accurately captured my contributions for the whole year yeah painlessly it takes a lot of work to brush to sweep under the rug all the mistakes i made or to try to recast them as achievements yeah now if it was a record of your failures

Just reel that off. Yeah. I don't know. I do try to think about how I can position, that's the word they used, position my failures as successes. For example, fastest recovery of the production database from backups ever. Responsible for making our security policies much more robust. helped promote office hygiene

by creating a body odor policy through being very stinky. Leave off that last bit. Yes. That's the narrative crafting bit. All right. Should I thank our wonderful patrons? Please do it.

Thank you to these outrageously excellent entities. Thank you to Trash Panda. thecomputersciencebook.com, the re-elected Jameson Dance Boogie Brigade, the re-elected Jameson Dance Committee, Santa Hopar, Noah Fraser-Logue, Kenzie Dodds, Jenny Kim, Owen Shardle, Benjamin Earl, if you'd like to join this illustrious crew,

don't... Go to softskills.io and click the Support Us on Patreon button. That was someone's name on Patreon. Yes. Craig Motlin, I Love Mavis, the Stochastic Parrot, Alice Jost, Tuscarus... That's what it's called now.

TuscarusOhio, patreon.com.au, we're hiring Ira Chan, monkey face emoji, Jonathan King Webtao Awesome Ending Testing Old Apa Fadye The Reelect Jameson Dance Committee Nick Hathaway

Travis Sanders Brayden Keynes John Grant Cody Please Hire Jameson Sale Nick Kantar and Philip John Basile Thank you

Thank you to all of these entities If you want to join their ranks you can go to softskills.audio and click the Support Us on Patreon button and make our day

both by helping support the podcast financially and giving us something interesting to say your name is still interesting it doesn't have to be a witty pun or an unpronounceable location name yeah but it could be could be whatever you want really i feel like this podcast will be successful when the developers over at patreon go what is up with all these weird names and then they trace the clues back to our podcast yeah once they email us Yeah, please stop asking your listeners to put weird emojis and unpronounceable names in their Patreon names. Yeah, we could fix the SQL injection vulnerability, or we could email the Patreon account that keeps dropping our database with their contributions.

Dave, do you want to read our first question? Yes, this comes from an anonymous listener who says, do you think an EM, which stands for engineering manager, or electrical model, should only... Or excellent mint. This mint is excellent. Okay. Do you think an EM should only be involved with management tasks and let the members handle the technical stuff, or should they have some technical expertise to manage things like architecture reviews or handle urgent incidents?

Short question. So I could read this question one of two ways. I could read them, they both assume the question asker is annoyed with how their manager is doing it currently. Either they have a non-technical manager and they're fed up that they can't contribute technically and don't help with architecture reviews or et cetera, or they have a micromanager, technical manager, who they just want to get out of their way, let them get stuff done. It's interesting that I just jumped to assuming that they're fed up with their manager. Yeah, I know.

What does that say? Part of the job. Annoying your team? Have people be fed up by you. It's a signal that you're doing something right or wrong. Sure. It's a signal. I think this depends on the size of the team quite a bit.

Okay. And basically, the smaller the team, the more important I think it is that the engineering manager can and does contribute to the technical work. But as the team gets bigger, that sort of drop in, you're only able to do like parachute in without context contributions. And then that's less helpful unless you just know everything. So you're saying if there's a team of one engineer, it's not helpful to have a non-technical manager to manage that engineer? Who's going to manage the engineer, Jameson? We're going to do four hours of one-on-ones every day. I do think, this isn't quite the question that was asked, but I think an engineering manager has to have a technical background or you're in for some hurting.

And if your manager is not technical at all and has not been a software developer or technical enough to understand the work at kind of a high level, I think that's bad. I don't know if that means they have to be in the trenches actively fixing urgent incidents or writing code or whatever. Yeah. So today I looked at a thing in AWS, looked at a database thing in AWS. And then several minutes later, a message came in about some connection issue in the database. And I was immediately like, oh, did I click? I swear I just opened the panel and looked at the config, but maybe not. And what was the outcome? Did you cause it? No. Well, if I caused it, I have not been discovered yet. That's the outcome. Okay, good.

No one knows I broke it yet. That's the outcome. If a manager breaks a database in the woods, but no one's around to see it, did the database actually break? Question for the ages. You're not supposed to answer. Yeah, that's right. You just think about that. Good. I didn't answer. Yeah, I just said meaningless space-filling noises. What do you think, Dave? I think it's a, I believe there is a movement right now that businesses expect their engineering

managers to be more technical than they did say 15 years ago. And I'm basing that on a few things. The first one is the Facebook staff reduction that has gained a lot of notoriety over the past few months where Mark Zuckerberg- Yeah, didn't they basically say, we've got too many managers. We need people that do stuff. Yep. They basically said, your jobs are not valuable and laid off a whole bunch of people. And also, you know, since when I started out in software development, there just weren't, there wasn't a large number of people with enough experience to actually be an engineering manager and have technical skills. And that's a side effect of being part of a very quickly growing

industry. The population of people who have a job grows from the bottom end of the experience curve, not the top end, turns out. I did the math on that, but more people join the industry without experience than join it with experience. It's a little bit imbalanced. And so when I was first out of college, I guess I did have a couple of engineering managers who were technical themselves. But I spent a good number of years having a manager who had no software development experience at all. It was a combination of MBAs and electrical engineers. And that was just kind of my path. It was maybe a little bit different. But for the last several years, all the companies I've worked for, probably for the last 10 years, have had engineering managers who are highly

technical themselves. Or at least who used to be, let's put it that way. Maybe they're not in the code day to day, but they, they can still speak intelligently about it. Yeah. It turns out that speaking intelligently about the code is a very different skill from, from what being able to write it. Yeah, it's true. Yeah. I don't know. Uh, I, I have a personal opinion on this, but I don't really know what the industry trend is at large for sure. But because of my ego, I believe that my personal opinion is equal to industry trend. Hmm. Well, who cares about the industry trend you need to believe that it is correct yeah capital c i just need to be right yeah and if the industry happens to follow your sage wisdom good for them i believe they'll be doomed so you

mentioned jameson that on larger teams you need more management more a manager's job is more tied up with the people management and project management and things like that and they have less time available to them to do technical stuff like writing code or even in this case they didn't even, the question asker doesn't even say writing code. It says things like architecture reviews or handle urgent incidents. I think regardless of team size, a valuable engineering manager should be able to do architecture reviews and even code reviews. You know, they're not necessarily going to have the same perspective as an individual contributor, but they should be able to do that effectively. Even if they're managing 10, 12 people, which would be on the high end.

I think you've answered the question though, then. You're basically saying they should be technical. Yeah, I think so. They should be technical and they should be doing at least some technical work still. I mean, I think about it this way. Imagine if you're managing a factory, and it's a factory that makes, I don't know, pencils. And your manager is like, what's an eraser? You know? Why? It's so wasteful to have these. Yeah, what is this thing? I can save us 15% on every unit. and so i mean that's to me that's what it seems like it would be how it would be to have an engineering manager who's not technical it's like they just have to trust everything you say

you know and they can't question you or challenge you to be better and honestly i think it's actually worse for engineers you might think oh great when the cat's away the mice play you know like there's no one here to actually i can say whatever i want but for your actual growth as a developer having a manager who can't apply a critical eye and tell you if you did a good job and have it mean something i think that would kind of suck as a developer you know it's like they would they would say good job and it'd be like yeah you don't even know what an eraser is i made these pencils so well but like you wouldn't i guess what i'm saying is you wouldn't know the difference between a good job and a bad job sometimes like you you know how and that that's

because in software, you can actually make a working product with just absolutely terrible, terrible code. You know what I'm saying? And a non-technical engineering manager could probably judge the result of your product. They could judge whether it's working. And in the end, that does actually matter a lot. But they don't know if you did a good job to create that. They don't know if you took too long or if you took shortcuts. They don't know if you used Haskell to do something kind of esoteric. They don't know if you used outdated libraries with security vulnerabilities in them. They don't know if you're, if you're writing good unit tests or if you're just, you know, writing tests with no assertions to get the coverage numbers that never

fail. So, so yeah, like I actually think that engineering managers should be technical. I think ideally they have developed code in the past and if the team is small enough, and I'd say like under six or seven people, they should be contributing code and actually doing IC work themselves. Maybe 10% of the time. There you go. That's my capital C correct answer. well we've given the correct answer so we have answered the question i think definitionally should i read our next one well yeah but i do want to hear if you have a different view on that like do you agree with what i said or do you have a different perspective i think i agree i

think they should be technical and i think i keep getting stuck on edge cases where well it could still work in this situation but if i try and think about what feels most likely to succeed i think a technical engineering manager in general will be better than a non-technical one even though the right non-technical engineering manager or the right team could could make it work i think i'd rather have a technical manager than a non-technical one there is a problem of now they know enough to disagree with you about engineering stuff but they're not building it and you wouldn't have that problem with a non-technical manager but that i would rather have that problem yeah all right so i i agree with you okay that was easy that's really my

goal in this podcast is to just say words that jameson agrees with and just hope for everyone else okay i always agree with you so wonderful it's done that's why we talk so much all right your turn read the next question for us all right this is from an anonymous listener who says hello Love the show. Thank you both for all the knowledge. I discovered this podcast when I was struggling as a newbie who was learning on the job at a tech firm. By applying your advice to fellow listeners to my own situations, I've now found myself as a well-regarded senior front-end engineer in fintech, financial technology. I've noticed that a big reason for this is my communication, organizational, and soft skills. What really sets me apart is my effective and

friendly friendly collaboration with junior devs tech leads and product managers alike as i work towards becoming a principal engineer should i lean into extending and displaying these aforementioned skills or are they actually time sucks since they are more fitting for a managerial track hmm nice i appreciate that you gave us all the credit but you should take some of the credit as well for doing well, I'm sure at least some of it is from you doing stuff, not just listening to us. Another satisfied customer to add to the list of thousands who are paying us 10% of their salary every month. It's great. It's worth it because the return on investment for us is very high. Real quick though, I just want to check on FinTech. I've heard this word before, FinTech,

of course, it's financial technology. What I didn't realize until this moment, which ChatGPT just confirmed, but Finland is actually financial land and the whole country is just financial companies. As I read this, I thought, you know, I know this is financial technology. What if this is dolphin technology dolphin tech what if wearables for dolphins it's more maritime yeah yeah there yeah exactly it's it's i mean the step tracking paradigm doesn't work if you have fins there's no there's not that impact or that movement of the of the wrists or feet so yeah the wearable technology is totally different for dolphins it's an untapped market yeah it is there's opportunity there, venture capitalists. Yes. Go forth and conquer. Okay. So the question

is, should I lean into continuing to develop my soft skills or are these just time sucks? And you came to a podcast called Soft Skills Engineering. I mean, the answer is categorically, yes, this whole podcast is a time suck. There are now 364 episodes available for you. i can't in good faith recommend you listen to all of them that would be a huge time suck so i think in general most developers would be better off if their soft skills were better and in fact that is the premise of of why we started this show that's true like like you said but i think there are diminishing returns and it's tricky as you become a more senior ic you definitely need to wrangle groups of people and communicate and and make sure that you are

listening well and and do a lot of soft skill things but also your technical impact needs to be large and impeccable so my inclination is is kind of to say if you feel really strong at these soft skills there's a different type of soft skill to work on that's more around getting buy-in and consensus and convincing people and educating groups and moving groups maybe that's the thing to focus on but if you're a smooth talker that doesn't have the tech skills to back it up i would hope that a promotion process would uncover that in the form of saying you're manager material Yeah, exactly. Yeah.

Yeah. Since they're more fitting of a managerial track. Yeah. There are worse things in life. Than a managerial track? Yeah. I mean, not much worse, but yeah. Here we are.

Yeah, I agree with you, Jameson. I think that the generic idea of soft skills, such as communication, organizational, and so on, they probably have a limit in their raw form. But there is probably a whole universe of skills that you didn't even know existed. For example, skills that involve reporting information to an executive team, skills that involve negotiating with an investor, skills that involve putting on an event. These are all things that I would call soft skills, but they're maybe not what people traditionally think of as just, I'm a good communicator or I'm empathetic. you know and so i would say as you as you grow in your career i think it's actually really fun

and very fulfilling to seek out opportunities where you can put yourself in situations that are totally new to you and this has characterized my career over the last 20 years where most of the reason that i change jobs or look for new things to do is to put myself in situations i haven't been put in i haven't been in before you know like right now for example i'm a member of executive team at a company. And so I have to prepare material for a board of directors. And I got to tell you, like, it takes a little bit of practice to be comfortable speaking to a board of directors, and then also engaging with them when they ask you questions. Like you can't, you know, you can't prep for that. You can't rehearse that. And so you have to just experience it. And,

and so to me, the new kind of frontier for soft skills development is not things like, how do I speak better or how do I communicate better? It's more like, how do I become comfortable with an audience of board members that have very different background than I do and who have a set of incentives and a set of, they have a perspective that's very different from mine on the company. You know, these people are looking to make money on the business that I'm helping operate. So like, it's very different. And just learning how to be not scared of talking to people like that is itself an entirely new skill. So yeah, good. But I got to tell you, like Jameson said, if your technical skills can't back any of that up, it really won't matter how

good you are. And in fact, I think people will resent you. For example, if I were to go to the board and speak just real smooth and confident, but full of lies, that would be a really bad thing oh man that would really come back to bite you i live in fear that i follow people who are really good at being convincing but that's totally divorced from whether they're right or not that's a concern i have me too yeah don't be one of those people not not saying that you will become one or you're deliberately trying to but yeah i do feel like the the way i think about a principal engineer role is someone who has org or company-wide impact on the engineering team who helps the team see further and get things done faster and kind of sets the direction and you

have to be good technically to do that you have to be good enough to to be right about that technical direction not just be convincing that's right you have to be both you know it's not enough to just be right and it's not enough to just be convincing you have to be right and convince people you're right because the rightest person on earth if no one believes them because they come across bad or some you know who knows what reason it will have no effect sadly except smugness you will have good smugness i think we're also being a bit idealistic i'm sure there are cases where convincing people have done have have done bad things at work have led folks to make poor technical decisions because they talk pretty yeah but i want to be idealistic anyways so i'm going to keep going

maybe a way to think about it is less about should i really focus on displaying these soft skills and more like where is the bottleneck right now yeah that's the limiting factor right now and it could be soft skills related right maybe it's some of those things you talked about dave maybe it's writing a design document that is coherent and yeah that moves that moves people emotionally as all design documents need yeah like this one brought me to tears achievement achieved yes make my team cry with joy when they read my design this one made my foot tingle it's actually a spell i've been bewitched that's how you know it's a good design document but maybe it's cloud architecture stuff or i don't know i'm gonna stop talking about

my guess is that you know as you move into a principal engineer role like jameson said which means you have you are responsible for directing potentially multiple teams of other engineers undoubtedly the frontier of soft skills that are required to do that like the the bar for skills that are required to do that, it definitely goes up. So it is unlikely that you have already achieved enough soft skills to do that job right now when you're also working on growing your technical skills. So likely you'll have to grow both because people don't tend to have practice learning how to influence multiple teams at the same time when you're working as an individual contributor or even influencing some of your peers on your own team. It's just not something

you have a chance to do. And I got to tell you, it is not intuitive sometimes the things you have to do and also not very comfortable to do those things. And so a lot of people don't tend to just practice them by default. Yeah. So you probably have plenty of room for growth in both areas. Like for example, the dance moves that Dave had to learn in order to communicate effectively to several teams. Never would have guessed. Dave was not flexible enough at the beginning to pull them off the warm-ups alone wore me out at first could not put his knee behind his head no you should see me in the design reviews now though syncopation whirlwind it's wonderful well have we answered the question i think so good luck

i don't even know what we said but i'm sure it was good capital c correct that's how you know it was good yeah that's the fugue state we enter when raw truth is flowing yeah we're just conduits all right what should people do if they would like their own questions answered go to soft skills.audio on the worldwide web and click the ask a question button where you can fill out our little form as always thank you so much to everyone who takes time out of their week to write text in that form with your text input device. We appreciate it. We love reading your stories. You give us amazing insights into how the world of software development is actually operating. And thank you. Please keep them coming.

Yeah. Thank you. We will catch you next week.