
Updating classic workplace sabotage techniques - cstross
http://www.antipope.org/charlie/blog-static/2016/05/updating-a-classic.html
======
thedevil
I'm a career changer from actuary to software developer. The most shocking
part of the career change was open office arrangements.

Both careers are technical and require both concentration and collaboration.
Actuaries tend to have their own cubicles (offices for mid-level and higher).

Software developers require much more concentration. So I just assumed that
the virtually all software developers would have their own offices because a
solo cubicle seemed inadequate for most developer jobs. And of course, who
would be dumb enough to use open office for developers? ... well, I got a
little surprise.

Everyone tries to undo the damage of a bad floor design with expensive
headphones, but it's just not adequate.

~~~
Baghard
[http://www.cs.virginia.edu/~robins/YouAndYourResearch.html](http://www.cs.virginia.edu/~robins/YouAndYourResearch.html)

 _Another trait, it took me a while to notice. I noticed the following facts
about people who work with the door open or the door closed. I notice that if
you have the door to your office closed, you get more work done today and
tomorrow, and you are more productive than most. But 10 years later somehow
you don 't know quite know what problems are worth working on; all the hard
work you do is sort of tangential in importance. He who works with the door
open gets all kinds of interruptions, but he also occasionally gets clues as
to what the world is and what might be important. Now I cannot prove the cause
and effect sequence because you might say, ``The closed door is symbolic of a
closed mind.'' I don't know. But I can say there is a pretty good correlation
between those who work with the doors open and those who ultimately do
important things, although people who work with doors closed often work
harder. Somehow they seem to work on slightly the wrong thing - not much, but
enough that they miss fame._ \-- Richard Hamming

~~~
nnq
It's slightly amusing that everyone seem to miss the huge difference between:

    
    
        A. Individual office with open door
        B. Open plan office
    

I'd imagine the ideal would be individual offices with no doors:

This would create a good enough sense of intimacy and would be obvious to
people that when they pass the space of you non-existing door they are
entering _your space_ so they should have _a reason to do it and you
acceptance._ And of course, having an actual _separate_ ceiling atop your
office is important - the visual part matters, we need the feeling of "private
cave" even if we agree to share it most of the time. And open space above only
brings anxiety and makes you feel that you are in an open savannah and a
predator can jump at you from behind the bushes anytime.

But of course, we live in a _plentiful_ age, _obsessed with efficiency_ (oh,
the bitter irony of the contradiction...), so all that _wasted space_ and
_extra paid on rent_ because open-office spaces are probably cheaper is a no-
no...

~~~
greenyoda
_It 's slightly amusing that everyone seem to miss the huge difference
between: (A) Individual office with open door (B) Open plan office_

Exactly. And Hamming didn't work in an open plan office at Bell Labs. The fact
that he writes about open vs. closed doors implies that they had offices with
doors.

 _" I'd imagine the ideal would be individual offices with no doors"_

Doors are very useful to have, even if they remain open most of the time:

\- Closing your door allows you to have a meeting with a couple of people in
your office without disturbing your neighbors.

\- If you manage people, you'll need to be able to have private conversations
with them (e.g., performance reviews).

\- Sometimes, you really need to concentrate on a difficult problem without
interruptions.

\- You'll occasionally want to be able to have private, personal phone
conversations, e.g., with your doctor.

~~~
nnq
> Doors are very useful to have

Then I'd use them as some kind of status token, to gamify things a bit.
Mangers would have offices with doors by necessity, for private conversations
with employees etc. And for the rest, if you are a lead developer, or tech
lead or senior developer, than you get a door added to your office. Otherwise
the hinges stay, but no door... like a hint of "when you'll get better, you'll
get that door" :)

~~~
chris_wot
An "incentivise the workforce through privacy deprivation", eh? I'd probably
take it a step further - open plan toilets. Some employees spend far too long
on the John. You can't stop them from going, that would be gross and
impractical. But you can use social engineering to help them remember they are
there to _work_ and to do so _collaboratively_.

I can't tell you how much time I've lost to the porcelain throne! (I never
measured it) but I do know that I want to get ahead, and when I get to do a
crap in a cubicle with a door, I'll have _made it_!

P.S. This is why wifi and laptops are so great. A lot of thinking time can be
had on the dunny. To really get your creative juices flowing, encourage your
employees to think about direction on the bog. You could get your next Gmail
there. Think of it as 10% time, without need to allocate the 10%. Your
employees will thank you!

~~~
SmellyGeekBoy
Or just kill two birds with one stone and swap all of their chairs for
toilets!

~~~
chris_wot
The CEO could be given a squatty potty instead of an executive chair. It's
doable.

------
tyre
1) Promote based on tenure. If they found your company first, they're a priori
more dedicated and therefore better qualified to lead.

