Is It Weird If My Boss Is A Product Manager If I'm An Engineer?

Transcript is auto-generated and may contain errors.

Hey folks, today we're going to the experienced devs subreddit and this topic is is it normal for the product owner or product manager to be your boss? So this Redditor was saying that recently their uh their manager was uh let go or left the company or something and um what leadership at the company has done is instead now made the uh the product manager that was working with this team uh basically the the the new manager of of the engineers. So uh essentially if I don't know how many teams there are but uh the engineers at least for one of the teams maybe it's the whole engineering org now report into a product manager and there is no engineering manager replacement. My assumption based on reading this is like there's actually no plan for an engineering manager replacement. It's kind of like, hey, we're just going uh this path forward.

So, this Redditor was asking like, hey, is this is this normal? What's up with that? And then, um right at the end of the post, they end up saying something along the lines of like, by the way, for context, like this is a a company that's primarily a marketing company. And then, um they were saying maybe maybe that's a factor or a difference. And I think that's an important thing to to call out as well cuz I always think context is helpful. um you know we talk about many different software engineering topics on this channel and uh I think that's always important to keep in mind right is that whether it's a small company huge company a company that is uh you know uh effectively 100% a software company versus you know a company that is some other product or service first and then software is an aspect of it.

There's so many different things to think about as we go through these topics, but I think that framing is uh genuinely helpful. um it might not might not be applicable in in your case, but I think that's also why it's helpful to kind of understand because if you hear the topics or in this case, if I'm reading through a post, if if I have very much like a I don't know, like a strong reaction to it, like oh man, like what the heck is that? Um, I think understanding if the context is very different than something I'm used to is a is a helpful thing. So, when I was thinking about what I wanted to cover for this topic in particular, uh I still don't know what the right word is, but I one of like the meta points that I want to make sure

that I get across is that I do think it's really important in a in a team, an organization to have um like I want to use the word conflict, but conflict is like too almost too strong. I'm gonna I'm going to use it and hopefully I come up with a better word as I'm talking. I don't know why. Maybe my brain isn't working because it's Monday, but I think it's very important to have uh healthy conflict between uh engineering and product. This is my opinion on this. Um, and so the the meta point being that if you only have engineering representation or only have product representation, there's not a diverse enough perspective to be able to focus on um like genuinely what matters for getting done. And to oversimplify and exaggerate, if you have only a product focus, you're going to be stuck in uh arguably like a a feature factory hell.

And if you only have an engineering focus, to exaggerate the other way, you're you're only going to be stuck in like a uh tech and architecture um refactoring hell without, you know, delivering features. So um obviously these are exaggerations on on both ends to an extreme. Uh but I I believe that you need healthy conflict between uh these two uh these two groups that are are motivated by by different priorities. So what does that mean? So in this person's case, they're going from having what I would call more traditional where you have uh engineers reporting up to an engineering manager and then the the product manager works with uh the team, right? So there's a difference between like a reporting structure and um and the fact that you can still have I don't know like influence on the product right so yes a product manager

will absolutely be working on uh set helping understand and set priorities based on what customers and sort of industry is is asking for right so which direction should the product and service be going in uh helping translate what users are asking for whether that's specific users, groups of users or um you know demographics uh and you know that can often mean that product managers are working with sales and marketing folks as well. So they bridge a lot of that side and so the engineers like in a traditional org aren't reporting to that person necessarily from like a career development perspective and that kind of stuff. So they do report into an engineering manager and then the engineering manager also works with the product manager in terms of setting you know specific priorities to go focus on.

Um so it is like a a partnership I would say and I've worked in different places where uh the amount of amount of ownership I guess is very much something that moves between you know those two two roles as an example. So, uh, let me see. Just to help paint a picture, when I was working at a digital forensics company, I would say that I'm trying to think like probably probably most of the time yeah probably most of the time uh you know product management would be setting the direction of the product and and ultimately like make it very clear like in conversations that these are really the things that we need to deliver. And that would come again from this uh this point of sitting in between like engineering, sales and marketing and the customers. Um, a lot of the time we would uh ship monthly and there were also some like large conferences that we'd prep for.

So product managers would be working on like what things do we need to try and deliver for those. So they'd be setting more of the road map and then obviously uh from the engineering side as an engineering manager and a software engineer be trying to make that a reality. So we would also try to bring up like tech debt architecture, things like that. So we'd always have to in a in a healthy way, right? Like push back on the asks to say, "Hey, like you want these things done, but like you may not understand like the sort of the details of what has to go into that for us to do a a good job. So like we have to represent that side and then there's back and forth and we come to like a middle ground." So, I think for a lot of it, I'm It's kind of funny now that I'm thinking about this.

