File details: 17.5 MB MP3, 12 mins 11 secs duration.
My name is John, and welcome to episode 2 of the Tech Leader Pro podcast. Today I am going to offer you some advise on how to handle escalations, but before we begin, I would like to briefly mention our sponsor Five.Today, which is the ideal product to help busy tech leaders to manage their days.
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!
And now, let’s get to our main topic without further interruption.
Regrettably as a leader, you will have to handle escalations from numerous sources both inside and outside of your team. It is one of the least desirable aspects of the leadership role, but it need not be as stressful as you think if you follow some simple rules to keep things compartmentalized.
Put simply, you need to reduce the emotion and stick to the facts, but let’s explore that in more detail during this episode.
Firstly, its important to think about the different sources of escalations you will encounter, for example:
Each of these are quite different, so let’s look at each of these separately.
In a previous role, I took over a large customer project from a predecessor who quit, which can only be described as a “dumpster fire”. The project was late, and stuck in user-acceptance testing due to hundreds of bugs being opened, and the customer sponsor was openly hostile towards us. Meanwhile, our team morale was rock-bottom and different teams were openly at war with each other.
The first thing I done was a root-and-branch review of every team we had working on the project, to look at where they were failing and what needed to be improved. I met a lot of internal resistance to this, especially when those teams learned I would be openly sharing the findings with the customer, but I managed to nullify that resistance by firstly securing the backing of our COO on my plan.
Once the report was in place, I then flew across the ocean to meet with the customer, along with a senior member of each one of our team’s working on that project, and apologized in person for over an hour to our sponsor as well as his bosses, right up to Vice President level. I admitted that we had made lots of mistakes, and would take action to ensure improvements were made to each team involved, namely solution architecture, QA, development, and project management.
I simultaneously raised my credibility with the customer by being honest with them, in order to gain their trust, while at the same time giving our customer the opportunity to vent their frustrations with us, which was good catharsis for them.
In the end, the weekly 1-to-1 call I had with the customer sponsor went from him shouting at me about how bad our organization was, to after a few months us both having a chat about what we were planning to do during the upcoming weekends. The hot list of open escalations had been reduced to zero.
There are a few key leadership lessons to take away from this story.
I am not saying that you should adopt this “open, apologetic tone” as a default: many times during my career customers or prospects have escalated on me without just cause. When a manager is failing on the customer side for example, they will sometimes try to deflect that blame onto the software vendor, namely you, rather than taking that heat from their bosses. In those situations, you really do need to push back on the customer, and present the facts to support your position.
Ultimately all escalations come back to the facts: especially when emotions are running high and people are pointing the finger of blame at one another, it is the facts that will save you from the fallout.
Typically when we face escalations from the marketplace, we are either talking about bad media coverage, or some actions taken by the competition that form a threat to us. Sadly this is all part of the rough and tumble of doing business, and my first advice is that you will need to take these challenges on the chin, but I can offer further advice for how to react.
Firstly, even if you are getting negative coverage in the media, well at least you are becoming big enough that the market is paying attention to you. That is undoubtedly a good thing. Secondly as any good marketer will tell you: there is no such thing as bad press. You can capitalize on the attention, knowing it will inevitably be short-lived, in order to push your own narrative, or you may simply choose to ignore it until it goes away. Remember news cycles and attention spans are extremely short these days, especially due to social media.
If on the other hand, the market is telling you that your competition is doing great, and is in fact ahead of you in terms of product development or deals being made, then you need to dig into that to gain the facts, and learn from them. There can be no shame, and I mean absolutely zero, in studying deeply what your competition is doing, where they are successful, and seeing if you can apply those findings to your company. In fact I will go stronger than that: NOT studying what your competition are doing could be fatal, especially if they arrive via a blind spot, and start to steal your customers from you.
Escalations within your team itself can arise from time to time, for example due to personality conflicts between team members, or team members disagreeing between themselves on the way forward and coming to you to arbitrate. For these kinds of conflicts, it is important to remain objective and not takes sides: once again you must establish the facts firstly before taken any position on a dispute amongst the team.
However, these arbitrations are part of the job and ultimately you will have to make a decision, as the team are escalating to you for this very function, having realized themselves that they cannot reach an agreement without your input. Once you make a decision, the team must accept it even if they do not all agree to it, and finally you will make it clear that you will now own the outcome, as it was your decision that broke the deadlock.
When team escalations involve only one individual, typically this is due to a morale issue, like someone threatening to quit, or most-likely that individual is not happy with their role or package. For these kinds of escalations, depending on the health of your personal relationship with the employee, it may warrant including a third party in the conversation, namely a member of your HR team.
In my experience, when someone starts to make threats about leaving and attaches a package increase request to that, 90% of the time they will quit, and you are better off letting HR know as early as possible (as well as reviewing you succession management for the affected role, but that will be another podcast topic).
Finally, I have seen these kinds of package complaints turn nasty on occasion, so you may need to have an additional arbitrator or witness present during each one-to-one conversation with the employee, and you should get that third person to follow up the meeting with minutes on outcomes and agreements in writing after the meeting.
Team escalations, especially those involving complaints, can be the most stressful escalations to deal with as you will be facing those team mates every day, so the critical thing to remember is that it is never personal, and you must communicate that frequently and often that you have no agenda at play, other than to simply come to an arrangement that makes everyone comfortable.
Escalations related to technology are actually the ones I enjoy the most, as they enable you to deep-dive into some specific area of technology with the team, in order to decide on what architecture to use, how to fix a difficult bug, or how to resolve a performance issue. For these kinds of escalations, typically the answer resides with the team themselves, but they may be temporarily stuck and therefore escalated to you.
In general, I see my role in these kinds of discussions to be the chair rather than the expert, after all when it comes to having a deep understanding of technology, the engineers in your team will know more than you. However if they respect you opinion enough to ask for you help, then you should offer your ideas, even if in the end a different solution is found.
The key point is to gather the team around a whiteboard or on a call, and get them talking about the issue until agreement is found on a solution. Your role is not to offer up the solution directly, but instead to tease that out of the team by asking the right questions, for example “have you tried X?”, or “what about applying Y?” etc.
So to recap, today we discussed that:
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!