Soft Skills Engineering - Episode 439: Harried VP of Eng and first startup job

Episode Date: December 16, 2024

In this episode, Dave and Jamison answer these questions: What advice would you give for working with an ineffective leader whose input is crucial to your work? I’m a senior developer for a mid-sized non-tech company with probably 60-80 devs, and in the past year I’ve been working more with a VP of software who seems to still be involved in code details, getting pulled in to production issues, in-person code reviews, etc. He’s a nice guy, but he seems like he’s being pulled in too many directions at once. When he schedules a meeting, there’s a 50% chance it happens on that day and time, and when we do have meetings, if we bring up questions and high level issues we need feedback on he’s quick to “take ownership” and say he’ll do X and Y. Inevitably, X and Y slip down the priority list because production issues and who knows what else, and we’re stuck waiting weeks on end for something that if he’d just delegated the work to someone else, we’d have long since moved on. But we still need his input to shape our work. How can we as lower-level developers (with a manager who isn’t involved in this project at all) help mitigate these delays? I’ve recently accepted a new position after spending more than three years at my first job out of college. Currently, I’m a Senior Engineer at a large, corporate-like company (300+ people), but my new role will be at a much smaller startup (20-30 people). I’m excited about the change but also a bit nervous, as I know startups can be fast-paced, and I’ll need to get up to speed quickly. What advice do you have for setting myself up for success in this new role—both before I start and after I begin? I have a couple of weeks before my start date and want to use that time to prepare effectively.

it takes more than remembering you're on call this week to be a great software engineer this is soft skills engineering episode 439 i am your host dave smith i'm your host and actually in real life currently on call person jamison dance soft skills engineering is a weekly advice podcast for software developers whether you're on call or not we think you'll enjoy it we actually have like a fake alarm that triggers a page when the on-call shift hands off and it hands off during the workday so it's yeah you're not going to get woken up by it but it's kind of nice because you definitely remember you are on call if you miss all the other notifications or whatever all these systems have some way of like telling you you're going on call but we have the

final boss of telling you you are on call which is a fake incident yeah yeah that you have to acknowledge within one minute or it escalates to your boss yeah which is me i guess in this case escalates to me self-escalation the ultimate in self-actualization yes let's thank our patrons which i will do i will take charge by doing it i want to thank the folks who contribute at such a ridiculous outrageous yet still surprisingly affordable amount of money that we shout them out every week thank you too this question comes from an anonymous listener they say hi dave and jameson what is your favorite color nice alexander kuzet kuznetsov 10 print mark lucas morton is cool go to 10 nick molyneux oppa 2 oppa 2 with little music emojis attribute error none type

object has no attribute to string javier gonzalez chewy ted timbrel alexa set an alarm for 4 a.m become a senior engineer.com unsalted french fries are morally objectionable dan from drone to play chase w norton dave do you want to read our first question level up your type script with type hero.dev never is not just how rude of me to just ask them to keep barreling through they got never is not just a crater on mars flamingo emoji i like chicken i like liver meowing spouts please deliver trash panda kyle boss kenzie dodds nevar is not just planet in the Vulcan system. Jenny Kim, Owen Chartle, the stochastic

parrot. Helicone.ai, best observability tool for AI. Red Panda's best panda. TypeScript is a Microsoft conspiracy. Jonathan King's nigh-beautiful functional user documentation. The artist formerly known as Object Object. Cody sailing to williamangel.net. Oh, wow!

I'm a good little podcast host, and I say whatever my soft skillets write. Nice! Travis, Brayden Cain's John Grant. This person's name is too hard to pronounce. Yep. Joe Grosberg, if you would like to join this illustrious crew, Dave, don't gloss over this bit. Maybe it's different. Go to soft skills.

The audio. And I hear you like movies involving time travel. Los. Oh, I'm not going to be able to pronounce this. Chrono. Chronomies. Los Chrono Chronomies. I don't know.

It's a great one. Don't watch the trailer. It's not good. Cody said. And then ran out. Either changed their name from Cody sale to Cody said or ran out of character. I would. Yeah, I wouldn't be surprised either way.

Don't watch the trailer. just watched the movie okay oh it's spanish it's los cronos crimenes that means time crimes ah nice i'm going in now i have to watch it weekend plans thank you thank you so much yes unless time travel is like unless i learn how to time travel from this movie and then i already watched it can remain yeah thank you so much oh we appreciate you we appreciate the the joy you bring to our lives. And you can bring additional joy if you want to join this group by going to softskills.audio and click support us on Patreon. Man, I got to tell you, I've had a little bit of a rough week, but that list of Patreon names just completely transformed this into the best week ever.

