How to (accidentally) sabotage productivity, according to the CIA.

In 1944, the Office of Strategic Services (the organisation which later became the CIA) published a Simple Sabotage Field Manual. It was distributed during WWII to instruct operatives behind enemy lines to disrupt companies and weaken their country by reducing productivity in the workplace.

This was recently declassified and while some of the instructions are outdated (fires can be started wherever there is an accumulation of inflammable material), we've picked out some surprisingly timeless techniques. While you have a chuckle at the dry language, and nod along in agreement at some of the parallels you see in your own workplace (from your peers, bosses or even yourself); we've included our tips to counter-combat these all-too-common patterns in the modern workplace.

The potential saboteur should discover what types of faulty decisions are normally found in his kind of work and should then devise his sabotage so as to enlarge that "margin for error"

 

William J. "Wild Bill" Donovan | First head of the OSS and supervisor of the Simple Sabotage Field Manual

Organisation and conferences

1. Insist on doing everything through "channels". Never permit shortcuts to be taken in order to expedite decisions.

What we see quite frequently is teams working in silos, and lots of debate about the problem that needs to be solved, rather than making progress. We advocate for dedicated focus and attention and speed. Ensure delivery teams are empowered to make decisions. In Co-Design workshops, ensure that senior decision-makers are included as participants throughout the process. If they are unable to attend, they must delegate authority to someone who is trusted to make decisions in their place.

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

Ensure that the delivery team includes subject matter experts, senior decision-makers, and the voice of the customer. With these engaged throughout the project, there should be no reason to defer to outside sources of authority or expertise. If in doubt, test with actual customers/end users and use this data to mitigate second-guessing of any decisions.

3. Advocate “caution.” Be “reasonable” and urge your fellow-coferes to be “reasonable” and avoid haste which might result in embarrassments or difficulties later on.

Trade certainty for speed, and if in doubt, put a prototype or early build of the product in front of actual customers/end users. Focus HAS to be on delivery of a working product that you can ship (this won’t be perfect, and won’t have everything you want most likely). If there's any fear of later recrimination, it should be the inevitable consequences of failing to deliver. Consider how you can create an environment of Psychological Safety in your team. Set clear parameters, and then trust the team. If you don’t trust the team, change it, or bring in additional people to fill any skill gaps.

4. Demand written orders.

Beware of 'waterfall by stealth’ aka AgileFall, Waterfall-Agile, Wagile or Frozen Water where nothing is moving. Scaled Agile entails an inherent tradeoff of certainty for speed. Ensure that this is accepted and reflected not only in documentation requirements but also in the wider set of systems and processes governing the project. For example, the fixed-price-fixed-deliverables procurement models typically used for capital investment are not appropriate for Agile projects. In Agile there are no fixed deliverables, but there is always progress. Funding should therefore be tied to progress.

5. Multiply paperwork in plausible ways. Start duplicate files.

This isn't just about freeing resources from documentation so they can focus on delivery. Source control and versioning is essential in DesignOps and DevOps, to avoid errors that arise from referencing out of date requirements and keep everything moving forward. Ensure everyone is collaborating on a common platform with messaging capability (e.g. Slack).

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

Ensure that the systems and processes governing a project are conducive to lean, fast and Agile delivery. Once a project has started, the rate of delivery should accelerate. Identify and remove any business process or requirement with the potential to impede delivery. Make sure decision-makers (the people accountable - who will get fired if this fails?) are established upfront, and they have the deciding vote.

Managers

7. Bring up irrelevant issues as frequently as possible.

The concept of a Product Backlog is often not widely understood. You must encourage focus on the prioritised set of features for this sprint, and let the team deliver those, before looking at other features. “Yes, Mr (or Mrs) Stakeholder your idea/feature is important, and the team will get to that in a later iteration, but right now they are working on the features that were already agreed on for this sprint.”

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

