The Project Saboteur’s Handbook

There are many ways to sabotage a project. Recognizing them is the first crucial step to counter them. In this brief handbook I will present a number of ways of sabotage that I have encountered in various projects. This post is the saboteur’s handbook. The countermeasures will be saved for another post.

Enough of introduction. It’s time to enter the dark mind of a project saboteur…

The Project Saboteur’s Handbook

The key success factor to sabotage a project is to draw attention and drain energy from those areas that are important to make the project successful. Any behaviour that draws the attention away from important work or drains energy from the project is allowed. Use your imagination and creativity to make sure that you never miss an opportunity drag the project one step closer to failure.

Strategy Overview

To give some inspiration on how to make a project fail I’ll present some strategies in this handbook.

  1. Focus on border issues to prove your own “knowledge”.
  2. Ask questions that you don’t understand the answer to. Keep ask for clarification.
  3. Avoid documentation.
  4. Avoid clear decisions.
  5. Ignore tasks assigned to you. Extra efficient if combined with the two points above.
  6. Focus on other’s few shortcomings.
  7. Keep meetings unfocused and avoid agendas.

Focus on border issues

border-issueIn a project there are a few key success factors that will have the highest priority. Next in priority are important issues followed by the vast majority of relevant issues. Most projects will not have time to handle all relevant issues.

The saboteur should focus on the next level: The tiny border that is the edge cases that are ignored, but cannot be easily dismissed as relevant. Some examples of questions to ask:

  • Can you prove that there are no compatibility issues with patch KB12345 that was just released by the OS vendor? (Wading through release notes for OS patches takes massive time. Presenting proofs take even more time.)
  • What happens if a user enters digits in the surname field?
  • What changes will be required for the next version of Internet Explorer/Windows/whatever? (Pick anything that is still just a release candidate with limited information available)

These kind of questions are particularly efficient as they serve two purposes at once. They require attention and energy from the technical experts in the project as they cannot be easily dismissed without a proper reply. They also prove for management that the saboteur must have genuine technical knowledge to be able to ask questions that the technical experts can’t answer. The things is that no true deep technical knowledge is required to ask the questions. It only looks like that.

Ask questions that you don’t understand the answer to

Asking a question that indeed has an answer, but that you lack the required knowledge to understand the answer to will make sure that anyone is unbalanced. Ask how it comes that a HTTPS session is secure against eavesdropping when the algorithm is well known. The explanation of how the crypto algorithms works mathematically is complex. As soon as the maths behind the algorithms is mentioned, ask for a simple non-mathematical explanation. If you have anyone in the project that even knows the maths to explain the algorithms this will drive them crazy – simplifying them without loosing the point is terribly hard.

Avoid documentation

no-documentationDocumentation is your number one threat against sabotage. Try to keep documentation to a minimum. Official meeting notes that prove exactly what was said months ago kills a lot of creativity. Without documentation it is always possible to bend the truth to put blame on someone else. The easiest way to prevent good documentation from being produced is to offer to take meeting minutes and then simply ignore the task (see ignored task below). If you offered to send out minutes nobody else will bother to take detailed notes so there will be no written record.

Avoid clear decisions

Clear decisions are similarly bad for the saboteur as documentation. It’s much better to get vague discussions where nobody really can tell exactly what was decided and what should be done. Without clear decisions for the productivity of the technical staff on the project will quickly drop. Without clear decisions there’s also much more room for creatively destroying the project.

Ignore tasks assigned to you

Anyone that’s part of the project will get tasks assigned. The best a saboteur can do is to ignore all tasks. Don’t just ignore doing them. Also ignore any questions about them. Deny any knowledge of the task existing at all. If there is no documentation on the task being assigned to you there is a big chance that you will get away with it. Be as convincing as you can that you’ve never heard of the task. That will make everyone but the strongest leaders doubt that they are correct in that you had the task assigned to you.

Focus on other’s few shortcomings

There will be times when somebody finds out that you are hardly doing anything productive and tries to nail you for it. The best defence is to focus on that person’s shortcomings. Ignore the blatantly obvious signs that you are not doing your job and focus on any small issues in that person’s job. There will always be something. The less issues there are, the more ambitious person and the more painful it will be for that person to have the issues pointed out. Focus will quickly move away from your own failures when your opponents start defending themselves.

Meetings without agenda or structure

The key to productive meetings is structured discussions following an agenda. Do your best to avoid agendas. If the discussion is coming close to an end on a topic it is usually a sign that a decision is about to be made. In that case, you should quickly move discussion away from the issue to avoid a clear decision. With the right skills the same issues can be discussed again and again ad numerous meetings, without ever making any decisions or coming to any conclusion. It will be a perfect black hole for valuable project time.

