leadership styles for pms

There is no one correct leadership style. If someone tells you “great PMs are servant leaders” or “great PMs are visionaries,” they are selling a brand, not teaching you leadership.

The reality is messier. On Monday, you are directing a junior engineer through a production incident — step one, step two, step three, no ambiguity. On Wednesday, you are coaching a designer through a problem she needs to own. On Friday, you are in a room with five stakeholders who all disagree, and your job is to facilitate consensus without having any formal authority over any of them.

The PMs who fail at leadership are the ones who have one mode. They are always the nice facilitator, or always the decisive commander, or always the consensus-builder. The PMs who succeed learn to read the room and switch.

The four leadership modes that matter in product

Forget the ten-style taxonomy from business school textbooks. In product management, four modes cover 90% of the situations you will face. The rest are edge cases.

Directive: “Do this, then this.”

You tell the team exactly what to do and how to do it. Low autonomy for the team. High clarity from you.

When to use it:

• A new team member who does not yet know the codebase, the product, or the customers
• A production crisis where speed matters more than learning
• An ambiguous problem where the team is frozen and needs someone to pick a direction

When it fails:

• When you stay directive after the team has gained competence — they will resent you
• When you use it as a crutch because coaching takes more patience than commanding

A project manager I trained described it well: “Directive is where you are directing the person what to do. Hey, for some time, do not think much — just do what I am suggesting. Step one, do this. Step two, do this. Step three, do this. Once this person has done it a few times, that is when you move to coaching.”

Coaching: “Let’s figure this out together.”

You ask questions more than you give answers. You let the person try, fail in small ways, and learn. You are still closely involved, but the ownership is shifting.

When to use it:

• A team member who has basic competence but lacks confidence or context
• A cross-functional project where the designer or engineer needs to develop product sense
• When you are grooming someone for more responsibility

When it fails:

• In a crisis where there is no time for learning
• When you are coaching someone who needs directing — they will flounder and lose trust

The GROW model is the most practical coaching structure for PMs:

Do not overcomplicate this. GROW is not a ceremony. It is four questions you ask in a 15-minute conversation instead of handing someone a solution.

Democratic: “What does the room think?”

You gather input from the team and make decisions based on group consensus. Everyone has a voice. This works when you need buy-in and the decision benefits from diverse perspectives.

When to use it:

• Prioritisation decisions where the team has context you lack
• Design trade-offs where multiple valid approaches exist
• Roadmap planning where engineering, design, and business all have legitimate constraints

When it fails:

• When you use it to avoid making hard decisions (“Let the team decide” is sometimes abdication, not leadership)
• In hierarchical organisations where the team expects you to have a point of view — showing up without one erodes credibility
• When the “consensus” is really one loud voice dominating a room of quiet people

Delegating: “You own this. Come back if you are stuck.”

You hand over the problem entirely. The person decides the approach, the timeline, and the execution. You are available if needed but not hovering.

When to use it:

• With senior, trusted team members who have deep domain expertise
• When you need to scale yourself across multiple workstreams
• When the person’s growth requires full ownership, not guided ownership

When it fails:

• When you confuse delegation with abandonment — you still need checkpoints
• When the person is not ready, and you are delegating because you are busy, not because they are capable

Situational leadership: the actual skill

The four modes are not a personality type. They are a toolkit. The skill is knowing which one to use, with which person, on which problem, at which moment.

This is situational leadership — and if there is one thing I would recommend you learn from this entire discussion, it is this.

The same person can need directive leadership on one task and delegation on another. A senior engineer who is brilliant at system design might need directive coaching when they are presenting to stakeholders for the first time. A junior PM who is shaky on strategy might be fully autonomous on user research because they have deep empathy.

The progression for any new person or new task:

Directive → Coaching → Supporting → Delegating

This can happen in three days or over three months. The timeline does not matter. What matters is that you recognise which stage you are at with each person, and that you explicitly name it.

I have seen this work well when the leader is transparent about it: “For the first two weeks, I am going to be more hands-on than usual. Not because I do not trust you — because you are new to this codebase and the fastest way to ramp up is for me to walk you through the patterns. Once you are comfortable, I will step back.”

