Learn once, run anywhere

I went to visit a new outsourcing partner overseas a few years ago. We were in a ramp-up situation where literally dozens of jobs needed to be filled. I had recruited in Europe, the US and Australia by then so I was curious about how my skills would translate in the outsourcing climate.

Before I get a lot further with this piece, we need to be clear about something: Companies exist to make money. Not to help you fulfill you dreams of creating order in the software universe or to sponsor you through all of the MCSE steps. Granted, those things are ancillary benefits that can come along for the ride, as long as they don’t get in the way of the business.

That’s how I looked at it when my company wanted to consider outsourcing. I saw it as a natural avenue to explore; a way of reducing costs. I certainly would have wanted the company to reduce costs in other areas so it would have been lop-sided to ask that they spare software development from consideration for saving some green. There are really smart (I mean scary smart) people all over the world so there’s no reason to expect outsourcing to fail categorically. So I figured that either I could make it work, or my competitors would do it, then take over my market by offering products at a lower cost.

So I’m back to my story. I had interviews lined up from morning to evening in 30 minute intervals. I don’t normally take notes during an interview (that’s for immediately afterward) but I made an exception because the names were so unfamiliar and there were so many people. Just as I had hoped, once the interviews started, I was in familiar territory. I won’t write about all of the interviews but a few of them stand out, and with the power of hindsight we can trace the outcome of each decision.

Candidate number one opened the conversation with “I am an expert on …” and he named a few technologies. I don’t have an issue with arrogance but this guy could not back it up with examples or facts. I voted thumbs down but let myself be overruled in a recap "round table" discussion afterward; he was no expert but he could be a decent coder since he had passed a written test up-front.

Candidate two was a rock star. Short on experience but spot-on with every behavioral question – like how to give constructive feedback to a peer, how to change your approach after a failure and even how to re-organize a project plan that’s in trouble. I said YES and stuck to my guns when other interviewers wanted to bounce him because he wanted too much money.

Candidate three was a tester, not a developer. I have a few case scenarios that I use in QA interviews – questions like “How would you like for the CEO to think of the QA function?” or “Would you ride in a plane that’s never been flown?” I use those mostly to establish whether the candidate understands that QA adds value (vs. just being a process stage or a cost center). This guy did not get it. He could not see the big picture – I knew he would never be accountable for the quality of software. But he had tons of experience, including previous projects that the other interviewers knew in detail, so I let him on the team.

Candidate four was an understated quiet kid. It was hard to get him to talk about himself or his projects. His resume was not even clear so I took out his written test. Unbelievable… I had only seen it done better once before. I loved the way he defined words like “semaphore” because it showed how deep of an understanding he had. I also liked his ER diagram – simple but he even used some standardization in the field names for the simple test example. Once I got him talking, I was sorry I only had 20 minutes. Of course I wanted to hire him but the other interviewers tried to tell me he would not work well on a team. When there was one opening left, I got him in.

Fast forward through projects and deadlines… Candidate One (Mr. “I am an expert…”) was the first to go. He was a charlatan from the start; one of those people who takes away from the productivity of everyone else by negativity. I wasted my time and the company’s money when I let him be hired. Candidate two proved his rock star qualities over and over again, eventually moving to the States to work at our headquarters. He was worth every penny of his higher-than-usual pay level, and he was easy to manage as well.

Candidate three, the QA analyst, mostly just took up space on the payroll until I could put the microscope on him during a third-party certification of the software. He was classic in his ISO-certified diligence preparing documentation and paperwork but useless in the lab actually doing testing. I knew there was a problem because we never saw the defect levels rise and then fall as we went through the transition from code freeze to release. I leveraged the crisis to move him out of the team. Candidate four, the quiet kid, never ceased amazing me. My favorite thing about him was how he learned a ton about the product – not just enough to write his piece of the code according to the functional spec… this guy had ownership!

I’d love to say I had a 100% record for that hiring trip to the out-sourcer but the truth is that we could have flipped a coin and gotten the same result – about half the decisions were good, half were poor. If I had stuck to my guns instead of doubting myself, I would have had that 100% kick off that I was after. I was right about the fact that great people are everywhere, and I would also have been right to assume that my instincts applied just the same to people everywhere, too.

Thanks for reading this Management Use Case. I'm the co-author of a new book on software development leadership entitled You.next() that features dozens of other use cases for leadership. Please see more at www.youdotnext.com.