I never felt like I didn't have input and control over like what my team teams were doing. But definitely, I think a lot of it was set by product, but we had a really good like in my opinion a really good working relationship between engineering and product. coming to Microsoft on the first platform team I was on. So deployment in uh Microsoft 365 we had um we had really good product managers like I I don't remember having bad interactions at all with my product managers and um I'm just trying to think like the the organization changed a lot though in the time I was there on the deployment team and this is an important detail because in the beginning It was very much like engineering managers are are quite literally defining like what is going to happen. It was it to me it was it felt like dictated by the engineering managers to be able to to set the road map make it happen.

And the product managers there were very much like this is I'm using the wrong words cuz they're too strong. So I apologize but the pro it felt like the product managers were in service of what that vision was. So very much the the inverse of what I was saying. So it was like engineering managers would set the road map. Here's the priorities we're going to work on and then product managers would help facilitate that. So especially if there were cross team interactions like they would you know jump into those and you know go work with other product managers across teams make sure that priorities and uh dependencies were sorted out. So then partway through there was a reorg and things changed dramatically. So it went from being like feeling 100% engineering manager run to the opposite. So I've and like when I say the org changed I mean like literally our our our product management uh entirely changed and that that working interaction.

So then the product managers were 100% setting every priority, work stream, deliverable, um, and almost to the point where it felt like I didn't even have any say in in what was going to be going on. So a complete 180, which is very very interesting. And then on the the team that I'm on now, um, sort of depends on like it's a bit of a hybrid. I feel like I have uh significantly more say in like what the team is going to be working on. I would say to me it feels like uh I don't know very much in control of that. And then the product managers are doing a really good job bridging like the the business needs down.

So like you know if we have to do certain initiatives to to save on uh certain spend or if we have I don't know performance goals that we need to hit like they're bringing that and saying cool like this is the ask but like from the engineering side like how are you going to make it happen right so uh a balance the other way so it it it changes even in my career so far very uh significantly depending on the situation. And I'm sharing all this because if you're thinking about what does this mean for engineers that report up to people in these situations? I got to switch one more lane here. Sorry. looking for an opening and I can't think at this the same time. Here we go. Okay. So, I think there's going to be a couple of weird things that happen on a team like this.

And it's not that it's impossible or whatever cuz I'm going to share one more thing before I get out to go to CrossFit. But I think one thing that's going to be weird is in terms of career development. if you have a a product manager that's managing engineers, um they were saying in this case that the the product manager is not technical at all. So I think that can be very challenging from a career development perspective. Uh not impossible, right? I think you could have a a very good manager that is not necessarily super technical. Um a lot of people will disagree with that. I have had non-technical managers that I thought were amazing. um there's just different sets of characteristics that they can really help with that. But I think if they're non-technical and then unable to effectively communicate with technical people, that makes it very challenging.

Uh when your manager is like that, um you know, it's hard to feel relatable to your manager if you're like, I don't think they can understand the things that I'm talking about. I don't think they understand career progression as a software engineer. Um, even if they do and you don't feel that way, like it's hard to build the trust and respect that way and that makes that working relationship very challenging. So, I think that's one part is like career development can look and feel pretty weird in a situation like that. Again, not that it's impossible. And then I think the other thing is that from a delivery perspective, right, this is most of the stuff that I was hinting at before. I think you lose a lot of the engineering um representation that goes into um priorities. And again, it's not that this is impossible to make work, right?

So my point is that in a in a structure like that they're dropping out the perspective of you know uh someone in a position who's helping set what the team should be doing. the dropping of the engineering focus of that, the engineering emphasis and then you get a product focus there which again not impossible to have this work but even in the Reddit comments like people get ready for you know get ready for the feature factory and what they mean by that is like get ready for the pressure of like hey like more and more features less and less time for things that like help ensure that your code base is not becoming more and more brittle. Right. So, I think those are two major challenges that I can see happening with that. And again, it's not that I want to spend the last little bit talking about like why I think that's not impossible to work.

