Building a team

I’ve been at my current company for a year and a half, and my role is a mix of technical communications and customer support (which is really technical communication with a specific person instead of a group of current customers and prospective customers).

As my company is growing and taking on more customers, I need to build a team. I’m figuring out what that team will look like, and what sort of skills and personalities I need to fill those roles.

Identifying the skills

This seems easy, and…yeah, it usually is. Given projected trends in your business, what skills do team members need to have?

I’m watching support requests increase in number and complexity. Training and documentation should help solve some of these, but they often answer the obvious questions. We try to anticipate questions, but our customers are very clever and think of things that we haven’t. And since I’m working for a small company, I’m not hiring for a large tech support organization with defined roles. I’m not looking for someone who will only provide Tier 1 or Tier 2 support (and that’s probably not a good plan, anyway): I need someone who can answer any question that comes up, and knows when to escalate that when necessary.

That’s not too big a request. But as I’m putting together requirements, I realize that I also need someone who can help me work on the documentation. Starting with troubleshooting, but also working on installation and usage docs.

So another tech writer who can answer the phones, or a customer support rep who knows something about technical communications.

Moving into a unicorn hunt

We don’t have an public API yet, but we will soon. So I also want to look for someone with experience writing code or API documentation (or both). This moves the requirements into unicorn territory, and will narrow the candidate funnel pretty severely. And increase the price of candidates, so I might have to adjust the requirements a little.

I know I’ve said this before, but a willingness to learn counts for a heck of a lot, and will help make up for any missing skills. We have some time and opportunity to let a candidate learn on the job. We don’t have a place to accommodate candidates who refuse to learn any new skills.

Yes, that seems almost impossible, but I’ve interviewed candidates who flat out declared that they weren’t interested in learning HTML, or documenting APIs, or even working with engineers (!!!). Free advice: DO NOT do that.

Skills, skill gaps, and redundancy

Skill gaps are bad. Single points of failure are worse. Although “someone can do it” sounds better than “no one can do it”…actually, I guess it is. It’s not great, and you want redundancy for critical skills (you’re in a bad position if you have only one person who understands the support system, or one person who can create XML mappings, or understands how to publish your content). But if you’re working for a small company, you’ll be stuck with that for a while.

I’ve been training a couple of non-support people on the customer support tool and processes. Otherwise I’d never be able to take a vacation. Until I hire a proper customer support agent, I have someone who can provide backup.

The most difficult part when hiring to provide redundancy is avoiding insult. Everyone wants to be special, and removing that can cause some distress. Even if it’s for the best reasons, and even if everyone understands the logic of it, people are going to start worrying that they’ll be minimized or even replaced. This is when you’re going to have to build your own skills and learn how to reassure your existing employees that they’re still very much valued.

And that’s critical: learn how to identify these stress events and get ahead of them. Because if you don’t, you’ll see your team’s productivity fall through the floor and, worst case, start losing people as they look for more secure jobs.

Building a team leader

Equally important when building a team: Do you want to lead? I won’t get clever by picking apart “lead” versus “manage,” but it comes down to this: Are you ok with moving away from the day-to-day tasks (writing docs, answering support requests) and moving into the realm of plans and schedules? I do. I’ve been stuck head-down in my work for a long time, and I know that things are suffering because I haven’t had time to do the medium- and long-term planning that is required to go from “barely coping” to “successfully managing and generally kicking ass.” Without a plan, I’m just fighting fires as they pop up. With a plan, I can work on containing the fire and…er…doing something more useful. Cooking a meal over it? Sorry, I think I lost the analogy somewhere.

Do you want to work on mentoring and career development? To be honest, this is something I need to work on. But I want to do this, so I know I’ll put the effort into it.

Can you give your team room to explore their roles? In other words, can you trust them, keep yourself from micromanaging, and encourage them to take on new tasks? Heck, that sounds awesome!

Lots of work, though.

But that’s not all!

This is a short overview, and I know I’m missing a few things. I’m also certain that there are points that I haven’t thought of. Please add some comments to point me in the right direction.

2 thoughts on “Building a team

  1. Nice post. I agree with the “willingness to learn” and add genuine enthusiasm and interest. These are the baselines without which it is tough to build a team. I like the customer support and tech doc cross-over, although I haven’t come across many who blend this. I used to think API documentation folks were unicorns, however I have seen encouraging moves recently of people interested in coming out of Dev/Eng and moving into documentation – and seeing this as a positive growth move, even if the salaries don’t always reflect this. I wish you luck, and look forward to hearing more!

    1. Thanks, Diana. The customer support and doc crossover is working on a small scale (i.e., me), but I need to see how it works as the team grows. I have had success as a doc team working very closely with support, but the metrics for success are very different.

      It’s good to hear that some developers are transitioning to techcomm. Maybe not great news for tech writers, but it’s good news for people looking for detailed API docs. I think having writers with a programming background will also help us come up with new ways to present API docs, which haven’t been that great so far.

Comments are closed.