Between the Workstreams: The Part of the Job That Doesn’t Have a Task
This is not a piece about AI. But it starts there.
As AI absorbs more of the executional layer of our work, what’s left is harder to automate and harder to quantify. Stakeholder management gets talked about plenty. But there’s a version of it that doesn’t show up in frameworks or training: anticipating what stakeholders need before they ask, owning the decisions that don’t have a clear owner, and knowing when your proximity to the work is helping versus when it’s clouding your judgment. That's the relational work. And it’s exactly what AI can’t do (yet).
I say this as someone who genuinely loves getting into the weeds. That instinct has served me well. It has also, more than once, been the thing I had to manage.
The story that clarified this for me happened on what looked, from the outside, like a routine intranet overhaul.
The Project I Thought I Understood
I was program manager for a company-wide intranet redesign at a large retail organization. On paper: a content and platform project. In practice: a hundred different people’s idea of what their work life should look like, built into a system.
The discovery phase was my favorite part. Sitting with individual teams, watching people articulate needs they’d been carrying for years. The DEI team was one of those conversations. They had a specific, well-reasoned ask: content templates and forms customized to their workflow. Not a vanity request. They had real documentation needs and a clear case for them.
They were right. In isolation, the ask made complete sense. That’s exactly what made it complicated.
One Yes, Many Consequences
The question I had to bring back to the team was uncomfortable: if we build custom templates for the DEI team in Phase 1, what have we just told everyone else?
HR and DEI were both ERP sponsors. Both needed event, news, and communication templates surfacing on the main page. Customizing for one before the other meant entering a revision cycle we couldn’t afford. Limited approval windows, too many stakeholders, not enough runway to get it right twice. And whatever we built for the sponsors wouldn’t stay contained to them. Sales, leadership, and other departments were watching. The bar we set for HR and DEI was the bar we’d be held to by everyone downstream.
Most scope creep starts as a reasonable request. We went with an out-of-the-box solution, the same baseline for every department. The DEI team didn’t love it. They’d made a good case, and I was telling them it wasn’t the right time. That’s not settling. That’s sequencing.
There’s no task in a project plan for this. No milestone that reads “challenge the reasonable request.” It only gets caught if someone is watching the whole picture.
The Part I Had to Manage in Myself
Here’s what I didn’t say earlier: I wanted to say yes to the DEI team.
I’d spent weeks in those stakeholder conversations. I understood their workflows. I’d built real relationships with people on that team. The problem they were describing was real. There’s a version of me that would have gone to bat for them because the problem was interesting, because they deserved the solution, because I was close enough to see it clearly.
All of that was true. None of it was the whole picture.
This is what doesn’t get talked about enough: the discipline of noticing when you’ve gotten too attached to a part of the project to see it clearly. Getting close to the work is how you understand it. Staying close, is how you lose perspective on it.
The PM’s value isn’t in being the most empathetic person in the room, though empathy matters. It’s in owning the decisions that don’t have a clear owner. The ones that live between workstreams, between sponsors, between what was asked and what was actually needed. No tool generates that call. It comes from being the one who holds all of it simultaneously and decides what serves the whole.
Close Enough to Understand. Far Enough to See.
On that project, I did the hardest part badly at first. I went deep into the DEI team’s world and almost stayed there. The pull to say yes was real because the problem was real and I’d spent enough time inside it to feel its weight. Pulling back wasn’t natural. It was a decision, made deliberately, that meant overriding something that felt like good instinct.
That experience gave me language for something I’d been watching in strong PMs for years. The best ones aren’t naturally removed from the work. They’ve learned to move deliberately between two modes: deep enough to understand what the work is trying to do, and far enough back to see whether it’s actually doing it. In and out. Close and back. That toggle is where the judgment lives.
The same dynamic is available to every PM regardless of industry. Every project has people deep in their workstream who can’t see past it. That’s not a flaw. It’s how focused work operates. The PM’s job is to move in and out of that focus deliberately: close enough to understand, far enough to protect.
The distance isn’t the skill. Knowing when to create it is.
The Questions That Don’t Have a Milestone
That project left me with a small set of questions I come back to when a request feels both reasonable and risky.
If we do this for one team, what have we implicitly committed to for every team not yet fully in the conversation? Precedent travels faster than the project plan. If you can’t answer that clearly, the decision isn’t ready.
What do we need to know before this makes sense? Sometimes the honest answer is that the data doesn’t exist yet. That’s not a failure. It’s a reason to sequence differently.
And the hardest one: am I pushing for this because it’s right for the project, or because I’m too close to see the difference? That question is uncomfortable. It was for me. It’s also the one that changes outcomes.
Why Waiting Was the Right Call
The intranet launched. The out-of-the-box solution worked. The DEI team eventually got templates built around their real workflows. So did other departments. The customization was better because we waited for the evidence, and because by then we had a full picture of what HR, executive leadership, and the rest of the organization actually needed alongside them.
But not every story has a clean ending. The organization went through bankruptcy and eventually closed. The intranet didn’t save the company. That was never the job.
What survived was the work itself. The sequencing decisions, the stakeholder framework, the process for handling competing needs across a complex organization. We documented it, refined it, and applied it to future implementations. The discipline of waiting for evidence before customizing, of mapping the full stakeholder picture before setting a precedent, cut delivery time for projects that followed. The work outlived the company it was built for.
That’s what relational work actually produces. Not just a delivered project. Something that compounds. The conditions you create, the decisions you own carefully, the precedents you refuse to set too early. Sometimes you don’t see where it goes until much later.
The distance isn’t built into the role. You build it yourself. It’s a PM skill.
And it’s the one AI can’t build for you. Anticipating what a sponsor needs before they ask, owning the decision nobody else will claim, knowing when your closeness to the work has become a liability rather than an asset. That’s the work between the workstreams. It doesn’t show up in a deliverable. It shows up in outcomes. And right now, it’s the most important thing a PM can get better at.
