Skip to content
Mountain Goat Software
  • Ways We Help

    • Agile CoachingGet expert guidance tailored to your teams, leaders, and real-world challenges.
    • Backlog Story ImprovementStrengthen backlog items so teams can plan clearly and deliver valuable work.
    • Estimating & PlanningBuild realistic estimates and plans that support confident delivery decisions.
    • Leadership AlignmentAlign leaders around priorities, expectations, and the conditions agile teams need.
    • Team Improvement SprintsTurn focused learning into lasting changes through guided practice over time.
    • Scrum Team ImprovementHelp Scrum teams improve collaboration, execution, and results on real work.

    Who We Help

    Helping Scrum teams and product, engineering, and organizational leaders improve how they work.

    Explore Who We Help →

    Workshops

    • View All Workshops
    • Working on a Scrum Team
    • Backlog Refinement Workshop
    • Mastering User Stories
    • Story-Writing Workshop
    • Accurate Agile Planning
    • Effective Scrum Master
    • Agile for Leaders
    • Effective Product Owner
    • Team Reset
    • Agile Coaching
    • Introduction to Agile
    • Certified ScrumMaster
    • Certified Scrum Product Owner

    Explore Services

    • View All Services
    • Compare Workshops
    • ROI Calculator
    • Results OverviewSee how private, team-based agile support improves backlogs, planning, Scrum events, and leadership visibility.
    • What Changes in 90 DaysSee the practical improvements teams and leaders can achieve after working with us.
    • Client StoriesRead how organizations have applied what they learned and improved how they work.
    • TestimonialsHear directly from participants, leaders, and longtime clients.
  • Agile Guides

    • New to Agile or Scrum
    • Scrum
    • User Stories
    • Product Backlog
    • Story Points
    • Agile Planning and Forecasting
    • Product Ownership
    • Agile Teams and Collaboration
    • Agile Leadership
    • Leading Agile Initiatives

    More Resources

    • The Mountain Goat Software Blog
    • Videos
    • Webinars
    • Free Tools
    • Books by Mike Cohn
    • Presentations

    Stay Connected

    • Weekly Tips from Mike Cohn
    • Mountain Goat Software on YouTube
    • Connect with Mike on LinkedIn

    Featured Resources

    • Agile Video LibraryBrowse Video Playlists from Mike on Scrum, user stories, planning, and leadership.
    • Scrum Reset DiagnosticFind the one problem to fix first and run a practical two-sprint reset.
  • About Mountain Goat Software

    • Our CompanyLearn who we are and how Mountain Goat Software helps teams and organizations.
    • Mike CohnMeet our founder, author, and longtime agile practitioner.

    Get In Touch

    • Book a Call
    • Send an Email
  • Search
  • Book a Call
Book a Call
  1. Home
  2. Agile
  3. Agile Leadership
  4. Lead Each Team the Way They Need

Lead Each Team the Way They Need

In This Topic

  • Why One Leadership Style Does Not Work for Every Team
  • The Goal Is More Team Ownership
  • Four Ways to Lead Agile Teams
  • Match Your Style to the Team’s Current Need
  • How to Know a Team Needs More Direction
  • How to Know a Team Needs More Coaching
  • How to Know a Team Needs More Support
  • How to Know a Team Is Ready for Delegation
  • Common Mistakes Leaders Make
  • What to Do If You Are Not Sure
  • A Leadership Self-Check
  • FAQ
  • Explore Further

Guides ▾

  • New to Agile or Scrum
  • Scrum
  • Agile Teams and Collaboration
  • Product Ownership
  • Product Backlog
  • User Stories
  • Story Points
  • Agile Planning and Forecasting
  • Agile Leadership
    • Create Clarity Without Removing Ownership
    • Support Self Managing Teams
    • Lead Each Team the Way They Need
    • When Should Agile Leaders Step In
    • Ask Better Planning Questions
    • Dont Compare Team Velocities
    • Finish Everything Every Sprint
  • Leading Agile Initiatives