2) Promote into/within people management roles based on their skill as an
individual contributor. E.g. the better the programmer, the better they will
be at managing programmers.

3) Create a set of company values vague enough to be meaningless. Enforce them
selectively and only when convenient.

4) In the name of inclusiveness, expand meeting invitations to anyone who
could possibly be affected by anything talked about. Refer to them as
stakeholders. Be sure to include anyone whose job is unrelated but may be
interested or have an opinion.

5) All goals should be subjective. The subjective meaning of the goal should
change based on timing, external factors, mood, or self-confidence. If you
aren't happy, someone (else) is doing something wrong and you should
immediately switch directions. This is especially important in hiring.

6) In all meetings (see 4), require consensus.

7) Set individual performance metrics based on effort. Strong indicators:

\- Individual sends emails late at night

\- You see individual in the office late at night/early in the morning

\- Individual speaks frequently in meetings

\- Individual always seems so busy

8) Hire based on pedigree, especially from names you know. If they did not
attend the Tier 1 school (Stanford), they're probably not an A player.

Recruit from companies with entirely different problems from your own. For
example, if you're a small startup, target executives at Google so they can
make you into Google. If you're a large company, acquihire small startups to
inject agility and hunger.

~~~
cookiecaper
Great list.

Some general commentary: companies don't get this way because people are
stupid. They get this way because people hyper-optimize for their own self-
interests. Everything on this list is a way to show off, suck up, or CYA, all
of which occurs because people want to stay employed and get promoted, and
they implicitly optimize for more immediate, local rewards like positive
social feedback from the colleagues they see on a daily basis.

Abstract and macro-level concepts are difficult to grasp and people have soft,
differing opinions on them. However, people who work with you daily will come
to "know" that you're a super hard worker if you're sending out emails at 4am.
Including the company's Controller in a database schema design meeting not
only gives you a chance to demonstrate your know-how to someone else in the
organization, but also wins points for being careful, considerate, and
cautious.

When promotion time comes, the less-visible heads-down coder who's been
working hard and churning out bugfixes gets a lot less credit than his more
boisterous, gregarious counterpart, who's been more focused on grooming
personal biases in his favor than actually plugging in commits.

In theory a good corporate leader is supposed to make sure this kind of stuff
_doesn 't_ happen, but they're only human, so really 99% of people operate
this way.

What it translates to is that if you want to be a successful employee,
remember ABC: Always Be Campaigning. Your primary job duty is popularity.

~~~
yuhong
That is why focusing on the performance of the team is probably a better idea.

------
gabesullice
A lot of these read more like workplace complaints and poor management
processes. The point of the original was how an individual already on the
system could perform small acts of sabotage.

My list would be: 1) overestimate small tasks 2) Corollary to #1,
underestimate large tasks 3) Find reasons to take the overestimated tasks and
perform them slowly 4) Encourage your colleagues to take the larger tasks 5)
Encourage bike shedding. Frequently evaluate your code standards. 6) If you
are in the position to do so, enforce a terrible naming standard. 7) Write
slow tests 8) Write useless tests 9) If you notice a coverage gap, try to
introduce a subtle bug

