I Almost Became a Chemical Engineer. It Taught Me The Skills I Use to Impact Organizations.
Being right is not enough. Here's an approach to moving stuck systems at work.
Before I was a product leader, I was a chemical engineering student. I earned my bachelor’s and entered an MS/PhD program. I didn’t finish the PhD (but the Master’s was a good consolation prize). More importantly, what I learned about how systems work has shaped how I’ve moved through my career and the organizations I’ve found myself in.
Here’s what happened. I was a good student. I passed my classes, did research, even published a paper in the Journal of Magnetic Resonance Imaging. But the PhD qualifying exam was a different kind of test than anything I’d faced before — closed book, pure memorization of complex equations we’d always been allowed to look up. The first time I took it, I came close but didn’t pass. The second time, I had a panic attack. My mind went blank. I did worse.
I had walked into a system I didn’t yet know how to read. Around the same time, my advisor — the first female professor in the history of that department — was denied tenure. I didn’t have the language for any of it then, but looking back I can see it clearly: it wasn’t that I was not worthy of a PhD. I was navigating a system with pressure points I couldn’t see or reach from where I was standing. That lesson has never left me.
What Chemical Engineering Actually Teaches You
Most people assume chemical engineering is about chemistry. It’s not, really. At its core, it’s about systems: how inputs and outputs flow through a process, where pressure builds, where feedback loops exist, where the points of leverage are.
You learn early that you don’t overcome resistance by pushing harder at the point of resistance. You find where the system wants to move, and you guide it there.
I stopped being a chemical engineer. But I never stopped thinking like one.
Organizations Are Systems Too
When I moved into product leadership, I brought that mental model with me. It’s always affected how I understand organizational dynamics.
Most people approach change inside a company as a persuasion problem. You build the best argument, gather the best data, make the most compelling case. And when it doesn’t work, you make the argument louder or more detailed or more insistent. Or worse, you start bad mouthing the decision makers.
But organizations behave like systems. Information flows through them. Power concentrates at certain nodes. Decisions get made based on inputs that often have nothing to do with who is most right.
This is why being right is never enough on its own. Being right means you have a good argument. It doesn’t mean you understand the system.
Over the years, I’ve become the person colleagues come to when they’re stuck. When the stakeholder won’t budge, when the right answer isn’t landing, when someone is about to go to war with the wrong weapon. The first thing I always ask is: have you tried to understand why they’re being difficult?
Your Most Difficult Stakeholder Is a Pressure Point
In almost every stuck situation, there is a difficult stakeholder. Someone blocking, resisting, or simply immovable.
Most people treat that person as an obstacle. Push harder. Build a better case. Escalate.
But in systems thinking terms, a difficult stakeholder is almost always a high-pressure node. A lot of force is already acting on them. They’re not difficult because they’re obstinate. They’re difficult because they’re under pressure and missing information. And that reframe changes how you approach them.
Empathy Mapping as Systems Analysis
For over a decade I’ve been teaching a tool for this — empathy mapping, originally developed by Dave Gray. Most people use it for user research. I use it as an organizational systems mapping tool.
When you apply an empathy map to your most difficult stakeholder, something interesting happens. You stop seeing them as a blocker and start seeing the system acting on them. What information is flowing to them, and what’s missing? What pressures are shaping their position? What are they optimizing for? Who do they influence, and who influences them?
Almost every time I’ve walked someone through this exercise, they have the same moment of recognition: oh. They’re not trying to be difficult. They don’t have the full picture. And they’re under enormous pressure.
That moment of empathy isn’t soft. It’s strategic. It shows you exactly where to act.
The Drip Campaign
When I was leading the launch of Shutterstock Editor, my most difficult stakeholder was the CEO and founder. He wanted us to move faster than was realistically possible — an ambitious roadmap, an aggressive timeline, and a deep frustration that the company couldn’t move the way he had as a scrappy solo founder a decade earlier.
But when I mapped the pressures on him, the picture became clear. In Q2 2015, for the first time in Shutterstock’s history as a public company, they missed their own revenue guidance - and by less than $1 million. But Adobe entered the stock photos market around the same time, so on the earnings call news, the stock dropped more than 32% in a single day. The CEO had gone from being a billionaire to not being one almost overnight. He needed this product to change how Wall Street saw Shutterstock.
At the time, the asks he made of me and my team seemed unreasonable. But I came to learn that he was a node under enormous pressure, with an incomplete mental model of how the system around him had changed. He was still thinking like a scrappy founder when he was now operating a public company with institutional investors, a large engineering organization, and Wall Street watching every quarter. The system had changed.
Knowing that changed my entire approach. I didn’t argue with him about what was achievable. I couldn’t expect that pushing harder at the point of resistance would work.
Instead I started a drip campaign.
Every month in our roadmap review, I led with not just what we had achieved but also what we were learning: first qualitative insights from user research, then early usage data as it became available. I shared more frequently with other key stakeholders too, so insights were flowing back to him from multiple directions, not just from me. Over time, gradually, his mental model of what was possible (and what constituted meaningful progress) began to shift.
The system moved. Not because I won an argument. Because I changed the information flowing into it.
The Skill Underneath the Skill
I didn’t finish my PhD. The system won that round. But walking away from that failure with the right lesson is the reason I’ve spent the twenty years since learning to read systems instead of just arguing inside them.
These days I see these systems and the people in them as a puzzle and approach it with curiosity. And that has made mountains of difference in my career.
Here’s what I’ve watched happen to PMs who never learn this. They stay sharp. They stay right. And they stay stuck. Every difficult stakeholder becomes a wall instead of a puzzle. Every stalled initiative becomes proof that the org is broken, that leadership doesn’t get it, that if people would just listen things would move. They escalate harder. They build bigger decks. They write longer memos. They keep trying to do more - until they burn out. Somewhere along the way they hit a ceiling they can’t understand. It’s made of a mental model that says being right should be enough.
It’s not enough. It has never been enough. And the PMs who figure that out are the ones who keep getting picked for the work that matters most. They get picked for the turnarounds, the launches, the high-stakes initiatives where the real challenge isn’t the product, it’s the system the product has to move through.
So here’s what I’d ask you to do this week. Pick the stakeholder you can’t move. The one you’ve been arguing with, escalating around, or quietly writing off as impossible. Stop making your case. Instead, map the pressures on them. What information are they missing? What are they optimizing for? What does the system around them reward and punish? Then ask yourself: what would I need to change about the information flowing into this system for it to move on its own?
That question is the difference between a PM who stays right and a PM who gets things done.
The skill isn’t being right. It’s reading the system well enough to know where right needs to go — and having the patience to put it there.
Have you ever been in a situation where being right wasn’t enough? I’d love to hear about it in the comments.
And if this post resonates with you, consider joining my team at Datadog! I’m hiring at the Senior and Staff PM levels.