Close

Agile leaders do not lead every team the same way.

That can be hard to accept.

A leader may hear that agile teams should be self-managing and conclude, “Great. I should step back and let the team figure everything out.”

Sometimes that is exactly right.

Other times it is a mistake.

A team that is new to agile may not yet know how to plan in short iterations, split work small enough, work across specialties, or finish something valuable every sprint. Leaving that team alone in the name of empowerment is not leadership. It is abandonment.

At the same time, an experienced agile team may not need much guidance at all. Tell that team how long its sprints should be, how to run every meeting, or exactly how to divide the work, and you may slow down a team that was already making good decisions.

Agile leaders need to lead each team the way that team needs to be led now.

That means knowing when to direct, when to coach, when to support, and when to delegate.


Why One Leadership Style Does Not Work for Every Team

Agile leadership is sometimes described as if there is only one right style.

Empower the team. Trust the team. Get out of the way.

That advice is useful, but incomplete.

Teams differ. A team that has been working successfully with agile for years does not need the same leadership as a team that started last month. A team with strong technical practices does not need the same help as a team that cannot yet deliver working software each sprint. A team with a confident Product Owner does not need the same support as a team whose Product Owner lacks authority or experience.

Even the same team may need different leadership in different situations.

A team might be ready to make its own decisions about sprint planning, but still need coaching on stakeholder engagement. It might be strong technically, but need help with product discovery. It might be excellent at delivery, but inexperienced at coordinating with other teams.

Agile leadership is not a setting you choose once.

It is a set of choices you keep making.


The Goal Is More Team Ownership

The goal of adaptive leadership is not to keep teams dependent on leaders.

The goal is to help teams become more capable over time.

A good leader might start by giving a new team more direction. But that direction should not become permanent. It should help the team build enough skill, confidence, and experience to take on more ownership.

Think of it as a progression.

At first, a team may need a leader to make some decisions for them or give clear guardrails. Later, the team may need coaching, then support, and eventually only occasional help.

That does not mean every team follows a perfect sequence. Teams move forward, stall, regress, and improve again. But the direction should be clear: leaders are helping teams need less direct leadership over time.

The goal is not to lead less.

The goal is to lead in the way that helps the team grow.


Four Ways to Lead Agile Teams

A useful way to think about leadership style is through four modes: directing, coaching, supporting, and delegating.

These are not job titles. They are not personality types. They are choices a leader makes based on what the team needs.

Directing

A directing style is useful when a team is new, inexperienced, or not yet ready to make a certain decision well.

That may sound un-agile, but it is not.

A team completely new to agile may decide that three-month sprints sound reasonable. They may want to do all design up front. They may treat the Daily Scrum as a status meeting for the manager. They may pull far too much work into a sprint, or they may not understand what it means to finish something by the end of the sprint.

A leader should not stand by and let the team make every avoidable mistake in the name of self-management.

With a directing style, the leader provides more guidance. The leader may set the sprint length, insist on a real Sprint Review with stakeholders, require that work meet a shared definition of done, or establish basic expectations for how the team will plan, refine, and inspect its work.

Directing can still leave the team room to do the work. Micromanagement assigns the daily details. Good direction gives a new team enough structure to make better decisions sooner.

The danger is staying in directing mode too long.

Directing should help a team get started. It should not prevent the team from learning to make good decisions.

Coaching

A coaching style fits a team that has some experience but still needs help improving.

The leader is no longer saying, “Do it this way.” Instead, the leader is helping the team see better options.

A coaching leader asks questions, suggests alternatives, teaches concepts, and helps the team understand the consequences of its choices.

For example, a team may be finishing work each sprint but struggling with too many carryover items. A coaching leader might ask how the team is splitting work, whether testing is starting early enough, or whether refinement is producing shared understanding before sprint planning.

A team may be holding Sprint Reviews but not getting useful feedback. A coaching leader might help the team think about who should attend, what should be demonstrated, and what questions would create better learning.