As a manager: 1) Discourage specialization in favor of "flexibility" 2) Assign
tasks to those with the least domain knowledge, within reason 3) Avoid letting
more than a single developer work on a particular system/increase the "bus
factor" 4) If you are able, under promise and under deliver 5) When brought
new ideas or are asked to use new tools, be very encouraging but say you need
approval. Never ask for approval.

~~~
karmacondon
The upvote button wasn't enough for me. Thank you for extending the ideas of
that work place sabotage concept for modern tech work, like Stross implied he
would. I'm not sure what to really learn from this sabotage idea, but your
comment pointed out many of the obvious flaws in how things are done
currently.

------
skrebbel
Am I the only one here who doesn't understand posts like these? Anyone who's
had a job or read a Dilbert comic once or twice can come up with lists like
these.

The difficult part is doing all of it right.*

Look, I appreciate the history here, but nothing in the article ties back to
actual planned sabotage. Do companies actually do this? Are top managers paid
by competitors to break the companies they run? I mean, nearly all items on
this list require C-level executive powers to effectively implement.

In all honesty, it feels to me like this article is more about how happy
Stross is about his career change than anything else. That's a perfectly good
topic, but can we turn this around? What's good, actionable, advice for
(aspiring) managers, founders and employees? What's the oppposite of active
sabotage? And can we encourage active, constructive anti-sabotage without
becoming a creepy cult?

*) HN used to have lots of submissions about how to run companies right. Is it just me, or have those disappeared somewhat?

~~~
ghughes
> HN used to have lots of submissions about how to run companies right. Is it
> just me, or have those disappeared somewhat?

I interpreted this as being one of them.

~~~
huac
How? He provides no tips or guidelines for what _to do_ , only some snark
about what _not to do_.

~~~
a3n
"Do Not Enter" street signs are useful.

------
vertis
My problem with posts like this is that it's a vehicle for bashing the
currently accepted practices.

Here are a few of my favourites in no particular order:

* Stand ups are bad - Let's be frank, I'm belting out code so quickly that staying on the same page as everyone else is just not worth the time anyway (at the speed I'm going it'll be done tomorrow anyway).

* Pair programming is bad - when was the last time _I_ caused a bug, right? Or for that matter hit a problem I couldn't solve, and wasted time having to research the solution. Never, right? Right...ohhhh look at the cute picture of my niece on Facebook.

* Open plan offices are bad - I'm super important to the company, the company would break if I went away. I'm so much of a star that I should have the best office. Not to mention, I need somewhere to put all my trophies.

* Meetings - don't get me started on meetings. BAN THEM ALL. There must be a better way to communicate? Email? Ummm, yeah Email, wait, no, I'll come back to email. I know, lets just have someone decide on the direction we're going to go and write it on a stone tablet, that'll save some meetings (I'll get started on the tablet right after I finish here). I mean lets think about it, why do we need to coordinate anything? I'm the rockstar and if you just leave me to belt out the code it'll all come together...what do you mean other parts of the business need to do things to get ready?

* Emails - I get too many of them. For stupid things too. Ops alerts, customers asking questions, internal announcements, travel itineraries. Being included on email chain discussions about direction? Who needs that. What do you mean you made a decision without consulting me? Now we have to start over with the direction _I_ want to go in.

And I'm out of time. Off I go to my lean, agile, open plan job.

~~~
kevan
>Stand ups are bad - Let's be frank, I'm belting out code so quickly that
staying on the same page as everyone else is just not worth the time anyway
(at the speed I'm going it'll be done tomorrow anyway).

Could you elaborate on this? I find standups most useful when we're working on
small widgets of feature work precisely because we move so fast. Standups keep
the business side in sync with the code we're putting out (e.g. features x, y
ready to release, expecting z next week). It gives them a tighter feedback
loop in case they need to manage expectations or coordinate with other groups.

If we're working on meatier chunks that take longer then we back off to a pull
model. When someone wants to know they ask, but daily standups aren't very
helpful when updates sound like "Working on <huge_feature> for the forseeable
future"

