Don’t be a hero manager
Being a good individual contributor means following best practices, applying patterns, testing thoroughly, being in control, solving problems. As technical managers, we still love to solve problems; we may even crave it because we are missing the short-term benefits of being an individual contributor. No tests passed, no tickets closed, no bugs fixed. We spend half our day in meetings or thinking about the future, with no sense of accomplishment or feelings of success from our actions, so when someone comes to us with a problem we obviously jump into solution mode, ready to share our well-earned knowledge with them.
There are many problems with this approach. We might think someone is asking for help when they aren’t really maybe it’s a situation they are handling and they are doing their job by keeping us informed, but that doesn’t mean they are asking for our advice. Even if they really are asking for help, there is a learning opportunity here that we will blow up if we just give them (what we think is) the solution. Moreover, imagine what a series of situations where we, the manager, “save the day”, is doing for our team in the long term. Do we really want a team that depends on us to make decisions and solve problems?
What are we here for?
So you might be thinking, “What am I supposed to do now when someone comes to me with a problem?”. The answer is simple, the good old “Don’t bring me problems, bring me solutions”. Works like a charm. Jokes apart (seriously, don’t ever say that), consider why you are a manager and what the expectations for your role are. This will obviously depend on your company and position, but chances are you are not there to write code, design systems, or fix incidents. You are there to build and support a team that is capable of doing those things without you.
Here are a couple of things that we can do preventively:
- Set expectations. We should make it clear to our team that we don’t have a magic wand that will solve the problems they bring to you. You will help them, but they are accountable (except when they really are not).
- Build a safe space. When we set expectations we might be sending the message that we don’t want to know when something happens, or if something breaks it’s their fault. We obviously don’t want that, and we need to build trust with our team so they don’t feel like they need to hide the problems from us.
Now, what can we do when someone approaches us with a specific problem?
- Find out what the real problem is. You do that by listening and asking questions.
- Identify the course of action to solve the problem. You do that by listening and asking questions.
But I already know how to fix this problem!
I would argue that although we might know how to fix a problem, every problem involves different people and circumstances, so it’s best to invest some time trying to dig a bit more into the problem itself before anyone jumps to solution mode. Take into account one or many of these can happen:
- Depending on the person that brings you the problem and how good you were at creating a safe space for them, this person might not feel comfortable sharing all the details because they feel responsible and don’t want to be blamed.
- What they think is the problem, it’s not really the problem, but a consequence of the real one.
- They don’t really know what the problem is, because they are missing information. Maybe they need to talk to someone and they don’t know who, or they don’t want to.
Approaching the conversation with curiosity, listening to what the other person is saying, and asking the right questions will hopefully help us get to the bottom of it. Sometimes it will be pretty straightforward, sometimes you will need more time or different techniques (like the 5 Whys) to get to the root cause, sometimes we might need more time to talk to other people or to gather objective data.
Imagine that a tech lead in your team is pissed because she’s been tasked to estimate how long a feature will take to be solved. You can assume that this person doesn’t feel confident making estimations and, using your extensive experience as an engineer, you think you can help her do it. But there are multiple reasons why she doesn’t feel comfortable in this situation, maybe she doesn’t understand why we need to implement this feature, or why she was not involved in early conversations, or she just doesn’t want to do estimations, or she fears that her team will need to stop doing something else to deliver this, or maybe she is fine with it but she is just venting a bit before getting into it. Each of these situations would allow for even further digging down; maybe this is not the first time this happens, maybe she doesn’t have a good relationship with her product counterpart, maybe she is not happy with the project, maybe she is not happy as a tech lead. Sometimes the real problem will become apparent easily, sometimes you will have to work harder, give more space, or time.
Once this is clear, we need to help the person (or the team) to identify the course of action to solve it, but it’s important that they come up with it, not us. We can use our experience to break down the problem if it’s too complex, to focus on the next thing that can be done, to point out things that they might be missing, or the impact in other areas of the company they are unfamiliar with, but our job here is to let them come with a set of actions they feel confident with, even if we don’t fully agree with them.
…even if we don’t fully agree with them
Yep. We have clearly defined the problem, identified grey areas, and risks, and they are comfortable with their course of action, but we disagree. Even if we are absolutely 100% sure that this is not the right way to fix the problem, we could still let them move forward with it. We, as managers, need to consider the risk of failing to fix the problem now with the opportunity for our team to learn from a mistake, of course taking into account that they could even be right, without considering what this means in terms of empowerment and trust.
Listening is a superpower
We probably think that we are very good listeners, we have been doing it since we were kids, right? Well… not really. Here are a few things we can consider during a conversation:
- The key to asking good questions is to get genuinely curious. It’s an opportunity for them to go deeper into the topic, but also for us. We shouldn’t assume that we know everything there is to know.
- We are there listening and nodding, but we are just waiting for an opportunity to jump and answer the questions ourselves. We are doing the discovery together, and we can contribute with our own experiences if they relate, but they should lead the process if possible. Are we giving them enough time to process the information and arrive at conclusions on their own?
- We know how to solve this, and we are asking them questions to guide them to what we think it’s the solution. This is only slightly better than telling them the solution directly. We should be genuinely curious when we ask questions. The problem we solved in the past involved different people and different circumstances, let them come with their own approach this time.
There is only one way to get better
Which is, surprisingly enough, practicing. Think about the last time a direct report approached you with a problem and how you proceeded. Do you think you could have done something differently?