That sentence alone prevents 80% of the resentment that comes from directive leadership.

The India-specific leadership challenge

Across eight years of training PM leaders in India, the leadership dynamics here are different from what American management books describe, and pretending otherwise will get you into trouble.

The hierarchy reflex. Indian organisations — even startups — carry a strong hierarchical instinct. When you become a PM Lead or a Group PM, your team will often default to waiting for your direction rather than taking initiative. This is not because they lack capability. It is because decades of organisational culture have trained people to defer to the person with the title. If you want autonomous, self-directed teams, you have to explicitly build that culture. It will not happen by default.

Consensus vs. speed. Many Indian tech companies oscillate between two extremes: autocratic decisions from the founder, or endless consensus-building that delays everything. The PM’s job is to find the middle ground. On reversible decisions, move fast. On irreversible decisions, bring people along. Know the difference.

The “yes” that means “I heard you.” In cross-cultural teams — and especially in organisations where the engineering team is in India and leadership is in the US — “yes” often means “I understand what you are saying,” not “I agree and will do this.” If you are leading such a team, you need explicit confirmation mechanisms. “I hear you saying yes — does that mean you agree with this approach, or that you need time to think about it?” This one question prevents weeks of misalignment.

The seniority trap. In Indian tech, people often get promoted to leadership positions because of tenure, not leadership ability. This means your peers and managers may default to a style that does not match the situation. A CTO who was a great engineer might be permanently stuck in directive mode because that is how their managers led them. A VP who climbed through consensus-building might be incapable of making a fast call in a crisis. Recognise these patterns in others so you do not repeat them yourself.

Leading without authority

Here is the uncomfortable truth about PM leadership: you have no formal authority over anyone.

The engineers do not report to you. The designers do not report to you. Sales, marketing, customer success — none of them report to you. You need to influence decisions and drive projects forward without a single direct report.

This is not a weakness of the PM role. It is the PM role. The sooner you accept it, the sooner you stop fighting a structural reality and start developing the actual skill: influence.

Build trust through competence, not charm. Engineers will follow a PM who clearly understands the problem, has done the research, and respects their time. They will not follow a PM who shows up to standup unprepared, changes priorities weekly, and compensates with charisma. In India especially, where engineering teams tend to be skeptical of “business people,” your credibility comes from preparation, not personality.

Give credit visibly. Take blame quietly. This is the oldest leadership principle and the most frequently violated. When the product succeeds, the credit belongs to the team. When it fails, the responsibility is yours. The moment you publicly blame an engineer for a missed deadline or a designer for a bad decision, you have lost the team.

Make their work easier, not harder. The best PMs I have worked with are the ones who remove blockers, shield the team from political noise, and never add unnecessary process. If your team dreads your meetings, something is wrong with your meetings — not with your team.

What does not work

The always-nice PM. Being liked is not leadership. If you cannot say no, cannot push back on unrealistic timelines, and cannot tell a stakeholder that their pet feature is not a priority — you are not leading. You are people-pleasing. The team will eventually lose respect because they know you will cave under pressure.

The micromanager disguised as a “detail-oriented PM.” There is a difference between caring about quality and reviewing every design pixel, every Jira ticket description, and every standup update. If you cannot delegate, you cannot scale. And if you cannot scale, you will burn out and take the team with you.

The absent PM. Delegation without check-ins is not delegation. It is abandonment. The PM who says “I trust the team” and then disappears for three weeks is not being empowering — they are being negligent. Trust is built through consistent presence, not absence.

The pacesetter who burns everyone out. Working long hours and expecting the team to match your pace is not leadership. It is a short-term performance hack that destroys long-term team health. If you are consistently the last person online, ask yourself whether you are setting a pace or setting a trap.

Test yourself

Where to go next

• The specific skill of influence: Influence Without Authority
• How to manage stakeholders across the org: Stakeholder Management
• Building and hiring a PM team: Building a PM Team
• The path to VP and CPO: The VP/CPO Path
• Managing through organisational shifts: Change Management