Sabotage

My palms haltingly slid over each other under the desk. My forehead was clammy against the soft stale office air. I'd been deep in Russia for months, and the day had finally come for me to use my position in the company to tilt the cold war in the favor of the US. I took a quiet breath to focus the shivering of my chest, and spoke.

"Should we consider putting this to a committee? We don't want to make a hasty decision that could come back and bite us later".

Perhaps that contrived example sounds a bit far fetched, but over my career I seem to have spent a lot of time within "innovation wings" that exist in larger companies. When I read the recently declassified 1944 CIA Simple Sabotage Field Manual I was shocked at how often I've been in meetings where people have nearly quoted its suggestions for sabotaging a company.

While most of the manual focuses on factories and assembly line or mechanical work, the section "General Interference with Organizations and Production" reads like a "best practices" manual for many companies today.

Meetings

• 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.

• Give lengthy and incomprehensible explanations when questioned.

I totally jump on my soapbox occasionally, and I think soapboxes and learning lunches etc can be very valuable in the correct place. This problem usually arises when the correct time and place isn't chosen. A monologue is great at a lunch and learn, but it's terrible in a standup. We should focus on giving concise answers, not using a lot of words to say very little.

I also find that while people are not often patriotic to the country, these days there can be a lot of "patriotism" to the company itself. Waxing poetic about the company's mission, how smart the people in the room are, or how we're on the cutting edge are usually just flattery. I find effective leaders invite hard questions and instead of dismissing them, they answer the actual question, or acknowledge they don't have a good answer.

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.

I find that we generally love to create a committee for anything and everything. Or we bring in "a lot of brainpower". But usually these highly paid people are mostly sitting idle or distractedly doing emails, so we're wasting salary money. At the same time we often end up with a polluted vision or a non-outcome for the meeting.

• Hold conferences when there is more critical work to be done.

Every dev that's attended more than one "status update" meeting in a day can account to what a waste of time these almost always are. (Beyond a proper standup that focuses on blockers and alignment, not progress updates). Status updates can be sent in a slack message and shouldn't be needed more than once a day, unless there is an active issue being worked through or something.

• Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.

This can be legit if some new information comes to light, but that's very rare. Even worse is when a person was invited to the previous meeting and skipped, only to cause chaos later. This can also look like you're not being open minded; the subtlety makes this particularly insidious. I like to say that you have an opportunity to participate, but if you don't, you forfeit the ability to circle back later, unless you can concisely produce a clear and present danger that was not previously noted.

• "Misunderstand" orders. Ask endless questions or engage in long correspondence about such orders. Quibble over them when you can.

I don't think people do this intentionally, but I think this principle extends to things like using monstrous email threads instead of a more 'real time async' platform like slack or rocket chat. This also applies to some level to having meetings that could have been a slack message, instead of being meeting averse until some resolution requires 'talking through it' with a small group. Similarly, we should use quick huddles instead of scheduling a meeting a week out. If the parties are all so important and busy that they can't do impromptu meetings, that indicates to me that there are also other issues that need to be addressed.

Derailing

• Bring up irrelevant issues as frequently as possible.

• Report imaginary spies or danger to the Gestapo or police.

I often see one dev, because of personality or they just feel a certain way that day, derail meetings. I don't think meeting agendas help much to prevent this. Instead I think having the right people (with the right attitude) is the best defense, as well as having a 'meeting lead' who puts effort into pruning tangents and putting off topic things into parking lots.

• Haggle over precise wordings of communications, minutes, resolutions.

Often epitomized in devs arguing over method names, our time is costly and we should be cognizant of the value of what we're spending time on. Is it really worth spending X dollars haggling over this point, or does it even matter?

• Be as irritable and quarrelsome as possible without getting yourself into trouble.

It's really important for us to be collaborative, but often that means friction. I find that choosing which battles to fight can make a major difference on how effective in those battles I end up being.

• Cry and sob hysterically at every occasion, especially when confronted by government clerks.

I haven't seen this one too often, but I have seen employees who at every meeting haven't gotten assigned work done because of a new and unique personal problem of the week, for months.

• Insist on perfect work in relatively unimportant products; send back for refinishing those which have the least flaw. Approve other defective parts whose flaws are not visible to the naked eye.

They say the perfect is the enemy of the good. I saw a bug report in 2016 that the website that needed to be done in a month had a bug that would manifest in 2040. The website is probably no longer in use today. Good enough and prioritizing working software over unlikely edge cases is important. Like some of these others, the responsible dev can often sound like they want chaos, but the real chaos seeps in through series of 'cautious' decisions, coupled with focusing on the wrong areas.

Caution

• Advocate "caution." Be "reasonable" and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on.

This is pure gold, and the bureaucrat's favorite everywhere. This sounds good, and pushing back on it makes you sound like a "cowboy" or "loose cannon". This is why startups succeed and big companies with every reason to continue to make money slowly degrade into obscurity. We should follow mature practices and write tests, but this is often used to excuse harmful process or a desire to not take risk or bear blame.

• 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.