Coaching is active.

The leader is still involved, but the involvement is aimed at helping the team think better, not making every decision for them.

Supporting

A supporting style works when the team is capable but still benefits from encouragement, context, and occasional help.

At this point, the leader participates in conversations but does not own the decisions.

The team may come to the leader with options and ask for perspective. The leader might help remove an organizational obstacle, connect the team with the right stakeholder, or help the Product Owner navigate a difficult tradeoff.

A supporting leader is available without taking over.

This can be difficult for leaders who are used to solving problems. A team may be about to make a decision the leader would not make. The leader has to decide whether the likely learning is worth the cost of the mistake.

Sometimes the right answer is to step in.

But often the better answer is to let the team decide, inspect the result, and learn.

Supporting requires patience. It also requires trust that the team’s growth matters, not just the immediate decision in front of them.

Delegating

A delegating style fits a team that has the skill, confidence, judgment, and context to make good decisions with little leader involvement.

This is where many leaders hope agile teams will end up.

A leader using a delegating style still provides direction at the right level. The team understands the business goals, constraints, and priorities. But the team does not need the leader involved in most day-to-day decisions.

The leader is available when needed. The team decides when to ask for help.

Delegating is powerful because it allows capable teams to move quickly. Decisions happen closer to the work. Team members feel ownership. Leaders are freed to focus on the system around the team rather than the details of the team’s work.

But delegation only works when the team is ready for it.

Delegating too soon can create chaos. Delegating too late can create frustration.


Match Your Style to the Team’s Current Need

The leadership style should depend on the team’s ability and confidence in the situation at hand.

A new team may need directing in the basics of Scrum but coaching on technical practices. A team may need supporting in sprint planning but more direction around a compliance constraint. A highly experienced team may need delegation most of the time but still need leadership help when organizational priorities conflict.

This is why agile leadership requires judgment.

Ask yourself:

  • Does the team understand the goal?
  • Does the team have the skills needed to succeed?
  • Has the team handled this type of decision well before?
  • Is the risk of a mistake acceptable?
  • Would stepping in help the team learn or prevent the team from learning?
  • Is this a team-level problem or an organizational problem?
  • Am I helping the team become more capable, or am I making the team dependent on me?

Those questions are more useful than asking, “Should agile leaders step back?”

Sometimes yes.

Sometimes no.


How to Know a Team Needs More Direction

Direction is useful when a team lacks experience, skill, or context.

You may need to be more directive when a team is new to agile, repeatedly missing the same basic expectations, unable to finish work inside a sprint, or making decisions that put the organization at unacceptable risk.

You may also need to direct when the team does not yet understand important constraints. A team cannot self-manage well around constraints it does not know exist.

For example, a leader might need to say:

“We need two-week sprints for now because we need faster feedback while the team is learning.”

Or:

“Every item we count as done needs to meet this definition of done.”

Or:

“We cannot release without meeting these security requirements.”

Or:

“The Product Owner owns the final priority decision after hearing stakeholder input.”

That kind of direction can be helpful.

The key is to explain the reason, keep the constraint as small as possible, and revisit it as the team gains experience.


How to Know a Team Needs More Coaching

Coaching is useful when a team is doing the basics but not yet getting the results it should.

The team may be working hard but carrying too much work from sprint to sprint. It may be estimating but not forecasting well. It may be holding retrospectives but not improving. It may be using Scrum events mechanically without getting much learning from them.

A coaching leader helps the team see what it cannot yet see.

That might involve asking better questions:

“What is causing work to carry over?”

“Are we starting testing soon enough?”

“What feedback did we get from the Sprint Review?”

“What tradeoff are we avoiding?”

“What would need to change for this plan to be more realistic?”

“What problem are we trying to solve with this rule?”

Coaching is especially useful when the team has enough experience to participate in the diagnosis but not enough experience to solve the problem alone.


How to Know a Team Needs More Support

