This is the second in an occasional series geared towards managers who are the first qa personnel in their engineering organization. I assume you are a qa manager at a small, fast moving company: you’re doing both management and individual contributor work, and there’s way more work to do than you have time or staff for.
If you’re in this situation, whom should you hire next? As with all things, the answers is it depends. Here are a few things to think about that will help guide your hiring strategy:
- How big will your team be eventually? Two or three? Ten or twelve? If you will be staffing a bigger team, you’ll have more latitude when selecting engineers with different skill sets and levels of experience. A smaller team means you must be much more selective in your hiring. With a smaller team you might have to forego some skills that you might otherwise want to have on your team.
- Domain knowledge: how much domain knowledge do you have? Are you already an expert in the field, or would you like one of your new hires to have a strong background in your company’s domain? I’ve worked at companies building software and services for use in business, personal finance, imaging and hardware, desktop publishing, advertising, music and internet search, and complex auction transactions. In most cases I did not have much experience in the domain before I joined that company, but learned it quickly while on the job. And I did make it a point to hire people who did have prior experience in those areas.
- Technical knowledge: as a successful generalist, I learn just enough technical material to do the job at hand. However, I make it a point to hire several real engineers with a solid cs/programming background. These days you must have a few people who are at a developer level with their programming skills. This is especially critical in the web world, where engineering vps often favor having developers or near developers do qa.
- Process knowledge: perhaps less a critical than some of the other considerations, but still worth thinking about. Headed towards the dreaded ISO 9000 or some sort of arcane SEI/CMM qualification? Does your organization strictly adhere to the dogmas of agile, scrum, or sigma six? If so, you might want to look for someone who has experience with these methods.
- Pick someone you have worked with before. If you’ve worked in the industry for a while and have a large pool of competent former co-workers to draw from, all the better.
- Pick someone who has the similar experience, style, values, and judgement. These criteria is predicated upon knowing someone pretty well, so you’ll have had to have worked with him before (see #1 immediately above).
So who have I made my first hires? I was the first qa guy at Claria, Playlist, and Auctionomics (I’m about to add a fourth company!). At Auctionomics we didn’t have the budget to hire additional staff, so I’ll skip that company. My first hires were guys I worked with before: Cliff I hired in to Claria, and Marc I hired at Playlist. Why these guys?
- Cliff worked for me at Visioneer and Marc worked for me at Playlist. I had worked with both for at least three years.
- Both were competent generalists: a solid understanding of the software development cycle, able to do not only qa, but their own IT, documentation, and even technical support.
- Both were strong on the technical side. Cliff does some programming as does Marc; Cliff built out some Visual Test suites at Claria and Marc built a great Selenium suite at Playlist.
- Both were and are excellent communicators, and got along well with all departments and personalities: dev, marketing, sales, legal, etc.
- Both came up to speed quickly on learning the new business domain – very important!
What about concerns from others in engineering that you are just hiring your friends? That’s a fair question; you must be able to prove that your candidate is a good fit.
What about concerns from others in engineering that there’s not enough variety within the qa department? That’s also a fair consideration, and I would address this by stating that for future hires your goal is to bring in a broader range of qa engineers (see the first list above). I like having department of diverse individuals: done properly it can bring perspective and prevent group-think.