Take the 2-minute tour ×

I manage a tech support team at a mid-sized software company. We are the last line of support, so issues that we can't fix need to be escalated to the development team. When I joined the company, our team wasn't capable of much beyond using a specific set of troubleshooting steps to solve known issues and escalating anything else to the developers.

It's always been a goal of mine for our team to shoulder as much of the support burden as possible without ever bothering a developer. Over the past few years, I, along with several new hires I've made, have made pretty good progress in that direction. We've coded our own troubleshooting tools which now ship with several of our products. When users have never-before-seen issues, we analyze stack traces and troubleshoot down to the code level, and if we need to submit a bug, half the time we've already identified in the code where in the code the bug is and offered a patch to fix it.

Here's the problem I've always had: finding support people capable of the work I've described above is really difficult. I've hired 3 people in the past 3 years, and I've probably looked at several thousand resumes and conducted several hundred phone screens to do so. I know it's pretty well accepted that hiring good people is tough in the tech industry, but it seems that support is especially difficult -- there are clearly thousands of people walking around calling themselves support analysts, but 99%+ of them seemingly aren't capable of anything beyond reading a script.

I'm curious if anyone has experience recruiting the sort of folks I'm talking about, and if you have any suggestions to share. We've tried all sorts of things -- different job titles/descriptions, using headhunters, etc. And while we've managed to hire a few good folks, it's basically taken us a year to find an appropriate candidate for each opening we've had, and I can't help but wonder if there's something we could be doing differently.

share|improve this question

migrated from stackoverflow.com Feb 20 '11 at 15:04

This question came from our site for professional and enthusiast programmers.

Voting to migrate to programmers.stackexchange.com –  Pekka 웃 Feb 20 '11 at 15:02
The job responsibilities you described is already beyond tech support, since it requires developing software tools and analyzing the product code. An appropriate job title would be Escalation Engineer. The requirements would be the same skill set as software engineer, but maybe a slightly different mind set geared toward production issues. –  rwong Feb 20 '11 at 15:13
+PositiveInfinity For doing it right. I second rwong: Find a title that works better and let the candidate know what your model is. Look for the weird....they turn pro faster :) –  Rusty Feb 20 '11 at 19:38

3 Answers 3

First of all, congratulations for a very progressive outlook on the role of support. Your employer should highly value the efforts you're putting forth to protect the development staff from unnecessary interruption.

I think your number-one problem is one of qualification. You're looking for junior to mid-level development qualifications for your support staff. If your support people are writing their own support tools and reading stacktraces, they're really not "end-user" support, they're development support. This is not a problem as long as you're paying them like developers. If, however, you're paying median support salaries, why should they do all that work for 40%-50% of what they're worth?

This is an organizational problem. Either your developers should be taking on more support work, or your existing support people should have a path into the core development staff. One way to model your support is that junior-level developers start in support and work their way to the core development team.

share|improve this answer
+1 for the progressive outlook comment! –  Al Biglan Mar 3 '12 at 2:51

I think the difficulty in finding people is because the role is too big as currently defined. Most support organizations start "tier-ing" their support teams...

Tier-1 asks questions like "what version are you using? is your machine plugged in?" and are focused on resolving basic usage questions or customer misunderstandings. If they can't answer the question, they collect all the information needed to "escalate" the ticket. People in this role are great at pulling information from people, working firmly but nicely with people

Tier-2 deals with trickier problems that might require a lab setup to mimic the customers environment and understand what is happening. They stop looking at the product as a total black box, and are able to understand the different components/subsystems/interfaces and the interactions between them. They don't dive into the product code, but might be generating the debugging tools you described.

Tier-3 looks into the code and is capable of generating a "patch" release to resolve a critical customer issue. These are typically developers who are focused on resolving tricky problems as quickly as possible. Issues they find are brought to the development team for injection into the regular product release cycle.

You might consider starting to "specialize" your hiring. You might want to look for a "Tier-1/2" person or a "Tier-2/3" person. You (currently) seem to be looking for a Tier-3/Developer position which is rare to find a developer who wants to maintain someone else's code as their primary focus.

Editorial: Your approach is great. But it can't scale. If this isn't a problem, then accept that finding a person a year to join the team is "a-okay" and works for your situation. If it is a problem, consider dividing up responsibilities a bit more. Just be sure that you keep the inherent goodness in your model:

  • the more the support team knows about the product and the technology it depends on and lives in, the better the support organization
  • the more the support and dev teams can work together and share information, tools and lessons learned, the better
share|improve this answer

One possibility would be looking for developers that don't want to actually do hardcore coding any longer. Possibly even in house.

I have known people that left programming for various reasons. One couldn't type for hours on end because of a repetitive stress injury. Another didn't like being so isolated from the customer. Yet another didn't like having to put in the long hours before product release. Some didn't like the fact they had no influence on the applications they developed.

Key would be appealing to these coders. Put in the job description that they will be challenged because they will still be using some of the skills they have acquired yet will not be have all the "burdens" experienced by the typical coder. Push the fact that they will using the applications they develop and that they will actually influence what those applications will do.

And as Dave said, pay them adequately for what they are expected to do.

share|improve this answer

Your Answer


