Live data from Hacker News

It's Never Too Early to Fire

a16z.com

161–170 of 189 posts

Re: It's Never Too Early to Fire

#161
post #101
post #96

Earlier quoted context omitted.

> As a senior programmer with a bit more life experience, I quit somewhere after only 2 months. They valued me, the pay was great, the tech challenges were interesting, but their processes drove me potty. I've done something similar twice, except there were no interesting technical challenges. Both were government jobs where I was lured in to do all this cool work and then get told to sit there and do nothing. The pa…

I was hired into my current position (as a contractor at a government facility) to be a 'software architect and software engineering subject matter expert.' The way the position was sold to me, it sounded like a good step-up in responsibility and an opportunity to grow. What I'm actually doing could be considered a cross between 'IT guy' and 'generic office staff' (I go to tons of meetings, write lots of system-engin…

I never just quit the other jobs outright. I simply started looking once I figured out what was going to happen.

The rest of the time at work, I spend inventing projects to helped me learn some interesting technology. My bosses were happy because I stopped bugging them for work to do.

Re: It's Never Too Early to Fire

#162
post #101

Earlier quoted context omitted.

I was hired into my current position (as a contractor at a government facility) to be a 'software architect and software engineering subject matter expert.' The way the position was sold to me, it sounded like a good step-up in responsibility and an opportunity to grow. What I'm actually doing could be considered a cross between 'IT guy' and 'generic office staff' (I go to tons of meetings, write lots of system-engin…

Then take advantage of it! Pay off as many debts as you can and bank the rest. A few years ago, the single most powerful thing I did was knock out all our non-mortgage debt. It's freeing to know that if something happened, I could take a pay hit of $Xk/month and still have the same lifestyle. Being unemployed for several months is way less scary if your monthly expenses are lower and you have cash in the bank.

In a way I suppose I am. My side project is getting a lot more love than it used to, given that my day job is pretty much a straight 40-hour gig that just isn't all that mentally taxing. I'm also taking some MOOC courses, etc.

Re: It's Never Too Early to Fire

#163
post #86

Earlier quoted context omitted.

"No one should ever be surprised when fired." I have unfortunately fired several people and I have always asked if they were surprised. One time someone said "Yes, I am surprised you fired me." I can't even tell you how destructive that was to my team. To be honest that person should never had been surprised nor my leadership team, but it happened and it caused havoc. It took years to fully repair the damage. I think…

Same goes for the review process. Nobody should ever go into a review not knowing what the results will be. The reviewer should be telling you things they've already covered with you throughout the year on a consistent basis.

Your right. I could never tell someone in a quick way what a good review looked like and yes Reviews and Firing should never be a surprise. I feel like my wife was 100% surprised by her's and her immediate response is I am leaving.

Also for reviews: no subjective remarks without concrete examples in writing.

People leave managers and not companies.

Re: It's Never Too Early to Fire

#164
post #67
post #18

Earlier quoted context omitted.

To be completely honest, the legal and cultural landscape in Europe is nothing at all like the US when it comes to letting employees go. Being US based, I would be extremely hesitant taking your advice if you haven't spent time in the US.

Which is when US managers work for European based companies this causes issues if they don't adapt.(And I am sure is the case also in the other direction). I have come across American managers move straight from Silicon Valley to Europe and not understanding that firing people in Europe (well in the parts I know, UK & Scandinavia) is rare, and not expected. Not understanding that there is a limited pool of potential…

> Which is when US managers work for European based companies this causes issues if they don't adapt.

This is such an important idea that Ireland advertises it as a perk of doing business there. In addition to tax breaks and all their other incentives, the government works hard to promote Ireland as a "stepping stone" to European business. EU rules, Eurozone finances, with an intermediate, English-speaking culture to help get past the pain points of leaving the US.

It sounded a bit silly to me at first, but on reflection I'll bet it's a pretty good move. Picking up a bad reputation in a new market is hard to recover from, and I expect a successful move to Europe would require either careful planning or a totally autonomous branch.

Re: It's Never Too Early to Fire

#165
post #101

Earlier quoted context omitted.

