Knowing when to take the lead and when to step aside.
This is an incredibly hard skill to master and very very few managers are good at this. The reason why this is hard is that there are a lot of variables to take into account and that requires very high judgement and awareness. This is best understood with a couple of examples.
This one time, my teammate and I were investigating a severe operational issue together. We explored a few different hypotheses for the problem and narrowed the root cause to be a change made by another team. We were about to contact the team’s on-call and ask them to fix the issue. This is fairly standard and should have been resolved quickly. But this is when our manager decided to get involved and started dictating what we should communicate to the other team. This resulted in a lot of back and forth which meant that resolving the issue took a lot longer than expected. After the issue was resolved and our manager left, my teammate wondered if things would have been more efficient if our manager was not around.
What went wrong here? The manager cared about the engineers, wanted to help but still ended up being a net negative in this situation. This is a classic example of not knowing when to step aside. If the manager had better awareness of the situation, getting out of the way would have been the obvious thing to do. Even a simple ‘Do you need my help?’ is a great indicator of trust in the individuals that they would seek help if needed.
From the previous example, it should be pretty clear when the manager should take the lead — when they can be a net positive in the situation. Of course, a lot of us believe in ourselves too much that we are convinced that we can always be a net positive in every situation. Having this belief is a necessary trait for someone in a leadership role but it needs to tempered with some humility.
Let’s take another example.
A new engineer who joined our team was tasked with building a new test framework. Building it requires a) a good understanding of the team’s systems and b) knowledge of API design to know to how to build a good framework. The engineer was clearly not capable of taking on such a complex project up front and struggled for a couple of weeks. The manager stepped in pretty late and decided to shelve that project in favor of a smaller more manageable project. At this point, the engineer’s confidence was shattered, the rest of the team had spent a lot of time trying to explain the requirements for the complex project and we lost a lot of engineering time. This was a clear case of the manager not being proactive and everyone else having to face the consequences.
From the above examples, it should be clear why this is hard. The equation is complicated by a manager having to think about a lot of factors such as:
- Different levels of experience (you may deal with a junior engineer differently from a senior engineer)
- Different personalities (certain types of people need a push whereas others need you to step back)
- Different situations (if it is business critical v non-critical situation where failure is acceptable if there is personal growth for engineer)
Good luck to all the managers out there!