Managers and Agile and Riding an Elephant

Leading Managing and AgileAt some point in time, Tanner Wortham and I decided to guest post on each other’s blog.

Tanner was kind enough to let me go first – and the results are here on Spikes and Stories “Retro Technique: Building Team Empathy”

Then it was “Tanner’s turn.” He pinged me via LinkedIn to nail down a topic:

Let me scan through my list of topics that I’ve jotted down over the last month.

Hmmm … I have one topic in mind about the manager’s place in an agile shop, but that’s a rather controversial topic (especially with how I intend to write it).

I’ve also thought of writing a follow up to one of my most popular posts: Tips To Be a Successful Scrum Master:  It would be the top 10 (or 8 or 7) tools a scrum master/agile coach should have in his belt. My initial post was primarily about mindset. I envision this one to be about mechanics and be more tangible.

What do you think?

To which my reply was:

Are you shocked?

Every good leader should try to teach people all he knows... Click To Tweet

Let the Dialogue Controversy Begin

Andy: Ok, Tanner. I’ll take the bait. Tell me more…

Tanner: Here’s my hypothesis and my solution:

  • Hypothesis:  The overlap between the role of the traditional manager and a self-organizing agile team creates unnecessary complexity, causes confusion, and creates dysfunction.  While there’s a place for leaders, there is no place for managers in an agile shop.
  • Solution: Toss the title “manager” in the trash and rename them as mentors, leads, or something other.  These previous managers will be assigned to an agile team as a team member.  They’ll mentor others of the same discipline on other teams and assist with inter-team dependencies, as needed. Managers and agile don’t mix.

A Shared Vocabulary: Managers and Agile

Andy: Interesting, and you did warn me 🙂 …. Two questions pop into my mind:

  1. What do you mean by “the traditional manager”?
  2. What do you mean by “an agile shop”?

Tanner:  Let’s tackle that second question first.  What’s an agile shop?  It’s pretty straightforward really.  It’s a place that embraces everything we know and love about the Manifesto for Agile Software Development (a.k.a. the Agile Manifesto).  Have another read here and here if it’s been a while.  If this agile mindset has permeated throughout the entire organization, you’re an agile shop.  Unfortunately, I wish it were that simple.  Here are a few cases where you might not be as agile as you think:

  • Did you follow the two links above and have a knee jerk reaction: “We’ve been agile for years. We rock in every way.”  If the answer is yes, you may not as agile as you think.  An agile shop is one who recognizes the journey for perfection is never achieved.  It’s a place where good enough never is.
  • Does your company execute scrum by the book?  Have you standardized everything across the company to work at peak performance? Might you actually be following the rules but not understanding the game? Doing scrum isn’t the same as being agile.  That’s for certain, and I talk about more about it here: “Agile Mindset Over Scrum Mechanics.”
  • Even if you and your teams live, breathe, and embrace the ways of agile, what about the rest of the company?  Do they?  You may be agile in all the right ways, but it’s important the company and all the “staff functions” have a similar mindset.

Here’s one more sanity check for you.  Go to Comparative Agility and ask your organization to complete their survey.  Ensure you sample the entire organization and not just those who agree with your points of view. The survey will compare you to other companies to see how you stack up.

managers and agile shopsNow, let’s talk about a traditional manager.  His name is Ed, and he’s an engineering manager. Several years ago, Ed was an engineer himself, but over time, he became a full-time manager and no longer practices his craft.  He hasn’t in some time because he wants to focus all his energy on his six direct reports, and they take up a lot of his time in a number of ways:

  • As a resource manager.  He assigns people to work based on their skill sets and also manages dependencies between his resources.  After all, no one knows the capabilities of his resources better than he.
  • As an arbiter of priorities and solutions.  When projects conflict, he decides which has priority.  He also dictates solutions, where necessary.
  • As a compliance manager.  And by “compliance” I am referring to the responsibility of ensuring that he and his people comply with all organizational policies, that all are good citizens and playing by the rules of the organizational game. When one of his resources misbehaves, he gets involved.  When it’s time for a yearly review, he gives it.  He’s also working with upper management about his reports’ yearly salary increases.
  • As a coach and mentor.  Ed doesn’t get to spend as much time as he’d like here.  Those first three buckets eat away at most of his day.  (Sometimes all of it on a chaotic day.)  And because he’s not practicing the craft himself or as involved in the code as he used to be, it’s sometimes challenging to give solid guidance.

