leadership vs. management

Management plans, organizes, and controls the work — schedules, budgets, task assignments. Leadership motivates and aligns the people doing it — building trust, setting direction people actually want to follow, resolving friction. A PM needs both, but in a matrix organization where team members report to functional managers rather than the PM, leadership matters more than usual: there's often no formal authority to fall back on, only influence.

tuckman's stages of team development

Teams don't perform well from day one — they move through predictable stages, and what a PM should focus on shifts at each one:
StageWhat's happeningPM's focus
FormingPolite, tentative, unclear on rolesClarify goals, roles, and how the team will work together
StormingDisagreement and friction surfaceLet it surface openly; don't suppress conflict, resolve it
NormingWorking agreements settle inReinforce what's working; keep it consistent
PerformingThe team runs itself wellGet out of the way; remove blockers, don't micromanage
AdjourningThe project (or phase) endsClose out well, recognize contributions
Storming is the stage most often mishandled — a PM who reads early conflict as a sign the team is broken, and tries to shut it down rather than work through it, often delays the team ever reaching norming at all.

influencing without authority

When a PM needs something from someone who has no obligation to prioritize the project, direct requests alone often don't work. A few things do:
  • Credibility — a track record of being reliable and fair makes people more willing to help when asked, because they trust the ask is reasonable.
  • Reciprocity — help offered earlier (unblocking someone, sharing useful information) tends to come back around when it's your turn to need something.
  • Framing around their goals — connecting the ask to something the other person or their manager already cares about, not just to the project's own timeline.
  • Escalating through the right relationship — when direct influence genuinely isn't enough, going through the sponsor or the other person's manager (transparently, not behind their back) is a legitimate tool, not a failure of influence.

task conflict vs. relationship conflict

Not all conflict is bad. Task conflict — disagreement about the best approach, the right priority, whether an estimate is realistic — is often productive; it surfaces real issues before they become expensive mistakes. Relationship conflict — personal friction, distrust, frustration that's become about the people rather than the work — is corrosive and rarely improves anything. A PM's job during disagreement is keeping it focused on the task, not letting it slide into the personal.

a short example

A PM's project urgently needs help from a database engineer who reports to a different manager and has no formal reason to prioritize this work over their own team's backlog. Instead of just asking for a favor, the PM frames the request around something the engineer's manager already cares about (reducing a recurring on-call issue that the fix would also help with) and offers to send a note to that manager afterward crediting the engineer's contribution. The ask succeeds not because of authority the PM doesn't have, but because it's framed around what the other side actually values.

practical notes

Influence is built over time, not summoned in a single ask. A PM's reputation for being reliable and fair earlier in a project is the credit they're drawing on when they urgently need a favor later.
Recognizing which stage a team is in changes how a rough patch should be read — friction during storming is normal and often temporary; the same friction during what should be the performing stage is a signal something's actually wrong.

related topics

reference