Soft Skills Engineering - Episode 229: Other people's code and moving into product management

Episode Date: September 28, 2020

In this episode, Dave and Jamison answer these questions: Questions I have been working at a large tech company for two years now, after I graduated college. My job title is ““Software Engineer””, but I have barely written any code on my job in the past two years. I’m on a product team that doesn’t own any infrastructure, and when the product managers want us to build something, we find out which teams in the company own the infrastructure and stitch a product together. We often get push backs because usually the infrastructure we need to build a product belong to some entirely different team who do not have stakes in the product we’re building. I am worried that my coding skills are deteriorating, since most of my time at work are not spent on coding. For example, meetings where people hash out how to do something in a system none of us are familiar with, chasing down people in other teams to ask them to squeeze out time from their busy schedule to help my team, and completing process paperwork. On the rare occasions when I do make code changes, it’s been copy-and-pasting another section of the code/config and changing a few parameters. It seems to me that success on this job depends mostly on knowledge of the different internal systems, as well as the social capital of knowing people on different teams. Is this normal? Is this what software engineering is about? Hi there! Love the show and your fun but useful answers. I have a career question and would love to hear what you think. I’ve been an Engineer for several years now and was recently asked if I’d like to move into Product Management. At first this sounded great. I’d get to set the direction of the product, get involved with strategic planning and roadmap meetings, and generally have more input into my squads work. The thing is … that isn’t what it is at all. Most of the time I am fielding requests from marketing and sales people for sales collateral, sitting on customer calls, and digging through dashboards to find enough ‘evidence’ to prove why we should prioritize the backlog the way I have in mind, and I have even become the ‘bad guy’ when the squads ideas don’t line up with the Product team. Have I made a terrible mistake? Is Product Management really a good move for Engineers?

it takes more than arguing about self-documenting code to be a great engineer this is episode 229 of the soft skills engineering podcast i am your host jameson dance i am your host and self-documenting host dave smith soft skills engineering is a weekly advice show where we answer your non-technical questions about the technical field of software development and just now i landed on a new technique to write self-documenting code and what's that Are you ready for it? Yeah. So you write your code and then you make a comment and you copy and paste the code into

the comment up above the code. So the code is the documentation. Oh, perfect. And the comment never lies that way. No. It literally says exactly what the code does. Yeah, it does. It tells you everything you need to know about the execution of that code.

Yes. It needs a name for that methodology. Stupid. book learning programming there's literate programming and this is like the less sophisticated street smart what's literate programming so i don't know this is the first answer but the second answer is on wikipedia i've read that it is sort of like writing your code as a prose document with executable code kind of interspersed in between do you have like a rising action a climax and falling action an epilogue yeah the hero's journey of this request all the

way to the database what if you were a master fiction author and then you pivoted your career into software development your code would be incredible bet you didn't see this plot twist coming it's a fault out of nowhere side effects yeah you didn't see that array index out of bounds exception coming what a plot twist now the cliffhanger that's called the halting problem you just randomly jump to another function yep you can never tell what's going to happen next do you want to thank our patrons dave i do thank you so much to those that are contributing at the level where we shout them out every week

on patreon they are oladapo fadiyi piarans vaneson ragnar harteson alexander microconfig.io nick travis sanders evgeny sladkowski dennis bogdanov braden kane steven armand lee john grant luke bayless philip john basile the agile ventures charity sean and vin lock if you would like to join this illustrious crew you can go to soft skills.audio and click support us on patreon and if you do that we'll give you access to our slack community which is just a fantastic place to come and chat and have some laughs with people who are like-minded software developers and pretty good pretty good cross-section there of different disciplines too i've noticed which is kind of cool yeah i learned stuff technically culturally learn all kinds of stuff from that group thank you i'm

going to read our first question i encourage you to do so okay i will accept the encouragement though even if i didn't ask permission this is from an anonymous listener i have been working at a large tech company for two years now after graduating college my job title is software engineer but i have barely written any code on my job in the last two years i'm on a product team that doesn't own any infrastructure and when the product managers want us to build something we find out which teams in the company own the infrastructure and stitch a product together we often get pushback because usually the infrastructure we need to build belongs to some entirely different team who do not have stakes in the product we're building i am worried that my

