♦When I first started leading cross-functional initiatives, I thought authority came from job titles.
Come on… It seemed logical. Managers and Directors had authority. Vice Presidents had authority.
I had… an email assigning me to a program and a Jira epic.
Unfortunately, Jira does not outrank anyone.
This created a small problem. Everyone expected me to deliver the product, but nobody involved in actually delivering it worked for me. Dev teams didn’t report to me, the ISSOs didn’t report to me, Ops & Sustainment didn’t report to me. Yet somehow, if the project failed, everyone would know exactly who to blame.
I eventually learned something that every PM, TPM, and program leader discovers the hard way: Everyone expects you to deliver the project. Nobody is required to listen to you.
Welcome to managing without authority.
Where using mom’s “because I said so” as a delivery strategy has a remarkably low success rate.
When you manage large, cross-functional programs, you are likely dealing with the matrix of a brilliant, highly opinionated, and fiercely autonomous workforce.
Engineers rarely tolerate bureaucratic red tape and unrealistic vanity dates that stifle their performance. Product managers are trying to ship enough features to keep everyone happy. Quality Assurance is trying to make sure none of those features take production down. Everyone has their own drivers.
So, if you walk into a room of cross-functional stakeholders and try to command them based on some arbitrary urgency that pulls them from their focus, you’ll be met with polite nods, silence, and enough NTR status reports to make you question whether anyone is actually working on the project.
Here is the reality:
- Dev Team A can’t force Dev Team B to prioritize a dependency.
- Security can’t force Operations to create a maintenance window.
- Operations can’t force the infrastructure team to deliver capacity.
- The TPM sitting in the middle of the chaos certainly can’t force anyone to do anything.
Yet somehow projects still launch.
Roadmaps still move.
Complex systems still get built.
The people who consistently make that happen aren’t always the ones with the biggest titles. They’re the ones who learn how to create alignment before they need authority. Because the truth is simple:
If your only strategy is escalation, you’re not leading the project.
You’re forwarding emails.
Stop Chasing Status UpdatesOne of the fastest ways to lose credibility with engineers is to micromanage their time.
We have all had (or have been — don’t worry you don’t have to raise your hand) that professional status collector:
“What’s the status for today?”
“Just checking in.”
“Circling back.”
“Following up.”
Or worse, the tyrannical PM:
“What’s taking so long?”
“Why is this ticket not done yet?”
“ah, I see you’re out of office next week…”
By the third message, the engineer is actively hiding from you on Slack. I’ve been that engineer.
The problem is that constant status requests are usually a symptom of something else: missing context.
When a TPM, PM, or manager repeatedly asks why a ticket isn’t done, they’re often trying to compensate for information they don’t have. They see a missed date. The engineer sees three production incidents, a broken dependency, and a security finding that appeared halfway through the sprint.
Most developers don’t wake up thinking, “How can I ruin the PM’s timeline today?”
They’re making tradeoffs. A production issue appeared. A dependency broke. Another team became a blocker.
Or they simply don’t understand why your deadline matters.
That’s where most leaders make a critical mistake.
They try to solve a context problem with control.
The instinct is understandable. The date is slipping, stakeholders are asking questions, and pressure is building. So we start checking in more frequently. More meetings. More status requests. More reminders.
Unfortunately, none of those things explain why the work matters.
Brilliant technical minds don’t want to be told when to ship by someone who isn’t writing the code. What they actually want is enough context to make good decisions. If they view your deadlines as arbitrary dates on a spreadsheet, they will treat them as optional.
The moment you connect work to consequences, the conversation changes.
- The Old Way (Control): “Hey, we really need the authentication endpoint completed by Tuesday’s deployment train. Let me know if you hit any blockers.”
- The New Way (Context): “If the authentication endpoint misses Tuesday’s deployment train, the localization team loses its testing window. That pushes the global launch by two weeks, delays enterprise onboarding activities, and impacts revenue tied to the release. Here’s the dependency map.”
Now we’re having a different conversation.
One is an arbitrary deadline.
The other is context via blast radius.
When engineers can see how a delay in one component affects five other teams, they usually don’t need to be managed. They start managing themselves.
They reprioritize. They collaborate. They escalate blockers earlier.
They protect the broader system because they finally understand the broader system.
You didn’t create alignment by demanding compliance. You created alignment by providing context.
Everything Can’t Be Priority #1♦People can’t align around ten different but equal priorities.
We’ve all had the super fun surprise “New initiative” meeting or email.
Leadership says it’s top priority.
Product wants more features, Engineering wants more time, Security wants more testing, and Operations wants stability. Leadership wanted it delivered yesterday.
The problem isn’t that someone is wrong. The problem is that everyone is right.
What NOT to do:
Promise speed to Leadership.
Promise scope to Product.
Promise quality to Security.
Promise flexibility to Engineering.
Before long, everything becomes Priority #1. At which point the word “priority” has lost all meaning. Every meaningful decision requires a tradeoff.
Want more features? More testing? More speed?
Something has to give.
Tradeoffs must happen. The question is whether you’re making it deliberately or discovering it accidentally three weeks before launch.
Alignment doesn’t necessarily mean getting everyone to agree either. However, it does mean everyone understands what wins when the priorities collide.
I like to title these meetings “Rock, Paper, Scissors”. Getting stakeholders together and making it clear whether we are prioritizing speed over features, or quality over speed, etc..
If speed is the priority, some scope may need to go.
If quality is the priority, the timeline may move.
If security is non-negotiable, everyone understands what that means for delivery.
People don’t need to love the decision. They need to understand the decision.
Because when priorities are unclear, every disagreement becomes a debate. When priorities are explicit, people can make good decisions without waiting for permission.
And that’s one of the most powerful forms of influence a TPM has.
Not deciding every outcome.
Making sure everyone knows how to decide when you’re not in the room.
♦Stop Managing Tasks. Think Like An Owner.TPM Survival Tip: Beware of the Green Lie
Month 1: 🟩 Green
"The architecture is sound."
Month 2: 🟩 Green
"We're slightly behind, but we'll catch up."
Month 3: 🟩 Green
"One dependency slipped. No major concern."
Month 4: 🟩 Green
"We've accumulated some technical debt, but it's manageable."
Month 5: 🟩 Green
"The integration testing window is getting tight."
Month 6: 🟨 Yellow
"The authentication service doesn't scale under load."
Three days later: 🟥 Red
"Everything depends on the authentication service.“
for my fellow or former SWEs:
if (projectStatus == GREEN) {
askForEvidence();
}
if (projectStatus == GREEN && launchDate < 30_days) {
askForMoreEvidence();
}The dangerous part about the “Green Lie” is that every individual task can appear healthy while the overall initiative quietly moves toward failure.
One of the biggest shifts in my career happened when I stopped thinking like a coordinator and started thinking like an owner.
If a TPM only cares about process theater, then “Is the ticket done?” is the only question they will ask. They simply measure activity and protect the process.
If a TPM has an owner mindset, they ask, “If this ships, does it solve the problem we intended to solve?”
An owner protects the outcome by removing friction and protecting engineering time from low-value work.
This distinction matters because engineers can spot process theater from a mile away.
Nobody gets excited about updating a spreadsheet or improving a burndown chart.
People get motivated when they understand the value being created.
The best TPMs I’ve worked with weren’t obsessed with picture-perfect Agile ceremonies.
They challenged ideas that consumed resources without delivering meaningful value. That’s what owners do.
So instead of asking whether the process was followed perfectly, ask whether the outcome justified the investment.
Ironically, this mindset also makes managing without authority easier.
Engineers respect leaders who protect their time, product teams respect leaders who understand business impact, executives respect leaders who deliver predictable outcomes.
When people believe you’re optimizing for the success of the system instead of the success of your project plan, trust grows.
The Dirty SecretYou’re probably thinking, “Okay, so sum it up. What’s the magic sauce?”
Let’s put it plainly: it’s communicating explicit tradeoffs, and using objective data.
Context is the difference between:
“The team said NTR, they’re working on it.”
and
“The team is working critical task X, and sustaining Y so that system Z doesn’t go down. The current resources do not have the bandwidth.”
Tradeoffs are the difference between:
“New Task A and Critical Task X are both priority and cannot slip. We need to beat the deadline if possible but we also need to add these new features to satisfy a new customer requirement within the timeframe.”
and
“New task A is higher priority than critical task X because of these downstream dependencies and reliant business outcomes. For this cycle, speed > optimization > scope.”
Data is the difference between:
“I think we’re on track.”
and
“The team averages 20 story points per sprint. We have 100 points remaining and two sprints left.”
Most cross-functional conflict exists because one of those three things is missing. People are operating with different information, priorities, and versions of reality.
Your job isn’t to force alignment. It’s to decrease ambiguity until alignment becomes the obvious choice.
TPMs with no direct reports can quietly move mountains while directors with massive organizations struggle to get alignment.
The difference isn’t their title.
It is trust.
Those TPMs consistently identified risks before they exploded, they understood the business, they made meetings shorter instead of longer, they brought data instead of opinions.
After enough iterations, something interesting happens.
People stop asking,“Who gave you authority?”
And start asking, “What do you think we should do?”
That’s the moment you’ve earned influence.
And the org chart never changed.
♦The Critical Skill Nobody Teaches You was originally published in Code Like A Girl on Medium, where people are continuing the conversation by highlighting and responding to this story.