~~~
vertis
Yep agreed. I was finding arbitrary reasons to rag on stand ups to illustrate
a point. You could absolutely write it the way you just said it and be even
better.

------
DanBC
1) Make people clock in. A local aerospace company used to make people clock
in, which is bad enough, but they had to clock in at 8:42 because
$BUREAUCRACY.

2) Have a small room for tea breaks. Split the workforce into two groups.
Schedule one to end at the same time as the next one starts. (Teabreak for
group A ends at 10:00 am; teabreak for group B starts at 10:00am;) This causes
disruption and disgruntlement between people trying to wash up their cups and
people trying to make their tea.

3) Allow some people to have cigarette breaks. Do not allow anyone else to
have anything similar.

4) Occasionally drop in to the small room during teabreaks and have an
important conversation, then allow that group an extra 5 minutes for their
break but make sure the next teabreak group does not have that extra 5
minutes.

5) Observe what side of the desk people prefer to have their telephone. Tell
them it's the wrong side, and that they must have it on the other side. Switch
it for them. A surprising number of people don't just walk out here. The ones
that stay? YOU HAVE BROKEN THEM AND VICTORY IS SURELY YOURS. CONTINUE TO CRUSH
THEIR SPIRIT UNDER YOUR BOOTHEEL.

6) Tell someone that you're going to give them a payrise if they meet some
vague but easily achievable criteria. Then, when they've achieved that, tell
them that you hadn't promised the pay rise, and that their 360 feedback is
disappointing this month. Especially because they keep moaning about the
generous pay.