But here’s what’s funny.  Would Ed ever exist in a new start up?  Doubtful.  When you’re small, everyone must contribute to the bottom line to survive.  Every person matters.  Person, not resource.  When you’re small, being lean matters.  Being nimble is necessary.  Waste is repelled.  Arguably, every start up starts out agile and along their journey … somewhere … somehow, something goes awry.

Start ups start out agile … and somewhere ... somehow, something goes awry. Click To Tweet

Wait, Don’t the Managers Actually Do Something Around Here?

Andy: Ok, I’m following you. My next questions is: if we 86 the managers at that level, what happens to that list of responsibilities?  And related: why stop at that “first layer” of management? What happens if we get rid of ‘em all?

Tanner: So it’s clear Ed doesn’t work in an agile shop. Agile teams are responsible for their own resource management and priority management.  The compliance piece gets more interesting.  For example, a solid agile team has an environment of trust and candor.  Team members give frequent feedback to others on the team. It’s specific, it’s relevant, and it’s helpful. These quick feedback cycles reinforce proper behaviors in ways that yearly reviews could only hope, and managers aren’t often present when something goes wrong.  They often have to deliver feedback second-hand never having observed what occurred.

Quick feedback cycles reinforce proper behaviors in ways that yearly reviews could only hope to. Click To Tweet

All that Ed has left on his plate is coaching and mentoring, which is arguably his most important responsibility.  After all, every good leader should try to teach people all he knows, not so he can be replaced but so he can be promoted.  In order for Ed to be an effective coach, he must be able to relate to his people, and in order to mentor, he must practice his craft.  In short, Ed needs to become a team member.  I recognize that he can’t be a full-time member since he has collateral responsibilities, and that’s okay.  We need to grow our people, and by putting Ed’s reports on other teams, we gain cross-team communication for free, and this is worth the price of admission.

And let me speak personally for a moment.  I’m a scrum master; I’m a manager of scrum masters.  I will always ensure I serve a team no matter how many scrum masters report to me.  It gives me an opportunity to grow professionally and to set an example for those that report to me.

Spotify Agile Management ModelMy inspiration for this model comes from Spotify and Henrik Kniberg, and it’s a very weak matrix model.  Squads are agile teams, and Ed would be a chapter lead for one of those chapters seen below.

That brings me to your second question:

“Let’s get rid of all managers!”

Absolutely not!  I’m only suggesting that those first-level managers become team members with mentoring responsibilities.  Not everyone should be a member of an agile team.  You can’t establish, guide, and executive strategic vision for a company if you’re knee-deep in tactical decision-making.  Spotify’s model suggests as much as well with the figure in the top left of each tribe.  His or her responsibility is to tribe as a whole with no team-level responsibilities.  Again, I only suggest first-level managers become team members.


Project managers in transition to agileAndy: Ah, now I see what you’re saying. (We can come back to the question of all or some later…) So what’s the transformation path for Ed look like, from his old role of command and control to servant leader? What skills does he need to learn/unlearn? Who helps him on his journey? And equally important, when Ed stands back from his command and control role, how and where does the team need to step up? (Ok, that’s more than one question….)

