Script

Introduction

In the classic view of management, we can visualize a pyramid with the leader at the apex of that structure, and the team in the layers underneath. In this model, the leader is able to observe broader patterns and strategies, and delegate actions and responsibilities for those outcomes to those in the layers beneath.

This hierarchical model of a team may not be very fashionable any more, especially in tech where engineers prefer a flat structure, but the reality is this pyramid shaped team structure has stood the test of time for hundreds, maybe even thousands of years.

Many engineers I have worked with really hate this structure however and will challenge it continually. One way they will do that, is to try to deflect actions back to the leader, for example via repeated escalations. The term I like to use for this is “reverse delegation”, and its a really dangerous pitfall for a leader to fall into.

But firstly, to explain what it looks like more clearly, you can imagine an inverted, upside-down pyramid, where the apex is pointed down and the wide base is pointed up: now we have the leader, you, positioned at the bottom of the structure, with all of the escalations, actions, and responsibilities flowing down towards you, which is naturally a very uncomfortable place to be! Effectively the inverted pyramid is the same shape as a funnel, which is funneling all of the work to the hapless leader at the bottom.

This is great news for your team as they can effectively give you the actions, while they are freed from those responsibilities. Meanwhile, you then become a “servant leader” in the literal sense, where you end up directly doing some or all of the work of your team.

This inverted delegation trap is a classic pitfall for new managers to fall into, but even seasoned managers can find themselves knowingly, and reluctantly falling into this trap due to having someone in the team that they do not trust to delegate to due to capability concerns, so then end up taking on a specific action themselves to “get the job done right”.

The long term consequences of reverse delegation is of course that it does not scale, as there are less people at the apex of the pyramid than at the base. If the base is ineffective, it needs to be fixed either by training, or if stronger corrective action is required, then by team member rotations. The leader is there to give direction, not do the work of a subject matter expert.

If you are an engineer listening to this, or a new leader, remember that the more you overwhelm your leader with every little detail instead of handling it yourself, the more you bog them down. And if you leader is bogged down with actions and escalations, then they have less time available to help you and your team to succeed where it matters.

Remember just like engineering, leadership is also a function with clear deliverables, even if right now in your career those leadership deliverables may not be clear to you. Worse than that, if you continue to escalate to an experienced leader, your credibility with that leader may reduce as they start to see you as part of the problem, and not part of the solution.

As a leader, if you see the same team members consistently escalating to you with topics that they should be handling themselves, you must make that expectation clear to that colleague: they were assigned the action, so they are responsible for the delivery.

You must keep pushing back on them. If you start to find this push-and-push juggle happening with the same individual too often, in spite of giving clear feedback on the expectations, then you must be honest and make a decision on whether or not that person is a good cultural fit for your team and worth the mentoring time investment.

To use an example, suppose you have an engineer in your team who has been assigned by you to resolve an issue. The engineer goes off for a few days to investigate the issue, and then comes back to you to present their fix, or so you suspect.

Instead of presenting the solution, the engineer presents two further issues to you that they have discovered during their investigation, and then asks you what to do about those. Meanwhile, the original issue is still open. This may sound far fetched, but I have been in this situation many times before. So why is the engineer in this example behaving like this?

1. They are buying time.
2. They are trying to highlight issues created by their peers or predecessors.
3. Most importantly of all, they are trying to make you responsible for what course of action should be taken next, therefore reverse delegating to you.

I call people like these “problem staters”, and I spoke about them before in my 2020 blog entry entitled “The problem is”.[1] They focus on problems, not solutions, and if you are not careful in how you manage them, they will surround you in a forest of problems as they discover news ones each and every day.

So what can you do to handle team members like this? Here are some strategies:

1. If we go back to the pyramid analogy, you want the top of that pyramid to be like a polished mirror, pointed down back into the pyramid. In other words, actions and responsibilities need to bounce off you and back into the team.
2. You can adjust you language to achieve this, for example if we examine the engineer who is presenting technical problems back to you to solve, your default response should be “what do you recommend we do with that issue?”.
3. Another approach is to “deflect and move on”, namely if an issue escalated to you just now is not a blocker, then tell your team “create a new issue on the backlog to track that, then ignore for now and move on to higher priorities”.

Ultimately, if a team member is constantly trying to reverse delegate to you and they are just not responding well to your mentoring, you are going to have to replace them out of your team. It sucks, but them wasting your time every day, and wasting company money, sucks a whole lot more.

Wrap-up:

So to recap, today we discussed that:

1. The classic image of a team hierarchy is like a pyramid, with the leadership function on the apex, and the team on the base. The leader delegates actions and associated responsibilities down to the team, while the team escalate to the leader.
2. In the reverse delegation scenario, the pyramid is upside down: the leader is on the bottom, with excessive escalations being funnelled down to them, along with the ownership of the actions and responsibility for every single little issue.
3. Reverse delegation does not scale, as the leadership function in any team is smaller than the team itself. The servant leader becomes overwhelmed, and will soon burn out. Meanwhile, the team is under utilized, and also blocked while waiting on decisions from the servant leader. Nobody benefits from this anti-pattern.
4. The leader must train their team to take responsibility for issues, especially when it comes to finding the solutions independently. Some team members become “problem staters”, when they get stuck in the anti-pattern of stating the problem to the leader, and waiting for the leader to propose the solution.
5. Problem staters need to be fixed via coaching, via clear expectations on their role being set. If they do not meet those expectations over time, then you may have to replace them in your team.
6. Inexperienced leaders can easily fall into the reverse delegation trap, but even experienced leaders can sometimes knowingly fall into this trap, when they cover under-performing members of their team in a bind, by taking over responsibility of their actions directly due to a lack of trust.

Finally just to emphasize, in my opinion “servant leadership” is a really bad idea, not only for the reasons I have already outlined in this podcast, but also because there should be no “servants” in any team, actually I find that term offensive.

Every body has a job to do in a team with a different set of responsibilities: dumping your responsibilities onto a “servant” should never been acceptable in any professional environment. We are all equals, we succeed or fail together.

I hope you enjoyed this episode, and I look forward to covering the next topic in this series with you! In the interim if you want to follow me online, you can find my blog at TechLeader.pro, or follow me on Twitter @TechLeaderPro.

Thanks for your time, take care and have a great week!

Refs:

[1] https://techleader.pro/a/527-The-problem-is

Download

techleaderpro-episode-4.mp3

File details: 14 MB MP3, 9 mins 47 secs duration.

Subscribe

Apple Podcasts (iTunes)

Spotify

Google Podcasts

Amazon Music

Main RSS feed

Sponsor

Five.Today is a highly-secure personal productivity application designed to help you to manage your priorities more effectively, by focusing on your five most important tasks you need to achieve each day.

Our goal is to help you to keep track of all your tasks, notes and journals in one beautifully simple place, which is highly secure via end-to-end encryption. Visit the URL Five.Today to sign up for free!