Ways to Minimize Employee Retention
rustyrazorblade.com
rustyrazorblade.com
If you have to choose only one item from the list, this one is really, shockingly effective and easy to implement. My wife was in tears the other day because she made two trivial, easily-fixable errors on some paperwork she was doing as a stand-in for someone who was out sick. She fixed the errors and resubmitted it when they were brought to her attention, but her boss still sent the original one around to the entire office as an example of how not to do the paperwork, offering a prize to anyone who could spot all of the errors on it, and all-but-outright-stated that anyone who would submit paperwork in such shape was a moron.
I'm willing to believe that her boss is just a complete fucking idiot and meant it to be funny, but it was extremely cruel and totally uncalled for. Publicly humiliating your newest employee for the incredible crime of "volunteering to help take care of something when the person responsible is out sick" is really, really dumb and a great way to ensure that nobody ever helps anybody else with anything. It's working, because while we were on vacation she came back to a huge pile of work that nobody had even made an effort to handle, even though anyone in the office could have pitched in. And since she's a fast learner, she's also stopped helping other people when they're out sick, because it can only possibly lead to either 1) Her doing more work for no recognition, or 2) Her doing more work for no recognition and getting publicly mocked for doing something wrong.
For some mysterious reason, the office she works for has a hard time retaining employees and a hard time hiring new ones. People also take a LOT of (unpaid) sick days there, which are informally known as "sick of all the bullshit" days, because they're happier staying home without pay than coming to work and dealing with their manager.
Praise in public, punish in private
You don't want to be the guy whose code is called out as garbage, unless you're doing it yourself.
This rings especially true for me at my current company. Everyone says around here that the most important skill you can learn is "expectation management".
When given a task that is supposed to take 1 week, the absolute worst thing you can do is complete it in 2 days. Actually, 1 day, or 1 hour would be even worse.
Doing that will only open the flood gates to dump an ever increasing workload on you, while receiving zero recognition.
I updated my resume and was gone in three weeks.
On one hand, a "you broke the build dunce cap" isn't the worst of ideas. (Although by far I prefer a check-in system that doesn't allow the build to be broken for everyone...)
I've been shamed, and semi-publically (within the team) shamed others, for not having written any unit tests before check-in.
I'm also a big fan of publically celebrating successes. When a tester writes up a good bug, I'll have it sent around to everyone as an example of what a good bug report looks like!
But as a manager, I would strongly advise you to steer clear of that tactic. Even if you've got awesome emotional intelligence (and I don't) it's easy to screw up. It's not worth it.
Really, don't do it. Because when you screw up, it hurts real people.
There are better ways to encourage people - for example, the positve feedback to the tester you described.
So true. I've had great managers that had great rapport with the team and everyone was tight knit enough that the manager could stand in the hall and say "hey, come over here and look at the ridiculous code Bill wrote" and it would all be in good fun, even for the person who was being mocked (being able to laugh at your own mistakes is important, IMO). And on the other hand, I've had terrible managers who aren't able to do it in a good-natured manner and it ends up being mean-spirited, condescending, and morale-killing. There's a surprisingly fine line between "lol, Bill, what were you thinking?" and "Bill wrote bad code and I'm going to call him on it, making everyone on the team uncomfortable, and thus cultivating an environment where everyone lives in fear of making a mistake."
I would actually argue that when done right, this sort of smack-talk can be healthy and reassuring to the recipient. It's a bit perverse, but I like a situation where my coworkers respect me enough to make fun of my mistakes without me or them worrying that it actually calls my competence into question. I've worked with people who you can't poke fun at, and it's usually because they actually are somewhat incompetent and making fun of their errors would be cruel.
Hopefully we never work together.
> Hopefully we never work together.
Indeed.
Not so much on pushing broken builds to production though.
Otherwise I would not advise.
23. Encourage sociable, pleasant employees to read Machiavelli and Sun Tzu.
24. Peer reviews and stack ranking!
25. Stress that everything must be done in-house. If your employees want a wheel, they must reinvent it themselves.
26. Play video games in your office during crunch-time or, heck, just take the day off. You deserve it!
27. Survey your employees to find out what extracurricular activities everyone enjoys. Then, ignore that data and hold a mandatory weekend game of your own favorite sport pitting your employees against those of a personal rival. If your team loses, throw your hat on the ground, jump up and down on it, and swear never to do this again. Repeat once or more annually.
28. If, after doing all this, you still have payroll to burn, hire somebody at twice the salary of anyone else, anonymously leak salary information for your department, and be sure to give this new employee absolutely nothing to do except twiddle their thumbs.
30. Advertise a position as advanced and interesting -- quant work, machine learning, GPGPU, distributed systems, etc. -- then hand your new hire a 15 year old heap of stinking web CRUD written in Perl and 1990s-style JavaScript to maintain.
(Both from my own personal experience.)
Niccolo Machiavelli "The Prince"
Also, as an software contractor, his thesis on private forces/ paid forces is quite enlightening.
I've had nothing but positive experiences from years and years of peer reviews. It's not even that I've had "nice" / overly-charitable peers who don't call me out on things: I've gotten good, actionable feedback that improved my career.
It's a pain in the ass to write them but I always put in a good effort because of the benefits I've received from them.
Oh boy. I worked one place where they handed out copies. It did not occur to me that this was a warning sign at the time, but... yeah.
This could be reposted as Business/Management 101 in the office for most managers, or apparently the guide many have been using.
I have experienced almost all of them and could feel the pain in each line item that would come from developers that care or product developers that know what it takes to ship a successful product, well written and thorough.
22. Developers don't like to concentrate on their work for more than about 30-45 minutes at a stretch. So make sure to liven up their days with lots of meetings spread over the course of the day!
However in terms of practical changes, this post can neither benefit you nor anyone else. We all know about broken management cultures that this post describes, but none of those managers in question would do anything but become extremely defensive if confronted by a post like this (which they wouldn't be because they don't know what Hacker News or a technical blog is).
To the clueful neutral observer we have to weigh out whether management is really this clueless, or is the author a poor communicator full of sour grapes? Honestly it's 50/50, but I would probably be too nervous to ever hire someone who posted this vitriolic of prose publicly, it just comes off as unprofessional.
Perhaps we should accept the shocking reality that there are really startups this awful to work for :)
I still think it was a funny and informative blog post though.
3. Interrupting people regularly for status updates.
4. Falling into "doom loop" of rushing software dev.
6. Changing communication tools regularly.
10. Being overly stingy with hardware.
14. Failing to deliver public praise.
17. Being stingy with information.
As a software developer, I've always coded alone. As an employee, I've always been a sales engineer. So the original post was actually very informative for me as I'm not familiar with the inner workings of a code development team nor the frustrations of its members.
I'd be curious then, about what you think about this? http://loup-vaillant.fr/articles/suboptimal-processes
(Disclaimer: this one is totally sour grapes. I left. Though I did learn afterwards, that this project was a significant net loss to the company.)
After reflecting on the responses here and amazingly balanced upvotes and downvotes I've received (it's hovering between 2-4, but changing frequently), I think actually what's going on is that I'm just annoyed by the OA's particular strain of satire. I guess when I read this heavy handed yes-is-no satire it just makes me angry that the author isn't just giving it to me straight. Whereas great satire has a unique thought-invoking quality, this type just feels like an overdone trope.
I'd get it if the piece were "21 Ways to Minimize Employee Retention, like my former manager John Q. Smith did at CompanyCo", but as just a list of silly shit management does, I don't know why you'd have a "no hire" level problem with it.
>However in terms of practical changes, this post can neither benefit you nor anyone else.
Your post can't benefit introverts the same way his can't extroverts like you.
Anyway, i'd argue that it isn't actually bad retention policies. They are actually quite good at retention. It is just that it retains the specific kind of employees, the ones that "learned to stop worrying and love ... err... it is actually enough just to stop worrying" (speaking from my personal experience - had worked and is currently working at such a place where the "not worrying" is the fundamental skill and the most of the current employees in the department have been here for 10+ years)
* Have CEO live in another state, but not let his absenteeism stop him from insisting the entire company change
* Throw chairs at people who want to release the code after it's feature complete [Ah, TJ, I wanted to give you a big ol' bear hug for finally pressing the point after hitting feature complete more than 10 times and us never releasing]
* Be constantly high on amphetamines
* Steal the identity of a math textbook author in suburban California
* Announce in a quarterly all hands meeting that it was a positive quarter because, even though the business lost money, and lost money faster than last year, the negative year over year growth got smaller (read: closer to zero), so you'll be losing the same amount of money YoY in no time!
If you guys think it's a harsh reality that companies do the stuff in this article... I guess I am curious if you guys have worked at venture funded startups?
I've worked at three including one medium sized exit and never experienced what's in the article or your post.
1. Create a constant state of uncertainty. Make promises you don't keep, and never explain why. Announce stuff that never materializes.
2. Don't give people any chance to successfully complete anything they start. (Simplest way: keep moving the goalposts.)
In my experience, people can take any kind of abusive crap, but uncertainty plus the inability to do anything worthwhile will either get people to quit or put them on the shortest route to a burn-out.
And the worst part is, these two ways are often not applied by malicious douche bags, but simply incompetent management. In the start-up world these are often entrepreneurs with no idea of and a total lack of empathy with what it's like to be an employee.
"14. Humiliate people in public."
Sounds like a personality disorder, possibly anti-social personality disorder. See: http://www.wikihow.com/Spot-a-Sociopath, in particular:
"9. See if the person makes uninterrupted eye contact. Sociopaths are known for giving intense uninterrupted eye contact. The person stares because he or she is completely comfortable staring at people to make them uncomfortable. Staring at others intently is a way to further his or her own means."
"1. Look for a lack of shame. Most sociopaths can commit vile actions and not feel the least bit of remorse. Such actions may include physical abuse or public humiliation of others."
22. Allow IT, regulatory, & quality to inhibit your productivity to the point that you work on side projects just to know what it's like to ship something.
Yeah, I'm currently interviewing else where.
19. Give estimates without consulting the people that are actually doing the work. When they disagree with the deadline, shrug your shoulders and explain that it can’t be changed and people are expecting it to be completed on schedule. Repeat every time.
20. Break the above cycle when everyone is about to quit. Get estimates down to the hour for every single feature. Assume no slippage. Add features but do not adjust schedule.
This happens a lot. It happens at my company when you screw up a build.