The CIAhas an old manual for subtly sabotaging infrastructure in occupied nations. The section on office organizational sabotage is a riot and the inspiration for this document. Here are techniques for sabotaging tech offices in the new millenia. I never did any of these, but I swear I experienced them all. Obviously, this is for entertainment purposes only.

This work is available under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Email

If an email has two questions, only answer one.

The Army has a term: BLUF– bottom line up front. Start your paper with the recommendation or result. Instead, you should go with the BLAB – bottom line at bottom. Keep the conclusion at the bottom.

Hide action items within long explanatory paragraphs.

Don’t read emails farther than the first sentence. Write long replies that bring up points already addressed in the original email. This retards progression of email threads by focusing discussion on trivial back-and-forth of basic points that don’t need discussion.

Important emails should strive to be a wall of text.

Add as many people as plausible to an email thread to ‘Loop them in’.

Fork email chains by removing recipients before replying.

If one co-worker speaks poorly of another co-worker in an email chain, later add the besmirched co-worker to the email thread without removing the message history.

On emails with a call to action and many recipients, don’t specify who the email is intended for.

Reply-to-all asking to be removed from an email chain.

Require daily status updates from all members, in email form, to a group email. Team members will waste time being compelled to write status updates that no one will read.

Communication

Ensure that every meeting has at least one remote attendee. Do not attempt to dial in the remote attendee until everyone has arrived and is ready to meet. Have everyone watch you struggle with the conferencing system. Alternatively, start the meeting without the remote attendee. Ten minutes later, bring in the remote attendee and ask everyone to start over again.

Make sure meeting rooms only have VGA-to-DisplayPort adapters and that the projector accepts neither.

Never bring your USB-C adapter to a meeting so you can spend ten minutes running back to your desk to get it. Alternatively, say you’ll just wing it or people should just crowd around your computer. Have as much complicated data in your presentation as possible when you do this.

Stifle open discussion by needlessly including C-level employees.

In a meeting with a contentious item, bring up the item again if the meeting becomes too productive.

Create acronyms for processes and things that don’t need an acronym and are highly specific. Use these acronyms in presentations and emails. When asked what the definition of the acronym is, make the employee feel stupid. Create an artificial divide of people who understand the acronym meaning and those who don’t.

Create acronyms in one department that conflict with acronyms in other departments. Cross-departmental meetings will become mired in misunderstanding. (Example: PM)

Slow productivity by being overly inclusive on your meeting invites. People feel compelled to go to meetings they are invited to.

Complain that you weren’t invited to meetings you didn’t need to be at. When invited, derail the meeting with questions and comments that help nobody.

Haggle over the format of meetings while in the meeting.

Book meeting rooms and don’t use them so others can’t meet.

Construct burdensome procedures and rituals for even the most trivial meetings. For example, vote on a note-taker.

In important meeting rooms, make sure every whiteboard marker is dead. Remove erasers from the meeting room in case a working marker is found.

Projectors should never be in focus or level.

Refer important decisions to committees. Include as many people as plausible. Make chronically unavailable workers be required attendees so the soonest available meeting time is two weeks away. A day before the meeting, reschedule it starting the whole process over again. Eventually refer the decision to an email chain after acknowledging the difficulty of meeting. Omit at least one key decision-maker from the email chain.

In a meeting where an action is decided, declare you have already done that item. Do this for every item. This ensures that no one actually takes responsibility for executing the action.

When a meeting results in agreement, dispute the agreement at the next meeting. Do not document this agreement or disagreement.

In a meeting where the status of an action is needed, claim it is not completed because it is taking longer than you thought or you are just about to get to that item. Repeat this as long as plausible.

In meetings, ask questions that you already know the answer to. When someone risks an answer, quickly reveal the correct answer in a way that makes the person feel foolish.

Leave food in the meeting room trash so that further meetings suffer an unpleasant odor. Consider leaving the food underneath the trash bag so it remains after janitor visits.

Put ice cold drinks on the meeting room table so the condensation leaves water after you leave. Spill your drink a bit if you can, but do not clean it up.

Always be eight minutes late to a meeting. Always have your meeting run over schedule if someone is waiting for the room.

Schedule long one-on-one meetings in large meeting rooms so teams have difficulty finding meeting spaces.

On large campuses, make meeting room names completely unrelated to location or size.

If there is a particularly combative or pedantic employee, ensure they are at every important meeting.

In presentations, the first few slides of your presentation should be a long winded biography.

In presentations, add lots of text to your slides and read them, verbatim, to your audience.

In presentations, only entertain questions at the end.

When attending a presentation, focus your attention towards your phone or laptop to demoralize the speaker.

When attending a presentation, waste attendees time by interrupting the the presenter to ask questions that only apply to you.

After a presentation, anonymously leave ambiguous but alarming feedback. “The speaker was culturally insensitive.” This mires the organization in fruitless retrospective.

All-team meetings provide the most leverage for a saboteur to waste productivity. Ask long-winded useless questions.

Forget to include remote team-members in meetings or other group activities.

