One of the most confusing and confounding bad hires I ever made taught me my most important hiring AND leadership lesson.

I was a few months into my first executive role at a Startup here in Austin, and ensuring that we hired quality, talented Software Engineers was ultimately my responsibility. 

We’d just hired a mid-level software engineer who’d come over from a much larger tech company, and while they were clearly bright and technically capable, after a few weeks it seemed like this hire might not have been a good decision. 

This person was rushing through their work, sacrificing quality in their code, not testing it, not having anyone else review it … all red flags in our organization and the standards by which we did things.

I talked with the Engineer’s manager, who met with her to discuss our concerns, and he came back to me pretty perplexed. He had the conversation, and this Engineer of his was insistent they were doing really well because they’d “done a lot of tickets”, and they were actually offended we’d claim otherwise. I chatted with the Manager, and we came up with a plan to try and better communicate that we weren’t all about silo-ing yourself off, putting your head down and cranking out a ton of tasks with no concern for quality and no collaboration with or input from teammates.

Despite our best efforts, we couldn’t get on the same page, they continued to protest our performance concerns and maintained they were doing great work because of the number of tickets they had gone through. Eventually we decided to part ways with this Engineer, and it really left me scratching my head.

To this day, any firing decision takes a lot out of me, even when I know it’s the right call and it pretty much always ends up being the best decision for both the company and the employee. 

And, in the case of a bad hire, we had developed the really useful habit of doing a “post-mortem” or retrospective on where we went wrong, and could this bad hire have been avoided? Most of the time, we learned at least one or two good lessons which allowed us to avoid making the same mistake twice.

With this one, though, I was really confused. I kept trying to figure out what went wrong? 

We’d gone through our normal screening & interview process, which was rigorous but pretty reliable AND fair to candidates. This person had even attended a department happy hour event and met a number of people on our teams, all of whom agreed they were smart, humble, eager to learn and grow, and basically every other trait we valued in team members.

So how were we so misaligned with this person on expectations? In a lot of ways, I felt like I’d failed them. Were we not clear about our style of working, collaboratively, with a commitment to quality over raw, breakneck speed? Why were they so insistent they were performing really well, even as we repeatedly explained that cranking out a bunch of tickets wasn’t our definition of success?

Then a thought struck me. We always talk about what people do on a day-to-day basis. The knowledge & expertise we need, the programming languages they needed to know, the tools we use. 

And we talk about that stuff all over the place. Job Ads, Internal Job Descriptions, Social Media posts, in conversations during Screens & Interviews. We talk until we’re blue in the face about what they would be doing, but we never talk about what would make them successful.

I thought maybe I was onto something, but I wanted to be sure. So I started casually asking around, in conversation with the other people in my department. And the more people I asked, the more I started to realize that it was hard-to-impossible for a LOT of people in my department team to clearly articulate what success looked like in their given position. 

I suddenly realized that, even as an Executive, as Director, I couldn’t really describe let alone define success for my position, either. 

So, out of curiosity, I asked my boss (our CTO), and here to find out he couldn’t really do it for his position either.

Mind you, I’m not talking about precise metrics or quantifiable goals here, just the basic parameters for success.

And that’s when I realized it doesn’t matter whether somebody has all of the qualifications, years of experience, and skills you’re looking for. It doesn’t matter if they’re a “technical” fit AND a “culture” fit. As an executive, as a hiring manager, as a company leader, it’s up to me to get as clear as I can about how someone will be successful in a given role, and to be able to communicate that clearly and concisely in all my recruiting efforts as well as with current employees.

Without clearly understanding and communicating how someone can be successful, I am setting us all up for failure.

Unfortunately this realization came all too late for that particular Engineer and for that organization, and yet it now serves as the starting point for how I build & grow teams, and in what I teach to other decision-makers tasked with hiring responsibilities: How someone is successful in a given position is all in how they deliver value to customers, the company, their colleagues, and themselves.

When you think about any position starting from the place of how they add value, everything else becomes easier.

So maybe set aside some time — even as little as just 5 minutes — grab a sheet of paper, and ask yourself “How would I know if I’m successful in my current position?” If you’re a Hiring Manager, see if you can clearly articulate success for the positions you manage as well as the positions you’re trying to fill, now and in the future.

Learn from my mistake and you’ll save everyone a ton of time, money, and frustration.