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.
Whenever I want to show my team better ways of doing things, I always pick on my own code or actions as the examples not to follow (if I can find them--otherwise I'll make some up). Then, I try to find examples from their work where they've exhibited the behavior I'd like (again, making up examples if needed).
You don't want to be the guy whose code is called out as garbage, unless you're doing it yourself.
I hope your wife finds a job at a company with an adult management team. The stress level you get from an environment like you describe isn't worth the cost.
> 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,
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.
This one also hit home for me. Founder bitched me out with 25 or 30 people within earshot (open office plan) for no good reason. I took care of their complaint 30 seconds later. After three years of loyal service, that's the level of respect I get?
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!
Teasing, shaming and other forms of negative humor are very hard to do with a positive result. People are astonishingly different in what they can tolerate and how they respond. I suppose, with the right people, and the right team dynamics it can be OK.
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.
> Teasing, shaming and other forms of negative humor are
very hard to do with a positive result. People are
astonishingly different in what they can tolerate and
how they respond. I suppose, with the right people, and
the right team dynamics it can be OK.
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."
Appropriate versus inappropriate is irrelevant, in my opinion. Can it work? Yes. Is it more likely to backfire and make your team miserable? Yes. Is it something that creates a hostile work environment? Debatable, and definitely situational.
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.
Some industries seem to have a culture of harsh negative feedback given publicly and it seems to work ok, but then people have an expectation of that going in to the industry.
There is a difference between being shamed for breaking the build because you didn't run the test suite (and well knew that you should run the test suite) and being shamed for making an innocent mistake because you didn't know better.
I can see the rationale for a dunce cap in an equitable organization answerable to no one but itself. Like, say, a founding team of four engineers each with 25% equity.
22. Hire antisocial self-declared "rock star" employees who can't stand other human beings.
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 absolutelynothing to do except twiddle their thumbs.
29. Absentee management. Set no goals and assign nothing, yet give people the vague sense that they are always behind. Combine slack with a sense of foreboding.
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.
Therefore a wise prince will seek means by which his subjects will always and in every possible condition of things have need of his government, and then they will always be faithful to him.
Most people associate Machiavelli with a devious, twisted mind when he was actually simply a pragmatic. He is labeled as an amoral guy since he admits that violent or cunning methods are sometimes useful.
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.
I think the problem with most peer reviews in practice is that they typically are not actionable or even concrete. I used to have monthly 1:1's where I got feedback that wasn't "keep it up" less than 10% of the time. Not a negative experience, very positive actually, but a huge waste of time that seemed to exist just so the person I reported to could see he was in-charge.
With #22 I really believe that you should be careful. Introverts can easily be confused as anti-social. Now if they're a dick to everyone for no reason that's a different story.
There may be a story behind this post as it feels quite personal, but this is a pretty good composite of bad management behaviors. I see this more of a collage than a specific rant. I could be wrong, but I've seen one or more of these traits expressed by almost any supervisor I've encountered (not all the time or all at once).
Another - Reward hard work and delivery with another project quickly and as scattered. When one delivers a touch project in an impossible timeline, rather than changing anything management side, deem them the "saver" and give them bad project after bad project with shorter and shorter timelines.
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!
If you have to write this post to vent because you are stuck in a job you can't afford to leave and you are scared you'll be fired if you raise these issues to management, then so be it, write the bloody post and I hope you feel better.
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.
Knowing the author personally and having worked at the same company with him (he left there a long time ago). I can say it is neither. It was among the most broken places I've worked. The author himself is a great communicator and technical lead.
Perhaps we should accept the shocking reality that there are really startups this awful to work for :)
I beg to differ. I know more than a few technical people in management positions who read Hacker News religiously. If confronted with this list by an employee, sure, they may react defensively. But if they come across it themselves, they may find a few pieces of "advice" on the list that they've been following unknowingly and decide to change their ways.
There are a few on there that people may be doing without realizing. For example:
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.
Given enough naivete and inexperience, I can see a well-meaning and honest manager failing at some or all of these.
>We all know about broken management cultures that this post describes...
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.
Yours seems constructive to me and I don't read it as unprofessional in any way.
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.
Some of these issues I see has being very, very difficult to communicate to a boss. Others I can relate to and have communicated to management before, especially about open office plans and estimates, with the response being that it is just the way things are.
I don't understand your strong negative reaction to this. The way I read it, it is pretty much a (very) dry humor piece in which anyone who has been working in software development for any amount of time is likely to recognize most of the points listed as being real things that happen (but hopefully not too many at the same job).
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.
sounds like you're an extrovert and the poster is introvert.
>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?
> 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.
A lot of this applies even to non-tech jobs, I think employers got a little to comfortable with high unemployment. Watch the hilarity ensue when those demographics change.
"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.
#19 and #20 seems the most common issues I've had to deal with in development.
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.
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.