Support is useful when the team is capable but facing a problem that requires leadership help.

The team may know what needs to happen but lack authority to make it happen. The team may need a decision from another group, help with a stakeholder conflict, access to a specialist, or protection from too many competing priorities.

In those situations, the leader should not take over the team’s work.

But the leader should not leave the team alone either.

A supporting leader might help the team get the right people into a conversation, remove an organizational impediment, clarify a decision right, or make a tradeoff visible to stakeholders.

The team still owns the work.

The leader helps with the conditions around the work.


How to Know a Team Is Ready for Delegation

A team is ready for more delegation when it regularly makes good decisions without waiting for permission.

You can see this in how the team plans, inspects, adapts, and communicates. The team understands its goals. It manages its work responsibly. It raises risks early. It makes tradeoffs visible. It learns from mistakes. It asks for help when help is needed.

Delegation does not require perfection.

No team makes every decision correctly. The question is whether the team generally makes good decisions and recovers well when it does not.

A team ready for delegation does not need leaders to disappear. It needs leaders to stay connected at the right level: strategy, goals, constraints, priorities, and organizational support.


Common Mistakes Leaders Make

Delegating Too Soon

Some leaders hear “self-managing team” and immediately back away.

That can leave a new team without enough structure to succeed. The team may develop habits that are hard to undo later. Worse, team members may conclude that agile means leaders no longer help.

Delegation should be earned through capability, not granted because a book or framework said teams should be empowered.

Directing Too Long

Other leaders make the opposite mistake.

They continue making decisions long after the team is capable of making them. They decide sprint length, meeting format, task assignments, technical approach, or team process even when the team has enough experience to choose well.

This slows the team down and weakens ownership.

A leader who directs too long may get compliance, but not commitment.

Confusing Support with Rescue

Supporting a team does not mean rescuing the team from every hard conversation.

If the team can solve the problem, let them. If they need help, provide it. If the problem sits outside the team’s authority, step in.

The distinction matters.

Leaders should help teams become more capable, not more dependent.

Treating Every Team the Same

Consistency is useful in some areas. Teams may need shared language, common goals, security standards, compliance rules, or a shared definition of done.

But treating every team exactly the same can create problems.

One team may need more coaching. Another may need more room. A third may need a clearer boundary. A fourth may need help with a stakeholder who keeps disrupting the sprint.

Fairness does not mean identical leadership.

Fairness means giving each team the leadership it needs to succeed.


What to Do If You Are Not Sure

Start by talking with the team.

Ask where they want more autonomy. Ask where they want more guidance. Ask what decisions they feel ready to make and what decisions still need more leadership involvement. Ask where leadership is helping and where leadership is getting in the way.

Then watch what happens.

A team may ask for autonomy but struggle when it gets it. That means coaching or support may still be needed. Another team may ask for guidance only because the organization has trained them to wait for permission. That team may need a leader to push decisions back to them.

You will not always get the style right.

That is fine.

Inspect and adapt your leadership the same way you want teams to inspect and adapt their work.


A Leadership Self-Check

Use these questions to assess whether you are leading a team the way it needs right now.

  • Am I giving this team enough clarity about outcomes and constraints?
  • Am I making decisions the team is ready to make?
  • Am I leaving the team alone with problems only leaders can solve?
  • Am I stepping in because the team needs help or because I am uncomfortable?
  • Am I explaining why a constraint exists?
  • Am I reducing direction as the team becomes more capable?
  • Am I helping the team learn from decisions rather than preventing every mistake?
  • Am I treating different teams differently for good reasons?

The answers should point to the kind of leadership the team needs next.

FAQ

Should agile leaders always delegate?

No. Delegation is valuable when a team has the skill, confidence, and context to make good decisions. A new or struggling team may need more direction or coaching before delegation will work.

Is directing an agile team micromanagement?

Not necessarily. Directing becomes micromanagement when leaders control too many details or keep control too long. But a new team may benefit from clear direction about sprint length, definition of done, stakeholder involvement, or other basic expectations.