In meetings where a remote team-member is attending via video, have attendees oriented facing away from the camera. When the remote team-member speaks, use body language that gives the impression that the team-member is an unwelcome interloper.

Create your own Dropbox / Box account outside of the organization. Insist on storing sensitive and important documents here.

If the organization uses Microsoft Office, make everything in Google Docs (or vice-versa).

Ensure that meeting rooms always have one or two less chairs than their declared capacity.

Bring up items that attendees are uniformly passionate about but unlikely to happen. A large portion of the meeting can be wasted with attendees ‘day-dreaming’.

Many chat applications (i.e. Slack) have very liberal naming policies allowing you to impersonate other employees. You could conceivably name yourself identical to an engineer and persuade victims to upload broken configurations to important networking configuration. Alternatively, you can intercept private messages intended for the actual employee and sow chaos.

Write critical documentation in the font Vivaldi.

Slack

In Slack, rename yourself to the CEO’s name and make your avatar the same as the CEO’s. Message IT with a list of people who were terminated and need their accounts disabled immediately. Start terminations with the team most likely to recognize your ruse.

Don’t use channels, instead direct message multiple people for everything. If anyone closes the multi-DM they will never find that conversation again.

Always use multi-DMs when a channel already exists with the exact same group.

Start direct messages with ‘Hi, can I ask you a question?’ and then don’t say anything for 5 minutes.

Use Slack workflows to spam a channel with thousands of MC Hammer emojis if someone says a common word like ‘stop’.

Integrate your build system outputs with the most productive Slack channels.

Politics & Workplace Culture

Bring politics to work.

Accuse various teams / processes / leaders of systemic racism in public forums.

Update your preferred pronoun in Slack to ‘Make America Great Again’.

When confronted about stirring up political conversation in the office, remind everyone it is important to ‘bring your whole self to work’.

IT

Name servers after their physical location. Later, insist the servers be physically moved requiring either a toilsome rename or accepting names that are misleading.

Sabotage automation of systems. When you fix a system, don’t update the setup scripts to include the fix.

Set ‘lockout on failed logins’ to as few attempts as possible ‘for security’.

Password policy: Exactly 15 characters. Require upper, lower, alpha, numeric, special. Password expiration 30 days. No re-use of passwords.

Make unlocking user accounts require an employee who is overburdened or hard to find.

Setup as many systems as possible to run using one set of common administrator credentials. Make migrating away from this setup as scary as possible ensuring it’s perpetual continuation.

Turn off logging ‘to save disk space’ or turn on verbose logging for everything ‘for security’.

Require the use of a flakey VPN client to do anything.

Require opening a ticket for anything. Staff the ticket processors with inexperienced employees.

Shuffle the labels on servers, networking equipment and networking cables. This is especially effective prior to maintenance.

Replace CAT6 cables with CAT5 cables.

Most system administrators assume network port speeds are set to auto-negotiate. Manually set the port speed of networking equipment to right above their current usage. As usage grows, the system will be impacted by the port speed and provide a difficult to discover bottleneck.

Systems that have redundant power supplies should have both power cables plugged into the same power circuit.

If a datacenter rack has two power strips, ensure that the failure of one will cause the resulting load to exceed the capacity of the other.

Procrastinate the application of security patches. Claim system stability concerns.

Make office Wifi burdensome to join. Require lengthy bureaucratic processes.

Argue for moving infrastructure to the Cloud but always suggest the Cloud vendor least likely to gain market traction.

Move the labels on ethernet jacks throughout the office.

Connect one ethernet cable to both jacks on an ethernet outlet. With luck, this causes a switching loop.

Lose the root password for networking equipment. Turn off remote administration.

Install remote management and virus scanning software on everyone’s PCs that uses 100% CPU when they are trying to get work done.

Morale

Put people on-call for systems they have no control over.

Publicly promote the least respected employees.

Treat every service incident, regardless of severity, as a potential disaster. Entertain wildly improbable scenarios to foment hysterics.

Change priorities weekly.

Leadership

Leave who has authority to do what ambiguous.

Hire and promote inexperienced, unpleasant employees.

Strive to make meetings end without a clear action.

Be unavailable and/or remote to subordinates.

Overrule detailed research findings with ‘your gut’.

If there is an employee that understands the whole system architecture, contrive a reason to fire that employee before they disperse the knowledge.

Fire people who brave an opinion so that no one feels safe expressing ideas.

Don’t provide overall goals. Provide detailed directions that doesn’t allow flexibility or creativity.

Acquire companies that are bad at what they do.

Environment

Come to work sick.

Cough loudly at your desk. The louder the cough, the more discouraging it will be to everyone who came to work to do work.

Put garlic in the air vents.

Party balloons near a vent or window will set off motion detector alarms all night.

Workplaces should be either too hot or too cold. Switch frequently. Dispute the temperature being unpleasant when someone asks to change the thermostat.

Set the thermostat to unreasonable levels then lock it in a clear plastic case.

Have two rooms be controlled by one thermostat.