Oh, good. I am so happy right now. Do you want to bring that happiness to our first question? Yes, I do. Okay, this comes from an anonymous listener who says, what advice would you give for working with an ineffective leader whose input is crucial to your work. I'm a senior developer for a mid-sized non-tech company with probably 60 to 80 devs. And in the past year, I've been working more with a VP of software who seems to still be involved in code details, getting pulled into production issues, in-person code reviews, etc. He's a nice guy, but he seems like he's being pulled in too many directions at once. When he schedules a meeting, there's a 50% chance it happens on that day and time.

and when we do have meetings, if we bring up questions on high-level issues we need feedback on, he's quick to, quote, take ownership and says he'll do it. Inevitably, they slip down the priority list because production issues and who knows what else, and we're stuck waiting weeks on end for something that if he just delegated the work to someone else, we would have long since moved on. But we still need his input to shape our work. How can we, as lower-level developers, with a manager who is not involved in this project at all help mitigate these delays. I hear the description of this person

and worry that that has been me in the past and could be me again in the future. Because I like software and programming and I don't know. It's fun. It's not fun to cause production issues. I think it is fun to resolve production issues. Therefore, but how can you resolve a production issue

if it was never caused? So, Jameson, I think you've created a perverse incentive for yourself. Yeah, that's okay. Yeah. Hmm. Uh-oh. Yeah, it's so easy to get sucked in if it's a thing you enjoy. Also, it's easy to get sucked into this stuff if there are other parts of the job that you do not enjoy.

A lot of VP stuff is like corporate, I don't know, politics is maybe a pejorative way to describe it, But lots of high-level cross-team coordination and setting vision and direction and resolving conflicts and incentives between groups and all the hard problems that nobody else can deal with bubble up to you. And so it can be a temptation, even at the VP level, it seems like, to just dive into the actual specifics of the work. And, I mean, we do, I think it's pretty common to, what's the word? I already used the word pejorative, so I can't use that again. Pejorate? To be negative about leaders who are not very hands-on, who could not do the job themselves. So this is sort of like the ruinous inverse of that, of like the leader who is too hands-on,

yet not doing the high-level stuff. Yes. I have an answer, but I want to hear your answer, Dave. Before I give an answer on what I would do in this situation, I actually have another explanation for why I sometimes slip into this mode. Because Jameson, after your confession, I feel inspired that I also must confess. and and that is because sometimes leaders want to shield their engineers from things that they perceive are drudge work or below them and they just say i'll do that so you don't have to yeah

so it's like you're trying to empower your team kind of servant leadership except sometimes they need a leader leadership that's true so the solution to this vp's problem is to change their leadership style uh you're not gonna do that so it's a harder problem to to incept into their mind like oh i need to work differently but i think the key to what you need to do is start saying the phrase i intend to a lot if you need feedback or blocking things or or information i don't know you need to eliminate dependencies on the vp of engineering and just give them an opportunity to approve or deny basically so you can say hey we need this information i intend to go figure it out or if there's some decision that needs to be made say well i assume

we're going to do this and so i'm going to proceed based based on that assumption let me know if that assumption changes so you're basically pre-empting your vp's opportunity to do the task for you by saying i'm gonna do it yeah yeah quick to take ownership but then doesn't do the thing that's fine you you just take the ownership right back take it before they can get it yeah yeah you snatch yeah you claim the ownership bring up questions and high level issues we need feedback on i think i mean maybe there's some things you can't do this with maybe if it's like well the other team might be eliminated by cost cutting concerns or something and you say well i intend to go fire them then tell me if that's wrong yeah within your scope of but allowed

to responsibilities i guess yeah is it is it like products decisions or how you i don't know how you ship dates or something like that like i think if you always start with here's what i think unless i hear definitely we're going to proceed this way it is a lot easier for your vp to nudge instead of and it might it might be the case that your vp has a belief about your ability to do this, to do these things. Like, oh, well, this person's already totally overloaded, so I can't possibly ask them to do it. And so I need to do it. And that might be a mistaken belief. And so I actually just got off a great call with an executive coach. And we talked about how to effectively give feedback. And he said something that I've been now thinking about for literally

ones of minutes. So, you know, it's very well baked. And he said, you know, Dave, most people when they give feedback, they talk about behavior and they say like, you're doing this and I don't like that. And they don't often go one layer below the behavior, the things that drive the behavior, which are beliefs. And he said effective feedback, well, ineffective feedback, like in this case, like Jameson, you said you probably can't change your boss's style. Well, you definitely can't change your boss's style if you just focus on the superficial behaviors that you're seeing, like, hello, how's that sounding good? Hello. So, because behaviors are often just a symptom of an underlying belief, that's where the best feedback happens. If you truly want to change