How do I know when to step back?

Step back when the team is making good decisions, learning from mistakes, raising risks early, and asking for help when it needs help. Stay connected to goals, constraints, and organizational support, but let the team own more of the work.

What if different teams need different leadership?

They probably will. That is normal. Agile leadership should fit the team’s current needs, not force every team into the same level of autonomy or the same amount of direction.

Can a team move backward?

Yes. A team that was ready for delegation may need more support during a major product change, team membership change, technical crisis, or organizational shift. Adjusting your leadership style is not a failure. It is leadership.

How can leaders avoid creating dependency?

Give enough help for the team to succeed, but not so much that the team stops learning. Ask questions before giving answers. Push decisions back to the team when the team is ready. Step in when the issue is outside the team’s authority.

Last updated July 16th, 2026

Scrum Cheat Sheet

Get Your Free Scrum Cheat Sheet

Keep Scrum's roles, events, artifacts, and core rules close at hand with a free quick-reference cheat sheet.

Download Now

Explore Further

A team copies what the leader does, not what he says.
Article

Leading Agile Initiatives: How Leaders Help Agile Change Succeed

Featured

An agile initiative is not mainly a one-time rollout of Scrum, Kanban, SAFe, Jira, new job titles, or a different meeting calendar.

Article artwork for Nine Questions Scrum Masters and Product Owners Should Be Asking.
Article

Nine Questions Scrum Masters and Product Owners Should Be Asking

Featured

Use better questions to improve collaboration, decision-making, and team ownership.

Article artwork for Self-Organizing Teams Are Not Put Together Randomly.
Article

Self-Organizing Teams, their Benefits, and a Leader’s Role

Featured

Explore self-managing teams, including the role of leaders and outcomes of effective teamwork.

Article artwork for Be a Great Product Owner: Six Things Teams and Scrum Masters Need.
Article

Be a Great Product Owner: Six Things Teams and Scrum Masters Need

See what teams and Scrum Masters need most from a product owner to make delivery smoother.

Article artwork for How To Coach Your Team to Run Daily Scrum Meetings Themselves.
Article

How To Coach Your Team to Run Daily Scrum Meetings Themselves

Three things to stop doing now so that running the daily scrum becomes a whole-team activity.

Article artwork for 8 Reasons Scrum Is Hard to Learn (but Worth It).
Article

8 Reasons Scrum Is Hard to Learn (but Worth It)

Transitioning to Scrum is worth it, but some aspects are challenging.

Scrum meetings are an investment in Scrum success. Orgs who are new to Scrum often feel as if Scrum teams meet too much. When they dig deeper, they discover the meeting time is about the same, but the meetings are more visible because they have names.
Article

Does Scrum Have Too Many Meetings?

Are teams complaining about Scrum meetings? Learn why that happens, and how to fix it.

Article artwork for How to Get Teams Aligned on What It Means to Be Agile.
Article

How to Get Teams Aligned on What It Means to Be Agile

Align leaders, teams, and stakeholders around what agile really means.

A Scrum team sits together, talking, in the background. In front are three calendar pages with key Scrum events circled. The text says Succeeding with Scrum is easier when you know when and why to conduct each meetings.
Article

What Happens When During a Sprint

Succeeding with Scrum is easier when you know when and why to conduct each of the Scrum events during the sprint.

Article artwork for What Product Owners Do & 7 Mistakes to Avoid.
Article

What Product Owners Do & 7 Mistakes to Avoid

Use seven common product owner mistakes to spot where ownership, prioritization, or collaboration may be breaking down.

Article artwork for When Planning Should Become A Shared Problem.
Article

When Planning Should Become A Shared Problem

Turn planning pressure into a shared conversation about options and tradeoffs.

Good agile transformation training leads to improved teamwork and better outcomes.
Article

3 Ways to Ensure Agile Training Works to Transform Your Teams

