Stepping out from behind the shield: Empowering your team to take ownership
Taking on all the responsibility yourself doesn't make the team stronger
A great leader is one who defends their team tooth and nail, protecting them from all external interference and allowing them to stay focused on the goal without ever having to do context switching. Only in this way will great results be achieved.
Do you agree with that statement? I hope not! I used to believe that too, but then I realized it only works in very few cases. Most of the time, the team is constantly bombarded with external requests, changes of direction, problem-solving, etc. It's definitely true that a leader's job is to shield the team and be able to handle everything that comes their way from the outside; but that doesn't mean passively taking it all in and focusing everything on themselves.
A team is only as strong as its weakest link. When someone acts individually, they weaken the team and increase the risk of failure. And this is not only true for the people who report to the leader, it is equally (if not more) true for those who lead the team.
I know what you may think when you read these first paragraphs: the main reasons a leader focuses everything on themselves are lack of trust and inability to delegate. But in this article, I want to focus on another equally important issue: being a "helicopter parent" to their team.
I realized that before I became aware of how to react correctly to external requests and plan fields, I always reacted to the two extremes:
I said NO to all requests
I said YES to all requests, taking them on myself and handling them alone to avoid burdening the team's planning
Obviously, neither of these approaches worked and led to a number of problems that I want to address below.
🙅 Saying NO to all requests
Strict deadlines, roadmap to follow, projects to complete, KPIs to achieve. “There is no room for anything else, I'm sorry but what you are asking for is not possible.” Locking all doors and completely isolating the team from the rest of the world for a quarter is practically impossible.
Business needs change rapidly and, simply put, saying no to a request or a change may lead to missed opportunities. A leader who habitually says no fosters a culture of risk aversion. Furthermore, it affects the atmosphere both within the team and in relationships with other colleagues and management.
When I had this approach, I believed I was shielding my team from excessive stress and workload by rejecting all external demands. However, this overprotective instinct can be counterproductive, preventing the team from experiencing growth through manageable challenges. “Responding to change”, as someone once said.
What could be a good idea, instead, is having this protective approach but with part of the team only. If you have some members of the team working on a critical path or dealing with strict deadlines, it would be a very good idea to protect them from external interference and let them focus. The rest of them might help and, as always, an open line of communication is crucial to avoid discontent within the team.
🫡 Saying YES to all requests
The other flip of the coin: not even considering the possibility of saying no to a request. Generally speaking this is even riskier than denying every request because it can quickly overwhelm the team with excessive tasks, leading to lack of clear direction and priorities, burnout, and decreased productivity.
In my case, instead, saying YES to all the requests coming from the outside meant centralizing all requests on myself to avoid overloading the team and making them switch contexts. Was it good? Nope. Have I stopped doing it? Nope, not entirely at least. I still find myself doing it sometimes. The first time I received this feedback was about 3 years ago. During a 1:1 meeting, my manager pointed out this behavior to me. Despite keeping it in mind since then, one of the guys on my team gave me the same feedback just recently.
The fact that it's done with the best intentions prevents me from feeling guilty, but it still doesn't mean that it's right to do so. I've tried to analyze the reasons that led me to take everything upon myself rather than saying no on one hand and not overburdening the team on the other. Some of these reasons are:
Difficulty in determining the importance of the request. Lacking context, necessary information, and not asking the right questions hinder understanding as to whether the request is legitimate and its priority compared to other activities
The desire to maintain positive relationships and be perceived as cooperative and responsive. Wanting to be accommodating, avoiding conflicts: it's way easier to say yes and take on more work than to have discussions.
There are a couple of important aspects to take into consideration. I’m talking about requests that could have been handled by me because I have the skills and the knowledge to address them. This is not always true, there are requests that I cannot fulfill independently. How can I handle these situations? This is one of the reasons why we shouldn’t just say yes automatically. Secondly, if I always had the time to handle external requests, there's an underlying issue. Either my work isn't important or I'm neglecting other crucial activities in my role.
🤝 Embracing change
As you can easily imagine, between saying yes to everything and saying no to everything, there's a middle ground where we can set boundaries while being flexible.
In another post, I’ve already talked about decision making and how to delegate and empower the team to make decisions. This is definitely helpful to avoid overload but there’s also an additional step required before relying on the team’s help to manage change: evaluate each request and master the art of negotiation.
I'm not stating any profound truth, but there's a big difference between knowing the obvious and applying it, and that's what sets things apart.
Two things have helped me live with stress-free changes in direction and external demands that impact the team's life: having a clear direction and understanding how these demands fit into the bigger picture, and most importantly, accepting that change happens rather than resisting it.
If we start from the assumption that no one will make requests just for the sake of it, but because there’s a specific need or problem to be solved, then it will be enough to clearly understand the reasons to realize the importance of such a request. This also enables the rest of the team to be more open and less resistant to changes on the fly. Once the reasons are clear, it's possible to decide how to proceed:
Consider the importance of the request: is the request aligned with the team's goals and priorities? Is it something that will have a significant impact on the project or the client?
Assess the team's capacity: does the team have the time and resources to take on the request? Are there any other tasks that are currently taking priority?
Evaluate the potential risks: are there any potential risks associated with taking on the request? Could it lead to delays, burnout, or other negative consequences?
According to the answers to these questions, there can be different ways to respond to the request: “Yes, we’ll do it”, “Yes, we’ll schedule it”, “No, we cannot do it as …”, etc. This is further confirmation that asking the right questions and understanding the impacts clearly does not necessarily mean having to say yes.
Another step we can take to improve communication and manage relationships with external parties is to “educate” stakeholders: help those around you improve their organizational skills. Better organization can reduce the number of urgent requests and lead to a smoother workflow. However, recognize that not all requests can be mitigated this way, and some need immediate attention.
TL;DR
Self-care and team care are essential for long-term success. Navigating external requests requires a balance between flexibility and setting boundaries. While it is important to shield the team and keep their focus, finding the right balance to let change be part of the normal workflow is important too.
Credits: Illustration 1