If you’ve ever been involved in a startup before the startup had competitors or were part of a disruptive change in technology, you’ve needed this hiring strategy. In this case, technical skills are close to irrelevant.
What’s really important when you’re starting a disruptive change or you’re hiring a not-quite-known skill set is to specify the kind of adaptability, problem-solving, teamwork–all those technical context-free and oh so important personal and interpersonal skills–required. This is a case of defining the deliverables helps you tremendously when attempting to define the job. Even so, you and the eventual hire may have to work together for a while to really see what the new hire needs to accomplish.Here’s an example from my career. Back in the early 90’s the terms “release engineer” or “configuration manager” had not yet been coined. The only common version control system at that time was RCS. I was the program manager for a very large (100 people) software project. The previous release had spent the last six months in integration hell. I was determined that this release was not going to do that.
I was lucky. Sun had just released NFS, an early configuration management system. It allowed for branching and labeling, techniques I knew I was going to need, to keep all the sub-projects proceeding on their own, and to allow me to do something that was as close to continous integration as I could convince the developers to do. I needed someone to manage the sources, the branches, and labels, and to make sure the integration was working.
I knew “librarian” was too wimpy a term for what I needed. I needed someone I could call an engineer, since this person had to convince, help, persuade, influence the rest of the project teams to use the system in a way that made sense for the project. (I could see what I wanted–to end integration hell–but had no words for what I really wanted the person to do.) But since the software was new, I had no idea what kind of engineer to call this person. When I interviewed, I looked for someone who would be taken seriously by the other developers, who wasn’t intimidated by new software (that might not work all the time), and who could share my vision. I think we called the position “program engineer” to go along with my “program manager” title.
They guy I hired was smart, had been a developer, and wanted to take a slightly different slant on the next project. He was fearless in the face of the new system. He had great problem-solving skills and managed to handle most of the developers with relative tact. We worked very well together and avoided integration hell. We had a couple of weeks of discomfort–that’s all.We were using a cutting-edge technology. If I had not found someone who could make the system work (and if the software had been vaporware), I would have been tossed out (that’s the bleeding part). But because I got lucky with the software, and knew enough to hire someone with the necessary interpersonal skills who could become a part of all the teams, we were successful.
To be honest, this strategy by itself is rarely needed, but looking for people who are adaptable, who are great problem-solvers, and who can work well in new/existing teams is almost always a good strategy.