A Project Manager Is Not the Developers' Manager

In modern software organizations, developers usually report hierarchically to an Engineering Manager, Tech Lead, or VP of Engineering—not to the Project Manager.

This dynamic often sparks confusion: If the PM is not their boss, how does the PM establish accountability around timelines, process, and deliverables without relying on command-and-control authority?

The Leadership Paradox: Authority Without Using It Against the Team

For me, authority should never be your primary weapon. When a PM relies on hierarchy or threats to force action, it signals that trust has already broken down.

I believe the best PM can have authority, without using it against the team. I would rather use that authority to protect the team, remove blockers, cover gaps, and keep the project moving.

Especially in Agile software environments, engineers own execution. The PM’s role is to facilitate focus, clarity, and momentum—not to act as an overseer.

Why Constant Follow-Up Destroys Velocity

One of the worst habits an inexperienced PM can develop is hovering over developers asking every couple of hours: "What have you finished?"

Instead of constant disruption, establish a reliable, respectful operating rhythm:

When Deadlines Slip: Diagnosis Over Punishment

When a ticket stalls or an engineer starts falling behind schedule, the instinctive reaction should never be reprimand. The reaction must be diagnostic curiosity:

• Is the task ambiguous? Are requirements missing edge cases or acceptance criteria?

• Is there an unhandled technical blocker? Are they waiting on external API keys or library fixes?

• Is the scope secretly growing? Did unforeseen complexity emerge during implementation?

• Does the engineer need pairing support? Would 30 minutes with the Tech Lead unblock the impasse?

• Is there personal fatigue or burnout? Is the workload realistic and sustainable?

Use your sprint tracking boards and metrics to spot patterns early, then initiate a constructive 1-on-1 conversation. Frequently, the problem is not motivation—it is a lack of clarity, support, or tooling.

Playing with the Timeline Like a Magician Playing with Cards

Software development is fundamentally uncertain. Business logic shifts, stakeholders introduce last-minute requirements, and unexpected technical hurdles arise. When reality diverges from the plan, the PM must adapt without panic.

I like to think of project management as being able to play with the timeline like a magician playing with cards: having enough visibility, flexibility, and contingency options to cover gaps without ever losing control.

This means knowing your team intimately: knowing who handles database spikes best, who excels at complex UI state, and how to re-sequence modules so blocked tracks don’t stall the entire release.

Conflict Resolution: Facilitator First, Arbiter When Necessary

Disagreements naturally occur—especially between ambitious Product Designers, pragmatic Developers, and perfectionist Tech Leads. The PM’s primary stance should be facilitating aligned resolution.

However, when a technical impasse threatens project survival, the PM must step in and guide the decision. Why? Because the PM uniquely synthesizes all constraints:

• The business deadline and customer commitments.

• The contractual scope and available budget.

• The engineering capacity and technical trade-offs.

• The long-term maintainability of the software.

Real-World Case Study: Turning Around Team Misalignment

I witnessed this firsthand when a developer on our team was consistently falling out of sync with our delivery process. Tasks were drifting, updates were sparse, and time was slipping away.

Instead of escalating to senior management or issuing disciplinary warnings, I sat down with him in an honest 1-on-1. We mapped out where the friction was, clarified the exact expectations, and adjusted the workflow to support his strengths.

Within weeks, his velocity surged, communication became effortless, and the project shipped smoothly. The issue was not solved through positional authority—it was solved because someone took the time to understand the root problem.

Key Takeaways

• Influence without authority is the hallmark of an exceptional Software PM.

• Eliminate hourly status check-ins; protect developer flow state with structured standups.

• When schedules slip, diagnose root causes before assuming poor performance.

• Reshuffle dependencies and sprint plans like cards to navigate unforeseen obstacles smoothly.