There's probably plenty of good material in "Processed World"
[https://en.wikipedia.org/wiki/Processed_World_(magazine)](https://en.wikipedia.org/wiki/Processed_World_\(magazine\))

~~~
JetSpiegel
[http://www.processedworld.com/Issues/issue29/i29down.html](http://www.processedworld.com/Issues/issue29/i29down.html)

Thanks for that link.

------
rdiddly
I declare false advertising.

Q: "How can we sabotage stuff?"

A: "Here's a bunch of stuff I think is messed up. Leave your own complaints in
the comments."

I am disappoint. No creative sabotage ideas here, only observations of stuff
already going on that we think is "wrong." Now granted, when looking for tips
on how to fuck shit up, you can look at actual fucked-up shit and get ideas.
But I guess I was hoping for something more creative. And yeah not the
supposedly hilarious hahajoke that "Golly things are so messed up we can't
even tell if they're inept or saboteurs," and not more complaints about "If
only the world listened to my brilliant ideas about how to do things the
'right' way (my way)." If I had a dollar for every asshole with an opinion...

~~~
chippy
It's because to admit to themselves that someone would want to sabotage a
technology company would be to admit something much more troubling.

There's no reason, in their healthy minds, why someone would want to sabotage
their IT company.

For me, the real interesting question is why would someone want to sabotage my
workplace.

------
klenwell
A corollary to #3:

It is also the job of Human Resources to ensure that the company scores as
highly as possible in the local business journal's annual edition of the Best
Places to Work. Here's a link to an "anonymous" survey with a unique ID
embedded in the URL. We strongly encourage you to fill it out.

------
EthanHeilman
>"Programmers don't need root/admin access to their development environments.
Marketing, however, need to be able to manage the CRM and should have global
admin permissions across the network."

This!

Air gap developer workstations, have a formal procedure including a detailed
approval form which must include a justification and must be reviewed and
signed off by C-level for moving information/software between the outside
network and the inside network.

~~~
JetSpiegel
Include clauses on the contract that forbid you from installing any kind of
software on work machines, and at the same time provision work machines with a
clean Windows 8 install. Not even Notepad++, it's notepad.exe for C# or
violating the contract.

------
gonyea
You don't need to sabotage competing tech companies. They sabotage themselves
just fine.

\- Byzantine hiring practices. Create engineering teams that are 95% new
college grads. They're the only ones who'll suffer your BS, while having no
experience to call upon in challenging decisions.

------
F_Catalan
Pile on every cargo cult "quality assurance" technique until everybody keeps
getting glowing performance reviews about how they helped implement the neat
SWOT matrix that pointed to the need for better performance reviews whose
consequence will make clear the path to even better SWOT matrices that will
discover that more extensive performance reviews would result in...

~~~
a3n
I call this work about work.

------
alva
Researching leaked/de-classified governmental documents can be incredibly
interesting, especially if its from a 3 letter agency. Tons of practical
techniques can be gleaned from studying the content or citations, which is
easily translatable from warfare/diplomacy to layman personal/professional
interactions.

A basic analysis of a selection of the NSA/GCQH leaks showed a significant
number of citations to various marketing textbooks and public research papers.

------
nxzero
If someone was actively subverting an office it would rapidly kill a company.

Maybe this is the point, but to me all the comments and even article itself
read more like a commertary on common issues than an subversive insider
attack.

~~~
StillBored
I think the key is, small acts of sabotage that could never be considered
sabotage, so there isn't any chance of getting caught. Using a hammer that is
to small or adding another technology to an already complex technology stack
would never be considered sabotage. They likely wouldn't even be considered
incompetence, especially in the latter case if the person who added another
database/programming language/web toolkit/etc managed to achieve something
with in in a short period of time.

Instead that person is a hero, and the costs associated with the decision are
initially small and don't show up until that person is long gone.

Repeated a few times the small hits to productivity/quality/etc will result
significant lost ground. This is probably even more important long term in the
technology industry than it is to a war effort. The sides would have to be
close to evenly matched and the war would have to go on a long time for all
the little bits of sabotage to add up.

~~~
sten
> latter case if the person who added another database/programming
> language/web toolkit/etc managed to achieve something with in in a short
> period of time.

This one bothers me. It's brought up all the time. And I completely agree that
adding a new tool or feature adds risk and technical debt. But if there's no
other way to do it... I work in a corporate VBA shop. 90 percent of our work
in the last year was in VBA. But next year is looking like python, R and JS.
How? Requirements changed. We got handed some projects in machine learning and
we delivered, crudely but still. While in the technical sense we 'could' have
coded it all in VBA it's not practical in the slightest to do so.

~~~
StillBored
I don't think that is an argument against having a handful of technologies in
any given stack. I think its more an argument against having a lot of similar
technologies. For example, I wouldn't dream of trying to write a device driver
in anything other than C, but I wouldn't try writing a web back-end in C
either. OTOH, I promptly ripped out ~100 lines of perl one of our developers
insisted on dropping into a bash script a month before he left. Turned out the
bash equivalent was actually more concise and didn't require yet another
dependency on top of the 4 major programming languages (not including bash)
already contained in the project.

------
lisa_henderson
My favorite by far:

"Teams are better than individuals and everyone has to be aware of the
valuable contributions of employees in other roles. So let's team every
programmer with a sales person—preferably working the phones at the same
desk—and stack-rank them on the basis of each pair's combined quarterly
contribution to the corporate bottom line."

That is gooood.

I would quit, yet be so traumatized that my productivity would still suffer,
even at my next job. A double win for the enemy.

------
epalmer
Heros that invoke long days to save the company from a crisis are well
rewarded. The rewards are increased by a factor of two if the hero sleeps
under their desk in an old, moldy sleeping bag. The rewards are tripled if the
hero created the crisis him or herself.

Edit: typo

------
YeGoblynQueenne
>> we can go a step further and institute hot desking—we will establish an
average developer's workstation requirements and provide it for everyone at
every desk.

Oh, dont' we all wish. In practice, unfortunately, what's calculated is the
average office worker's workstation requirements. Then the developer gets
that, too, like everyone else.

~~~
JetSpiegel
8GB of RAM ought to be enough for everybody.

Even if you need two instances of Visual Studio on a VM.

~~~
YeGoblynQueenne
I was mostly thinking of monitor arrangements and how hotdesking messes with
that.

For instance, in my old workplace at Small Company™ I had two 24-inch
monitors. In my current (but only for another two days) workplace at Big Corp™
we're only allowed a single 19-inch monitor. Try running two instances of VS
on _that_. I have to constantly Alt-tab between browser and IDE, or stack
windows side-by-side, which is not optimal. Obviously, because we're not
allowed to keep anything on our desks, we can't bring our own monitor from
home. So.

>> 8GB of RAM ought to be enough for everybody.

And even that is not a given. Frex, in the last two years at Big Corp™ I had
to run a lot of machine learning algorithms - those were for my MSc course,
sponsored by my employer so it was OK to run during office hours. Now, my work
laptop has 12 GBs of RAM and it's noticeably faster than my home laptop, with
8 GBs and a similar processor.

And the fact that my office laptop has 12 GBs is a happy accident. Normally
you only get 4 GBs, 8 if you ask nicely. So I was going to ask for 8, but
let's just say I got lucky and the person who managed my request for the new
laptop didn't know much about RAM and suggested the 12-GB stick spontaneously
(and obviously I didn't turn it down).

But that's just a silly way to handle this sort of thing. Big Corp™ can afford
to give devs much more if it wants to. It just doesn't value them as highly as
other staff, who get the goodies _they_ value highly.

------
ipsin
It's also a little irritating that a couple of commenters focus on
minority/diversity hiring as a way to commit sabotage.

In my experience, people who might be called "minority" or "diversity" hires
tend to kick ass, possibly because they have put up with so much cognitive
bias about how they supposedly don't belong.

------
kmfrk
Maybe this one is too obvious, but:

11) Ping ping tables and other noisy shit.

~~~
1ris
tabletop football is mandatory for hipness.

~~~
kmfrk
oh my god

------
flerchin
Disallow email export. Delete all email older than 90 days.

~~~
cardiffspaceman
FRCP?

------
ipsin
I'm disappointed that this list seems to be made with the intent of describing
current practices, rather than how you can actually disrupt the workplace as a
saboteur.

The idea of promoting incompetent people still works. That's a gem.

For the small hammer/big hammer, simply choose technologies that are less
suited and make them work. Sorry, our CRM is also our mapreduce framework.
Make security an afterthought, and the world will do your sabotage for you.

~~~
cookiecaper
Surprisingly many get away with only rudimentary security controls. I have a
client that absolutely _refuses_ to upgrade off Rails 2.3, even to the drop-in
Rails LTS releases. Their "web director" keeps insisting that no one would
want to infiltrate and that there's no damage can be caused by a compromise of
Rails anyway.

The frightening incompetence of that guy is maddening. Incidentally, I don't
think he was put in place to sabotage the company. Just a case of well-meaning
nepotism.

------
nutball
I think the "sabotage" techniques suggested by the author actually benefit
companies whose main product is built by intellectual labor. Companies care a
great deal about controlling workers: to get them in line, to squeeze labor
from them, to weed out motivated folks whose interests don't align with
profit, to shut down rabble-rousers, etc. Since the dawn of work, workers have
resisted working, and Agile, etc. are just the new strategies management use
to control this new group of creative workers.

I wish the author had addressed worker sabotage too. More on that here:
[http://thenewinquiry.com/essays/manual-
override/](http://thenewinquiry.com/essays/manual-override/)

------
protomyth
Pick vendors that ship patches to their enterprise software as a 705 megabyte
SQL file that must be run and files that must be manually placed on the
machine.

You might think I joking, but I'm not.

~~~
JetSpiegel
That's child's play. Here's a much worse true story.

\- Spend a couple months researching existing solutions for a complex product
\- Pick the "perfect" one \- Ask for a quote \- Recoil in horror at the price
(about 1 weeks pay for that decision maker, in a 100+ people company) \- Steal
the damn JS library from their demo page \- Use it on the product \- ... \-
Profit? Once they can sell this turd

------
rcarmo
I went through the second list and got a perfect 10 for one of my previous
positions and an 8 for most of the others. This is as realistic as Dilbert.

------
hackbinary
Give everybody in the company local admin rights. This will give all staff the
ability to experiment and learn more about technology. Since everyone now has
local admin and they can now manage their own computers, you can fire the IT
staff who previously managed these workstations.

~~~
1ris
This sounds like it will result in a better environment that there is in many
places. I have seen places with a strict "don't install anything policies" far
to often. (I have even seen terms that techincally forbade executables in the
home dir. For programmers.) Don't use anything you like. Or want. Or could use
to work more productive. Use the outdated debian version of the shitty
software that the benevolent admin choose for you. And good forbid you BYOD.
Or want to the admin to install anything else. Fist of all, the admin knows
best, second it's not in the debian repos.

Given you have backups and ensure they can't fiddle with the authentication
system: Go for it. It's like BYOD but with provided hardware.

~~~
hackbinary
We give our people who have reasonable need Local Admin.

Giving local admin to the non-technical staff who want to download 'free'
software (not FLOSS, free as in beer) because they think (at best) that they
are saving the company money, but instead infest their computer malware. Most
people are totally disinterested in their computing environment, let alone
managing it. We standardise on certain packages because there is utility in
having common programs from support, training, and administration points of
view, but ultimately if there is a good reason to get/use something else, we
will do that.

Furthermore, any user with a local admin access can use a Kerberos 'Golden
Ticket' leverage attack to gain full domain access across the entire realm.

Are you seriously telling me that you want the teller at your bank to have
local admin access to his workstation?

How about the person at the IRS/CRA/HMRC/<you government tax office> that you
just called?

Local admin has its place, and certainly the first test is that will the
person endanger their system by running dubious programs. The next question is
if that person does infect their system, can they clean up the mess
themselves?

We went from a situation where we had local admin across our estate where we
had at least one virus problem a week to one where I can not remember the last
time we had one. Finally, can you really trust a Windows workstation after it
has had an infection?

------
cdevs
Is my job being taken down by the cia? So many meetings and rules! This list
is epic I would expect mike judge to write t for Silicon Valley. As for its
usefulness in the real world the opposite of each rule should be shown to all
management as what to do.

------
rcthompson
Fortunately, someone already wrote the corresponding guide for software
developers: [https://github.com/Droogans/unmaintainable-
code](https://github.com/Droogans/unmaintainable-code)

------
yuhong
I wonder if there are companies who pick CEOs randomly from new MBA graduates,
and pay them an extremely high salary with no stock options or other
incentives. Or pick CEOs randomly from resumes submitted and trains them to be
professional CEOs.

------
davidgerard
As a sysadmin, I have long thought that the most effective workplace sabotage
I could do would be not to question anything I was told to do. A huge chunk of
my job is suggesting when things are in fact a bad idea.

------
ddalex
I'm weirded out by not seeing Intel mentioned here, as being the inventor of
cubicles, hotdesking, and failure to be in mobile business while having the
best phab tech out there.

------
wglb
See also
[https://en.wikipedia.org/wiki/Bureau_of_Sabotage](https://en.wikipedia.org/wiki/Bureau_of_Sabotage)

------
xerophyte12932
It's scary how many of these policies my company follows...

------
bitJericho
I'd rather have a closed door and office and a company wide IRC server.

------
tajen
1) Everything which doesn't have a rule should have a rule.

It applies to the kitchen policy, to the bathroom policy ("Keep the toilets
clean"), to the password policy. Initiate a company discussion to get
feedback, the exclude the black sheep.

2) Spread rumours about how the dept/company/sector is cutting jobs. It is
very important that employees feel they're in surplus so they'll work more.
Keep them upset about things, so they'll focus on that instead of programming.

3) Promote women. Don't help men to succeed or learn things.

