When Your Product Manager Becomes Your Boss

Dev Leader Weekly 146

Jun 28, 2026

TL; DR:

Healthy conflict between product and engineering matters
A non-technical boss isn’t an automatic dealbreaker
Surface tech debt before it gets ignored
Join me for the live stream (or watch the recording) on Monday, June 29 at 7:00 PM Pacific!

When Your Product Manager Becomes Your Boss

This week’s topic comes from a post over on the ExperiencedDevs subreddit, and it’s a good one: is it normal for the product owner or product manager to be your boss? The person who posted it had their engineering manager leave -- and instead of backfilling that role, leadership made the product manager who already worked with the team the new manager of the engineers. So now the engineers report into a product manager, and as far as I can tell there’s no engineering manager replacement coming. That’s just the path forward. They were asking the obvious question: is this normal, and what should I make of it?

You can check out my full thoughts on this in the video below:

One Detail Changes the Whole Picture

Right at the end of the post, they dropped in a piece of context that I think matters a lot: this is a company that’s primarily a marketing company. Software is an aspect of what they do, not the whole business. And they wondered if maybe that was a factor.

I think it’s a huge factor, and I want to call out why I love that they included it. We talk about a ton of different software engineering topics, and the right answer almost always depends on the situation. A tiny startup is not a giant enterprise. A company that’s effectively 100% a software business is not the same as a company where software supports some other product or service. When I read something like this and feel a strong gut reaction -- wait, what the heck is that? -- the most useful thing I can do is check whether the context is just very different from what I’m used to. It usually is. So keep that in mind as I share my take: your situation might not map cleanly onto mine, and that’s exactly the point.

Why You Actually Want Conflict Between Product and Engineering

Here’s the meta point I really want to land, because everything else hangs off of it. I think it’s genuinely important for a team or an organization to have healthy conflict between engineering and product. “Conflict” is almost too strong a word -- think of it as healthy tension between two groups motivated by different priorities.

If you only have product representation, you get pulled toward what I’d only half-jokingly call feature factory hell -- crank out features, crank out more features, and never make space for the work that keeps the foundation from getting brittle. Flip it around: if you only have engineering representation, you exaggerate the other way into tech-debt-and-architecture hell, endlessly refactoring and re-architecting while shipping very little customer value. Both extremes are caricatures, obviously. But that’s the whole reason you want both voices in the room. They pull against each other, and that tension is what keeps you focused on what actually matters: shipping real value without quietly rotting the codebase.

So when a team loses its engineering manager and folds entirely under product, my first concern isn’t “a PM can’t manage people.” It’s “who’s representing the engineering side of that tension now?”

The Traditional Setup, and What’s Really Shifting

In a more traditional org, engineers report up to an engineering manager, and the product manager works with the team. Those are two different things, and it’s worth separating them. The product manager absolutely helps understand and set priorities -- they’re translating what customers and the broader industry are asking for, figuring out which direction the product should go, and often bridging into sales and marketing. But the engineers aren’t reporting to that person for career development. They report to an engineering manager, and the engineering manager partners with the product manager on what to actually go focus on. If you want my full breakdown of that role, I wrote about what’s actually expected of an engineering manager.

What’s changing in this Redditor’s case is that the reporting line and the engineering representation are both collapsing into the product manager. The partnership tension I just described doesn’t have an obvious counterweight anymore.

Ownership Moves Around -- a Lot

I want to paint a picture from my own career, because the balance between product and engineering is not fixed. It moves.

Back when I worked at a digital forensics company before I landed at Microsoft, most of the time product management set the direction of the product and made it very clear what we needed to deliver -- they sat between engineering, sales, marketing, and customers. We shipped monthly, and we’d prep hard for some big conferences, so product would shape a lot of the roadmap around those. From the engineering side, as an engineering manager and a software engineer, our job was to make it real -- and to push back in a healthy way. “You want these things, but you may not see all the detail that goes into doing them well, so let us represent that side.” Then we’d meet in the middle. Funny thing is, even though a lot was set by product, I never felt like I lacked input or control. We just had a genuinely good working relationship.

Then I came to Microsoft, onto a deployment platform team in Microsoft 365. Early on, it felt almost the opposite -- engineering managers were quite literally defining the roadmap, and the product managers were there to facilitate that vision, jumping into cross-team dependencies and smoothing things out. Then there was a reorg, and it flipped dramatically. Product went from facilitating to owning every priority, work stream, and deliverable -- to the point where it sometimes felt like I barely had a say. A complete 180, on the same org, in the span of a few years.