someone's behaviors, it's a good idea to have a conversation about what they believe that's causing those behaviors. I would not say that I've mastered this. I haven't even really practiced it much because I typically just focus on behavior because that's kind of the knee-jerk place to focus. But if you truly did want to change your boss's style, one way to approach it is to say, I'm seeing that you pick up a lot of tasks. And I don't know if you're aware, but sometimes when you pick up a task, because you have so much going on, the tasks take a long time to complete. And it's quite possible that another engineer could have completed them faster and we would spend less time being blocked. And this affects our quality of life because we get frustrated

that we can't make more progress. It seems like maybe you hold a belief that is stopping you from letting others work on these tasks. Can we talk about that? All very permission-based, of course, in order to get the best outcomes of where they'll actually confront the belief. And you never know how this is going to go because not everyone is very introspective. Your boss might be like, what do you mean? I'm just doing a good job here. I'm working really hard. You got a problem with that? Yeah. It's natural for the VP of software to be the most productive engineer on the team. You can't argue with these numbers.

They're just fantastic. But it could be that you have someone who's willing to be a little bit introspective and say, yeah, I do have a belief that the team can't do these. Or I have a belief that the team does a bad job when they take on these little tasks. Or last time I let someone do it,

they took even longer than I would have taken. Yeah, I really like that. It sounds like there's a layer between you and the VP though, because this question asker mentions their manager who's not involved so yeah if if you can talk to your vp i i think that is pretty reasonable but you probably can't it's probably hard to do right yeah i assume so 60 to 80 devs you're one of the teams there might even be two layers honestly oh yeah with that many people maybe

not but but that makes it even weirder that the vp is like doing code reviews and yes this is a production issues i can see a vp being involved in but not in solving them typically they're involved in communicating and and coordinating with the rest of the company and and guarding the engineers so they can actually focus on solving the thing it could be with this i assume with this vp being so hands-on it could be that they're actually yeah yeah they missed stuff in their code review so that's why they have to be even more careful in the vp code reviews that they do take even longer on them yeah of course the problem here is i need to double down yeah well what do you think we answered the question well i mean what i think what we've done well

is we've validated the listener that yes this is a this is a weird situation that is not likely to be good for anyone and you should feel empowered to try to resolve it but you might be powerless us to do so. So congrats. I think if you tell people, hey, I'm going to do this, stop me if I shouldn't. That feels a lot different than waiting for permission. I like that a lot. I think your answer was the best answer. That can get you pretty far. Oh, thank you. It's so good because it's like, here's what I can do in my situation without having to exert unholy amounts of weird, organizationally awkward influence on someone else. Yours is probably a better like underlying solution it sounds hard right but it would it would be interesting to try to

pull off we don't advise doing hard things so let's just go with the easy short term take the easy way out our third motto all right dave should i read our next question yes please this is from an anonymous listener who asks i've recently accepted a new position after spending more than three years at my first job out of college. Currently, I'm a senior engineer at a large corporate-like company of 300 plus people, but my new role will be at a much smaller startup of 20 to 30 people. I'm excited about the change, but also a bit nervous as I know startups can be fast-paced and I'll need to get up to speed quickly. What advice do you have for setting myself up for

success in this new role, both before I start and after I begin? I have a couple of weeks before my start date and want to use that time to prepare effectively. From 300 people down to 20. Hmm. that's gonna be fun yeah i i like the 20 to 30 size it just feels good you're well below dunbar's number of of kind of keeping everybody in your head and modeling their behavior and yeah small enough to avoid a lot of coordination overhead and small enough that there's probably a lot of unsolved problems that you just get to go in and solve oh yeah and be the person who establishes how you do this thing. That's true. You will be a trendsetter, undoubtedly, even if you don't want to be. Yeah. So I kind of see two questions in this. How do I get up to

speed quickly? And the other one is sort of like, can I do anything to prep ahead of time? I kind of want to answer the second one first, which is, I don't think, I mean, so much of being effective at a company is understanding their code base and the product and the problem space. And that would all be tricky to do ahead of time. Yeah. And kind of getting to know the people you work with and building connections and safety with them. So you can't really do that. There is one thing you can do that I've done at several companies, which is reach out to the manager at your new team and ask them if there's any material that you should study before you arrive. And if it's a 20 to 30 person startup, they might even have stuff they could send you

that's like proprietary stuff. But they're like, we don't care. We're a 20 person startup. got nothing to lose we're going to send you all of our stuff or they at the very least they might send you online references or topics that you should become familiar with like oh we use this cicd pipeline tool you should probably become familiar with that you can go set up a free account and start learning how that works or oh we use this language that you maybe don't have a lot of experience with let's go read a book on that this this isn't so much startup specific advice though. This applies at any job. Yeah. I feel like time spent doing that can be useful, but it'll be much less effective than time spent doing that once you are embedded in the company.