Use Co-Design workshops to ensure important decisions are made by the project stakeholders collectively. Side conversations and back-room decision making should be strictly forbidden. With this achieved, decisions will have been witnessed and validated by all stakeholders. This eliminates the need to justify or re-litigate decisions after the fact. Consider an outside facilitator (e.g from Apolinar), to help navigate the different stakeholder priorities and opinions.

9. Be worried about the propriety of any decisions - raise the question of whether such action as is contemplated lies with the jurisdiction of the group or whether it might conflict with the policy of some higher echelon.

Ensure the delivery team has a clear mandate that is aligned with the project objectives. i.e. The team should have authority over those things for which they are responsible and accountable. Any 'higher echelons' with the potential to overrule decisions made by the delivery team later in the project should be included in the CoDesign process. If they are unable to participate, they must delegate authority to someone who is trusted to make decisions on their behalf. If in doubt, test with actual customers/end users and use this data to mitigate second-guessing of any decisions.

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

Perfect and complete do not exist in Agile delivery. There is only something that is able to be shipped and will be better than what you have now. Of course, you require quality but it will never be 100% perfect. It will never be 100% finished. Plan and budget resourcing for post-launch sprints to improve and add features. This will alleviate tension about delaying the initial launch.

11. Order high-quality materials which are hard to get. If you don’t get them, argue about it. Warn that inferior materials will mean inferior work.

Platform and technology selection should be geared towards surfacing enterprise data to digital experiences in the shortest time possible. This is not to say that enterprise system re-platforming is unnecessary, only that this shouldn't stand in the way of lean, fast and Agile delivery. There is always a way. You can always scale up later, but you can't regain lost time. When you don’t have a product in the market and you don’t have users, scalability is not your primary concern.

1. Start with Co-Designing, Prototyping and Testing the ideal Human Experience (HX) and then work backwards.

2. Don’t wait for the perfect backend...it doesn’t exist. Almost all organisations face challenges with legacy applications.

12. Never pass on your skill and experience to a new or less skilful worker.

Excellence is a function of learning and improvement over time. In order for this to be possible, knowledge and insight must be shared within the team.

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

The Human Experience (HX) of technology requires looking beyond the customer experience, to design for delivery as well. You can't just throw people at a problem, you need to include them in the process right from the beginning. Ensure change management is budgeted and resourced in the plan and not an afterthought.

14. In making work assignments, always sign out the unimportant jobs first. See that the important jobs are assigned to inefficient workers of poor machines.

Don't mistake activity for progress. The delivery team should always be focused on priority tasks. If in doubt on the priorities, test with customers/end users.

Let’s take down these saboteurs

Organisations waste time and money, discussing the possible solution and trying to agree internally on what is best for the end-users.

Our solution? Our frequently referred 5-Day Co-Design Sprint and Scaled Agile Framework.

Co-Design Sprints

• Provides input from the customers early in the process

• Diffuses internal debate

• Allows progress and builds momentum

SAFe for Lean Enterprises

• Provides a knowledge base of proven integrated principles and practices

• Provides competencies for Lean, Agile, and DevOps.

Experience shows us the best results are achieved when:

1. Stakeholders are aligned in support of a clearly defined strategy

2. Decision making is supported by data-led insights

3. Delivery is fast, lean, and agile

4. Innovation and delivery is owned internally

Start thinking HX: Every organisational tech failure in history shares one common factor: a lack of human focus. CX is great if you can compress your audience into a single box and call them “customers.” UX is cool if your whole problem is interaction design (hint: it isn’t).

HX is about understanding the human experience of technology. It’s a much bigger, more flexible, and more powerful idea to help your business succeed at digital transformation. If you want to design great technology, you have to start at the beginning, with your team, and your capability, building out from there to the end user.

We have very relevant experience and capabilities matched to your requirements, particularly with our vast hands-on experience working with full-stack Agile delivery. This combined with our world-class Human Experience (HX) methodology and our relevant experience will ensure a great outcome, check out some of our impact stories.

Our approach is to work quickly, remotely if necessary, flexibly, and systemically. Apolinar exists to help business leaders navigate the digital landscape, build capability, deliver projects and demonstrate value. Fast.