How to Fire Someone Humanely

I‚Äôm surprised by how often I encounter someone in a leadership role who has never had to fire anyone. I suspect it‚Äôs a combination of technology companies generally having pretty flat organizations and also the tendency to have dedicated HR functions in larger companies that insulate people from any ‚Äúunpleasant business‚ÄĚ.

Whenever I’ve had to fire someone, I’ve not slept well the night before. Regardless of the reason, you are changing someone’s life and everyone deserves to be treated humanely. It definitely gets easier after you’ve done it a few times but I hope that it never becomes routine.

Here are my 10 recommendations for how to fire someone humanely:

1.  Immediately set the tone of the conversation upfront.  
It gets super-weird if you have a friendly ‚Äúhow are you?‚ÄĚ conversation and then fire someone. ¬†I normally get straight down to business and open with ‚ÄúI’m sorry we have to have a difficult conversation today‚ÄĚ before the person¬†even sits down.

2. ¬†Do not use the word ‚Äúfire‚ÄĚ.
The word ‚Äúfire‚ÄĚ creates an emotional reaction – to‚Äúfire‚ÄĚ someone implies an active act of aggression. ¬†I generally say¬†‚Äúthis will be your last day‚ÄĚ. ¬†That way, it‚Äôs not a value judgment or a process – it‚Äôs just a fact.

3.  Keep it short.
There is no point in dragging it out. ¬†But, you should at least give the person a short and true reason as to why it’s happening, unless there is a good legal reason not to.

4. Do not get drawn into arguments.  
If someone wants to argue, be clear that this is the decision, it’s already made, that you understand they are angry but that it’s not beneficial for either side to drag it out.

5. Have your paperwork in order and be aware of the local employment law.
For example, here in CA, it’s the law that you have to give an employee their final pay in the form of a check when they leave.

6. Say you’re sorry it didn’t work out.
It helps humanize you in the process. It might seem trite or hollow to say¬†‚Äúsorry‚ÄĚ but, on balance, I believe it helps soften the blow.

7. Don’t fire someone on a Friday.
You’ll read¬†conflicting recommendations in this regard but I am strongly in the camp that says firing someone on a Friday is a Bad Idea(tm). ¬†It means they are likely to¬†just seethe about it all weekend. ¬†If you fire them during the week, they are more likely to focus on finding another job.

8. Have others ready to cut the cord.
You will need to confide in a small group of people ahead of time so they are cued up to terminate account access, etc as soon as the person leaves the room. Create a list of accounts ahead of time so it is not a rush and nothing gets missed.
You may be tempted to think something like “I’ll just leave Dave’s email on until the end of the day”. Resist this temptation at all costs. Although this may seem counter to the “being humane” approach, the potential benefits in terms of seeming more humane and feeling better are massively outweighed by the downside risk of the person doing something stupid.

9. Treat the person with respect and try to make it as comfortable as possible.
If possible, try to make sure that their team mates are not around to gawp as the person clears their desk, etc. This will again require the confidence of someone you trust.

10. It should not be a surprise.
Firing someone should be culmination of a process of clear and honest communication over weeks if not months.  If you are a good manager, the person on the receiving end should be clear on the gap between what is expected of them and their performance.
With the exception of gross misconduct,¬†if there hasn’t been such a dialogue,¬†you probably shouldn’t be firing the person.

Advertisements

How to Hire Software People

At the time of writing (Dec 2013), hiring software people in Silicon Valley is as hard as its been since the dotcom boom of the late 90s (remember getting a Porsche as a signing bonus?). While the rest of the US and the world is still staggering through an uneasy recovery, we live in this weird bubble of 100% employment and inflated salaries.

I could debate whether this situation is sustainable or healthy (hint: no and no), but it is the current reality and, if you’re trying to build a software company today, you have to deal with this reality.

Your ability to find and retain software talent is currently one of the biggest, if not the biggest, barrier to the success of your business.

Know Who You are Looking For

Write a Job Spec

This sounds obvious but this step is often skipped, especially within smaller companies. Perhaps its perceived as too “big company” for a startup but this is a classic false economy.

It’s one of those activities where the process is more important than the output: by forcing yourself to write a job description, you force yourself to think about who you are looking for: you’ll create a lens through which to view candidates and you’ll give yourself clarity on where you are willing and where you’re not willing to compromise. ¬†You’ll also have a very useful start for recruiters (more on them later).