Place programmers in large open areas with no walls, privacy or sound abatement. This greatly reduces developer productivity by eliminating the ability to focus on a task. If confronted, claim that a white noise generator resolves the issue.

Mechanical keyboards provide a loud distraction.

Keep a gym bag with foul smelling clothes under your desk. Leave your workspace so no one can complain to you.

Leave only enough toilet paper on the roll to hide the fact that there is no more toilet paper.

In meeting areas, leave a big bowl of unsweetened chocolate.

COOK FISH IN THE SHARED MICROWAVE

Cook popcorn in the shared microwave

Software Development

Insist that any code you encounter, no matter the quality, is trash and must be totally rewritten.

Wait until a project has been built and is in review before declaring that the architecture is all wrong.

Insist that new problems cannot be solved without adding a new technology to the stack. Strongly argue for a technology that happens to be immature and whose failure modes are not well understood.

Bloat project scope with unnecessary security requirements. For example, require that every action be comprehensively logged with a multi-year retention period.

Advocate for writing custom database drivers. Implement resulting driver poorly.

When possible, tie projects to custom forks of largely used mission critical systems like MongoDB or MySQL.

Aim to make code difficult to comprehend. Make as much code fit onto one line as possible.

Compound the complexity of trivial code with parallelism and async.

Use the popular motto ‘Move fast and break things’ to justify why your code breaks things.

Insist that you need ‘the right tool for the job’ and introduce a new technology that no one knows how to use.

Use the popular trend of allowing developers to write in any language as a justification for writing a critical system in a language no one else has the knowledge or toolset to use.

Insist that transactional data should be stored outside of a transactional datastore because ‘transactional systems can’t scale’.

Insist that high volume, low value, non-transactional log data is stored in an expensive datastore like SQL Server. This causes high resource consumption and the need for tens of thousands of dollars of unneeded SQL Server licenses.

Don’t sanitize inputs. Alternatively, wrap inputs in a function that is named to give the impression of sanitization but actually does another trivial task like removing vulgar words.

Write custom security algorithms.

Marry other team’s projects to unstable libraries and dependencies.

Marry important business objectives to unstable software projects.

Wildly inflate estimates of any project using unquantifiable justifications such as ‘technical debt’.

Attempt to introduce as many external dependencies as plausible to any system you encounter.

Block every project by insisting that there is not enough testing. Do not provide clear guidance for when there is enough testing. Do not provide feedback until after a lengthy testing cycle.

Design your databases in-efficiently so that only after considerable time has passed and the database has become mission-critical and harder to modify is the inherent problem revealed. The fix will be burdensome and time-consuming to implement.

Do not check in code for a pull-request until you have accumulated a few weeks worth of work.

Delay progress by being overly critical with pull-requests and work reviews. Insist on perfection. Be burdensome with unimportant matters of code style.

Reject pull-requests and leave no feedback or explanation.

Derail technology discussions by making confident, yet false, assertions that cannot be disproven without further offline research. When later confronted, claim ‘that’s not what I said’.

As a software project nears the critical final stages, send the best programmers to a conference for a week.

Assign the most inexperienced programmer to infrastructure.

Mid-project, replace one inexperienced programmer with another inexperienced programmer. This compounds the negative effect of inexperienced programmers.

Mentor junior programmers with anti-patterns. See above list.

Hire junior developers who find joy in using new tools, languages and libraries. Put them on a team that is well established and values stability.

Documentation

Do not comment any code, especially complex or sensitive functionality.

Do not write documentation. If confronted, claim you will write the documentation when the project is complete– fail to do so.

Put your documentation in a separate storage system that uses its own set of logins. Make yourself unavailable when providing logins and support for this system.

Heavily document self-evident processes while completely omitting critical ones.

Write documentation in the style of a long winded story.

Keep emergency response documentation long-winded, out of date, undiscoverable and in one unreadable paragraph.

Do not update documentation when a system changes.

When you ask for help on a forum but eventually figure out the solution on your own, don’t update the forum with the solution. Instead write ‘Nevermind, figured it out.’

Store documentation in unsearchable formats like jpgs or PowerPoints.

Store frequently updated diagrams as jpgs to make updates difficult.

Frequently move the storage location of documentation and architecture.

Gather a committee to create emergency processes. Weight the committee with people who have never or will never be responding to emergencies. Ensure that everyone’s opinion makes its way into the document. If the meeting is one hour, spend 45 minutes on the social media strategy. Ensure the document is a minimum of 30 pages and is front-loaded with pages of ‘Introduction’ ‘Purpose’ and ‘Stakeholders’ exposition.

Use a different chat system than all the other teams. Insist that yours is better and that everyone else should migrate. This also works with file sharing and collaboration systems.

When the team has a shared document space, do not use it. Send a document over email or especially slack so it can’t be forwarded. Only send the changed document to a subset of people it’s needed by. It’s also helpful to use v4, arbitrary dates, and people’s names in the file name. Add FINAL whenever you are sure someone else will change it later.

Always send Keynote files to PC users and Powerpoint to Mac users.