This actually makes me want to work there. At past jobs I've often been frustrated by management's inability to let go of problem employees. If the team isn't gelling or someone just isn't contributing, changes need to happen.
Note: someone might say that I was the problem, which may be true, but I wasn't let go either, so my point still stands ;)
This works incredibly well. At my last company I fired about a third of the engineers I hired after 3 to 6 months and ended up with a great technical team. I never know how good an engineer is going to be during the interview process but after 6 months it is blindingly clear.
I am upfront about the winnowing process during the interview, it scares some candidates away but I often get a very positive reaction to this "meritocracy by proof" approach. Another advantage is you can take some flyers on people with nontraditional backgrounds and find the occasionally diamond in the rough.
> This works incredibly well. At my last company I fired about a third of the engineers I hired after 3 to 6 months
Wow. I wonder, have you and this smug author ever considered that you are the problem?
Interviewing is a two-way process, it's the candidate's job to back up everything that's on their resume and make sure they present an honest view of their ability but it's also your job to decide if someone is a good fit for your team before making them quit their comfortable job and move to your start-up. By firing a THIRD of all people you convince to join your company, you are both incompetent and irresponsible. Precisely the kind of harmful deadwood people enjoy see getting fired.
If you are convinced that someone is the perfect fit for you based on a few interviews, then you've either discovered a bullshit artist or haven't dug deep enough. Interviewing is a terrible way to make a hiring decision. We just haven't discovered a better way to do it.
Interviewing can definitely give you an idea about a person, bull shit artists exist (in vast numbers), but they're not that hard to ferret out at the interview stage, presuming the interviewer knows his stuff and is not some HR flunky.
The trick is that during an interview you can choose to concentrate on the person or you can concentrate on their technical skills. If you manage to concentrate on the person instead then you'll find out soon enough whether they'll be 'good' for your company. The technical stuff is the easy part.
I've never had to resort to 'trick questions' or 'test assignemnts' to find out whether or not someone is capable.
Discussing their past has been much more fruitful in spotting trouble early on.
Interviewing is an art, not a science. There has been a whole lot of fuss about google and other companies getting on the 'metrics' bandwagon. I think that only works because they can datamine tens of thousands of applications and spot interesting trends.
If you're in charge of a start-up or a mid-sized company with maybe 10 to 50 employees the number of people you will be hiring will be much lower and the hiring process itself will consume a disproportionate amount of time.
Keeping your turnover low (as in: hire the right people right away) has an immediate pay-off both in time spent as well as in keeping the peace within your organization, and not investing months of time in to the wrong people only to fire them.
You hit the nail in the head, in my career I have fired 3 people (managed thousands). In the interview game to many people focus on the how long have you used X technology instead of the person themselves.
It is real easy people, interview the person and look for passion, seriously it overcomes all else. As long as the person has no obvious glaring personality flaws and passion, the rest will fall into place.
People in tech careers are for the most part self driven and want to do what they do.
If you (anyone in general) have had a problem with more than 5% of the people who have worked for you, then you may be the problem. Trust me I have meet far more incompetent tech managers than I ever have tech employees.
Who by the way are generally skeptical people who don't follow leaders that they do not respect. Given the grandparents cavalier attitude about firing tech people and the authors I would suspect that they are failing to position themselves as a leader in their technical talents eyes, and loosing their trust with every termination.
Seriously firing people does psychological damage to those that remain, it shows a lack of investment in people that resounds in their mind, it should be reserved for those that refuse to work for whatever reason.
My way of addressing that part was to simply ask what the most complicated thing was they ever programmed, and then to ask one or two follow up questions about that. I've got enough field experience that just by asking that one question I'd be able to come up with a follow up question that would nail a 'poser' in one go, if the answer was satisfactory I'd let it go at that and assume they're telling the truth, if not then I would ask one or two more follow up questions and by then I'd usually know for sure if someone is fibbing or just nervous (people can be very nervous during interviews, the bigger problem to me always was to not discard 'good' people that are simply nervous and botch answers to questions rather than the fear of hiring the wrong person because they manage to bamboozle me).
Another thing I did was to take as much time as I wanted during an interview, I would schedule at most one interview per half day just to make sure that I didn't have to cut an interview short. This made the interview process more relaxed and on the whole gave me enough time to figure out what made someone tick. Most interviews were over very quickly anyway, but every now and then it took a long time to get a feeling for whether or not someone would fit.
One of my biggest discoveries was that when hiring someone good that they would refer their friends, and they would be pretty critical about who they'd refer, screening out a lot of potential duds for me without any effort on my part.
In the Toronto office we ended up hiring four guys that already knew each other previous to joining the company.
This can also work against you, another 'group of friends' applied and I would have been happy to hire just one of them, he stuck with his friends instead.
I once hired a guy that just wanted to learn how to program but did not yet have the ability. This was a risky move, because as a startup you don't really have the time to invest a lot of it in to a person that is not yet proven. But it worked out very well, and Jeffrey actually was one of our most reliably productive people, in part because we gave him a chance that probably nobody else would have.
Sometimes having a will and a drive trumps technical ability.
I've never had the luxury of hiring a non-programmer to learn on the job, but I can see how it could work out. But perhaps you mean "technical ability when hired". I certainly am willing to let someone learn a lot of stuff on the job, including a new language.
However I quibble with your last point, or at least say that some jobs require an ability to grok abstraction, recursion and/or pointers and that no amount of will can overcome an inability to do that.
I'll also note that some paradigms cannot be quickly learned by most. I observed that in general for OO when it became "the thing" in the '90s and I suspect functional programming also takes "more than a month". E.g. one thing I'm saying here is that you couldn't necessarily expect a procedural programmer who already knew C to be able to really learn C++ or Java in a month. Yeah, they could learn how to write C in those languages, but learning the OO paradigm took longer.
Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong. Learning functional programming might be much easier for those with flexible minds.
Hence the 'sometimes', that one person was an exception both in that I hired him without the ability to program yet and in the fact that he actually came through in the end, I doubt that that is something you should try to repeat. I just got lucky.
The way I found him was that his father was the cleaner at our offices and if I would please give his son one chance. I did and I never regretted it for one second.
Then again, the OO paradigms I learned (which did not include any Smalltalk ones) were both very hard (to get right) and I now think they are also very wrong.
Based on this and your other comments, I'd like to hear more about how you came to this conclusion. This isn't the right thread for it, though... perhaps, if you're interested in writing about it, you could make a new post?
I can put it simply: the only thing worse than an imperative style with side effects is one where the side effects are chained, in this case through a set of interacting objects. I came to it from the hard experience of doing it, e.g. think sequence diagrams; the methodology was OOSE.
However lately I have been wondering about the utility of this approach for GUIs.
That's been my experience too. "Object model" almost always translates to "spaghetti". The promise of OO -- that objects would provide a flexible abstraction mechanism for writing software at the level of the domain while encapsulating low-level details -- has not been realized in practice.
I think the promise can be realized in pure UI and AI other than that it is much a-due about nothing. COCOA is a good example of pure UI, as well as some of the JavaScript UI kits. I.E Dojo or YUI. Given that UI objects are well encapsulated via OO is is a natural fit. When you get back to the service layer, you end up either writing overly complex OO stuff or butchering the language to make it functional.
Thankfully Rich Internet Applications are cleanly separating these concerns and you can use an OO toolkit for pure UI and a functional language the stand up RESTful services.
The days of bastardized JSP/HTML/TILES/STRUTS/Kitchen sink are numbered, for just that reason. Trying to shoehorn all of these technologies into a server side OO framework was becoming way to cumbersome.
You left out that the promise of reuse doesn't seem to be borne out and is perhaps harder when doing OO than in other domains. Probably because side effects are more pervasive and it's damned hard to design good object hierarchies (and heaven help those who don't have the discipline to keep their class relationships in a directed acyclic graph).
Modularity is a win and OO only superficially encourages it.
I haven't interviewed as a programmer in a long time, so I'm curious, what defines "the most complicated thing was they ever programmed?"
Algorithmic complexity, like a graph database or a computer vision system or an AI? Does it matter if they just read a bunch of papers and implemented the formulas? Does it matter if they used libraries like OpenCV? Does it matter if they decided the best implementation path was to outsource it and use a SaaS like DirectedEdge?
Social complexity, like a Facebook or Meetup or Digg? Does it matter as to whether they came up with the technical architecture or social architecture to actually process all those votes and friend requests and event managements, versus just doing what the tech arch or design lead told them to do?
I've implemented device drivers in x86 assembly (a well-trod path and it wasn't very original work) and AI (for a video game, original work but with lots of abstractions provided) and an embedded systems JPEG block rewriter in C (abused the spec to create something very original, but was ultimately only a few dozen lines of code when all was said and done). Which of these is "most complicated" and why?
Sorry for the sluggish response, I completely missed your comment.
Any one of the answers you gave there would have sufficed to be used as the 'platform' for further discussion, if you had named those three with the 'Which of these is the most complicated and why?' I think if would have led to a very interesting discussion about your past work for a bit.
Let's take the video game AI as an example. My follow up question would have been something along the lines of 'That's an interesting one, what kind of behavior did your AI govern, and how did you go about implementing that?' or 'How did you protect your AI from getting stuck in a loop or becoming too predictable?', or any one of a bunch of questions about the sort of thing you run in to when you build a video game AI. I'd know pretty quickly if you actually did write a video game AI (I wrote a bunch of video games, and even though I wouldn't class the routines governing the bots as 'AI' I think I can relate enough to the problem domain to come up with some questions) or if you're making it up.
For myself, if someone would ask me that question I'd answer a fully integrated cad-cam system for lathes and mills. That one kept me busy for two years, ended up as about 50K lines of high level code and another 20K of assembler to make it fast. The hardest part there for me was the equidistant operation, it took me quite a while to get it right because I'm weak in the mathematical department, it's actually one of the few times in my programming career that I got so stuck on a problem that I hired a tutor to brush up on the required math.
In my opinion that is the easy part, It is a testable skill (not trick questions). I always have a dummy environment set up with a skeleton app set up and once I am down to the last few quys I ask them to write something from scratch. Generally something simple like a CRUD screen that takes no more than an hour. I generally pair with them and work as a sound board to work out the problem with them. It is very natural and puts a real developer in an environment they are comfortable with. As soon as they see an IDE and no trick questions, the good ones tend to fall into a groove. The cool part is that I have learned so many tricks from many of these sessions.
>Wow. I wonder, have you and this smug author ever considered that you are the problem?
I'm positive I am part of the problem but I haven't found a better way for me to build a top notch team given my skill set and inclinations. As we grew I hired a good engineering manager who was able to reduce that ratio significantly.
To reiterate, in the interview process I explicitly lay out the methodology and all the risks involved as I understand the pain, stress and cost that a failed hiring causes. The end result of all of this was a very talented and efficient team that produced a great product which dominates it's vertical.
I'm not sure it's possible to make the right choice every time when hiring - and even if he's firing a third of his hires it means that he's getting it right two thirds of the time.
Given how lousy interviewing is as a method for discerning quality employees, I'm not sure that's a bad result.
This ain't Baseball, it's a horrible result. I would NEVER hire a manager or leader that fired a full 1/3 of his hire. It just shows a lack of any kind of management skill and behavior like this will quickly tell your remaining 2/3rds that you are not very good at management. They will leave soon thereafter. Now, I realize that a lot of the folks on YN are young and probably thrust into their first management role without any training or mentorship. Best advice I can give is to NOT discount the generations of study on this topic and try to make shit up on your own. Read a few books on how to motivate and make employees more productive and you'll be a lot more successful than the idiot blog author
While I agree with the essay (will write on that next), firing a full 1/3 of those you've hired is going to be very debilitating for the organization. And not something I think most startups will be able to afford.
And if you report or have to answer to anyone, they're not likely to be impressed that you hired that many duds/people who just didn't work out.
> firing a fill 1/3 of those you've hired is going to be very debilitating for the organization.
Exactly, hiring the right people is good for the employees (they have steady jobs in an environment where not all the faces are new all the time) and for the company because of the high cost associated with new hires.
The cost of bringing a new employee up to speed is usually taken as anwywhere from 6 to 12 months of their gross pay, assuming they're engineering positions (and that's what we're talking about).
For other work the cost can be lower or higher depending on how much time and effort needs to be invested by the company to get a new hire up to speed on the company procedures, code base (in case of software), work out team issues and any in-house training programs.
And if you report or have to answer to anyone, they're not likely to be impressed that you hired that many duds/people who just didn't work out.
I think it's important to note that the author is writing from the viewpoint of a serial entrepreneur, which means the context is small startup environments.
Presumably he still might answer to a board, but those may all be co-founders. Regardless, I don't think they would need to be impressed by his management style so much as his end results.
How many startups are funded entirely by real co-founders? Some, I'm sure, and a lot more now, but is that the exception rather than the rule?
So if you have "normal" investors, unless the board that includes them is really hands off they'll notice and I can't imagine it will help his credibility. If it's that hands off you're in trouble in that they aren't likely to be very committed to the venture.
Exactly! This concept of "firing" is the purview of assclowns. People that have no management skill yet who lust after director or VP titles after a year in the industry. These people are doomed to building small things. Small companies, small product, small careers. You better wake up and realize the world is made up of people not code.
A company I know puts all new hires on 90 day probation. If, within 90 days you can't show you can begin the process of integrating, out you go. Their ratio is about 1:5, though typically they let the people resign since it's far less damaging to their future careers.
I say 1:5, which I feel is high, this number despite a rigorous technical interview process.
On a different note, another company that somehow started in small-town U.S. needed to expand their engineering staff. They looked in the Bay Area but the salary reqs were far too high so they settled on Portland. Got a team of engineers stood up in a satellite office. And then because of some minor personality conflicts and a lack of management skill failed to use them. This gave that team a bad reputation as "the team that sucks".
Now to be fair, they weren't the hottest rock-star coders in the world. But they could take a detailed spec and put out some reasonably solid work -- in other words, the absolutely normal, run of the mill developer. The problem was with the front office, not the engineers, they simply didn't know how to put together technical requirements that a remote site could follow. They conducted all of their engineering task assignments with daily, in-person staff meetings, verbally assigning tasks to engineers and writing down the task name in a development tracker (usually with lots of white board time).
A year later, the Portland team, unable to ever attend any of the daily, in-person, task assignments, and the front office unable to put together a decent set of specifications to send to a remote office, had no assignments, and a bad rep. The whole team was ultimately let go.
I'd fire you and find someone that is better at judging fit beforehand.
A full third is really very high. Consider apprenticing yourself to someone more experienced for a while to figure out what it is that you are missing while hiring, especially if the absolute numbers are high. If you've hired six people in all your time and fired 2 of them then we'll take it as a statistical anomaly.
Out of 25 people hired I've had to fire exactly 1, but I rejected almost 95% of all applicants to open positions, not limited to the engineering department.
I think one big difference in the way we look at this is that if you hire someone you also have a responsibility to them, evaluating fit is something that is your responsibility, and failure is up to you to correct, through teaching, training and mentoring.
It seems you think that you have no responsibility for them other than to fire them when you've decided your 'extended interview' is over.
In most countries there is an agreed upon 'trial period', which allows an employer to terminate a contract without any penalties, depending on the country these periods last from 30 days to 6 months. But it is actually pretty rare to have to fire someone within that period, even if there does not have to be 'cause' a high firing rate during the trial period reflects bad on the hiring manager.
The reason for that is simple economy, hiring people and firing them within 6 months is a very bad investment for the company, that person cost almost as much in time spent getting them up to speed as a person that is productive for multiple years.
If you're hiring someone that is out-of-work and down on their luck then you could argue that something is better than nothing and you gave them a chance, if you entice people to leave a job where they've worked for years and you then end up firing because of a mis-judgment them you've caused a real problem.
Urk, I had forgotten about the problem of enticing people from good jobs. Many of them will be your best employees, but if you have this sort of "fire 1/3rds" process and are up front about it you'll lose this entire talent pool.
And it won't do anything good for you company's reputation. Read Death by Lethal Reputation http://www.asktheheadhunter.com/halethalrep.htm; I'll also note that failed startup Thinking Machines (the Connection Machine company) had absolutely the worst hiring practices of any Cambridge, MA area company in the '80s (details upon request).
I'd like to request details on Connection Machines' hiring practices. (Or do you prefer people to privately email?) I've read some things about them, but there's usually more lore than reality in post-mortems.
I've worked mainly in startups and think that startups rarely approach their potential. The managers often comfort themselves with delusions, and the employees for their part often passively take the work they're handed.
Like a men's club, one blackball from any employee and you weren't hired. I think this is documented, and I don't know how long they continued the policy (see below, I passed that test).
Early on at least they took forever to hire. E.g. I did a serious interview with them (my interview with Danny Hillis, who was part of my social circle, started with an aggressive "Why aren't you in school!??" (the answer was money)). They got back to me more than a month after that interview, by which time I'd accepted a much less desirable job (sysadmin for their Lisp Machines).
I was told they failed the second time to fill this job and that three full calendar years later (!!!) they hired a classmate of mine in their third try (I pretty much knew the entire talent pool available at the time).
We can be quite certain that damaged their productivity early on; my experience was at the very beginning of 1984 and I'm not sure they failed to hire anyone for this slot in the meantime.
In one well sourced account, they asked for a reference from an applicant's current employer (of course without clearing this with him first). Except for that case, I've never heard of anyone doing that, ever.
While they were the coolest place to work at in Boston, I can see how they might in part have suffered a "death by lethal reputation" (there are many additional and well documented reasons in the public record, of course).
I'd fire you and find someone that is better at judging fit beforehand.A full third is really very high. Consider apprenticing yourself to someone more experienced for a while to figure out what it is that you are missing while hiring
This advice seems ill-suited to someone founding a startup. A founder is a manger out of necessity, not out of an affinity for people-managing. Are such apprenticeship opportunities readily available?
As someone who has only been on the receiving end of managerial treatment, I agree, emotionally, with your position (and presumably would enjoy working for you). However, I'm not sure it makes rational sense.
It seems you think that you have no responsibility for them other than to fire them when you've decided your 'extended interview' is over.
It's important to note that it's an extended paid interview.
The reason for that is simple economy, hiring people and firing them within 6 months is a very bad investment for the company, that person cost almost as much in time spent getting them up to speed as a person that is productive for multiple years.
I've heard and read assertions to this effect before. Do you have studies (or even anecdotal evidence) you could provide that would quantify this?
This also begs the question of the overall productivity of the team, rather than any given individual, or is that what you mean by time spent getting them up to speed?
if you entice people to leave a job where they've worked for years and you then end up firing because of a mis-judgment them you've caused a real problem.
Possibly, but if the firing is from a startup and the stable job was a larger company, I suggest this is to be considered part of the risk.
I did exactly such enticing with a friend and colleague of mine to a startup which eventually failed (and again to another one, which is perhaps in the process of failing).
His original employer valued him enough that they were more than happy to have him back, even a year later. I expect this to extend to all "A players."
For a start-up the rules are a bit different, but in a way for a start-up it is even more important to hire the right people rather than to use a more trial-and-error based approach to hiring.
Start-ups as a rule have less time to lose on stuff like that and replacing a person in a start-up usually carries a severe penalty. The teams are usually much smaller and dropping a team member will have a significant impact, much more so than in a larger organization (but even there it can hurt a lot). A start-up I invested in lost their #2 programmer due to a series of problems and it almost killed the company.
As for apprenticing, the possibility to learn is always present, but maybe not in your own company. When you find yourself in the need of knowledge it doesn't hurt to go through your addressbook, find someone with more experience in the field that you want more knowledge in and ask.
I've done that quite frequently in my career (and I still do that, as some HN'ers can attest to) and I've found that people are usually very happy to teach a new skill or to augment an existing one if you ask them. Of course they're not obliged and you can't make any demands but as a rule it doesn't hurt to ask.
> It's important to note that it's an extended paid interview.
Yes, that's true, there is some compensation. But I always looked at firing someone - and it fortunately was very rare - as a sort of divorce on bad terms. The better way to go about it is to talk things over, if possible help find your employee a spot where they're more in their place rather than at a high pressure start-up where the margin for error is a lot lower.
> I've heard and read assertions to this effect before. Do you have studies (or even anecdotal evidence) you could provide that would quantify this?
As a rule I ask companies where I do technical due dilligence how long it takes them to get a new hire up to speed. The companies where this goes fasted are around the 3 month mark, as a rule those companies have fairly simple systems and no long running projects or large code bases. The longest are around 2 years, these are companies that usually have a limited size in house development team, sometimes requiring skills on the cross roads of two or more disciplines working on technically complicated projects.
On average, assuming a linear increase in productivity over the time that you hire someone to the time that they are as productive as the 'old hands' it seems to work out to at least several monthly salaries of time wasted, for one because the new hire is not yet productive, but also because he/she is a drain on the members that were already productive before the hire was added to the team. The latter factor is one that is overlooked very frequently.
> This also begs the question of the overall productivity of the team, rather than any given individual, or is that what you mean by time spent getting them up to speed?
The team as a whole.
> Possibly, but if the firing is from a startup and the stable job was a larger company, I suggest this is to be considered part of the risk.
That's true, but then only if the person hired is made well aware of the risk and can balance it with a pay-off in proportion to that risk.
When I was young and without responsibilities other than to myself I would work simply on what I thought was interesting and I couldn't have cared less about the compensation, so if I would have gotten fired (which never happened, but theoretically it could have) I wouldn't have cared much about it.
Employing someone with a wife, kids and a mortgage and then throwing them out in the callous way the poster suggests, after hiring them capriciously is really bad for your business' reputation as well as for your employees.
You really don't want to get known as a company bad attitude towards new hires, the better people will simply not even apply to a company like that.
In the end all you'll get is people that more or less expect to be fired in the next 6 months.
One of the best companies that I've read about culture wise was the 'old' HP, I've done my best to try to learn as much as I could from how they treated their employees and I think it did me well. If this stuff interests you, then there is plenty of stuff documented on the web about it, there is also a book called 'the HP way', which contains a few valuable insights.
Other books that I've found great showing me bits and pieces of how to grow in to the role of a manager after being a techie all my life were 'the soul of a new machine' by Tracy Kidder and a book about the very first computers in war time England, but I can't recall the title.
> did exactly such enticing with a friend and colleague of mine to a startup which eventually failed (and again to another one, which is perhaps in the process of failing).
His original employer valued him enough that they were more than happy to have him back, even a year later. I expect this to extend to all "A players."
That's great, but the economy is not what it was several years ago, and I suspect that people leaving a good job will expect their new employers to treat them with some respect, it may be that by making such a move they are taking a considerable risk. Of course, nobody is forcing them, but it doesn't hurt to be careful with other people.
edit: I'm sorry you got modded down, I don't see any reason for that in your writing.
Probably not, unless someone else jumps in, since I actually agree with you and am merely exercising skepticism to solidify my conclusion. [1]
As a rule I ask companies where I do technical due dilligence how long it takes them to get a new hire up to speed
At the risk of quibbling, this strikes me as a couple steps removed from anecdotal. I expect a degree of subjectivity, but without direct observation, it's merely hearsay (not entirely unlike some interviewing techniques, but I digress).
On average, assuming a linear increase in productivity over the time that you hire someone to the time that they are as productive as the 'old hands'
That's a big assumption, and one I would suggest is false for experienced technical people, especially non-programmers.
I detect an additional, implicit assumption, that a new hire's productivity will ever reach (and/or not surpass) that of the veterans around them. Similarly, you're assuming that they will, at some point, cease to be a drain on the team.
Employing someone with a wife, kids and a mortgage
I don't think it's any of an employer's concern what an employee's personal/family situation is, nor appropriate to base hiring/firing decisions on it. Fortunately, the labor laws in my jurisdiction support such a view quite strongly.
and then throwing them out in the callous way the poster suggests, after hiring them capriciously is really bad for your business' reputation as well as for your employees.
This may be true, but you haven't pointed out where capriciousness or callousness (beyond a separation of business and personal) is advocated, either by the OP or the OC.
[1] I hesitate to use the term "Devil's advocate," as it carries a connotation of absence of engagement or conviction.
At the risk of quibbling, this strikes me as a couple steps removed from anecdotal. I expect a degree of subjectivity, but without direct observation, it's merely hearsay (not entirely unlike some interviewing techniques, but I digress).
It's not even removed, it is anecdotal, I don't even know for sure if they are telling the truth, and possibly neither do they. But the universal component seems to be that they all agree that it takes time, so the only thing left to argue about is how much time, and hence roughly how much cost. We're talking about a fair sized sample though, so even if it isn't a research project it will hold some water.
The question is born out of my own experience that it can take some time to get a new hire trained, coupled with a bit of information about the complexity of the subject matter it usually gives me some insight in to how well their documentation is and how good their teams are at communication and dealing with integration issues.
That's a big assumption, and one I would suggest is false for experienced technical people, especially non-programmers.
I detect an additional, implicit assumption, that a new hire's productivity will ever reach (and/or not surpass) that of the veterans around them.
Not necessarily, there is probably some correlation with how fast someone gets up to speed and how far they'll go, sometimes you get lucky and you find someone that managed to outperform the people that you already had. But as time progresses the chances of that are smaller and smaller, simply because of the body of accumulated knowledge by the 'old hands'.
Similarly, you're assuming that they will, at some point, cease to be a drain on the team.
Well, everybody is a 'drain' on everybody else in that respect, but during the initial period where someone is entirely new to something that drain can be considerable.
Especially in those 'rare' cases where the documentation leaves something to be desired. Of course that would never happen in real life ;)
I don't think it's any of an employer's concern what an employee's personal/family situation is, nor appropriate to base hiring/firing decisions on it. Fortunately, the labor laws in my jurisdiction support such a view quite strongly.
No, but that doesn't mean that it hurts a lot more to fire someone for whatever reason if you know that it will affect his or her dependents as well. I agree that's arbitrary but I'm by no means perfect.
Downsizing is the hardest in this respect, it causes no end of grief, nobody did anything really wrong, but still you would have to let people go.
This may be true, but you haven't pointed out where capriciousness or callousness (beyond a separation of business and personal) is advocated, either by the OP or the OC.
I think the capriciousness is in the part where he says 'in startups, where you hire fast and loose', which is something that I don't think is necessary at all, and then corrects the failure to invest enough time in the hiring process by firing an overly large portion of his hires, most likely people that he would have never hired in the first place if he had spent a bit more time in the beginning.
A third seems like an awfully high ratio; as someone else has pointed out, there are real (and immediate) repercussions from firing.
I've fired someone before, and I'd do it again. But it was a horrible experience; and I would want to avoid that kind of experience, especially for 3-6 months.
One thing that gave me a lot of confidence was to set up a peer review system. Once I saw that the group had the same instincts I had, it was a no brainer. (Peer reviews are so much more interesting on many levels, actually. I don't know why this never occurred to any of my bosses.)
Other than this, the "one week trial period" proposed in Rework (http://37signals.com/rework/) seems like a good way to avoid a "several month realization of uh-oh". Has anyone ever tried this out?
Marc Andreesson wrote (about hiring suits, not engineers): "if you know what you're doing, the odds of a given executive hire working out will be about 50/50. That is, about 50% of the time you'll screw up and ultimately have to replace the person. (If you don't know what you're doing, your failure rate will be closer to 100%.)" http://pmarca-archive.posterous.com/the-pmarca-guide-to-star...
From my own experience, the best team I ever worked on was one where we had a rigorous interview process... and fired 2 of the first 6 engineers, i.e., one third.
As an employer you will find yourself with the quality of employees that you deserve. Treat your employees right and they'll be loyal and hopefully will treat you right in return. Treat them bad or whimsically and it will come back to you just the same.
Employer-employee relationships differ from country to country but the above is I think a universal truth. Be a 'bad boss', hire and fire at will and you'll find that your employees will continuously be on the look-out to see if they can do better before you have a bad (pointy) hair day.
Treat them well and they just might amaze you in what they can do for you.
Managing people always was the part of the job that I dreaded the most, as the ceo of a relatively small company. The biggest reason for that was that it took time away from my 'first love', computer programming. But I hope that I never treated the employees of my company as cold and heartless as the article suggests, I'd be interested to hear his employees side of the story.
Different strokes for different folks, it is very well possible that this strategy will work for a certain style of CEO, in a given job-market and location, but I'm fairly sure that it would not have worked for me.
I'd rather spend a bit more time on the hiring side of things and get the right people on board than to go for a 'trial-and-error' approach like this and to have to go through the painful (for all parties) process of getting rid of a third of the new hires every six months.
I have a particular problem with the sentence:
> Your team thinks you suck if you don't have the chutzpah to fire.
That speaks to me of a CEO that is at heart a very insecure person.
He wasn't saying that you fire people to show you've got balls. He was saying that teams will think less of you as a manager if you don't fire bad people. And he's right about that.
Hiring and firing bad people manifests itself as additional chaos to the others who are trying to get their work done.
For those in the trenches, those doing the firing will have
already lost credibility for hiring the bad people in the first place.
But you might be able to find a way to make them an asset to your organization any way. There are many kinds of 'bad'.
There is 'incompetent', but that usually comes with a specific field of competence, maybe the employee has different skills and can be given a new role where they're more productive and happy.
There is 'anti-social', this is a real problem and should probably have been caught at the hiring time, a person like this is going to have a hard time being a part of any team.
Then there is 'not in this team', if you have only one team then that's easy, but if you have more of them you might try a different one.
There are the 'loners', people that can't work with others but have to do everything their way, these are usually better suited to become entrepreneurs themselves (I had one guy like that working for me and I helped set him up to start his own business and he actually succeeded in an amazing way).
And so on. So even if you can't keep a bad person on the team there are a few more steps before you bring out the shotgun.
I've literally fired exactly one person, the reason was that he was starting up a competing service and at the same time approached our customers. That was reason enough for me for an on-the-spot termination when I found out.
Other than that we never had any issue that we couldn't resolve amicably or part on good terms without having to resort to firing someone outright.
It depends on the circumstance. In a small startup, it's going to be a given that a certain fraction of the people you bring on are inappropriate for the company, and that you can't predict this in advance. Fire them, before they do too much damage to the codebase, morale, et cetera. In a larger company, firing is much more of a last resort, because people can always be moved around, and because if the only problem is that they aren't producing, it's probably because they weren't mentored and this can be rectified-- large companies usually have enough time and resources that they shouldn't need to fire many people, except when things are so bad that layoffs are necessary.
Indeed. I should clarify that. If you're in a very small startup, let's say 0-30 people, the chances are that most people working there have some say in the hiring process. If someone his hired and doesn't work out, most are on the same page about what's going on.
Once a company gets to the point where people are being hired and fired by managers, churn becomes an additional chaos factor that people trying to do work have to deal with.
He doesn't mention bad people in the bit I'm referring to, he literally says:
"Your team thinks you suck if you don't have the chutzpah to fire."
And that just makes no sense.
Firing bad people is in the other bit above, where it says:
"No, firing bad people improves the culture because it sets standards, and proves consequences.
One bad apple does ruin the bunch."
Hiring bad people is what ruins the culture, firing them improves it back to what it was before you hired them, if you're lucky. Most times will never go back to what it was before.
He doesn't mention bad people in the bit I'm referring to, he literally says:"Your team thinks you suck if you don't have the chutzpah to fire."And that just makes no sense.
If reading the bit out of context makes no sense, perhaps a different reading, such as suggested by parent comment(s) is indicated.
That's possible. I'd attribute it to an oversight then, the missing 'of a bad apple' at the end of that sentence.
Then it would make more sense. But firing people is a step done with some restraint, bad apples get their chance to improve 'or else' and if it doesn't work out then the 'or else' gets activated, and presumably the whole team will be on board with that decision.
The last thing you want is to be seen as someone that fires people to prove that you do not suck.
Is it just me or is ignoring the interview process in favour of the firing process as poor as the opposite? The best method is to weight them about equal.
Have a rigorous interview process where you try to hire only the best fit. If the new employee is a failure, have the ability to admit you made a mistake a correct it. Best of both worlds.
Firing a new hire is not a cheap process and it does affect your reputation/company morale.
Absolutely true. I'm really surprised at the attitude of the article, it almost seems as though firing is seen as a replacement for a good interview process, and to shore up a lack of authority by instilling fear or showing 'guts'.
I think you need both. You need to detect, and rectify, problems as soon as they occur. It's much better to catch potentially badly-fit employees (which doesn't mean they're necessarily bad, but just not right for the position you're trying to fill) in the interview process. However, there are subtle problems (people who can't handle large projects, or who don't document code, or who interview well but are actually unethical) that can't be caught in the interview process at all.
This is oddly similar to the compile/run time distinction in bugs. You want to push as many of your bugs to compile time as possible (not-so-subtle plug for static typing) but it's impossible to have catch all of them in compilation; such is the nature of bugs. Similarly, you want to catch as many problems as possible in the interview process, but can't get all of them.
He's wrong, tho'. The #1 reason that managers don't fire poor performers is that firing is a huge, huge pain at most companies. Everyone might "know" they're a chump, but HR will want proof in writing, over a period of time, and god help you if the person is any sort of minority.
Which is why in most companies poor performers get "promoted" to where hopefully they can't do too much damage. If you're lucky, they can be contained to writing reports that no-one reads. If you're not and someone forgets why they were promoted, then they might actually end up in charge of something, and no-one wins. Except for the HR department. They always win.
The corporate job where I'm at right now has this exact problem. HR has made termination require a LONG process that starts with a 6 month "performance initiative plan" before enough data can be collected to fire someone. And even then it requires a tremendous amount of executive level approval.
We've had lots of incidents in the past where older employees would play the "I have a health issue" card to avoid being fired. Just to avoid getting sued, the company would capitulate and "promote or move" them away from the manager who didn't want them.
Part of the problem is that as companies get bigger and their pockets get deeper, an entirely new class of employee enters which is low skill, highly cunning, and completely untrustworthy. Unfortunately, in my experience, most of these individuals always fit a certain profile:
Middle Aged Men (50+)
Low level of education
Most of these people are hired for two reasons:
1) Need someone for grunt work (support/maintenance)
2) Need someone that will accept a very low salary
Once a few incidents happen, HR and legal issues take over and begin the stranglehold on operational efficiency that infects large organizations.
This was great, however, it also rests on the premise that management and those above them has the knowledge and ability to recognize what constitutes a bad employee. Sometimes, through their own ignorance, what is "bad" really is good. It's so sad that that type of problem permeates the software industry. Firing "bad" people fast should be a good thing but only if you can judge bad from good.
This is a refreshing alternative to the "better to turn away a superstar than to hire a dud" approach that seems so common. I've always felt that it was caused by risk aversion anyway.
What's missed here is that being fired, for a lot of people, has real consequences. I don't think I'd take a job where I thought there was a 1/3 chance I'd be fired in the next 6 months.
If you're a startup, you're hiring people who understand the lack of job security. If you're a large company, there's no excuse for firing 1/3 within 6 months: you can move people around until they fit. If you're getting rid of more than 10% in the first 6 months, you're doing something wrong.
My thought: we should have a real safety net (including universal healthcare and a basic income that everyone gets, even the gainfully employed millionaires) and then allow companies to hire and fire whomever they want, because no one's life gets ruined by the loss of a job. But this would be a radical departure from the society we currently have.
Is there any hire at will (which as a term of art includes firing and leaving at will) European country with socialized medicine and the dole?
I told that plenty that make it so difficult to fire a person that they have high youth unemployment rates (e.g. France), but the above three with a strong "Protestant work ethic" might work out well. Or the incentive structure, if a lifestyle on the dole is too good for too many people, might be disastrous in the long term.
I'm inclined to think the latter will be the outcome but wonder if we have any tests of the proposition.
In Germany i think it is easy to fire employees in the first 6 months (probation period). A probation period of up to 2 years might be possible, but I am not sure (there was a lot of discussion about this some time ago).
One thing that happens is that some low-level jobs have high fluctuation. Especially as the government pays some additional money for some jobs in the first couple of months (which seems extremely absurd to me). So some clever employers fire their employees once the government subsidization has expired...
> Is there any hire at will (which as a term of art includes firing and leaving at will) European country with socialized medicine and the dole?
Britain probably qualifies to some extent, because employees cannot claim unfair dismissal if they were sacked before they'd been working for an employer for one year.
As far as I know (and I admit I don't really), don't they all make it hard to fire someone, at least after a trial period?
What about Denmark?
They're supposed to have a private sector that's way above average for Western Europe, but I don't know or remember about firing policies or if they have a dole.
Dole as in any able bodied man who isn't working can draw government payments that provide an acceptable level of living.
At will means anyone not in a contract can be fired at any time for any reason (well, you can disallow a few narrow ones like getting pregnant in most situations).
Or the incentive structure, if a lifestyle on the dole is too good for too many people, might be disastrous in the long term.
Within about 50 years, due to technological advancements, we'll have 20-40% paid employment (not unemployment) and there'll need to be some sort of dole.
Personally, I think it would be great to have a society where people don't need to work. The people who only work because they have to wouldn't be working, which means that the people who are working are those with ambition and talent, and only those.
The arch-conservative and historian part of me tells me in reply that "The Devil finds work for idle hands." For a pre-Christan example of this, look no further than Rome's initial "bread and circus" period.
The wealth gained from the Republic's Third Punic War had an ultimately disastrous result in all sorts of ways.
That said, you're absolutely right, we will someday have a true post-scarcity society, although the near total suppression of real nanotech research in the last quarter century makes me leery of predicting any dates.
Start with this item at the end of the home page: Changing the narrative in the U.S.
In short, "the establishment", e.g. existing chemists appropriated the buzz Drexler created while not actually doing what he was promoting for the usual parochial reasons plus in many cases a genuine and legitimate fear of what his style nanotech will bring about.
Right, so the failure of significant progress towards Drexler's vision must be due to some kind of secret conspiracy of physicists and chemists rather than, say, the fact that atom-by-atom assembly is ridiculously hard?
I should probably vaguely mention that my PhD work was not entirely disconnected from the idea of fabricating devices by placing individual atoms in locations with sub-nm precision. I suppose I should be offended that nobody let me in on the fact that we're supposed to be suppressing that kind of work.
It wasn't secret! See e.g. the "debate" Nobel Chemist Smalley had with Drexler in Scientific American and then I think the JACS. Smalley started out with a straw man ("fat fingers") in both, which is not a sign of honest intent.
The bottom line is "where are the grants and research centers for Drexler style nanotech"? Either he's lying about this---I'll admit most of my info about this is from him or people in his orbit---or he's mostly right.
Or let me put it this where: when you graduate, where are you going to be able to go to work on "Productive Nanosystems" in his style? Name names, this should be something you're looking for or at least aware of, or can ask about tomorrow when you go into "work".
ADDED: I know it's "ridiculously hard", for if finances hadn't gotten in the way I would have most likely eventually gotten a Ph.D. in work "not entirely disconnected from the idea of fabricating devices by placing individual atoms in locations with" atomic precision in the '90s.
Ah, it would have been easier if you'd started out saying "beyond the foreseeable state of the art" or "impossible". Then we could have discussed that issue.
However your appeal to authority (that authority being yourself) does not falsify what Drexler has said about this or his evidence.
And if you'd started out by saying "I think that full-on atomistic assembly nanotechnology isn't being taken sufficiently seriously by the scientific community" rather than "nanotechnology research has been suppressed for the past 25 years" then you'd have had a more sensible argument.
A great book that espouses this principle is Fire Someone Today: http://www.firesomeonetoday.com/ There's a lot of other practical entrepreneurial advice in there too!
Just looked up this company on Glassdoor. As I suspected this jerk has created a company culture of suspicion and hate. He himself is not respected by his team as is proved by his abysmal rating. As a potential employee I'd take one look at this review and head for the hills. An example -
"“Lord of The Flies Meet Corporate America.”
Pros
Product works well and is fully supported by a highly skilled team. Some positions offer work from home.
Cons
Management plays favorites for their friends and plays immature games. Nothing you shouldn't expect from a company that had a fight club. Overall the upper management doesn't seem to care about their employees rather tech support or sales. Constant turn over in the sales department lead by myopic management team. You will love the atmosphere with your coworkers but despise the management for their lack of respect and unethical conduct.
Advice to Senior Management
Treat your employees with respect. You can not expect your customers and channel to respect you when you constantly cut good people from your team. I would advise the executive team to seriously look at their management who has regular turnover. Sometimes its the process not the person."
In a way, it's an admission of impotence. When you fire someone, you're saying that you don't have the resources or power to turn that person into a success at your company.
The "resources" angle is crucial. Large companies can afford to have a non-producer for 6 months and train him up to being able to contribute, and they generally should. Startups usually can't afford this.
Of course, this excludes the cases where a person is fired for doing something seriously wrong or unethical. But I imagine it's much easier to fire in those cases.
I don't think it's within my power or anyone else's to turn many people into a success if they can't grok pointers, recursion and/or abstraction and one or more of those is necessary for the job (I'm assuming a small enough startup they can't be put someplace "safe").
I'm pretty sure the abstraction bit is innate (I'm assuming they've passed high school math), and very sure I can't teach it nor is it my duty to. Pointers and recursion are not so bad (but again, in these sorts of situations I'm probably not in a position to get them up to speed on something so basic and so far reaching in effects (especially unsafe pointers)).
A pink email and a guard escorting you out of the building do a great job reducing heart attacks or a bullet between your eyes. You still have to park your mercedes out of sight that day tho.
Huh, whatever CMS he's using didn't enter in his HTML comment as, well, a comment. Up near the top of the article: "<!-- If what I write makes me look like the grim reaper of CEOs.-->"
Very interesting. And it agrees with the one unique piece of advice I give people who are considering whether to go to work at a new firm, "Try to determine if they can fire people."
One quibble:
"It takes time to glean an employee's pithy attributes: work ethic, intelligence, attention to detail, enthusiasm, even personal hygiene."
You should be able to judge at least initial enthusiasm in your interviewing process or you're not doing a good job of selling your company or it's an impossible sales proposition. Either of which you should do something about at a high priority.
But I'll admit that sustained enthusiasm is what really counts and of course only time will tell WRT to that. And I'm not sure what you'd do with people who take some time to warm up to a situation (ADDED: well, make sure they've been enthusiastic about at least one prior job; if they're too young to have any/many and are already cynical you'd probably best pass on them :-).
For programmers you should be able to get a reading of intelligence and attention to detail in the interview as long as you do minimal testing (perhaps Fizzbuzz, my preferred 3 tests of reverse a linked list (pointers), recursive factorial and find error in this block of code, etc.).
Having them work out loud with you a relevant design problem is also good, although recognize that only 1/5 of programmers "get" abstraction (according to the Antipatterns book and my personal experience); if you need/can afford having programmers who don't get it, you'll want to gauge their ability to follow orders and "do it this way" "just because" the architect says so.
(There are potentially lots of slots in an organization including a startup for all sorts of competent people, e.g. look at the 2nd Coders at Work interview Brad Fitzpatrick, the Live Journal Founder. They had an older employee who produced awful code, but they loved him since his forte was quickly figuring out difficult integration problems which no one else liked to do or was good at. He handed them messy solutions filled with duct tape and bailing wire and they mined the interfaces from them and made clean versions that fit with their system.)
Anyway, my advice is to pay close attention to what this author says, just don't let it cause you to significantly relax your hiring system since hiring, working with and then firing duds is always debilitating for all concerned.
Personally, I'd take a good understanding of functional programming as a substitute for a good understanding of pointers. I mean, the point of the exercise isn't to find out how well they know pointers (they'll rarely use them anyway). It's just a way to figure out how smart they are.
When I was doing this, groking pointers was required and functional programming unfortunately just wasn't an option. E.g. during this period LISP was anathema (even to the point where one project at the beginning of this decade died because it could only be done in something that productive but use of it was rejected for no good reason).
So my test was for understanding pointers as well as figuring out how smart they are at programming.
Plus as noted when things get ugly (e.g. in some debugging situations) groking pointers is required and as long as Johnny von Neumann's initial hack architecture rules that will remain true.
Today, I would most certainly take someone with "a good understanding of functional programming as a substitute for a good understanding of pointers", I'd just make sure a few also grok pointers and other low level stuff.
(I am so happy we have exited the Dark Age of Programming Languages.)
Back when I was doing this C and/or C++ was required (in general and for the job).
Today, I don't know what I'd do (besides ask them to do it with pointers anyway, pseudo-code is fine for this problem). Someone from a Javaschool might work out well, but they'll be lost in some harder debugging situations, so I guess I'd try to make sure they'll ask for help when it gets that messy and make sure I had some uber-programmers to support them (such as myself :-).
I have a friend whose test is to sort a linked list using any sorting algorithm (it can be bubble sort) and any language (excluding trivial calls to library functions). It's fairly hard in C, trivial in ML or Haskell, and this is the point of the test: if you're able to use a high-level language, this is a benefit.
Errr, one of the points of my test is "do you grok pointers?" Which is an hard or impossible thing for many people and is needed in some subset of programming jobs.
But I'm sure many fewer today, note that I started out with punched card FORTRAN "IV" on an IBM 1130 and then did a lot of UNIX on PDP-11s. Fortunately I was able to play with LISP starting a couple of years after that first experience.
Today the world is almost entirely different, e.g. it's hard to buy a processor that had less L1 cache than the max address space of those machines' macroarchitecture.
ADDED: Or as I like to say, echoing someone I forget:
Note: someone might say that I was the problem, which may be true, but I wasn't let go either, so my point still stands ;)