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 out-dated (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 and non co-operation are normally found in his kind of work and should then devise his sabotage so as to enlarge that "margin for error".
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.
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.
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.
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.
This isn't just about freeing resource 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).
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.
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.”
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.
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.
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.
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 replatforming 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.
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.
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.
Don't mistake activity for progress. The delivery team should always be focused on the priority tasks. If in doubt on the priorities, test with customers/end users.
Organisations waste time and money, discussing the possible solution and trying to agree internally what is best for the end users.
Experience shows us the best results are achieved when:
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.