coding skills are deteriorating since most of my time at work is not spent on coding for example meetings where people hash out how to do something in a system none of us are familiar with chasing down people and other teams to ask them to squeeze time out of their busy schedule to help my team and completing process paperwork on the rare occasion when i do make code changes it's been copy pasting another section of the code slash config and changing a few parameters it seems to me that success in this job depends mostly on knowledge of the different internal systems as well as the social capital of knowing people on different teams is this normal is this what software engineering is about oof wow okay can i just say this question asker is very perceptive

i mean not just perceptive but i would say tuned in to what success takes here where where they say That the key to success here is knowledge of these other systems and social capital in other words influencing other teams to do stuff Yeah, that's really cool. Yeah, I work at a really large company It's not quite like this But I have noticed that you can get pretty far by knowing a lot about internal systems and knowing who to ask other questions as well I mean if the graph of stuff you have to navigate is larger Knowing more about that graph will help you like at a startup. I'm trying to think back to it I feel like my time was focused on the problem domain quite a bit

yeah and on like how to implement stuff in the problem domain and here my time is focused a lot more on like how to use all the different tools to solve the problem domain ah that is in and of itself a problem domain yeah it is actually yeah it actually you're right i have i have met a skill that i've noticed yes that has developed where it's easier for me to explore this social graph and and i find out faster who owns what thing and stuff like that and then do you also have like a bank account of favors that you can call in to get things done uh yeah got my little black book yep my rolodex yep i guess there's two ways i can go favors that you can call in meaning you've done good things for people or just knowledge that these other people would rather not have public

yeah skeletons in the closet yep yeah that's true there is a level of cognitive overhead and I've heard this called a big company tax for getting things done in big companies and I definitely have felt that where it's like I could go do this and if I was at a startup I absolutely would because there would be no one else to ask but instead I'm going to have to go get on someone's calendar

convince them to shuffle their roadmap around for my benefit and boy have I developed some techniques for doing this I just want to hear about those techniques I don't want to tell you it actually makes me sad to even think about it it's so true you lie awake at night thinking about the stuff you've had to do to get your priority item on someone's q1 roadmap exactly exactly am i still a good person okay so as long as we're here let me just share one thing you know it it is true it is absolutely

true that a commitment from a team member on a team that you don't belong to is not truly a commitment until you have the buy-in of the leadership chain of that person like it's it's a flimsy promise at best and so i've developed techniques for solidifying those commitments up the chain aha it's like well bob said he would build this but i'm going to check with bob's manager and bob's manager's manager and bob's director and i'm going to get them to say it in writing anyway but yeah so that is true is this what software engineering is about that's the question yeah well yes okay so the answer is yes and no to me i will give answers yes and no to this question it depends on your tenure so right out of college a couple years into your

career this is not what software engineering should be about i think that the best way to spend your time in your first few years out of college is building a technical knowledge base a foundation if you will to build on but as you grow and your scope of responsibility increases then yes this is what software engineering is about yeah when you're doing things that affect larger groups of people or that you need it's it's more than just your own brain sitting down to figure out how to do yeah and this is where it gets really squishy because it's about convincing people it's about understanding politics and what other people want you know it's it's tricky but absolutely necessary to get big things done yeah i mean i i work at a very

large company. There is some amount of figuring out who to talk to and finding out the way that this specific problem is solved in this organization. But most of my team's time is still spent like building stuff that we own. This sounds uniquely bad in that you don't own anything. I agree. And that's exactly true of my company as well, or of my, sorry, my immediate team. It's a big company, but most of the people I work with directly work on their own software, on their own products with control over their own destiny. But I do know of teams who don't actually own any software themselves,

which sounds like that's what this listener is in, this kind of situation. You know, we don't own anything we build. We don't own the infrastructure. We spend our time convincing other teams to build what we need. Yeah, I can see why the incentives don't align here. Like, I don't know, maybe there's some team

that owns a product that has a database and you're like, we don't have a database of our own. Let us piggyback off of your thing. And like, no, we don't want to be, we don't want to get paged because our stuff is down because you wrote a bad query or something like that like yeah yeah this is weird this is hard it is hard it's super hard to manage and it almost makes me think like you're you're turning into a glorified technical product manager where you have the technical chops to go interface with these other engineers on these other teams

yeah but really you're just giving them requirements hmm i mean i agree with your concern that it is it is bad that your technical skills are not developing i don't think all is lost though i think it would be good for you to move to a role where you're more directly creating things but you could probably be more effective in that role now because of the experience you've had where you've had to do a lot of investigating unfamiliar systems and getting groups of people to work together and stuff so you sort of like skipped the first half of your career where you're figuring out your technical knowledge base yep and kind of like done it backwards and you've You've developed the architect or principal or manager skills, but without the tech skills to

