sqa | doc | management
100 hours series: Spock or Riker: selecting your first hire

100 hours series: Spock or Riker: selecting your first hire

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
All of the above are important considerations. However, I believe for hiring your right hand man (or woman), you should consider just two things:
  1. 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.
  2. 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).
Your first hire should be someone who is similar to you. Why? Your were hired into the company because of who you are: your experience, style, etc. Therefore, it makes sense that the second person into the qa team should be someone very much like you. In addition, because there is so much work to do in a start up, with a second in command that you know, you’ll be able to delegate easily and with more confidence.

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!
In short, Cliff, Marc, and I had similar backgrounds, experience, and style. It worked out very well in both cases. The developers who worked with Cliff and Marc found them to be excellent hires.

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.

So who was the better pair: Kirk – Spock or Picard-Riker? Clearly Spock, logical and unemotional, was cut from a very different bolt of cloth than Kirk, usually impetuous and running on instinct. Picard and Riker were clearly better suited to work together: look how much longer their series ran.
Good luck!

One Response to 100 hours series: Spock or Riker: selecting your first hire

  1. Spock, FTW.
    Did Riker ever cross-circuit to B? Did Riker ever think to jettison the shuttlecraft fuel to make a flare? Did Riker play an instrument? Did Riker ever create a mnemonic memory circuit in 1932 using only stone knives and bearskins? You know the answers.
    Spock saved the day many times, whereas Riker didn’t do much other than stand around the bridge and get fatter as the seasons went by. And who tolerates being called a bathroom-innuendo nickname like “number two”?
    Perhaps most importantly, Spock worked with Kirk. I’d expect that ANYONE could handle reporting to Picard, but can you imagine reporting to Kirk? So Spock gets bonus points for successfully navigating workplace politics under a peacock boss.
    Riker is a tool; Spock wins by a landslide.