The sunny side of firing someone

On the one hand, I've previously suggested that managers should be quicker to fire underperforming workers, but on the other hand, it's absolutely true that some disappointments from workers are because of my own lapses in communication. When I wrote about one-on-one meetings, some people suggested to me that one-on-one meetings allow a manager to tell one worker one story but tell another worker a completely different set of facts, and the end result is that workers ended up feeling like they've been lied to. So when I recently wrote about this, I included this story, which I think shows both sides of the issue.

There are times when workers feel they’ve been lied to when they have simply misread or misheard some communication from their manager. This is an actual communication that I recently had with a freelancer I was working with, putting together some preliminary numbers for a marketing campaign:

Me: About Task 3, can you wrap this up by Thursday or Friday?

Them: I’m busy on Thursday, but I can get to Task 3 on Friday or Saturday.

Me: Are you sure you can’t get this done on Friday?

Them: I don’t know. I’ve got some things scheduled for the afternoon on Friday. I’m not sure how long that might go into the evening. But I can get it to you by Saturday afternoon, for sure.

Me: Look, this doesn’t have to be perfect. Don’t go overboard. Just put in what time you can on Thursday and Friday. In this case speed is more important than quality. Whatever you can do is fine.

Around 9 PM on Friday I had not heard from them, so I wrote to them again:

Me: Hey, can you please send me whatever you’ve got regarding Task 3?

Them: I told you, I can get it to you by Saturday afternoon.

Me: I told you the deadline was Friday.

Them: You never said the deadline was Friday.

Me: What I said was, whatever you have by this point, Friday night, is fine. I think I said that speed is more important than quality.

Them: Yeah, but you never said that Friday was the deadline.

Me: Okay, that’s fine, but please send me what you have.

They sent over what they’d done so far, and it was fine. In this case, we were both a little bit in the wrong, in that neither of us made explicit what the deadline was. I thought I’d been reasonably clear that by Friday night they should just send me whatever they had, but they felt that I’d authorized them to keep going until Saturday. It’s important to be very clear about expectations, otherwise workers hear what they want to hear and then they sometimes feel that you lied to them.

In this case, I simply failed to make 100% explicit that the deadline was Friday night. If I had invested a little more time into the communication, I probably would have made clear what my expectations were.

I've previously suggested that larger, stable firms should do more to offer some kind of apprenticeships to novice tech workers. But in small startups, when the whole team is just 4 of 5 people, often you need for everyone on that team to be perfect, so if someone on that team isn't perfect, you need to be fast to fire people. This was one of the main conclusions that I put in my book "How To Destroy A Tech Startup In Three Easy Steps."

I was referring to small companies and startups where there aren’t such things and founding engineers are like gods within the company and can have such ‘professional’ attitude.

I have seen it happening.

Comment on the code review but follow up privately and offer to pair.

It’s extra work but it shows the contributor that you’re not just out to poke holes and make extra work, it shows you actually care about their development and progression as an engineer

Companies rarely fire tenured staff except for layoffs. Often this is due to issues such as

- Tenured staff have a track record, if they are suddenly under-performing it seems more likely that their manager is to blame. Rather than a lack of ability.

- Tenured staff have institutional knowledge which can be hard to estimate and replace, the fact that a bad engineer still knows why something was done a certain way and can help others is sometimes sufficient.

- Tenured staff sometimes have implicit responsibilities that are unclear to new hires. An engineer with 10 years in the company might spend almost all of their time doing some form of product/tech leadership. The rare times they write code it may be deficient in some manner or another.

- Tenured staff know how to read the tea leaves. The fact that they are still with the company likely indicates that they know how to avoid situations where they will get let go. Sometimes this is as simple as hopping on maintenance work for profitable systems.

On the other hand, a new engineer doing their first project may actually not have the skills to get the project done. Or, more likely they were hired for new initiatives that leadership is fundamentally skeptical of.

The guys never reached out after the fact, so I haven't spoken to them, which is part of why it makes me sad to think about. I don't lack for friends and other positive things, it's just sad because I really liked these guys.