Okay. So, um would I like a situation like this? No. But um I was already kind of hinting that from the career development perspective, I absolutely think that you can have um non-technical people uh lead engineering teams from a career development perspective. Uh, so I think that if you're in this situation and you're not immediately trying to like leave or find an alternative, I would make sure that you spend some time in the beginning to help make sure that you and your manager, this product manager, have clear, effective communication that you understand like at what level you need to communicate things to them so they get it right. If you're talking about classes in code and things like that, they might have no idea what you're talking about and no interest. So, you're going to have to quickly learn effective ways to communicate with them. And ideally, they would be doing the same, but you don't control that.

What you can control um is how you're communicating with them and then sharing with them different ways that are effective to communicate back with you. Um, and that's really important when you're trying to set expectations uh in conversations, right? So, if if you and your manager are not seeing eye to eye on what things are, you're going to have to make sure that your communication is very clear. I think from a roadmap perspective, right, this can work as well. Um, so if you don't have an engineering manager representing engineers on that, are there architects? Are there tech leads? um is the product manager who's leading these groups uh now you know trying to I don't know get input from the engineers on the team based on where the tech debt is uh how should we do we need to rearchitect certain parts of the system

how does that all play together because it's you know on the surface it sounds like it's easy enough for them to just like ignore it and not ask so if they're not the ones asking because they may not know. It's hard for them to to know all the technical engineering side if that's not their focus. How do you and the other engineers make sure that that's brought to the surface? Right? If if we can sit here saying, "Hey, they're probably not going to ask about it." And then we have a couple of options. One is to sit and sulk and be like, "Wow, that sucks. I guess we're going to be a feature factory. I guess we'll never work on any tech debt or, you know, improve our test infrastructure or or rearchitect things. You can take that approach or you can say, hey, they're probably not going to ask about those things because they don't know about those things.

So, we should be proactive in making sure that we're bringing it up. I think that's a more helpful strategy. Um, I think at least that's something that's in your control to be able to bring up. Now whether or not they choose to take that input, different story, but I think ultimately that's the part you control is making sure that that is brought up being conveyed um the pros and cons, risk analysis, things like that for those areas that you know they're they're not going to have good exposure to. And again, if they're if they're not willing to take that into perspective when it comes to prioritizing things and work streams that like maybe that is a sign that like, hey, that's not a a good spot to be long term, but at least that's the part that's in your control.

And just to kind of finish this this thought out because I'm at CrossFit here, but um I had a period in my career at the digital forensics company I was at where um this kind of thing happened at a larger scale. So the so I was an engineering manager. So it's not like my it's not exactly this but the VP of engineering was uh so left and then the interim VP of engineering was our our uh our product management leader. So we had product in charge of all of engineering, right? So similar but sort of a different level in the reporting hierarchy. And honestly, I think they were while I was there, they were the best they were the best VP of engineering even though it was interim uh that I had worked with, which is funny, right? Because the whole framing of this thing was like, oh, you know, having someone in uh from a product perspective, oh no, there's no engineering.

Uh I think that this person at least in my my eight years there was the best um engineering leader that I had um like at that level. I think there were different points in time where like my my direct boss was not a VP um and I had good leaders that way but um in terms of like the VP of engineering uh would have been the best and so if we dig into the characteristics of that like was he technical uh wasn't writing code not a software engineer but technical enough in terms of communication um did a really good job listening to the engineering side like I think very much understood that it needed to be a balance. We needed healthy conflict between product and engineering to prioritize properly and I think that I think that he just understood that so well and could communicate very effectively from from both the product and engineering side.

He could make it very clear if he wasn't understanding the technical details of something, right? Not not bullshitting you, but if you were explaining something and he was like, "Hey, I don't get it. Could you explain it a different way?" Like you you could very easily work with him on on things like that. Never felt frustrating. Um, but I think it was his, a lot of it was his willingness to like make sure that he actively took in engineering concerns and not just like, hey, product folks got together and said, we got to go do ABC through Z and ship it by next week, so figure it out. Um, but yeah, so just just an example for you where I had someone in a product role uh overseeing all of engineering, and I thought they did a tremendous job. Um, and even from a career development perspective when I was reporting into them, I always felt very well supported.

Um, so my point here is like I think it's it's not an absolute deal breakaker. I think statistically I probably got very lucky. I think more often than not it probably doesn't work out super stellar, but I think if you're aware of some of the parts that you can control and influence, um, you can try to play that part. And uh if that doesn't pan out, then I would say yeah, maybe it's time to go uh looking for a spot where engineering is going to be represented. So, hope that helps. Thanks for watching. I will see you in the next video. Take care.