If you are committed to pissing off your employees, but can’t quite find the way to do so, you can follow these rules and achieve success.

Encourage proactivity: Management loves that word. It means that the employees don’t have to react, but to act in advance. This roughly translates into easier management. No documentation, specs or any kind of information needs to be provided to the employees as they will have to proactively seek for it.

Discourage excessive proactivity: If some employee still feels like doing things on their own, trying to document things himself to lower the learning curve of (your) future hires, develop an in-house tool to save (you) time or money or to do things like refactoring code or implementing agile methodologies, simply smash the enthusiast’s morale by drowning his efforts with indifference, corporate policies, lack of management back up and other tools at your disposal. Simply discard any suggestion on improvement; either say no directly, or say yes, yes and let it die slowly. Either way works fine.

Don’t let your managers get involved: Don’t ever promote any veteran team member, who’s apt to the task to a management position. Things might get too smooth, as that person might not only be able manage the team great but also have a deep understanding on the subject being managed. Simply hire someone from the outside who only knows about management (carrying around a leather agenda and/or an iPhone, arrange meetings, speaking about subjects with no expertise, without saying anything of value and still sound serious, etc). The less your manager knows about the team, the better. After all, it’s the soldiers who must receive the gunshots.

Give awards: Before you think this might drive someone’s morale up, think about the other team members (and other teams) who don’t get one. It’s a no brainer: one morale up, a lot down. Give it to the people who deserve it less: those who spend their time speaking about how great their work is instead of actually doing something. That will definitively piss off everyone else.

Sever their tools: If your employees need tools, like a computer, an operating system, a database, and some tools to work better, then the best thing you can do is to deprive them of these; not of all at once, but of one by one, to extend the agony. If they need commercial tools, say they are off-budget. If they need open-source tools, say it doesn’t comply with internal norm X and that it requires special authorization (which of course they will never get). Make them fill endless forms and write emails. Don’t renew their licenses. Make them work online on a server located in another continent with more than 10 seconds latency. Forbid the use of putty for console work. All gradually, while demanding the same results.

Spoil their focus: Make sure they are included in every possible, unrelated mailing list. You will make them waste hours of e-mail reading and manual filtering. Remove any abstraction layer that prevents them from knowing problems that don’t concern them. Your best weapon here is an open space (like a whole floor) where there are 100+ people working, without walls in the middle. Encourage loud ringtones of cellphones abandoned at their desks and coffee chats that distract others. Arrange pointless meetings and conference calls that focus around subjects that don’t concern them (thanks, vegittoss15!).

Hit their interest with a train(ing): Give them obligatory training on subjects that don’t interest them, and haveno interdisciplinary connection with their job.

Bug them: Make sure all defects are carefully prioritized as high. If someone breaks the code (specially if that someone breaks it repeatedly), don’t let that person fix the code they broke. Instead make someone else (preferably with no background on the subject) fix it in a very narrow timeframe. Let anyone assign bugs to anyone, without any knowledge of the developers available time. Preferably, in a system on which you cannot track who assigned it to you.

Before thinking it might not work, it will. It is based on a true story (it has happened to me).

Edit: As many people has pointed out (and they are right!) not every veteran developer makes a good manager (most don’t have the soft skills). To rectify this, I’ve updated rule #3. Thanks for the feedback!

No related posts.