Make sure your job spec not only covers the skills and experiences you’re looking for but also the attitude that you are looking for.

Cultural Fit

“…culture isn’t just one aspect of the game, it is the game…”Lou¬†Gerstner

Everyone says that “cultural fit is important”, but what does that really mean?

Firstly, let’s define what “company culture” really is. ¬†There are many definitions out there (Google it) but the two that I find most useful are:

a. company culture is “the way things get done around here”, and

b. company culture defines who gets respected and rewarded in your company.

Your first task is to take a long, hard look at your organization and ask yourself what your company culture truly is.  If you need help, there are various online tools and surveys to help you tease this apart.

Bottom-line: if you run a boiler-room full of fist-bumping, Izod-clad Brogrammers, own that reality.

If your company culture is not what you’d like, what do you want it to be? ¬†Armed with this insight, you can select people that fit that culture and have a chance of nudging it in the direction you want it to go.

But, don’t fool yourself that your company culture is what you wish it was, rather than what it is. Hire someone that is a misfit for your culture and they’ll pretty quickly suffer “organ rejection” and at best you’ll be back to where you started, having lost some credibility. ¬†It takes a very strong personality to come in from the outside and change the culture in a significant way so be realistic about the degree of change any individual hire can make.

3 Kinds of People

There are many tools and models to categorize people. One model I use to help understand the kinds of people you need in a startup is to divide people up into just 3 groups:

  • people who are good at designing the machine
  • people who are good at building the machine
  • people who are good at operating the machine

By “the machine”, I mean your business and your product, whatever that may be.

Very rarely you’ll find someone who is good at 2 out of 3. I have never met anyone that is truly good at all 3.

With a startup, you need a few designers and lots of builders. ¬†Only later, when you’ve probably pivoted multiple times and worked out the business you are actually in, do you need operators. ¬†At that point, you’re probably not a startup any more.

The Danger of Big Company People

The history of Silicon Valley is littered with smart and accomplished people with established careers in big companies who have tried and failed in the startup business.  The question of why this is true is probably a whole post in itself but here are my quick views:

  • specialists versus generalists – as organizations grow, people’s responsibility tends to become narrower and deeper; more specialized. In a startup, you need to wear many hats and will likely pivot multiple times. Therefore, generalists tend to fare much better.
  • discomfort with ambiguity – running a startup is all about making an endless series of low-data, high-risk decisions. Big companies have established markets and products, lots of data and a more predictable future.
  • inability to work with extremely limited resources – big company people are used to established infrastructure and an organization that has the scale to do multiple things in parallel. With a startup, attempting to do several things at once is often fatal and acute focus is required at all times.
  • managing not doing – in a larger company, people typically spend the majority of their time just managing the organization. In a startup, you need to be able to both do the work and hire and manage self-starter people who can help.
  • the romance versus the reality – last but not least, many big company people fall in love with the idea of a startup but have little understanding of the reality.

I advise extreme caution if considering hiring people who have no prior experience working at a startup, however accomplished they may be in their big company career.

Big company people are generally operators. ¬†You have to take into account the stage of your business – the “right kind of people” changes over time.

Finding Candidates

Find a Good Recruiter

In today’s hiring market in Silicon Valley, the hard reality is that the people you want to hire aren’t looking for jobs. ¬†This means that to hire the people you want you have to:

a. spend an inordinate amount of time networking, going to meetups, searching on LinkedIn, etc, or

b. get very lucky, or

c. hire a recruiter.

As I said in my post on Focus, I think that spending your time on the early stages of recruitment is not a good use of your time as a founder/exec of a company.  There are people that do that for a living and there are better things for you to be spending your time on in terms of building value in your business.

So, although they are much reviled, my strong advice is to find yourself a good recruiter.  For most non-executive level positions, you should only need a commission-only recruiter (you pay them a % of salary when they successfully hire a candidate, nothing upfront).

