Productivity is a what you expect from from every organization. In his latest interview Google CEO Sundar Pichai told reporters 'Productivity as a Whole Is Not Where It Needs to Be' so everybody loves productivity and pushes for it. But what is productivity have to do with CIA you might ask. It has a lot to do with spy agency.
During World War 2 when axis powers invaded a large part of Europe, one of their aims is to use captured areas industrial might for their war machine. Of course, workers do whatever they can do to sabotage their own factory. But they are walking on a thin red line. If they were caught, they would be shot. If they do too much, they would be helping invaders. OSS the precursor to CIA write a manual in 1944 which was declassified in 2008 to do just that slowly killing productivity without anyone noticing it.
Simple Sabotage Field Manual is an handbook of anti-pattern for productivity. It includes parts for coal, transportation, telegraph etc. For software developers the interesting part is the part on how to kill your organizations productivity in subtle way so that although you seem to work, you most definitely not. Here are the tips.
- Insist on doing everything through "channels." Never permit short-cuts to be taken in order to expedite decisions.
“I won’t tell you if it’s possible or not. You have to open a Jira Ticket. And let me check.” Sounds familiar ? The people you are asking knows it, you know the person you are asking knows it. But refused to share it because it will be a cross department information leakage. And nobody likes a snitch.
- Make "speeches." Talk as frequently as possible and at great length. Illustrate your "points" by long anecdotes and accounts of personal experiences.
You felt the disturbance in the force. You make eye contact with your buddy and he slowly nod his head. Everything is in slow motion now. And person sitting next to you begins. "The last time we have to make so much change in our codebase is we order ten pizzas for night …" and the rest of the day is gone.
- When possible, refer all matters to committees, for "further study and consideration." Attempt to make the committee as large as possible — never less than five.
"We should create a committee for all thirteen departments that will be affected by the change to find out how much it will take in man hours to upgrade our codebase from React 16 to 17." by the time the report is ready React 18 is announced.
- Bring up irrelevant issues as frequently as possible.
"But my friend thinks purple background is better."
- Haggle over precise wordings of communications, minutes, resolutions.
“You said you stored your content and files in GitHub but in Git content is metadata it’s not clear what you meant so please MAKE IT CLEAR! Also the time you spent on issues is given with minute resolution make it in seconds. Is it too hard to write two more numbers ? And... What’s wrong with your TPS reports. You forgot to put the new cover sheet. Did you see the memo. I’ll make sure you get another copy of that memo.”
- Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision.
"I know we agree to use React, but I sent you a blog post about Angular, which shows Typescript by default is a better choice for enterprise software."
- Advocate "caution." Be "reasonable" and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on.
"We should not rush things .NET Framework 4.8.1 is just released so no need to rush to switch to .NET 6."
"I know Python 3. I’m not sure if it will get the traction required and worth the transition. You know it's working fine with Python 2"
While some of this might be seemed off, I’m sure you hear some of them before and if you hear all of them in your current workplace … Congratulations, you have a saboteur among your peers.
So where can you read the original ? https://www.hsdl.org/?abstract&did=750070
I hope you use the information wisely and increase your productivity.
Top comments (0)