Drain energy

Remember that the key success factor to successfully sabotage a project is to draw attention and drain energy from those areas that are important to make the project successful. Any way that works can be utilized. You only have to find one way to drain the energy. Those running the project need to prevent all possible wastes of energy. It’s a battle that’s very hard for them to win.

This post is part of the Project Saboteurs series.Project Saboteur Taxonomy >>

  • Pia Fåk Sunnanbo on 2013-01-04

    The items below may also come in handy for the Project Saboteur:

    (11) General Interference with Organizations and Production
    (a) Organizations and Conferences
    (1) Insist on doing everything through “channels.” Never
    permit short-cuts to be taken in order to expedite decisions.
    (2) Make “speeches,” Talk as frequently as possible and at
    great length. Illustrate your “points” by long anecdotes and accounts
    of personal experiences. Never hesitate to make a few appropriate
    “patriotic” comments.
    (3) When possible refer all matters to committees, for
    “further study and consideration”. Attempt to make the committees as
    large as possible – never less than five.
    (4) Bring up irrelevant issues as frequently as possible.
    (5) Haggle over precise wordings of communications, minutes,
    resolutions.
    (6) Refer back to matters decided upon at the last meeting and
    attempt to re-open the question of the advisability of that decision.
    (7) Advocate “caution.” Be “reasonable” and urge your
    fellow-conferees to be “reasonable” and avoid haste which might result
    in embarrassments or difficulties later on.
    (8) Be worried about the propriety of any decision – raise the
    question of whether such action as is contemplated lies within the
    jurisdiction of the group or whether it might conflict with the policy
    of some higher echelon.

    They are cited from CIA’s now de-classified “Simple Sabotage Field Manual”, available at https://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf. I think anyone who has participated in a large project has seen most of them in action.

  • Iris Classon on 2013-01-04

    Great post, laughed out loud when I read it, I’m rather tempted to print it out and send anonymous copies to certain developers I know :D

    I don’t know who said this, but I was once told there are two types of people those that give energy and those that drain you of energy. While we sometimes switch between being one of those types, people tend to me more one or the other. You want to surround yourself with those that give energy, and maybe not spend to much energy on those that steal energy.

    That always made sense with me, and I think the things you describe above are traits to recognize those people by- and avoid :)

  • Susann Ribbing on 2013-01-07

    Really witty Anders! Do i read some bitterness? Just don’t let them get at you, keep them close and make the them your allied, maybe even hostages.

  • Johan Svärd on 2013-01-07

    But hey, I think you’ve left out the Software developers! :)
    We’re quite good at this game too, given the chance…

    1. Always claim that you’re done with any specific task, until pushed. This makes everyone else distrustful AND you will eventually get the chance to pretend to be a victim of unfair treatment. “Why are you always asking me, this is harassment!”, can stall the best of meetings…
      Actual real life quote: “J, are you done” “Yes.” “Are you, really?” “Yeah…” “Are you?” “No.” “Have you started?” “Yes” “Really?” “Yeah…” and on…
    2. Grab work items that are central to the sprint/project/whatever and sit on them for a week or two. Then just return them, with a statement like: “I don’t know how to do this.”
    3. Appoint all the most intricate work items to the most junior/least suited member of the team. This can always be masked with the well intended: “This is good for his development.” Very often not for the project’s though…
    4. Intentionally misinterpret all questions/items in effect all texts that can be interpreted. Then do as much work as possible in the wrong direction. This behaviour can be disguised as “educational” for a while, giving it a very good potential for prolonged sabotage…
    5. Personal favourite: Do all work items as isolated as possible, allowing for no contextual thought or how it will be perceived and understood by a user. Or if any other work items are a continuation on this particular item.
    6. Disregard project scope and boundaries. If done correctly the sky is the limit to how much time a project can be delayed…

  • Frederick Somerville on 2013-01-08

    And lets not forget the “silent beggar” who deflates a three day long meeting at the final 10 mins when the moderator asks “How has this workshop been?” and the silent beggar simply states, after three days of silence.
    – “I think you are all totally wrong and I strongly disagree with everything said and every decision you made”

  • Leave a Reply

    Your name as it will be displayed on the posted comment.
    Your e-mail address will not be published. It is only used if I want to get in touch during comment moderation.
    Your name will be a link to this address.
Software Development is a Job – Coding is a Passion

I'm Anders Abel, a systems architect and developer working for Kentor in Stockholm, Sweden.

profile for Anders Abel at Stack Overflow, Q&A for professional and enthusiast programmers

The complete code for all posts is available on GitHub.

Popular Posts

Archives

Series

Powered by WordPress with the Passion for Coding theme.