back it up. It's like when you're playing one of these video games where you have to level up certain skills and you did things kind of out of order. Yeah. But it'll make it really easy to go back to the earlier levels and just dominate. Just like jump over all the bad guys. Yeah, exactly. Because you press the jump button a million times. I'm so good at jumping. did you ever play oblivion no never heard of it it's an elder scrolls rpg and the way that skills work in that game is you get more skilled at a thing by doing it and some of the skills are like running so people would just rubber band their controllers so that their character just runs around for a long time to level up running it's like the easiest farming ever yeah just like the

most boring soul-sucking grind in the universe you can just go swim for 14 hours to get faster at swimming nice so that's what's happened here yeah so speaking of large corporate jobs that's right we should make a video game where you're actually an employee at a large corporate job and you have to level up these skills i think there's a game developer simulator oh wow but i don't think there's a corporate employee simulator i guess the stanley parable is sort of like that a little bit nobody would play it though because they'd be like i just got home from my big corporate job i don't want to do this again for the evening yeah but now you can act out your fantasy of like i don't know calling a meeting and everybody comes or whatever your

wild dreams are everyone shows up on time you're like oh your project is complete on time it's wild fantasies this is a power fantasy dave you ship a product no bugs customers love it no one's mad at you yeah you're like oh i love this game so much okay so what do you do here's my advice if i'm in this position two years into my career i am definitely getting out i think that at this point in your life it would be so much more rewarding and fun to build your own stuff and build a technical foundation of knowledge and not just be out convincing other people but like jameson said it's not a complete waste you've definitely develop some skills that will be useful future in your career so we haven't said how to get out

you can always quit your job always always always that's the the underlying bedrock of all the advice on this show but do you think there's a way that the question asker can maneuver their current role into something more hands-on technical building things well one thing you could do is all these other systems that you're supposed to go integrate with instead of integrating with them you could just re-implement them and then crowd out the other system and just say look we own that now yeah you see this database cluster that's my database cluster now you shouldn't let my software onto your onto your machines oh that's right you already have a trojan horse entry point they're letting you put like build stuff you could just be like hey i'm gonna slip you some code just

implement this don't worry about what it does it changes all the permissions to their service only your team can manage it perfect i'm a product team that doesn't own any infrastructure yeah this is interesting i mean i don't have any insight into how infrastructure works at your at your company but often the group that that there's some kind of operations group that manages the underlying pool of infrastructure and then you get to run your stuff on it so it's it's not the weirdest thing in the world to run in an environment that you don't own completely i mean i guess devops is trying to encourage that ownership stack to go deeper but there are a lot of places where it it doesn't it feels more like you don't have the freedom to make your own decisions about how to

build something yeah they say they have to stitch together like pieces of other people's products and and kind of piggyback off of them i guess this might be naive but what's to stop you from saying like the best way to implement this is to write a new service that does this thing or something like that you know and then write it yeah and then write it well nothing's to stop you from saying that it might not be true though ideally it would be true when you said it i have another suggestion here which is that one of the benefits of you getting to poke around and all this other code and interacting with all these other teams is you now have a really good vantage into how they operate and which ones would be good teams to work on and if one of them looks particularly

appealing and cool why don't you put in for an internal transfer and go join that team yeah that's true i've seen that happen before where folks that worked closely together just ended up switching on to the same team could be fun and it's a lot lower risk for you because you've seen how they operate that's like a lowercase q quit your job yeah because you're still technically changing jobs just right that was a big deal well i like it have we answered the question i think so at least good enough good enough okay do you want to read our next question dave sure this one also comes from an anonymous listener who says hi there love the show and your fun but useful answers that's debatable that should be an and right why is that a but fun but useful sometimes

useful and always fun okay i have a career question and would love to hear what you think i've been an engineer for several years and was recently asked if i'd like to move into product management at first this sounded great i'd get to set the direction of the product get involved with strategic planning and roadmap meetings and generally have more input into my squad's work The thing is, that isn't what it is at all. Most of the time, I am fielding requests from marketing and salespeople for sales collateral, sitting on customer calls and digging through dashboards to find enough, quote, evidence to prove why we should prioritize the backlog the way I have in mind. And I have even become the,