The best agile training leads to real results. Learn how to ensure your investment pays off.

A series of arrows, each reading sprint, leads down a highway to a distant sign reading "product goal." One of a product owner's many responsibilities is to set a product goal: that next mile marker for the product.
Article

What Does a Product Owner Do, When, and Why?

Clarify what product owners do before work starts, during planning, and throughout each sprint.

Text graphic: Notice the habits that strengthen collaboration.
Article

The Chivalrous Team Member

Recognize helpful behavior that strengthens collaboration and trust.

Article artwork for Why Soft Skills Outlast Technical Skills on Product Development Teams.
Article

Why Soft Skills Outlast Technical Skills on Product Development Teams

Soft skills are the ones that can lead to lasting success.

An illustration showing a repairman fixing a Scrum appliance
Article

Why Scrum Isn’t Working Even Though You’re Doing Scrum

Story splitting helps teams turn large user stories into smaller, valuable pieces they can finish within a sprint without turning them into tasks.

A man and woman discuss the sprint goal inside open elevator doors. The caption reads, A sprint goal is a one-sentence summary of the focus of a team's sprint. The idea is to be able to relay what the team is working on in the length of an elevator ride.
Article

The Sprint Goal: What It Is and How It Can Help

Sprint goals are something every Scrum team should try to create. Learn what sprint goals are and what a good sprint goal looks like.

Article artwork for How to Create Self-Sufficient Scrum Teams.
Article

How to Create Self-Sufficient Scrum Teams

Help Scrum teams take more ownership without becoming disconnected.

A rowing team gets to the finish line faster than other kayaks rowing as individuals
Article

Why Your Scrum Team Still Works Like Individuals

Learn how handoffs, individual task ownership, and status-report daily scrums keep Scrum teams from collaborating—and what to change next sprint.

Article artwork for What Is a Product?
Article

What Is a Product?

Define products clearly so backlogs, teams, and ownership make sense.

Text graphic: Estimate product backlog items before sprint planning.
Article

2 Times to Play Planning Poker and 1 Time Not To

I recommend using Planning Poker on product backlog items rather than on the tasks that make up a sprint backlog.

Article artwork for Your Team Won’t Think of Everything in Sprint Planning Meetings. And That’s OK.
Article

Your Team Won’t Think of Everything in Sprint Planning Meetings. And That’s OK.

Your team is probably spending too much time in sprint planning meetings. Here’s how to spend less time but plan better.

Article artwork for The Goal of Sprint Planning.
Article

The Goal of Sprint Planning

Sprint planning may look like it’s about tasks and estimates but those are not the goal.

Becoming a product owner is a big decision. Have you considered becoming a product owner? Maybe you should.
Article

Should You Become a Product Owner?

Explore the skills, paths, and tradeoffs to consider before stepping into the product owner role.

Training

  • Services
  • Agile Coaching
  • Backlog Story Improvement
  • Estimating & Planning
  • Leadership Alignment
  • Agile Training ROI Calculator
  • Team Improvement Sprints
  • Scrum Team Improvement
  • Private Workshops
  • View All Workshops
  • Compare Workshops

Agile Guides

  • Topic Hubs
  • New to Agile or Scrum
  • Scrum
  • Agile Teams and Collaboration
  • Product Ownership
  • Product Backlog
  • User Stories
  • Story Points
  • Agile Planning and Forecasting
  • Agile Leadership
  • Leading Agile Initiatives

Resources

  • Agile and Scrum Videos
  • Webinars
  • The Mountain Goat Software Blog
  • Books by Mike Cohn
  • Free Tools
  • Weekly Tips from Mike Cohn

About Us

  • About MGS
  • Our Company
  • Mike Cohn
  • Client Stories
  • Testimonials
  • Contact Us
  • Book a Call
  • Send an Email
Mountain Goat Software
Copyright ©1998–2026 Mountain Goat Software. All Rights Reserved.
  • Contact Us
  • Terms and Conditions
  • Privacy Policy