I think something you could do that could still be really useful even while you're not there yet is just get to know the product really well. I'm assuming they have some kind of product you can see in some way. Yeah. I don't know. It's a startup. I'm assuming it's some kind of SaaS app. get an account if it's b2b then ask them to make you like a trial account or whatever and just dive into it and try and learn how it works from a user's perspective that's a huge part of being effective in a lot of places but especially at a startup it's like you really want your engineers to know the product well and care about the product and it can be hard to set aside time to actually just learn how the product works if you're heads down building stuff like sometimes

you might not even know about whole features until you have to go touch them to make technical changes so just an overview of like what the product does and how it works and how people use it i think would be useful to come into the business with totally great idea assuming it's launched yeah yeah and assuming it's not like a i don't know you're not building rockets or something yeah what about getting up to speed quickly kind of once you're already there oh boy How do you do that? I mean, you just throw yourself into it. We've talked about how to be effective at a new job in the past. And I'm the kind of person who's just like, look, for the first few weeks, I'm just going to eat, sleep and drink this company and work a lot of

extra hours and kind of throw myself into it. Not everyone is into that style, but that's how I tend to roll. Yeah. Don't show up and say, okay, so where's like your documentation that I read to just learn everything? Because they don't have it. If there are 20 to 30 people, I'd be astonished if they had good documentation yeah one thing i have i'll say it out loud and then i'll see if i like it there's always some it might be oral tradition kind of passed down from the other engineers but there's always some like how do you get the thing running process you could well i don't know this isn't really how to get you up to speed quickly this is just like a good thing to do when you start a new place it's always out of date right the docs for getting the thing running

locally they rot away as a new person joins and then the process changes but everyone already has their stuff set up so you can kind of like go in and update and document things as you go that's not really about speed it's more about just like learning things i would if it's a startup they might have this culture already but i do believe you should try to make a change to the code base as quickly as possible even if it's just a readme change ideally it's some kind of actual functional thing of like i don't know some little tiny tweak but i would i would try to speed run like getting one character at least one character of code change into the code base yes and live if you can yeah yeah because that lets you see beginning to end the whole process

for getting something out and that's important it also might point out like oh this process is horrible and i feel like i can improve it so we can make it go a lot faster yeah yeah i feel like joining an early stage startup is a it's a weird mix of like there's some stuff established already there's some stuff that was decided when it was a one-person startup and hasn't scaled but no one has had time to change it and so there there probably are opportunities for being the person to point out hey we can go faster now at our scale if we if we do this thing it worked when it was just the one person but yeah yeah yeah like our look out for like our vp can't code review everything anymore yeah yeah well that one i mean this is only 20 to 30 people and those aren't even all

developers probably yeah the other vp could do it at 60 to 80 so you got plenty of room that's heavy scale yeah that's that's true plenty room to grow i think um one other piece of advice for joining a startup is be willing to go with the flow and change direction or roles spontaneously. What worked yesterday might not work today. And you might find yourself having to do completely unrelated things because it's a startup and we're all in this together trying to get this thing going. And that means you might not necessarily get to do the very comfortable, get a ticket, work the ticket, submit the code, next ticket process that you maybe have become used to at a 300 person company yeah it might be a lot more open-ended you might have to do more discovery or

deciding or defining also i think it is more important at a startup to talk to everybody no matter what they do and kind of learn how it's much more likely that an engineer at a startup will be working with like sales or customer success or finance or whatever other roles there are at the company than a much larger company where they're much more siloed off That's part of the fun. Yes, it is fun. I really enjoy that. Also, I'll say that startups are often more open to change than big companies.

And sometimes changing the way things work is actually the path to productivity. But at a big company, changing the way things work is a great way to take on a ton of overhead and prevent productivity. So when I worked at OmegaCo, the absolute best thing I could do for my team to move fast is to adopt processes and practices that were already widely adopted at the company. And yeah, maybe it's not your favorite programming language or web framework or your favorite database, but it is well understood, will not get any pushback from anyone, and will just flow smoothly. Whereas at a startup, this might actually be the time when you need to make some pretty

significant changes like, hey, this database doesn't work well for this application or this process doesn't work well let's change it and the change cost is really really or the switching cost i guess you would call that is very low typically compared to what it would be at a large company yeah yeah there's not the embedded no one's job depends on on it keeping the same behavior yeah exactly well i think this will be fun i think you will learn a lot of stuff i agree have we answered this question i think so all right what can people do if they want their own questions answered. Go to softskills.audio and click the ask a question button where you can fill out our form. We want to express our deeply heartfelt gratitude to everyone who does

that each week. We really appreciate all the questions that come in. I only have surface level false gratitude for them, but I will continue. I will try to develop deep heartfelt gratitude. Nice. All right. Thank you so much. We will catch you next week.