Tanner: Are you familiar with the elephant and rider metaphor?  This video explains in well in two minutes.  It’s a great metaphor that describes how to affect behavioral changes, and Switch by Chip Heath explains it thoroughly.  It has three parts:

  • The rider.  This is your logical side.  It’s the side that sees you’ve put on a few pounds and says, “I’d like to lose some weight.”
  • The elephant.   This is your emotional side.  When you get hungry, this is the side of you that says, “I’ll just cheat this one time because I’m starving.  It’s no big deal.”
  • The path.  This is the external environment.  If your pantry is full of fattening food, your path is littered with the temptation to lose that weight so the food has to go and be replaced with healthy alternatives.

All three parts must be addressed, and even when your logical side recognizes that change is necessary, it will have a hard time directing the very large elephant if he emotionally disagrees with the change.

That brings us back to Ed.  We’ve adjusted his environment by placing him on a team, but that’s certainly not enough.  As Chip Heath points out in Switch, “For anything to change, someone must start acting differently.”  We need to address the three parts we talked about above for the change to be successful.  So let’s talk about that.

First, let’s direct our rider by scripting a few critical moves.  We’ve discussed with Ed our new expectations as a coach and mentor, and we also talked with him about peeling off his other responsibilities as a resource manager and compliance manager.  Additionally, we’ll need to ensure he isn’t overwhelmed with direct reports so if he had six previously, we’ll adjust it to three.  Finally, by placing him on a team, we’ve adjusted his environment and changed his routine.

Second, we’ll talk to our emotional elephant.  I fear Ed will feel this is a demotion.  Ed’s contributions as an engineer and before he became a manager were instrumental in the company’s success.  We’ll stress this.  We’ll also stress that we want our senior engineers leading from the front, not the back.  And, Ed, didn’t you say some of your guys were looking for promotional opportunities?  We’re creating those opportunities, and we want you to help lead that charge.

Finally, let’s shape the path.  Instead of implementing a sweeping change across the entire organization all at once, Ed will lead our first pilot.  He’ll be our first manager turn leader.  With his help, we’ll uncover the pain points, the difficulties, and if all goes as planned, he’ll be our first success story, which he can share with others in the organization as we continue to adopt the change.  By calling it a pilot and by starting small, it gives us breathing room to learn from and recover from any small failures that happen along the way.  These failures are okay.  In fact, they’re expected.  Although the idea is simple–place Ed on a team–the impact is great, and the change of context is bound to affect many parts of the organization.

Failures are okay. In fact, they’re expected. Click To Tweet

Everything is Hitched to Everything Else

Andy: I like it. And it reminds me of a quote by John Muir.

“When we try to pick out anything by itself, we find it hitched to everything else in the Universe.”

So when Ed begins to change, everything else needs to change too. Just about all of what Ed used to command and control now gets distributed to the team.

Let me see if I can elaborate in the format of a matrix:

