The Space Between: Navigating the Fault Lines Between EMs, PMs, and Leadership

I’ve been leading teams in high-growth environments long enough to know that most friction doesn’t come from malice—it comes from misalignment. Between product, engineering, and leadership, it’s easy for roles to blur, expectations to drift, and trust to erode. These aren’t horror stories. They’re lessons. This is what I’ve seen, what I’ve felt, and what I think we can do better in my organization.

✨ The EM's Dilemma: Strategy Without Authority

As an EM, I often have context from the team and proximity to the technical constraints, but I’m not always in the room when goals are shaped. I’m asked to execute, but not always consulted on what we’re executing.

In one conversation, I said:

"I still feel like we're building solutions from the top down, when I'd rather I and the team understand the problem and decide the solution."

It’s not that I don’t trust the intent—it’s that I know we can do better work when the team understands the why. Too often we chase an idea with some fancy name instead of the underlying need. We end up building stepping stones without knowing where the path leads.

📊 PMs in the Middle: Translators or Traffic Cops?

I’ve been lucky to work with PMs who take ownership, admit fault when things slip, and genuinely want to improve process. One example:

"I might have failed in this instance... It was not documented and I simply forgot about it."

There’s humility in that. But the bigger issue isn’t individual mistakes—it’s the lack of structure. Decisions made in passing don’t make it into plans. Agreements disappear without follow-through. Regular 1:1s and sprint reviews aren’t about status—they’re about building a shared memory.

Without rituals, we rely on recall. And that’s fragile.

🔢 Leadership: Close Enough to Guide, Far Enough to Miss the Cracks

Leadership often plays catch-up—not necessarily because they’re absent, but because the planning machine moves fast and input gets distributed unevenly. At the same time, there have been moments where leadership has injected themselves into detailed execution work without being asked, inadvertently creating confusion and stepping on team autonomy. When I raised concerns about planning chaos, the response was telling:

"We clearly need to sit down and discuss all of these though and make sure that we are aligned. Q3 planning definitely snuck up on all of us."

They weren’t defensive. They acknowledged the breakdown. But it’s a reminder that alignment isn’t a one-and-done event. It’s a system. And when that system breaks down, EMs and PMs are left to patch holes downstream.

🔥 When Support Becomes Interference

Support from leadership and product is critical—but it has to be aligned. When directors manage engineers directly or PMs push features without understanding the technical landscape, the result isn’t speed—it’s confusion.

In one instance, a critical fix was coordinated between leadership and engineers on my team in a private Slack thread. I wasn’t looped in. I didn’t find out until weeks later. No one was trying to sabotage anything, but the result was the same: fractured ownership, eroded trust, and duplicated effort.

If you’re going to hold someone accountable, you need to give them the space to lead.

Empowerment without autonomy is a trap.

⚖️ Purpose Over Process: The Workflows Example

Take Workflows. In our internal developer platform (IDP), Workflows is a feature that allows engineers to walk through a collection of steps, provide input, and have a microservice or microservice resource provisioned for them. It's another word for a multi-step form. Everyone agrees it’s important. It saves time. It reduces manual toil. But when we started talking OKRs, things got murky. Do we measure feature completion? User time saved? Number of requests handled?

I asked:

"Workflows is a means to an end. Is there a way we can identify and measure the end? Like the problem workflows solve?"

It’s easy to mistake tools for outcomes. But the real value is in what the tool frees us from. If we could handle provisioning and onboarding manually at scale, we wouldn’t need Workflows. But we can’t. And we’re tired.

So let’s measure what matters—time reclaimed, friction reduced, sanity preserved.

⚙️ Fixing the Fault Lines

If we want to improve the space between roles, we need to:

• Maximize trust. Trust is never static—you're always earning it or losing it. We should act in ways that reinforce trust in each other’s intentions, capabilities, and roles.
• Define ownership of communication. Who writes it down? Who follows up? Don’t leave it to chance.
• Invest in rituals. Regular check-ins, sprint reviews, retros—whatever it takes to keep memories shared and priorities clear.
• Focus on problems, not buzzwords. Survey responses aren’t mandates. They’re signals. Don’t ship the word; solve the need.
• Acknowledge the emotional labor. When things slip, people feel it. Recognize that, support each other, and move forward.
• Treat goals as destinations, not deliverables. A feature isn’t a goal. It’s a stone on the path.

You should all be working toward the same horizon. Work towards building a path that makes it easier to walk together.