quote, bad guy when the squad's ideas don't line up with the product team. Have I made a terrible mistake? Is product management really a good move for engineers? and being president sounds like a good job such a good job like you just go to the white house nobody can tell you what to do just do whatever you want all day but really it's work and lots of the work sucks yep yeah i like this sentiment of i thought i could just be in charge and do what i wanted but it turns out that there are lots of demands on me i think that's a pretty common sentiment yeah it turns out convincing people is just as big a part of the job as as knowing the right thing to do in product management because there's a weird thing about product management

where like lots of people will not call themselves product managers but everybody has product ideas and nobody feels like they need some special qualification to have an idea to convince that it's the right idea right like engineering i mean yeah people usually have some kind of qualification or experience if they want to contribute that way but like everybody can use a thing and think of a way that it could be better so you have a lot more people who can potentially help you or just tap you on the shoulder and try and tell you why they have to do why you have to do their thing that's true and i think one of the big secrets of product management is that it really is in my opinion the hardest job of all the kind of horizontal functions that

go into creating software i think product management is the hardest why because they have to be able to interface with literally everyone in the rest of the company this person already has called it out they're getting pinged from sales and marketing they have to interface with support. They have to interface with the executive teams. They have to do a lot of convincing. And that makes their job very hard because it's not just about deciding what to build and then building it and shipping it. It's about all the other stuff that goes into making that a reality. Yeah. I thought it was interesting digging through dashboards to find enough evidence to prove why we should prioritize the backlog the way I have in mind. I've seen this go poorly

where in an environment of very low trust, because you can always ask for more evidence. I don't think there's ever like a super 100 clear absolute yeah direction that's just self-evident from looking at the product so true so i've seen people get stuck in this loop of like someone disagrees instead of saying i disagree and hashing it out they say show me some data and then i don't know there's some stuff you can't have data for like yeah you just gotta have a judgment call at some point so i could see that being frustrating exactly and if you don't give the data then and they can accuse you of not being data-driven. Yep, exactly, which is a cardinal sin.

You have to A-B test this new market somehow. Yes. Do and don't go into this new market and then show the percentage conversion rate change. The beauty of that is every dollar you make, you can say with a very low p-value that that dollar was due to the treatment of going into the market.

Yeah, I become the bad guy when the squad's ideas don't line up with the product team what do they mean by you think the squads ideas don't line up with the product team i assume isn't a squad from that spotify thing oh that's guilds right squad is some like agilely googling this the individual teams that make up a company in agile management are known as squads is this safe squads tribes and guilds this might be a safe thing i don't know okay so a squad is a spotify thing and it's like the cross-functional team that produces software together so it would include the product manager and engineers and qa and ui designers okay sounds

like you're set up to build spotify perfect did it copy the organization next comes the product squad's ideas don't line up i mean i've i've seen pretty it feels like a pretty normal thing to have some push and pull between product and engineering especially the more separate those are if if they're separate orgs where products might not have good insight into kind of technical debt or pain points. Engineering might not have customer data or the contact with salespeople. So there's, yeah, there's certainly some tension there. Product is naturally inclined to push for new shiny things over kind of like definitely over ripping things out and probably over making existing things better. Yeah. It sounds to me like this listener went into product management

thinking it was one thing, which I think a lot of people think it is and realize that it's actually so much more and now is wondering if they've made a big mistake. What do you think? Have they made a mistake? So it sounds like their goal for going into product management was having more influence over the direction of the product. And there's all this other stuff that has popped up like sales and evidence and handling disagreements between product and engineering. But I think a question that would be useful to answer is, but even despite all that stuff, like, do I still have more influence over the product in a way that i want because maybe maybe this is the price you pay to get that thing sometimes you deal with other stuff too right it's a good point if you

don't then it sounds way worse but if you if you do like yeah this is what it takes to influence the product you got to convince people that you're right and and kind of resolve conflicts when people disagree with you and that's a fair point handle sales because it turns out that people they want to sell the things so they get giant commissions and product helps that and yeah so i've seen two examples of people in their careers as engineers who wanted to have more control over something and more influence over something and found that it the best way for them to do that was to get adjacent to the role that they thought might have more control let me give let me give two examples so the first one is actually an example of a product manager this is an engineer