Function/role/issueCommand and control Boss/Manager
Aka “The Parental Manager”
The manager/leader
Aka “Teacher, Mentor, Coach, Facilitator”
Problem SolvingEd provides solutions and answers to problems.Ed now asks “the right questions
Performance ReviewsEd does the annual evaluation.Ed facilitates 360’s
CompensationEd decides based on consultation with upper management.The team decides compensation within the constraints of their environment (total team budget) – Perhaps they have a salary formula that includes “Merit Money”
Hire/Fire DecisionsBelongs to the Ed with consultation with upper management.Who to bring on board, who to jettison are all team decisions, along with consultation with Ed. And ties go to the team….
MetricsCreated and reviewed regularly by Ed and upper management. Used to show success or failure.Metrics are chosen by and used for learning by the team. They create their own evolving metrics ecosystem. See these posts.
ChangeTop-down, big bang, and terms dictated to teams. Failure is not an option.The team is given authority to experiment. Failure (with learning) is not only “tolerated” it is encouraged.
Conflict ManagementProblems are escalated to Ed who attempts to resolve conflict. Individuals rarely give constructive criticism to one another.Ed helps create a safe container for conflict but solves nothing. Ed is now a catalyst, facilitator, coach and perhaps shrink. The team uses feedback wraps and improvement dialogues. See these posts.
Job Descriptions / TitlesEd writes them.The team defines the roles they need to GSD. Roles are fluid.
Goals / VisionEd dictates the what of the goals, but rarely offer the why or solicits feedback.A high level “organizational mission” provides intent. It is understood that end states are not fully clear. Ed encourages creativity and innovation; experimentation
ProcessEd defines the processes. Expects the team to follow them w/o questions. “This is the way we do it, it’s the way we’ve always done it…”The team creates their own processes which are evolutionary. They keep what works, and change what doesn’t. Complexity thinking. Retrospectives.
EnvironmentEd controls it. Largely siloed and most interactions require Ed’s assistance between individuals.Ed ensures that necessary organizational financial resources (budgets) are available for the team to accomplish its mission. Team can work when/where they are most productive.
AuthorityPermission is granted from above.All authority not expressly reserved to higher organizational structures is granted to the team. Team exercises autonomy, initiative, judgment, within loose guardrails. Team uses a delegation/empowerment matrix. Team Agreements. See these posts.
MotivationEd relies on both a carrot and a stick. External motivation is preferred. KPI’s are dictated top-down.Ed supports systems that enable intrinsic motivations. OKR’s
Cross Team CoordinationEd handles all cross-team issues.Ed enables S2 and S3 (scrum of scrums)
HR PoliciesTop-Down. Work work work. Ed approves and records your time off. He probably tracks your hours. And, sorry, there is no overtime pay. You’re exempt….Policies are created bottom up to support the healthy working of individuals. Work-life integration is a priority. The organization supports developing/growing competencies: Skill Matrix

Kudo/Merit systems

Training / CompetenciesDictated competencies. Ed rarely suggests training for his team and consideration for training brought to him requires a great deal of convincing. “Show me the ROI on the course…”Team determines skills/competency needs. The environment provides the capability to get them. May provide expertise, as a “Master” to Journeymen and Apprentice (Technical, Business, Transformation)
FailureEd will find someone to blame seeking. After all, failure is a punishable offense.Everything is accepted as a learning opportunity. Failure (with learning) is a thing to be celebrated. The prime directive of the retrospectives. Success cannot exist without failure.
Compliance (hr, legal, regulatory, ISO, etc)


 Ed is responsible for ensuring all members comply with organizational mandates, policies, standards, etc.. He might assign out related tasks, but he is the single wringable neck.
Constructive Conflict, Radical Candor. Shared fate.
Sorry, Ed. Your neck is still wringable for this one until we change our legal system….

Where to Go From Here?

When we try to pick out anything by itself, we find it hitched to everything else in the Universe. Click To Tweet

Wow, thanks for sticking with us … this ended up being an epic post. Any thoughts on what to do about stuff like ISO Compliance when working with a agile shop?

And what happens if/when we scale this model to the larger organization?

Those, our friends, might just be the subjects of a few future posts!

Recommended Reading


  1. Jurriaan Kamer

    Excellent post!
    When it comes to compliance, I believe there are often alternative ways to satisfy the regulatory requirements. Often the problem is in the way the traditional control departments operate. If their way of working is redesigned from a team perspective, it can be done while keeping the responsibility on a team level. Also, many controls can (and should) be automated.
    I talk a bit about this in the last part of my post about cutting red tape:

  2. Phil Zofrea

    Fantastic topic and discussion format! The company I’m at right now has challenges in the performance evaluation, compensation and hire/fire areas that you’ve identified. We are looking to implement 360s and a monthly meeting where the person answers – What went well for the last month? What do I need to improve? What are action items I want to accomplish before next time we meet? This is driven by the person themselves with feedback and guidance given by the mentor or manager.

  3. Pingback: The Power of Three: Navigating Uncertainty – AgileUprising

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top