I was hired into my current position (as a contractor at a government facility) to be a 'software architect and software engineering subject matter expert.' The way the position was sold to me, it sounded like a good step-up in responsibility and an opportunity to grow. What I'm actually doing could be considered a cross between 'IT guy' and 'generic office staff' (I go to tons of meetings, write lots of system-engin…

I see this happening alot. Basically government needs smart people like this to step in and rescue things when things go wrong, but they don't by any means want people like this changing the company culture or inconveniencing other people with doing more work or better work. You are there to be that smart computer guy who fixes things when things they don't understand go wrong. They pay you alot of money to be there…

> drain your brain more by asking to create documentation to make the integration of technology in the company appear more valid than it really is

Exactly this. This is my number one job here.

Re: It's Never Too Early to Fire

#166
post #74

Earlier quoted context omitted.

You're pointing out an important difference: firing because of experience/performance vs firing because of behavior. Being a bit naive, making mistakes, and needing ramp-up time is to be expected, especially from a junior hire. You absolutely need to give time to correct that sort of thing, and firing fast is not a good move. Some of the best devs I've worked with needed a few months to ramp upbefore they hit full st…

I just want you to know that I'm a beginner in management (having hired two juniors for my startup), and I'll use this advice (The junior is not productive, but him being reasonably motivated is the reason why I'll keep him).

I'm somewhat playing devil's advocate here, but how is your startup's documentation?

Sometimes juniors have a hell of a lot of trouble admitting that they don't understand something. Consequently, they won't be productive because they not only don't understand what they're doing, but they don't want to demonstrate their ignorance.

If I were in your shoes, I would do a couple of things:

1.) Make improving documentation a big part of their improvement plan.

2.) Make it very clear that you value clarity above all else and actively encourage them to tell you they don't understand something.

Re: It's Never Too Early to Fire

#167

This is probably the worst advice for a young founder. Had a client who was a 24-year-old startup founder, one of his investors got me involved to help him hire some folks and help define project process. We hired a great developer, who freaked when he saw how sloppy the code was. Rightfully said, "We can't maintain this..." Anyway, the founder had written a lot of it, so it wasn't a shock to him that the code was ba…

In fairness, the article is about executives, not employees, but everything you said is right.

One of the biggest and hardest jobs a startup exec/founder/whatever has is having a steady hand in the face of serious fucking freakouts.

It's a natural tendency to blame juniors for shit being all fucked up, even though a) shit being fucked up is your natural state of existence and b) shit being fucked up is all your fault. You fucked shit up.

My cofounder and I have talked each other down from the ledge many times. I'm maybe less patient with junior cats naturally than I should be, but I know my tendencies towards Jobsian ass-chewing and I am mostly successful in suppressing my bloodlust when things go wrong and I have to fix them.

Re: It's Never Too Early to Fire

#168

Why would anyone work in a person or company that is known to fire quickly?

Because I want to work in a place with fewer toxic employees. Also, since interviews are not that accurate at predicting future employee success, having a way to correct hiring mistakes means that a business doesn't have to be super-defensive about hiring folks who just don't work out.

Re: It's Never Too Early to Fire

#169
From the book 'Peak: Secrets of the new science of expertise', Anders Ericsson and Robert Pool state that to be an expert you must be successful at something more than once.

Which means that just because someone was successful doesn't mean they were directly responsible for it. Like being on a team where you may have even been the manager but the team players were what made it truly successful. If you were successful on two different teams then the odds of you being a key player in that success are much higher.

Re: It's Never Too Early to Fire

#170

Earlier quoted context omitted.

> If you are hiring and then firing junior people fast, you are the problem. I'm going to challenge this point of view. It is absolutely, and obviously, expected that junior people have a ton to learn, and they should be given leeway for that learning process. So yes, if you fire a junior person because you're not willing to put in the mentorship necessary, then I agree, you are the problem. However, junior people re…

>However, junior people really shouldn't have any problem with motivation and drive How are you going to determine if that really was the problem? Every time I've heard a colleague say something like this, (s)he is just utilizing a model in his/her mind to explain the behavior, and pretty much never attempts to validate/falsify. Pretty much always post hoc justifications.

It's really not that hard. When I have multiple peers of the person coming to me saying that someone is not putting in effort, and they aren't dependable, and they don't follow through, that's a pretty clear signal.
Post reply on HN