While engineering departments are trained to understand why there was a mistake and how to prevent its repetition, many hiring teams lack a similar process and often make bad hires. Fortunately, there’s an easy fix.
Have you ever made a bad hire? If you’ve hired more than a handful of people you probably have. I can think back to some early hires of mine when I hired engineers who were smart and competent, but not a fit. One had spent his career doing modeling in software, rather than building the commercial enterprise systems we were creating. Another came from a big bank and wasn’t comfortable in a less structured startup environment. Neither lasted long, which meant that we needed to re-start the hiring process. Fortunately, I was able to learn from both to avoid repeating my mistakes. Many companies, however, don’t; but you should, and you can.
The should should be obvious. I tell my teams I’m ok if they make a reasonable mistake, no one is perfect, but they should never repeat a mistake. (Side note: we’re not running a nuclear reactor or doing surgery, where mistakes cannot occur; the nature of our business is to trade off some risk, including mistakes, for speed. If you’re in a business with a lower tolerance for mistakes, you may not want an “it’s ok if you make a reasonable mistake” attitude.) As I wrote in The Career Toolkit: Essential Skills for Success That No One Taught You, you need to create a learning organization.
Now for the can part. In engineering we have what’s known as a root cause analysis. Whenever there’s a problem, we drill into what was the underlying cause and why we did not detect and stop, or even prevent it, sooner. We then come up with concrete actions to prevent this from happening again.
When I realized my mistakes with the two hires I mentioned earlier, I asked myself how I could have spotted the disconnect during the interview process. I realized there were parts of their background I was not exploring and then came up with an approach (specific types of questions during the interview and reference check periods) to cover those blind spots.
When you or your teams realize something was missed during the process, review what was specifically missed and what steps to take to cover that aspect during the interview process. This should be a formal meeting, but it doesn’t have to be a long one (it’s usually pretty fast). In the case of the lack of cultural fit, it was recognizing that someone coming from a big, bureaucratic corporation may not fit into an unstructured culture. This was the acute example, but it was then expanded to recognize cultural fit needed to be addressed in general, regardless of prior roles. Shortly after we had a series of questions to explore someone's work culture preferences. That whole process can be done in thirty minutes at an SMB. At a larger company you may want to be more rigorous or get more input from a larger set of people so it may take more time. Even so, if you think about the cost of a bad hire—the wasted interview time, the onboarding and training cost, the emotional disappointment of a bad hire—this is a small price to pay to defend against it.
While such practices are common in software engineering, they are less so in other departments, including HR. If you’re not sure how to do this, reach out to someone in IT to get some input (assuming they have a root cause analysis process in place). Whether you call IT or not, what matters is that you set up some feedback loop. For bonus points, do the feedback for good hires as well as bad, to see what’s working, or what may be working, but can still be improved further.
It’s critical to learn about corporate culture before you accept a job offer but it can be awkward to raise such questions. Learn what to ask and how to ask it to avoid landing yourself in a bad situation.
Investing just a few hours per year will help you focus and advance in your career.
Groups with a high barrier to entry and high trust are often the most valuable groups to join.
