Andrew Spittle

A couple weeks ago I was talking with other customer support folks about pain points in quickly growing a customer support team. Our team at Automattic has grown quickly since 2012, when we had around 16 Happiness Engineers. We hired close to 40 support people in 2013 and over 25 in 2014. Our job posting is always up and our only constraint on hiring is the pace at which we can find the best Happiness Engineers.

In talking through that experience with other customer support people I shared a few lessons from Automattic’s growth. These are just things I’ve found to be true about a high growth support team so your mileage may vary.

Maintain your hiring standards

As you grow you desperately need to maintain the hiring standards which formed your team. This is particularly the case if the impetus for growing your team is exploding support volume, management pressure, or a growing user base. With that pressure you become inclined to compromise on hiring standards in order to achieve faster growth. Those borderline candidates who you’d reject 6 months ago you’ll now think of as, “But we could train them…” While that may be the case every borderline candidate you hire ultimately slows down the team while they wait to catch up. Our hiring motto at Automattic is that a “Maybe” is a “No.”

The 6-month speed bump

When you hire a lot of people over a short span of time you also create a lurking iceberg of expectations. New jobs come with a honeymoon-like period. A new hire clearly wanted to join your company, else why would they have applied, and now that they’ve been hired everything smells like roses…for a while. If you hired 6 people in April that also means you’ll have 6 people coming out of that honeymoon period come the fall. Compound that by hiring 6 people a month for 6 months and, boy, is that iceberg massive! Be aware of this. It’s not to discount valid critiques from those team members, but it does need to be taken in to account. Sometimes this week’s fire is merely 6 people simultaneously hitting a given point in learning what works, over the long run, for their productivity.

Here’s one way that collective 6-month speed bump plays out. When people join their first distributed company they love the seemingly boundless freedom. They love their work, love working from home, love the schedule flexibility and dive in whole hog. Pretty soon, though, they realize that they’ve lost all discipline in setting work aside. They find they let pings interrupt them at all hours. They find themselves working 60-hour weeks. They find that they have no quiet time. When you have many people simultaneously hitting this inflection point it can be expressed as an issue with company expectations or with the team itself. You have to take a step back, though, and realize that this is a growth process everyone goes through. You have to help each person realize that, in part, the problem is one of individual expectations, workflows, and discipline. If instead you restructure the entire team in response to this pain point you ultimately withhold from people a learning experience that helps them build sustainable and healthy individual remote work habits.

Teach systems, not information

If your training focuses on simply teaching the information necessary to do the role then you’re creating a burden of technical support debt you’ll eventually need to repay. The most common way I’ve seen this come up in support teams is new hires consistently asking for a list of who owns what features across product teams. If you’re a small, agile, or continual deployment-driven company this type of list is a wild goose chase of sunk costs. The effort required in maintaining that list is crazy, particularly if your product is fairly involved. Instead, focus on teaching new hires the systems they need to learn in order to discover for themselves who owns what feature. How can they leverage the source code repository? How can they lean on the bug tracker? Do they simply need reassurance that it’s ok to ask? When that systemic knowledge becomes second nature then it frankly doesn’t matter how fast the development side of your company is moving. Your support team will be able to keep up and keep pace with where to report bugs, suggest improvements, and ask for help.

Be wary of past experience

This is similar to being mindful of the honeymoon period. Part of why you’ve hired this team is the strength of their past experiences. However, when people start out they see pain points at your company which were solved problems at their past job. While a fresh perspective is valuable, be wary of someone’s desire to solve an issue using the same process their past job did. Your company is your company. It’s not the same marketplace, culture, tools, people, systems, users, or challenges as any other company. Ultimately you want to be wary of new hire-driven solutions which seek to merely transpose past solutions on to new problems.

Thanks to Erica and Simon for helping me edit and compose these ideas.