By Jon Mattingly
When it comes to building your team, there’s an old adage in the startup world — “Hire slow, and fire fast.” In my experience this has held true, but like every other aphorism, it’s a lot easier said than done. Letting a member of your team go sucks. Period. But there’s a way to handle it with grace, and unfortunately, it’s an essential skill to master if you intend to be an effective leader.
Second to building something that people want, hiring the right team is the most important thing you need to get right for the success of your business. The quality of your team is going to determine everything that you do — from how quickly you release features, to what kind of customer support experience your customers have, and even what it feels like to come in to the office every day.
What they don’t tell you is that even if you do your job perfectly, and even if you hire all the right people at the right time, you’re inevitably going to have to fire someone. In fact, when it comes to things like firing people, there are a lot of aspects of being a startup founder that you probably weren’t told. Below are the things I wish someone had told me.
Unfortunately, firing is an essential skill to master if you intend to be an effective leader.
When you need to fire someone, it usually isn’t because they stole the office’s deluxe double-platinum espresso maker. It’s usually because they just aren’t good enough. It is already so hard to succeed as a startup, and you simply must have the best team working for you at all times. You just can’t afford to employ anyone that isn’t delivering on their role. In my experience, there are two reasons why this happens: either they were not fit for the position in the first place (your fault), or you outgrew them (nobody’s fault).
The person you hire to bring you from two employees to 10 might not be the one to take you from 10 to 50. Startups grow really fast — sometimes a lot faster than people do. This inevitably leads to situations where your “star employee” is underachieving a year later. Bigger companies can often afford to put resources into employee development programs, and while that’s certainly desirable, the reality of a small startup is that those types of benefits just aren’t possible. Do everything that you can to help, but don’t feel bad about outgrowing someone.
Unless you’re an amazing actor, you’re never in the office, or you’re a psychopath, it’s usually impossible not to signal to someone that they’re on their way out. This is especially true with small teams, where you all interact and see each other all day, every day. In fact, if you’re doing your job right and communicating clearly, this should never happen.
Once you’ve made the decision that someone needs to go, act on it as quickly as possible. Waffling around and dragging your feet is only going to make things more painful and will ultimately breed well-deserved resentment.
I’ve fired quite a few people, and every single time, it has sucked. Really. Some founders say that it gets easier, but I don’t buy that. I don’t think it should. If you’ve done your job right and hired good people in the first place, it should never be easy to fire someone.
If you’ve done your job right and hired good people in the first place, it should never be easy to fire someone.
Early-stage teams aren’t just coworkers, they’re friends. These are people that have given their heart and soul to something you’ve built, who you’ve spent long hours working closely with. They’ve been your brothers and sisters in arms, so to speak, and now you’re kicking them out. And it usually isn’t even their fault. That sucks. Only once have I ever felt good about firing someone, and I never should have hired them in the first place. The onus was on me.
It’s OK to be bummed, it’s OK to cry or take the afternoon off. Don’t think you need to hide everything and be the stoic model of resilience. If anything, your employees want to see that this bothers you. But your success as a founder is going to be dictated by how well you respond to the moments when you get knocked down, so get back on the horse and keep riding.
Every company has a tendency to blame their problems on people who aren’t there to defend themselves. There may even be some validity in it. You let that programmer go because they weren’t writing good code, so it only makes sense that there would be problems with it later, right? Odds are, you didn’t do this when the employee was still there, so it shouldn’t be OK when they aren’t. If anything, you should take responsibility for not helping prevent the issue in the first place. It can be hard, but do everything you can to prevent this kind of dialogue. Nothing good comes of it, and it ultimately creates a negative, toxic culture that nobody wants to be a part of.
There’s a famous quote in Star Trek: “The needs of the many outweigh the needs of the few.” I think this is the quintessential “easier said than done” quote, so it fits the theme nicely!
When you hire your first employee, your responsibilities change. You’re no longer responsible for only yourself, you’re responsible for their livelihood as well. This isn’t even counting your responsibilities to your users, your investors, and so on. Even though it is hard, you need to remember that you are running a company, and your first responsibility is to make that company succeed. You are not a charity, and you are ultimately harming (many) more people than you are helping by keeping someone on staff when you know you need to let them go. It doesn’t have to be easy, but it needs to be done.
Jon Mattingly is the CEO and Co-Founder of Kodable, a scaffolded computer science curriculum used in over half of U.S. elementary schools.
Originally published on Unreasonable.