working on a team at a company I worked at. And we thought this person would be a great product manager. And so we offered that to them and they said, okay, but I'm only doing it for six months. You know, I'm interested in the idea of having more influence over this product. That sounds great. So six month trial period, and then we'll see how it went. Well, after six months, the engineer said, nope, I want to go back to being an engineer. And we respected that. And I think they discovered that really as an engineer, and in this case, more of like a team lead engineer role, they actually had more influence over the project, not necessarily more than the product manager, but enough to satisfy their desire while not having to deal

with like the 80% stuff that a product manager does that they didn't want to do. So that was the first example of getting adjacent to the roles. It was more of like a tech lead role than a product manager. The second example is a friend of mine who loves having influence over engineering teams and building great culture, but hates management. They also tried becoming a manager and after a few months said, I don't want to do this and have since built a fantastic career as a manager's partner, still officially only in the role of a technical lead for the team. So they're still an engineer. They're not in management, but they have had such positive impact on several teams that I've observed them on where they fix things like culture problems. They've helped

resolve conflicts that normally you would think is only a manager's job, but they love it because they don't have all the management responsibility, but they can still influence the team. So I think sometimes when you want to have influence over an area, you might be surprised to learn that getting adjacent to the official role is actually more beneficial than being in that official role. I think we've talked about this before, but there's this thing that happens when you're an engineer and you contribute to the product where you get lots of kudos sometimes because people don't always expect it. If they've kind of got this model of what engineering is like in their head and then suddenly you want to meet with customers or something, then that's awesome. Oh,

an engineer who's super interested in product you're doing such a great job and then if you move into where that's your job you don't get the kudos as much anymore yeah they're like wow you're a really terrible product manager yeah yeah you can you can be doing the same amount of quality impact on the product but like the expectations are a lot different yeah so expectations management set yourself up to where failure looks pretty good yeah this also reminds me of the question we talked about last week about becoming there's somebody who who was trying to move into this tech lead role but wasn't given the title and the raise yeah and i think we we ended up talking a lot about this idea of a trial period where you kind of try it out so it's easy to back out and too late but

wouldn't it be great if this was a trial period yeah product management so you could say actually i don't like this that would be great once again it all comes to time travel i mean so many of our answers yeah just go back in time and do it different yeah that would solve a lot of problems and introduce some amazing paradoxes we never saw coming i mean what could possibly go wrong yeah i would like to be the agile time traveling consultant how's that what do you mean oh i don't know just make money by saying nonsense but it's related to time travel somehow i see keeping time keeping time travel within the time boxes yeah or like i don't know going back and tweaking the sprint commitment if you're a hardcore scrum group look like you always hit your numbers

by going back in time and telling you what to commit to is that the dumbest use of time travel you could possibly think of it feels like it is i wanted time travel just so i can go adjust this field in jira yeah nothing else will change the only thing that will change is i'll be able to say i hit all my commitments by shrinking the denominator surely that couldn't have any unforeseen consequences yeah probably not i'm sure i'm sure it's safe i mean if time travel movies have taught me anything you can make small changes and not have huge impacts on the future yep okay i think i've used up all my brain power on this question okay you got anything else i mean i would say it's probably time to get out it sounds like this

is not what you wanted to do and you jumped into this job without knowing what it really involved and i would probably bail out i think you can achieve your goals outside of the product management realm and now you know yeah i have seen lots of engineers become successful product managers so it's not impossible they are good and they do tend to be the favorite product managers that the other engineers have ever worked with have you ever noticed that yeah i've heard you say that before but also i i know some folks who have gone into it and really enjoy it yeah it can be a very viable thing but it kind of takes a special special personality that's a little more rare in engineering i like this bold direction that you've set dave of of explicitly recommending

doing a thing instead of saying it depends and i'm gonna increase the contrast by saying it depends and being yeah i think you should look at if it's achieving your goals or not and if it's not then do a different thing but if it is just keep going you might also i mean this this is a dangerous road if it doesn't work out but you might also try be going into product management at a different company because product management varies a lot from company to company yeah all right now we've answered the question okay good work good work team yeah you did great what can people do if they want their own questions answered go over to softskills.audio in the worldwide web and click on ask a question we've got a little form you can fill out there thanks

so much to everyone who has done that we really appreciate all the questions we get one day we will get to all of them although at the current rate that will never happen so you have to slow down or we'll have to speed up this is like the countable versus uncountable infinities okay how so for every episode we get like an uncountable number of questions yeah there's just they're they're both we will do the show forever and we will get questions forever but currently we have more infinity questions yes infinity showtime yes that's right all right think about that i guess that's your homework i'll leave you to ponder that we'll catch you next week