Sorting out and scaling support
Bringing order to chaos
While last week we discussed building a support team from scratch, this week the situation is a bit different: you’ve been brought on to clean up and improve a support function, probably in preparation for scaling it as the company grows. As usual, read the general notes about joining as a support leader and building a team from scratch first, since here I’ll only talk about what’s specific to this situation.
So why are you here, then?
Instead of starting from zero, when you join a team like this you’re walking into an already functioning machine. It may be rickety, but support is getting done. Processes exist, even if only implicit, and your job is to sort through everything, figure out what’s working and what’s not, and formalize everything. So instead of jumping right in with the goal of taking over support from a non-support person, you should spend your first month or two observing instead. Figure out:
How is support being handled now? Similarly to starting as the first support hire, you need to figure out just how the existing support team is actually doing things, as opposed to anything they might have written down or aspire to.
Speaking of the existing support team, get to know everyone on the team you are now leading. Is there an existing structure to the team? What is everyone’s experience level and skillset? Do a lot of shadowing, and make sure you see how every individual on the team operates.
How is morale and general satisfaction? There are two specific questions to ask each individual: first, how are they personally feeling about the team and their role in it? Second, what do they like and dislike about existing support processes? Both pieces of information will be highly useful.
How does your team work, formally and informally, with other teams in the organization? Get to know those other leaders to have the same conversations about where existing processes are working well and where they should be improved or just rebuilt from the ground up.
Gathering all of this information will take some time, but at the end of it you should have a good understanding of how things work today, and some inkling of where you should start to build formal structures.
Still gotta learn to support the product too!
As if you didn’t already have enough on your plate, you still need to learn the nuts and bolts of supporting your company’s product or products too. Even if your team is fully staffed and you’re not needed to handle support issues with the rest of the team, there are several good reasons to learn how anyway. First, and most practically, backups are always needed. Team members will go on vacation or get sick, and in order to prevent overworking and burning out whoever is left, you’ll be able to step in to lighten the load. Second, knowing the joys and frustrations of working in this particular support team will leave you better positioned to understand what the team needs and where your efforts in systematization can be most effectively spent.
The third reason is a bit less objective than the first two, but no less real. Put simply, your team will respect you for it. What do I mean? Everyone has been in the position, at least once in their career, of reporting to a boss who doesn’t actually know what they do. It’s frustrating and demoralizing to realize this, and makes someone a lot less likely to respect and trust their leadership. By getting down into the trenches with your team, and demonstrating that you can do the work too, you’ll go a long way to building an early rapport with your team that will serve you well as you take the reins.
But what if you can’t actually do the work yourself? That’s a reasonable concern, and it’s bound to come up from time to time. I think this might be a good topic to dig into separately, and I’ve just added it to my ever-growing topics list, but for now I’ll confine myself to this observation: you were hired to lead the team, not to do the same job as them. Your technical skills may not be quite at the same level, and that’s okay. What matters is that you do your best to learn the technical work, and make an effort to understand where your team is coming from. Learn what you can, show an interest in the rest, and that will go a long way.
Professionalizing the team
Now that you’ve ramped yourself up and understand the nature of the team you’re leading and where things currently stand, we get to the reason you were actually hired: taking all of the chaos and molding it into a precise structure, or at least a sturdy edifice that can stand on its own. This process is a big enough topic that I’ll have to expand it into a separate post (some of you are likely seeing a pattern here) but in brief it looks something like this:
List all established processes, where ‘established’ means ‘there is a stable or mostly stable process for this activity’.
Looking at the list of processes, look for gaps. What new processes need to exist? Do any existing processes need to be expanded to fill those gaps? Are there redundancies where processes and procedures can be consolidated? Add new processes to the list.
For each of those processes, through direct experience (shadowing, doing the work) and discussions with the team and any other teams involved in the process, determine whether the process is good, needs some tweaks, or needs to be redesigned (or ‘designed’ in the case of new processes) from scratch.
You now have a work list. Each process on that list should be systematized through discussion with your team and other stakeholders, and formalized in writing to ensure everyone is working from the same playbook. Even the ‘good as-is’ processes most likely need written documentation.
This will keep you busy for a while. The most important thing here, as in so many of my posts, is communication. Listen to the folks who’ve been doing the job, and clearly communicate back to them the changes you’re proposing to surface any objections early. If you unilaterally build new processes, they will be doomed without broad buy-in, both within and without your team. On the other hand, if you take your time and ensure that everyone’s input and concerns are received, you are much more likely to end up with accepted processes that your team can rely on, both now and as the team grows into the future.
Thanks for reading Andy's Support Notes 💻💥📝!