Servant Leader or Slave – a rant about “removing impediments”


Many organisations are talking about removing impediments as the responsibility and duty of the Scrum Master/Agile Coach/Delivery Manager. These roles will from here on be referred to as servant leader. Every time I read this in a job ad, I see it as a red flag telling me that the organisation in question hasn’t understood what it means to have (or create for that matter) a high-performing team.

Removing impediments

At one of my previous clients, a product manager proclaimed that a team should be like a D9. If you don’t know what a D9 is, I can tell you that it is a bulldozer manufactured by Caterpillar. The point he was trying to make was that the team should always be moving forward, towards the goal. Nothing should be allowed to stand in their way. And by “D9-ing it”, nothing would be able to stand in their way, because they would simply bulldoze it. I love the metaphor. It is short and simple and carries with it a powerful message.

A Caterpillar D9 Bulldozer

Where it went wrong, however, was when it came to removing the, so called, impediments. This was an organisation that was so focused on moving forward that it completely missed the point with creating a high performing and empowered team.

Promoting passive behaviour

If you have a team and everyone expects the servant leader to “remove impediments” you are promoting passive behaviour which fuels a culture with a mentality of someone else’s problem. Meaning that someone else will take care of that thing, i.e. it’s not a concern of mine.

I have actually taken part in the following conversation. An engineer was talking about what he was currently working on but there was nothing on the physical board that promotes his work.

  • Me: Why don’t you write that on a post-it and stick it on the board so everyone can see that it is ongoing.
  • Engineer: I don’t have any Post-its.
  • Me: Aren’t they usually here, right next to the board?
  • Engineer: Yes, but there are none left.
  • Me: Have you checked the stationary cupboard?
  • Engineer: No.

I walked the 7 meters required to get to the cupboard and picked up a pack of Post-its and took them back.

  • Me: There you go, now you can write a note and put it on the board.
  • Engineer: I don’t have a pen.
  • Me: Why don’t you use that one? “pointing to a pen on a desk nearby”

Engineer picks the pen up and gets on with it.

This is not the only time I’ve been in a situations like this, and it’s usually the organisation’s fault. When an organisation emphasizes that the duty of removing impediments as someone else’s problem rather than the team itself, you get a dysfunctional behavior. This behavior will creep lower and lower in the complexity ranks of tasks. Until you get to the point described in the conversation above, where a simple task like getting more Post-its will be someone else’s problem.

No time to work proactively

In Lean, we talk about eliminating waste. Waste in the sense of proactively identifying potential process improvements, instead of reacting to an event that has already occurred and caused damage. Don’t get me wrong, we still need to react to events and make sure we learn from them. But this should be on rare occasions. As a servant leader to the team, and organisation, we should do all in our power to make sure that there are no major events to react to.

If we continuously work proactively we will minimise the number of bumps in the road. But in an organisation that puts so much emphasis on that the servant leader has to react to all these bumps in the road, there will be no time left to work proactively. Resulting in the servant leader doing nothing other than reacting to one crisis after another. This goes completely against my beliefs about servant leadership.

I regularly talk about having the mindset to try to work yourself out of a job as a servant leader. Because – if you put yourself in a position where the team depend on you, or anyone else for that matter, they will never become high performing in its true sense.

It is fairly recognized nowadays that an engineer working with software development is a knowledge worker, and for this reason traditional management methods are no good and incentives like a monetary bonus makes little difference. However, there seem to be some sort of misconception that the servant leader is not a knowledge worker. And that the emphasis on working proactively to improve the team or organisation is not important. The important part is removing impediments. And the team decides what an impediment is.

Letting the team define their impediments is not what it means to empower them!

What is an empowered team?

Many organisations talk about empowerment as a means to create high-performing teams. You can phrase the following in many ways, but in essence: An empowered team is a team that has all the means to solve all their problems by themselves.

When you ask a truly high performing and empowered team, they will never, or very rarely, admit to having any problems. They will simply have yet another task to do that was unknown to them up until this point.

Let me repeat that:

An empowered team is a team that has all the means to solve all their problems by themselves.

Imagine your team is your 5-year old daughter that has a new pair of laced shoes and she is on her way out to play. But she can’t tie her shoes by herself. So you tie the shoes for her, obviously. The next time this occurs you have a choice to make; do you simply do the task for her again, or do you accept the responsibility of teaching her the skill necessary in order for her to become independent?

Creating a high-performing team is much like raising a child. You teach them values and principles that are important in their operating environment. When faced with new tasks or problems arise, you are there for them to convey your knowledge and expertise. You are also responsible for identifying when to step back and not intervene, to allow them to learn on their own.

Sometimes the process of failing will be much more valuable than someone telling them how to avoid failure. You facilitate interactions, encourage exploration, teach, mentor and sometimes (when necessary) you even tell them what to do and how to do it. But what you don’t do, is hinder their development by doing the same things for them, over and over again! After all, isn’t the goal to get them to move out of the house?

With my rant finished I just want to conclude this piece by saying:

It is not the duty of the servant leader to remove impediments for the team, it is the duty of the servant leader to teach and empower the team to remove their own impediments.

Joakim Sahlberg

And to keep doing this until there are no more impediments, just yet another task to do that was previously unknown.

Leave a Comment

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