On the team I’m on now, it’s more of a hybrid. I feel like I have a lot of say in what we work on, and the product managers do a great job bridging the business needs down -- “here’s the initiative, here’s the spend or performance goal we need to hit” -- and then leaving the how to engineering. Three very different balances, all in one career. So when someone asks “is it normal for product to run things?” -- honestly, the ratio swings all over the place depending on where you are.

The Two Things That Get Weird

So what actually gets harder when a product manager is directly managing engineers? I see two big ones.

Career development. In this case the poster said their PM isn’t technical at all. That can make career growth genuinely tricky. Not impossible -- I want to be careful here, because I’ve had non-technical managers I thought were fantastic, and plenty of people will disagree with me on that. There are real strengths a non-technical manager can bring. The hard version is when someone is non-technical and struggles to communicate effectively with technical people. That’s when it gets rough -- it’s hard to feel relatable to a manager when you don’t think they can follow what you’re working on or understand what career progression looks like for an engineer. Even if they actually do get it, that gap erodes the trust and respect that make the relationship work. I went deeper on how you even evaluate this in measuring manager effectiveness.

Delivery and representation. This is the thread running through everything above. When you drop the engineering voice out of priority-setting, you lose the person who’s supposed to argue for the foundation. You’re left with a product focus -- and like a bunch of the Reddit commenters warned, get ready for the feature factory: more and more features, less and less room for the work that keeps your base from getting brittle. It’s not that it can’t work. It’s that the structure quietly removes the counterweight. Getting non-feature work onto the roadmap is already hard enough with an engineering manager in the room -- I broke down that whole battle in how to get tech debt prioritized.

How You Actually Make It Work

Here’s the part I care about most, because it’s the part you can control. If you’re in this spot and you’re not immediately heading for the door, do two things.

First, invest early in communication. Figure out how to talk to this manager so they actually get it. If you start going on about classes and code structure, a non-technical PM may have no idea what you mean and no interest in it. So learn -- quickly -- the level you need to communicate at, and ideally help them learn how to communicate effectively back to you. You don’t control their half of that, but you fully control yours, and getting this right is what lets you set clear expectations when you’re not seeing eye to eye. This, by the way, is the exact skill I’d argue separates good developers from great ones -- being able to translate technical reality for a non-technical audience.

Second, be proactive about surfacing the engineering side. A non-technical product manager probably isn’t going to ask, “hey, where’s our tech debt, do we need to re-architect anything?” -- not out of malice, but because it’s genuinely not on their radar. So you’ve got two options. You can sit and sulk -- “well, I guess we’re a feature factory forever, no tech debt work, no improving our test infrastructure, no re-architecting.” Or you can say: they’re not going to ask because they don’t know to ask, so we’ll bring it up. Lay out the pros, cons, and risks for the areas they don’t have exposure to. Whether they act on it is a separate story -- but the part you control is making sure it gets raised. And if they consistently won’t factor it in when prioritizing? That itself is a useful signal about whether this is a good long-term fit.

My Best Boss Was a Product Leader Running Engineering

I’ll leave you with a story that complicates the whole “product running engineering is bad” narrative. At that same digital forensics company, there was a stretch where our VP of engineering left, and the interim VP of engineering was our product management leader. So product was, quite literally, in charge of all of engineering -- a different level in the hierarchy than this Reddit situation, but the same basic shape.

And honestly? In my eight years there, that person was the best engineering leader I worked with at that level. Which sounds wild given the framing of “oh no, product is in charge, there’s no engineering voice.” So what made it work? He wasn’t writing code and wasn’t a software engineer, but he was technical enough in how he communicated. He listened to the engineering side. He clearly understood that you need that healthy conflict between product and engineering to prioritize well. And when he didn’t follow a technical detail, he’d just say so -- “I don’t get it, can you explain it a different way?” -- no bluffing, never frustrating to work with. A lot of it came down to his willingness to genuinely take in engineering concerns instead of just handing down “product decided, go ship it by next week, figure it out.” Even reporting into him, I always felt well supported in my own growth.

So, Is It Normal -- and Should You Worry?

My honest read: it’s not an absolute dealbreaker, but I’d also be lying if I said I’d love being in this exact situation. I think statistically I got pretty lucky with that interim VP, and more often than not, I suspect this setup doesn’t pan out quite as well. But the outcome isn’t fully out of your hands. If you’re aware of the parts you can influence -- communicating in a way your manager actually understands, and proactively making sure engineering concerns reach the prioritization table -- you can tilt the odds. And if you give that a real shot and it still doesn’t work? Then yeah, it’s probably time to go find a place where engineering gets a seat at the table.

If you’ve got a situation like this you’re wrestling with, you can submit it anonymously over at codecommute.com and I’ll do my best to make a video response. Hope this one helps.

Dev Leader Weekly

Discussion about this post

Ready for more?