Whenever we’re in a boom/bubble, a huge crop of recruiters springs up and, like me, you are probably inundated with their unsolicited inbound messages. ¬†Here are a few things to watch out for in dealing with recruiters:

  • look for recruiters that have been through multiple boom/bust cycles. We’re in a boom/bubble now so it’s easy to be a recruiter. Only the good ones have the staying power through the tough times.
  • adding multiple recruiters (for a role) often doesn’t help much, due to the very limited supply of candidates. ¬†It actually makes more busy work for you since you’ll have to track which recruiter has introduced which candidate first; otherwise you’ll end up having to deal with an irate recruiter who wants his commission for introducing a candidate to you months ago who you just hired via another recruiter by accident.
  • beware of recruiters that try to hook you in with candidates that they don’t actually represent and have never actually spoken to. Some recruiters are not averse to copying resumes from LinkedIn and then presenting them to you as candidates they actually represent in order to get your business.
  • beware of recruiters who overly “coach” candidates ahead of interviews, based on feedback from prior candidates they’ve sent you. If a candidate’s answers to your questions sound too good to be true, they probably are.
  • fees are always negotiable, as are guarantee periods. ¬†The standard initial offer from a recruiter currently is usually 25% of first-year salary with a 3 month guarantee. ¬†Negotiating down to 20% and 6 months should be possible in most case, bubble or no bubble.

On your side, you should also make sure you have realistic expectations of any recruiter and understand what you will need to do to be successful:

  • provide the recruiter with a written job spec (see above)
  • recruiters are not software engineers. Although a good technical recruiter should be expected to have a basic understanding of different skill sets, they are not going to understand the nuances you do. ¬†They should be able to ask questions you provide them, though.
  • tell the recruiter which companies ¬†suitable candidates are likely to be currently working at or ¬†worked at recently.
  • be responsive and professional in the recruitment process.
  • a recruiter can bring a horse to water but it can’t make it drink – the onus is still on you to make joining your company the most attractive option of the many options that any good candidate will have.

Compromise

Given the ridiculously competitive hiring market and the level of entitlement (see below), you are highly unlikely to find the “perfect candidate” and will almost certainly have to compromise on at least one attribute.

The important thing is to be clear on what to compromise on and what not to.

Don’t compromise on cultural fit or talent – that’ll slowly erode the quality of your organization. ¬†Filling a position with someone who doesn’t cut the mustard or fit with your culture just to fill it is almost always a recipe for disaster – i.e. worse than hiring no one.

The first thing you might compromise on is specific experience. Unless you are hiring for a highly specialized skill-set or have a very time-critical need, I would always choose the more talented person over the person with the more specific skill-set or experience match. This is because the more talented person will almost always out-perform the less talented person in a matter of weeks.

To take a concrete and pertinent example for software engineering candidates, Ruby-on-Rails engineers are particularly hard to find and demand a premium in the current market. ¬†But, it’s not like a great (or “rockstar” as a recruiter would put it) engineer with no Ruby-on-Rails experience is suddenly going to become a terrible engineer just because they don’t know Rails. I will put money on the great engineer with web development experience but no Rails experience outperforming the less talented engineer with Rails experience within 4-6 weeks.

Another attribute you might compromise on is work location; whether its someone talented who lives a long way away or someone more local who just prefers to work from home. ¬†If you’re based in Silicon Valley, opening up your search to other locations massively increases the pool of available candidates.

Hiring someone who is not local and helping pay for their relocation is potentially a great deal versus having to pay a premium for someone already local.

Alternatively, while allowing remote working introduces its own challenges (such as instilling culture), it is a viable option, as long as you build your organization, culture and processes in a way that supports it.

Interviewing

Dealing with Entitlement

Don’t take it personally; the market has educated everyone to think that they’re great, even when they’re not.

I recently spoke to a candidate who received over 20 inbound calls from recruiters the day he quit his previous job. He wasn’t that great. In this kind of market, evenly distinctly mediocre people only see signs that they’re superstars.

Software people in the Valley are also currently ridiculously pampered as employers go to greater and greater lengths to attract people.

Bear in mind that, in the software business, the workforce leans young. ¬†If you’re 25, you haven’t even seen one economic cycle in your adult, working lifetime – as far as you’re concerned, it’s always been like this, and always will be.

Combine this with the Millenial generation’s trademark attitude (is that really true, or were we all just dicks when we were young?) and you have a heady mix of entitlement.

So, get used to candidates asking all the questions. Get used to entitlement. Accept that, currently at least, its an employees market and you are selling to every candidate.  Take a deep breath.

One and Done

You are going to lose candidates if you don’t move quickly. ¬†The best candidates will be gone in less than a week. Promise.

With this in mind, I highly recommend a “one and done” approach to recruitment. ¬†Schedule candidates to come in for a block of 2 to 3 hours max, have everyone you want to interview scheduled back-to-back and be prepared to make an offer that same day.

Standardized Assessments

