Simple knowledge-sharing sabotage field manual

In 1944, the OSS — Office of Strategic Services — of the USA shared with their Europe-based agents a sabotage manual designed to create friction, frustrations, slow-downs, and disturbances in Nazi organizations.

80 years later, it’s interesting that the guidelines look familiar in many large companies. For instance:

Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions.

I recently could have the chance to give a talk at the Bordeaux JS Meetup about how this sabotage manual could be applied to knowledge sharing in tech companies. This post summarizes its content.

Context

Our common goal is to harm the company *Deforest Corp*. They have a bad ecological impact as their primary mission is to massively destroy natural forests to favor intensive agriculture. As a software developer, you’ll join a feature team working on an app used by employees that drive deforestation sites. This app has undergone recent bugs so software quality is a major concern.

Your mission will be to degrade code quality (or at least, not improve it), increase bugs risks, and negatively impacts the relationships among members in the team. So we choose a smooth, subtle, and (almost) pacific approach. If you’re too radical, you’ll probably be fired immediately, so no interest.

Your action plan: hurt everything related to knowledge-sharing. Why so? It’s one of the factors that fuels business performance, developers still spend a lot of time answering questions and looking for answers, and knowledge-sharing is still a challenge for developers. More generally, it breaks knowledge silos; still need to be convinced of the value?

Let’s see how to do it?

The guidelines

1. Don’t share the root causes of the bugs you fix. You increase the risk that someone else performs the mistake related to the root cause, and the bug will happen again.
2. Don’t share the code improvements you made. Any best practice that has a positive impact on the code (readability, performance, …) should be kept for you, preventing others to apply them in their code. Don’t be too greedy about that.
3. Don’t update obsolete documentation. If you spent a lot of time finding an answer because the Wiki was outdated, ensure your colleagues will also face troubles. Leave it as it is.
4. Make yourself unavailable for onboarding sessions. Onboarding new developers is a great exercise for sharing knowledge with a newcomer. Make sure that won’t happen.
5. Don’t read or react to content shared by your colleagues. Someone just shared a nice post on Slack? Of course, you’re too busy to read it. But don’t even ask for a short digest, and don’t react at all. They’ll get tired.
6. Support the idea that aligning your coding standards is pointless. Everyone should write code in their own way. YOLO, right? This will bring heterogeneity in the source code, leading to potential quality issues.
7. Decline all pair/mob programming sessions. Pair and Mob programming sessions optimize the output while fostering social interactions. You don’t want that.
8. Pretend you didn’t see you’ve been asked to do a code review. Oh, you saw this notification for reviewing a pull request? We already received too many notifications, right? So I’m sure you missed that. This will create a good latency.
9. Postpone the code review by pretending a huge workload. Sometimes, you’ll see the notifications. But guess what? You’re too busy, you also have work to do. So wait 2-3 days. And finally, just be honest with your colleague and say “I did my best but unfortunately could find the time. Can you ask to someone else?” Precious time lost, we love that.
10. Validate the review without reading the code. Free LGTM distribution at random locations. Don’t take that chance to improve the code, identify possible bugs, or share valuable tips. People will think you did a review. Send code as it is in production.
11. Suggest conflicting best practices from one review to another. You’ve suggested one coding standard the last time? Suggest now the opposite. This will bring confusion, friction, and heterogeneity in the code.
12. Feed endless discussions during code reviews about coding standards. GitHub/GitLab provides features to create comment threads, right? Use it as much as you can. This will create latency in the process. And of course, disagree with your interlocutor.
13. Make comments on source code NOT updated during the review. Run discussions on the code that have not changed at all (you know, these lines of code not starting with “+” or “-” in the diff). Why not? Huge frustration coming in.
14. Decline any help coming from someone external to the team. 1. A technical coach is about to bring new best practices and methodology to the team? Decline it. We can’t impose a coach, they need your adhesion. Don’t give them.
15. Don’t share anything related to your technology watch. Did you go to a great Tech conference? Don’t talk about that to your team, don’t share any replay. Don’t talk about some nice blog posts you’ve read. Keep them for you.
16. Question the ROI of the community of practices. Don’t you think it’s strange, these people gathering several times per month, to share common problems and feedback that would be interesting to everyone? They’re just talking, and we have features to implement. Don’t learn from others teams that share common problems with you.
17. Ensure the company won’t pay for the books read during Book Clubs. So that people will be discouraged 1. from participating and thus won’t read that book that still looked interesting.
18. Ask a lot of questions during Coding Dojos. The size of the room, the exercise statements, the schedule, and more. Complain about everything. Ensure this 90min-session won’t be optimized.
19. Call for BBL boycott. Brown-Bag Lunch is scandalous. At that time, everyone should eat alone and not have a chance to learn while sharing a meal.

The summary

Of course, reasoning by absurd is a voluntary choice I made. If knowledge-sharing matters in your context, of course you should consider doing the opposite ;). If some of the guideline remind you some experiences you lived, sorry to hear that and I hope it’s past!

What about you?

I’ll end by sharing this 3-min test to evaluate how your current engineering teams are performing in terms of knowledge-sharing, hoping it will give you some insights :)