Fixing broken support: pitfalls
Can't fix what's not broken, so maybe you'll have to break it first (please don't do this)
As I not so subtly alluded to last week, it’s one thing to make a plan for improvement, but quite another to implement it. There are a lot of things that can go wrong, including but very much not limited to:
The steps you have identified are out of your budget: acquiring new tools, new training, or new headcount
Despite your best efforts at education, your own leadership refuses to sign off on your plan
Contractual agreements prevent following the plan you have laid out: for example, while you and your leadership agree that restricting support availability to specific hours is the right move to improve service, you may have an existing contractual arrangement with some or all customers requiring 24/7 availability
While these (and many other force majeure events) are things to keep your eyes open for, there’s not a lot you can actually do about them beyond being aware and advocating for yourself and your team. What I want to focus on today is one set of roadblocks you can actually navigate under your own steam: how you and your team surmount interpersonal and interdepartmental hurdles that can come from making changes in how you do things.
Technology and procedures
The longer a tool, a process, a cross-team interface has been in place, the harder it is to dislodge. People get used to how things are done, and few people enjoy change even under the best of circumstances. Replacing carrier pigeon communication with email may make perfect sense from a business, timeliness, and technological perspective, not to mention the cost in pigeon room and board. But there’s guaranteed to be someone whose preferred workflow relies on carrier pigeons—perhaps they fertilize their tomatoes with the guano—and will be upset about having to relearn ‘the new way’ to send support updates. However innocuous the change, someone will probably be put out by it. Don’t take it for granted that everyone will see the clear benefits that you do.
Meet the new boss
Setting aside process and technology changes entirely, consider the interpersonal context. You may have come in to replace existing support leadership, in which case you’ll need to take some time building up your own crew and getting to know your new team, while at the same time fighting off comparisons—spoken or otherwise—with previous leadership. Perhaps the team had a bad relationship with their leaders before, in which case your biggest challenge is convincing them that you’re different. On the other hand, they may have loved the old boss, and you’ll have to endure unflattering comparisons if not outright rebellion when you operate differently.
When you find yourself in this situation, do three things immediately:
First, figure out which kind of leader you’re replacing: liked or disliked. Ask your own leaders, ask your team one on one.
Second, if this wasn’t already made clear during the hiring process, find out exactly why the previous leader is gone. Get this from leadership, not from speculation or watercooler chat. This reason may or may not be something your team is even aware of, and may be something you can’t discuss with your team. But pretty often it’ll be something everyone knew about, and you won’t need to tiptoe around.
Finally, armed with that knowledge, prepare the charm offensive. Demonstrate by your actions that you are a leader who can be trusted with the stewardship of the team, that you have the team’s and company’s best interests in mind, and that you have a vision for what the team can be. It certainly doesn’t hurt to reinforce all of this in your individual and group meetings, of course, but words on their own are meaningless.
If you’re slotting into an existing command structure, and the team’s previous leader is still around, you’ll still have to deal with those pains of transition, but your job isn’t as difficult. You can strategize with your predecessor directly to present you as either the natural continuation of existing good leadership or as a change for the better. (If the old leader was bad, and doesn’t recognize the need for a change, that’s another conversation entirely. Better hope you’re managing them and not vice versa.) Presenting a unified front to your team that the shift in leadership is a good thing for the team should go a long way to smoothing out the transition.
What will the neighbors think
Be aware that the changes you are making have an impact on more than just your team. Customers will notice a change, and the other groups that the support team interacts with internally will also have to get used to the new normal. Head this off as best you can by keeping your counterparts informed. The more regularly the support team interacts with them, the more in-depth your communication needs to be. A simple heads-up is sufficient for teams you rarely interact with, but for closely allied functions like customer success and presales technical teams, it is imperative that their leaders know exactly what you’re up to and on what timeline. If, for example, you plan to update your internal severity prioritization scheme, tell any other customer facing teams immediately so they can communicate this change to their own customers. And of course you solicited their input ahead of time, right? Nobody likes being taken by surprise.
Any customer-relevant changes also need to be communicated to, big surprise, the customer. Sometimes this will be your team’s responsibility, sometimes it will be coordinated on a customer-by-customer basis with the customer success team, and sometimes it’s best to communicate via official channels to the entire customer base via marketing or a communications team. Whichever is the case in your organization, communicate with all relevant internal stakeholders and ensure that the customer is in the loop before making any changes to the service you offer.
Go forth and fix things
Making big changes to any system is going to be disruptive, more so when the systems are complex. And a support team has a lot of moving parts. Be prepared for a prolonged period of adjustment as you are tuning and improving your team’s composition, processes, and tooling. But the more you prepare ahead of time, and communicate your upcoming changes to all stakeholders, the more likely you are to end up with a significantly improved support experience. Good luck!
Thanks for reading Andy's Support Notes 💻💥📝!