People are not easily categorized but, in order to make your interviewing process and more scientific, agree a standardized way for each interviewer to write up their responses.

Here is the format I have used for some time:

  • Score out of 5 in terms of suitability for the role (4.5s are extremely rare, I’ve never seen a 5)
  • HIRE / NO HIRE – force people off the fence by making each interviewer decide whether the candidate is a hire or not
  • Pros – max 5 bullet points
  • Cons – max 5 bullet points

To keep it truly objective, these assessments should be sent only to the person doing the hiring so that different interviewers do not influence each other.

What to Ask

Let’s be honest; an interview is a highly artificial situation. Working with someone day-to-day is nothing like an interview. ¬†What you’re trying to do is make an assessment in 30-60 minutes of whether someone is likely to perform well and integrate with the team.

That’s hard. It’s particularly hard because software people generally are highly introverted – hell, they got into this career to start with to avoid having to talk to people.

Personally, I rarely ask any specific “technical” questions. ¬†Partly, I have the luxury of a team of people who can do that better than I can but, more importantly, I believe that you can teach skills but you can’t teach attitude.

My experience is that hiring people who you can work with, trust, rely on and communicate ‚Äúat the speed of thought‚ÄĚ is more important than someone’s specific background and skills.

I also find resumes to be nearly useless since they tell me nothing about the person’s attitude and are generally so carefully word-smithed and full of generalities that they don’t really tell me much at all.

What I want to know most of all is:

  • is this person a relatively normal human being* who I can effectively communicate with?
  • is this person accountable? Will they do what they say? Can they be relied upon and trusted?
  • is this person likely to deliver results?
  • does this person learn from their mistakes?

(* this is the software industry – “normal” is a relative term.)

My main way of answering these questions is to ask people for their stories. I want to hear about projects they’ve worked on where they were pleased with the results and I want to understand why they think the project was successful and what their role was in the success.

More importantly, I want to hear about projects where they look back and kick themselves and wish it had turned out differently. I want to hear why they think it turned out badly and what the lesson is they distilled from that experience. I strongly believe that you learn a lot more from failure than from success.

All of these stories also present many opportunities to dig into the specifics to test the candidate on what they really know and what they really learned.

What Not to Ask

Firstly, familiarize yourself with what you are not legally allowed to ask candidates – you might be surprised.

Next, remember that an interview is already an artificial scenario bearing little resemblance to actually working with someone. So, avoid making it even more artificial with ridiculous riddles and brain-teasers. ¬†I think these kinds of questions are really about making the interviewer feel smart and smug than about eliciting any useful responses from the candidate. ¬†People claim that they are good at making people think “out of the box” and testing reasoning skills but how about asking them some questions that are relevant to your business that achieve the same thing?

Remember that an interview is not your opportunity to show off how smart you are (seriously, this is a widespread problem in the Valley). ¬†So, don’t ask highly specific questions about a particular subject unless it’s absolutely critical the person you hire knows about that on their first day at work. ¬†Those questions just tell you whether the candidate happens to have dealt with that particular subject, not how talented they are.

Lastly, avoid asking obvious questions that you’ll only ever get one answer to. ¬†“Are you trustworthy?” ¬†“Are you a hardworker?” “Are you a team player?” Would anyone ever say “no”?

People to Avoid

Lastly, here is my short list of People to Avoid ™:

Talented Assholes

People who rub other people the wrong way should be avoided, even if they are incredibly talented.  The damage caused is not worth it and the aggregate results of the team will suffer as a result more than any individual talent will compromise.

Heroes Need Not Apply

A close cousin of the Talented Asshole is the Hero. The Hero will discover a big problem 2 weeks before a product is due to ship and work 18 hour days to save the day, fully confident of success and the imminent adulation of the team. The problem is that the hero will fail 90+% of the time.  The Hero should have told everyone else and asked for help. The team beats any individual 99.9% of the time.

“I’m not technical”

Even if you’re hiring for a non-technical role, this is Silicon Valley and you need to have some base level of interest in technology and in the industry. There are people who seem to wear ¬†“I’m not technical” as a badge of honor. ¬†Particularly in a startup, you need people who are generalists and adaptable. ¬†I have little time for “I’m not technical”, just like I have little time for engineers who have no sense that we’re writing software to satisfy a customer need, not for the sake of it.

That’s it. Have fun out there. ¬†Oh, any one last thing; if a penguin walked through the door right now wearing a sombrero, what would he say and why is he here?