I’ve worked with phenomenal product managers who transformed teams. I’ve also worked with PMs who slowly suffocated projects with process theater.
The difference isn’t experience, credentials, or certifications. It’s whether they understand that Agile terminology isn’t vocabulary. It’s a toolkit for solving specific problems.
Let me show you what I mean.
The Fake PM Playbook
A fake PM runs meetings like this:
Daily Standup:
“What did you do yesterday?”
“What are you doing today?”
“Any blockers?”
[Engineer mentions blocker]
“Okay, let’s take that offline.”
[Nothing happens]
Sprint Planning:
Fills the sprint with whatever’s at the top of the backlog
No discussion of capacity, dependencies, or risk
“We committed to 40 points, we should be able to do this”
[Spoiler: They can’t]
Retrospective:
“What went well? What could be better?”
[Team shares honest feedback]
“Great! Thanks everyone. Same time next sprint.”
[Nothing changes]
They know all the words: velocity, story points, burndown charts, acceptance criteria. They run every ceremony on schedule. They update Jira religiously.
And the team is dying.
The Even Worse Version: The Spreadsheet Tyrant
Actually, I need to correct myself. There’s something worse than a fake PM who performs Agile badly.
It’s the PM who doesn’t even bother with Agile.
Let me introduce you to the Spreadsheet Tyrant:
Creates their own tracking spreadsheet (because Jira is “too complicated”)
Makes updating this spreadsheet everyone else’s problem
Has columns labeled “Sprint 1” and “Sprint 2” but no actual sprint planning
Thinks having a column called “Sprint” means they’re doing Agile
Leaves meetings and immediately posts notes
Then forgets everything that was discussed
Assigns dates without consulting the team
Ignores developer feedback entirely
Thinks project management is about making colorful status reports
This PM doesn’t even know what a retrospective is. Or if they do, they’ve never run one.
No standups. No sprint planning. No velocity tracking. No process at all.
Just a spreadsheet, a dream, and a complete disregard for the people actually building the software.
What This Looks Like in Practice
The Meeting:
Engineer: “This feature will take 3 weeks because we need to refactor the authentication system first.”
PM: “Great! I’ll put you down for next Friday.”
Engineer: “That’s 8 days from now, not 3 weeks.”
PM: “Leadership needs this by Friday, so let’s make it work!”
[Meeting ends]
5 Minutes Later:
PM posts meeting notes: “Alan committed to delivering authentication feature by Friday.”
Engineer: [screaming internally]
The Spreadsheet:
Meanwhile, the PM has updated their color-coded Excel masterpiece with:
A date you never agreed to
A scope you never committed to
A status of “On Track” when you haven’t even started
Your name in the “Owner” column (because now it’s your problem)
Two Days Before “Your Deadline”:
PM in Slack: “Just checking in! Still on track for Friday?”
Engineer: “As I mentioned in the meeting, this is a 3-week effort.”
PM: “Hmm, I don’t have that in my notes. Can you update the spreadsheet?”
Why This Is Worse Than Fake Agile
At least the fake PM pretends to care about process. They run the ceremonies. They track velocity (even if they don’t understand it). They create the theater of structure.
The Spreadsheet Tyrant doesn’t even do that.
They’ve decided that project management is:
Writing down what they want to happen
Putting dates on a spreadsheet
Telling leadership everything is “on track”
Blaming engineers when reality doesn’t match the spreadsheet
There’s no feedback loop. No adjustment to reality. No learning from past sprints (because there are no sprints). No protecting the team from impossible demands.
Just magical thinking, weaponized.
The Real Damage
This kind of PM doesn’t just fail to help. They actively make things worse:
They create false expectations with leadership
Leadership thinks everything is on track because the spreadsheet is green. Then they’re blindsided when nothing ships on time. Who gets blamed? Engineering.
They ignore technical reality
Engineers explain constraints, dependencies, risks. The PM nods, takes notes, then assigns dates as if none of that conversation happened. You can’t plan around physics you refuse to acknowledge.
They make the spreadsheet everyone’s problem
“Can you update the spreadsheet?” No. That’s literally your job. I’m busy building the thing you keep promising to people without asking me first.
They create a paper trail of commitments you never made
Meeting notes that say you “committed” to dates you explicitly said were impossible. Now when you miss the fake deadline, there’s documentation that you “agreed” to it.
They eliminate psychological safety
Why bother giving honest estimates if they’re going to be ignored? Why mention risks if they won’t be factored in? Why participate in planning if the dates are predetermined?
Eventually, engineers stop fighting. They just nod, let the PM write whatever fantasy they want, and update their resumes.
What Good Project Management Actually Looks Like
A real PM (Agile or not) understands their job is to:
Gather accurate information (What will this actually take? What are the risks?)
Make realistic plans (Based on what the team says, not what leadership wants to hear)
Communicate honestly (Up to leadership: “This is possible in 3 weeks, not 1 week”)
Protect the team (From unrealistic expectations and constantly changing priorities)
Adjust based on reality (When things change, update the plan, don’t pretend they didn’t)
Whether you use Agile, Waterfall, or a napkin, the principles are the same: listen to your team, plan realistically, communicate honestly, adjust as needed.
The Spreadsheet Tyrant does none of this. They just make a pretty document and hope reality conforms to it.
Spoiler: Reality never does.
If You’re Working With a Spreadsheet Tyrant
You have three options:
Option 1: Document Everything
Every time they assign an unrealistic date, respond in writing: “As discussed, this is a 3-week effort due to X, Y, Z constraints. I cannot commit to Friday delivery.”
When they post meeting notes saying you committed to Friday, correct them publicly: “To clarify, I did not commit to this date. Please see my email from this morning explaining the 3-week timeline.”
Yes, it’s exhausting. Yes, it feels adversarial. But you’re protecting yourself from being blamed when their fantasy plan fails.
Option 2: Escalate to Your Manager
“I need help. The PM is assigning dates without consulting me, ignoring technical constraints I’ve explained, and documenting commitments I never made. This is creating false expectations with leadership and setting me up to fail. Can you help align on realistic planning?”
Bring specific examples. Show the pattern. Don’t make it personal, make it about outcomes.
Option 3: Leave
If leadership won’t address it, you’re working in a dysfunctional organization. The Spreadsheet Tyrant is a symptom, not the disease.
The disease is a company that values the appearance of control over actual delivery. That doesn’t value engineering input. That punishes honesty and rewards magical thinking.
You can’t fix that from your position. But you can choose not to participate in it.
Good companies exist. Go find one.
What’s Actually Happening
The fake PM thinks Agile is a process to follow.
The real PM knows Agile is a framework for making decisions.
Here’s the difference in practice:
Scenario 1: The Blocker
Fake PM:
“Let’s take that offline.”
[Translation: I don’t want to deal with this in standup, it makes the metrics look bad]
Real PM:
“Okay, you’re blocked on the API key from Legal. I’ll ping them right after this standup. If I don’t hear back by noon, I’m escalating to the VP. You, can you start on the error handling while we wait? That’s not blocked, right?”
What just happened:
Immediate action (not “I’ll look into it”)
Escalation path defined (not hoping it resolves itself)
Team unblocked with alternative work (not sitting idle)
All in 30 seconds
That’s what “removing blockers” actually means. Not asking about them. Removing them.
Scenario 2: The Overcommitted Sprint
Fake PM:
Sprint planning, 40 story points committed, team velocity is 28.
“I know it’s a stretch, but leadership really wants this shipped. Can we try?”
“Our velocity is 28. Leadership wants 40 points. Here are our options:
Deliver the 28 points that matter most (I’ll defend this decision)
Add a developer mid-sprint (I’ll fight for this resource)
Cut scope on some stories to fit more in (let’s discuss trade-offs)
Extend the sprint by a week (I’ll negotiate timeline)
Which path gives us the best outcome?”
What just happened:
Acknowledged the constraint (velocity is real)
Gave the team agency (not a false choice)
Committed to fighting for them (shield, not punching bag)
Made the trade-off explicit (not pretending we can do everything)
That’s what “sustainable pace” actually means. Not hoping people work weekends. Protecting the team.
Scenario 3: The Retrospective
Fake PM:
“What went well? What could be better?”
Engineer: “Our deployments are taking 3 hours and failing 30% of the time. It’s killing our velocity.”
PM: “Great feedback. Let’s add that to the action items.”
[Next sprint: Nothing changes. Next retro: Same complaint. Repeat forever.]
Real PM:
“Deployments are taking 3 hours and failing 30%. That’s a 9-hour tax per sprint on a 5-person team. That’s costing us 45 hours, more than a full engineer.
Here’s what I’m doing:
I’m creating a story for CI/CD improvement in next sprint (top priority)
I’m pulling DevOps into planning to scope the fix (Wednesday)
I’m presenting this to leadership as a velocity blocker (Friday)
If we can’t fix it in one sprint, I’m requesting dedicated DevOps support
Who wants to lead the technical design? I’ll clear your schedule.”
What just happened:
Converted complaint into action (not “thanks for sharing”)
Quantified the impact (leadership speaks ROI)
Set clear timeline (not “we’ll get to it eventually”)
Cleared path for execution (removed other work)
That’s what “continuous improvement” actually means. Not collecting feedback. Acting on it.
Why Fake PMs Survive
Because from the outside, they look productive:
All ceremonies on calendar ✓
Jira boards updated ✓
Velocity charts published ✓
Stakeholder updates sent ✓
But look at what’s actually happening:
Blockers persist for weeks
Velocity trending down
Quality issues increasing
Morale cratering
Best engineers leaving
The fake PM is performing Agile theater. The show looks good. The team is suffering.
What a Real PM Actually Does
A real PM understands that every Agile practice exists to solve a specific problem:
Standups exist to surface blockers early.
Not to report status. If I can’t act on what I hear, I’ve wasted 15 minutes of 5 people’s time.
Sprint planning exists to make explicit commitments with full information.
Not to fill the sprint. If we’re overcommitting because of pressure, my job is to push back with data.
Retrospectives exist to change how we work.
Not to vent. If nothing changes after a retro, I’ve failed.
Velocity exists to enable realistic planning.
Not to shame the team. If velocity is dropping, something’s wrong with the system, and it’s my job to fix it.
Story points exist to estimate complexity.
Not to measure productivity. If I’m using points for performance reviews, I’ve fundamentally misunderstood the tool.
The real PM knows the jargon because they’ve used the tools to solve real problems. The fake PM knows the jargon because they read it in a book.
Team starts padding estimates (learned helplessness)
Retros become performative (no one believes anything will change)
Good engineers leave (they can work anywhere)
Mediocre engineers stay (Stockholm syndrome)
With a real PM:
Engineers trust that blockers will be addressed (transparency increases)
Team estimates honestly (psychological safety)
Retros drive real change (engagement increases)
Velocity improves (because obstacles are removed)
Team morale improves (because they’re set up to succeed)
The Test
Want to know if your PM is real or fake?
Ask yourself:
When was the last time the PM removed a blocker without being asked twice?
When was the last time the PM said “no” to a stakeholder to protect the team?
When was the last time something changed because of a retrospective?
Does your PM understand the technical trade-offs, or just parrot what you told them?
Would you follow this PM to their next company?
If you’re hesitating on any of these, you’re working with a fake PM.
What I Learned from Both
I’ve been lucky enough to work with world-class PMs who made me a better engineer and leader. I’ve also worked with PMs who drained the life out of teams with process theater.
The difference was never about following Agile correctly. It was about understanding why the practices exist and having the courage to use them.
A great PM:
Uses standup to remove blockers, not collect status
Uses sprint planning to make realistic commitments, not appease stakeholders
Uses retros to drive change, not collect feedback
Uses velocity to plan sustainably, not measure productivity
Uses story points to estimate, not judge
A fake PM does all the same ceremonies but misses the point entirely.
If You’re a PM Reading This
Ask yourself honestly:
Am I removing blockers, or just acknowledging them?
Am I protecting my team from overcommitment, or passing pressure down?
Am I driving change from retrospectives, or just checking the box?
Do I understand the technical constraints, or just hope the team figures it out?
Would my team follow me to my next role?
If you’re uncomfortable with your answers, good. That’s the first step.
Agile isn’t about knowing the vocabulary. It’s about using the tools to solve real problems.
The words are easy. The work is hard.
Do the work.
If You’re an Engineering Leader Reading This
You can’t always choose your PM. But you can:
Coach them (Share this post. Have the conversation.)
Escalate strategically (Document the impact: velocity, morale, attrition)
Protect your team (Be the shield they need until the PM situation changes)
Vote with your feet (Life’s too short to work with fake PMs indefinitely)
I’ve done all four at various points in my career.
Sometimes the PM learns. Sometimes leadership intervenes. Sometimes you leave.
But don’t stay silent while your team suffers through Agile theater.
About the Author
Alan Bollinger is an engineering leader with 25+ years building products and teams. He’s scaled organizations from solo to 20+ professionals, doubled team velocity through real Agile transformation, and operated as fractional CTO delivering measurable business outcomes. He’s worked with great PMs and terrible ones, and believes the difference is understanding that Agile is a toolkit, not a script.
Currently seeking VP Engineering or CTO roles where process serves people, not the other way around.