"Will this affect feature X?" is a question that's often hard to answer with an affirmative no, and easy to spin off into a committee that we now need to hear back from, effectively halting the current effort. This is a great way to stop a project dead in its tracks. Instead, I propose that we should be opt in instead of opt out. This puts a lot more responsibility on people to proactively understand what others are doing. However, it makes shipping features a downhill move instead of an uphill battle.

• Do everything possible to delay the delivery of orders. Even though parts of an order may be ready beforehand, don't deliver it until it is completely ready.

This reads to me like a comparison between waterfall and agile, or agile philosophy vs big business implementations of agile. It's interesting to me how often people will talk about frequent deploys and then explain an mvp that requires an entire system to be built out. We should be comfortable releasing not just dark launched full features, but also with partial releases, so long as they make sense.

Documentation

• Multiply paper work in plausible ways.

I find that Confluence does a great job of digitally multiplying paperwork, with companies often having many similar but slightly different pages, all stale to differing degrees. I think git wikis are often a bit better as developers are generally more likely to edit existing pages, but it's always a challenge. It seems like some of the best defenses are having a single system for documentation (that's git based and near the code) and using systems designed for devs as opposed to other roles. However, the best defense of all is to not focus on documenting things that others won't read. Perhaps we should take a cue from landscapers who wait to lay down path until they see where the grass has worn bare.

• When training new workers, give incomplete or misleading instructions.

I find people often put a real focus on documentation, and usually the more focus on documentation, the worse it is. People like to add new documentation and not upkeep the old documents, and the team quickly moves into a place of documentation overload. Better to improve and simplify the process, hire self starters, and train people to fish. Trading extensive documentation creation for minimal documentation close to or in the code, plus pairing with new devs to give them tools to solve problems can do wonders. I find that often the docs exist and the newer person doesn't know where these exist and can waste time looking in the wrong places.

• Never pass on your skill and experience to a new or less skillful worker.

Having a 'documentation culture' helps make this worse, as people assume the new worker "should just read the docs" when they don't even know where the relevant docs are. It's important to recognize when someone is struggling and jump into a huddle with them to figure out where the core gaps are.

Environment and Tools

• Insist on doing everything through "proper channels." Never permit short-cuts to be taken in order to expedite decisions.

• Apply all regulations to the last letter.

It's interesting to me how often companies have or are worried about "Shadow IT Shops". Clearly these shortcut shops wouldn't exist but for the abundance of regulations and process to get anything done through official channels. When we need to sidestep an official process, it's usually because the value of that process is outweighed by the effort to do that process, usually because both the value is overestimated and the tooling / process itself is arduous.

• Multiply the procedures and clearances involved in issuing instructions, pay checks, and so on. See that three people have to approve everything where one would do.

• Work slowly. Think out ways to increase the number of movements necessary on your job: use a light hammer instead of a heavy one, try to make a small wrench do when a big one is necessary, use little force where considerable force is needed, and so on.

I've read that the greatest indicator of software maturity is essentially the amount of time taken up by your CI/CD process (specifically time elapsed between code getting to master and running on a production server). I think those fast feedback loops are hugely important. I'd also say this applies to having blazing fast tests and having deploys that aren't cluttered with steps and process.

• Tell important callers the boss is busy or talking on another telephone.

I often see this with tech leads, where they, or their access, are bottlenecks. When the TL is out, PRs can't be approved or new github repos created etc.

• Contrive as many interruptions to your work as you can: when changing the material on which you are working, as you would on a lathe or punch, take needless time to do it. If you are cutting, shaping or doing other measured work, measure dimensions twice as often as you need to. When you go to the lavatory, spend a longer time there than is necessary.

I see this with the oft complained about needless meetings. It's interesting how often people complain about useless meetings and yet they persist. As a TL I try to really fight to reduce the number of hours spent in meetings, as well as the frequency of those meetings. This can also apply at the team level with priority shifts meaning focus shifting from one effort to another more than it should.

• Do your work poorly and blame it on bad tools, machinery, or equipment. Complain that these things are preventing you from doing your job right.

I watch dev after dev struggle with the same problem and shrug their shoulders instead of writing a tool so that problem goes away. It feels like you're doing something bad at first, but spending time on a reusable tool almost never is a bad investment.

• To lower morale and with it, production, be pleasant to inefficient workers; give them undeserved promotions. Discriminate against efficient workers; complain unjustly about their work.

This is super disheartening to see, and seems prevalent across most big software companies. Lawsuits have driven many cautious companies to make the process to fire someone incredibly difficult. At the same time I have often seen more frequent promotions that are at or below a cost of living salary increase, which encourages high performers to go elsewhere.

No constraints

At the end of the day, no one wants to be responsible for when things go bad. That bias means we'll almost always error in the other, safer direction. To be a great craftsman means we must take risks. At one company I worked they used the phrase "no constraints" to mean "what if we had all the power in the world, what would we do then?" as well as "let's think not 'how can this go wrong' but 'how can this go right?'". I think those exercises and that "bias towards action" are really important. We must fight to tackle problems, instead of just recognize their existence, or wait for someone else to take the risk.