Patch It with a Product Manager
Engineering leaders are burning out. Product managers started earlier, and for different reasons.
The other day, Gergely Orosz wrote a short but pointed thread about why CTOs and VPs of Engineering burn out and leave. Naturally, every CTO and VP of Engineering — and plenty of other people — recognized themselves in it, reposted it, and started giving one another survival advice. I read it too and, of course, thought about myself and, more broadly, about all the product managers I know.
We have always been taught that our bread and butter, our main tool, is influence without authority. You do not manage anyone, but you still tell people what to do, because you do not give orders — you persuade. You have no real power, but you have credibility, soft skills, the ability to herd cats, all of that. You are a mini-CEO. No one will give you CEO authority, but you have to influence without that authority.
It already seemed like something of a dubious idea before, but now it feels particularly stark. Influence without authority does not exist. There is only absorbing consequences without authority.
Construction material
Judging by conversations with colleagues, I have a persistent sense that the product manager in a modern company is a construction material, something between sealant and expanding foam. You can pour one into any hole, and they will close it. Missing an analyst? Patch it with a product manager. Customer success has got into another fight with engineering? Patch it with a product manager. Nobody figured out who is responsible for onboarding users to new features? Well, you get the idea.
And the product manager can sort all of this out! That is precisely the problem. If they failed to sort it out even once, someone would have to notice the hole. It is all that same “sock work” I have written about before: nobody notices it while it is being done, but the moment you do not do it, it is your fault.
The Work That Looks Like Luck
This morning I conducted an audit of my sock drawer and found twenty-three of them in there. Twenty-three is a prime number, indivisible, and in this case, unfortunately, odd. Which means that somewhere in the apartment or in the interdimensional fold specifically engineered by nature for the disappearance of single socks, a twelfth sock is leading an a…
So I suspect that, disguised as the attractive idea of influence without authority, which even I once wrote some posts about, we were sold a way to plug holes in organizational design with one person, for free.
“Well then, build a system!”
Yes, the favorite response to this complaint. Fine, let us talk about the system.
Today, this really can be automated. In one evening, you can build a tool that retains the context of meetings, Slack, JIRA, Notion, and goodness knows what else, and answers questions like, “Why did we decide to make the button red back then?” For the first time in history, this is technically quite easy to do, and from a product perspective, it is even an interesting problem: account for all the stakeholders, create the minimum set of skills, and so on. Except a system is worth exactly as much as the number of people who use it. And people use it only to the extent that it benefits them. And what is easier — going into a new system or messaging the product manager privately? In other words, it is a question of incentives. Which the product manager does not control, because although they are supposedly a mini-CEO, they have no direct reports.
In other words, every door in this profession opens with a different key, but those keys always belong to someone else.
Prioritization was never the problem
Here is my next hot take: prioritization has never been a difficult problem. Honestly. At any given moment, everyone in a company has a rough understanding of which problems need to be solved. And if you look at things soberly, there are usually three possible solutions, not thirty. For twenty years, we have been grinding through RICE, ICE, Kano-whatever, two-by-two matrices, and Miro boards covered in sticky notes in a hundred and fifty colors, while always having a fairly good idea before starting any of these exercises what we would be working on next quarter.
Plotting things along “impact/effort” axes is not exactly rocket science. As for the more difficult part, I think a senior product leader is responsible for three systems. Everything else follows from them.
The truth system: how, and how quickly, the company learns what is actually happening with the customer and the product.
The commitment system: how that knowledge is turned into a small number of completely specific promises.
The learning system: how quickly the company can admit that it was wrong (or that it was right), and change direction (or double down).
Almost every product dysfunction I have seen was a failure of one of these three systems. And none of them can be fixed with a new prioritization framework.
Discount autonomy
Middle management is now being spread upward and downward: some responsibilities are moving to the C-level, and others to the people doing the hands-on work. I like one side of this, and I will not pretend otherwise. Less of the layer that repackaged other people’s slides and did nothing useful. More hands-on work. Fewer approvals. Great.
But it is also a very effective way to pay very senior people less. Remove one level, and someone with fifteen years of experience ends up doing the work of two people. It gets a nice name: HI-IC. Autonomy! Speed! No bureaucracy, you are your own boss. And a salary that is 25 percent lower.
Engineering leaders can escape this through fractional consulting, Orosz writes. Product managers have fewer options. We can either work as strategic consultants or do hands-on work part-time. The first option is not too bad, but you need to understand from the outset that you will be working as the founder’s therapist, not as a product consultant. Once you accept that, it is fine. Product managers vary in how good they are at therapy, of course, but they know how to listen actively, and there is not all that much more required. The second option is terrible, because you do the same work you would do full-time, but for one-fifth of the salary, because “you only work 40 hours a month!” Avoid this whenever possible.
“This is what we’re building”
And finally — founder mode. When the CEO returns to operations, the CTO loses autonomy. Frustrating, but the founder understands that if production goes down, fixing it with Claude Code is unlikely to work.
The product-specific problem is a setup where every founder intuition becomes an immediate commitment, while product is still expected to validate it, coordinate it, and make the outcome look intentional. So the PM becomes a kind of narrative and organizational middleware, translating impulses into strategy.
And somehow, suspiciously often, it turns out that good product taste is rarer among founders than the founder-mode posts would have you believe. Much more often it's the taste of a person who badly wants things to turn out exactly the way the neural net convinced them they would.
Also: a CTO can leave a company with a bad strategy because they were responsible only for the technical side. A product person looks as though they were the one who came up with the bad strategy, even if the decisions were made without them. They leave with it on their résumé.
This is where I am supposed to offer some survival advice, e.g.:
Understand your PM persona
Manage up
Build trust
Set boundaries
Pick your battles
When you cannot win the battles you’ve picked, quit early…
I don’t have any advice. But do keep influencing (without authority, of course), the consequences are not going to absorb themselves. And if you can, find yourself some genuinely interesting interests outside work.