How to Sabotage Your Software Company in 10 Easy Steps (Without Getting Caught)

I love a good revenge story—something dark, thrilling, and deeply satisfying. Picture this: a software company called Elite Virtual Intelligence Labs (EVIL). When you were just 6 years old, the owner of EVIL, drunk behind the wheel, struck and killed your beloved dog in a hit-and-run. Your world shattered in an instant. But that pain turned into something else—a thirst for vengeance. You swore that one day, you’d take everything from him: his wealth, his empire—his precious EVIL company.

You hit the books hard, eventually earning a spot at MIT. You didn’t stop there. You climbed the career ladder, each step driven by the desire for justice. Twenty-five years later, you’ve made it. You’ve joined EVIL, now a global powerhouse corporate, as their new CTO. And the man who killed your dog? He’s still in charge. But this time, it’s your turn. It’s sweet revenge time! But this isn’t a movie where you can sabotage the company overnight. No, you need to be smart. One wrong move, and you’ll be caught, fired, and slapped with a lawsuit. You’ve got to play the long game. Here are the 10 (easy) steps to bring EVIL to its knees… without getting caught.

1. Process Over Progress: The Golden Rule of Stagnation

This step is all about setting the stage for chaos—I like to call it "the enabler."

The first value in the Agile Manifesto is "Individuals and interactions over processes and tools." Welcome to Sabotage 101: prioritize the complete opposite.

Someone wants to do something simple that’ standard practice? Tell them to raise a ticket in a system that looks like it was built in the early 2000s, or have them follow an overly complicated process. Someone needs help with anything? You guessed it—ask them to raise a ticket in the same abomination of a system or get stuck in that same ridiculous process again. Engineers want to build software? Did their software designs go through the Architecture Review Board (see step 4 for committees)? If so, bring in Scrum!

Make sure processes always have multiple steps, each handled by a different team. The more people involved, the slower it gets. And, of course, have everyone repeat the same information over and over. If something doesn’t match up, send them back to square one. Bonus points if the process makes no sense at all. Some steps of the same process should be done through the ticketing system, others via email—whatever keeps it unpredictable and inefficient.

While some saboteurs claim that not documenting processes is the way to go (it keeps people guessing, they say), I’d suggest you take a different route. Make sure the processes are constantly changing. Keep multiple versions of the documentation, all outdated, and make sure the current version is nearly impossible to find. Most people won’t even realize they’re using the wrong process until they’ve wasted hours on it. And the kicker? After a month or two, when they need to follow the same process again, it will have already changed, so they’ll be stuck in the same cycle all over again.

When it comes to software development, lean hard into Agile (or your interpretation of it). Make Scrum mandatory for everyone, no exceptions. Treat every process step like it’s sacred, and enforce it to the letter. This will naturally lead to more meetings (see step 3 for why that’s great and how to maximize the effect). If anyone dares to suggest that your approach is doing more harm than good, just tell them they don’t understand Agile and are "doing it wrong." Imply that, at the end of the day, it’s their fault since Agile is being used successfully by so many others.

Once teams are crippled by the processes, deliveries will slow down. This is the perfect time to bring in reinforcements. Hire additional roles like Agile Coaches and Scrum Masters to "fix" the problem (don’t worry, we’ll talk more about this in the next step).

2. Create Jobs That Look Important, But Aren’t

One way to create useless jobs is by building a bloated management hierarchy. Add layer after layer of managers, each determined to protect their position in the organization, and they’ll do most of the work for you. If you really want to stir things up, make sure employees report to multiple managers. That’ll guarantee overlapping priorities, drawn-out approval processes, and plenty of misalignment. Exactly the kind of inefficiency you’re aiming for!

Another approach is to hire way too many project managers and create roles like Scrum Master, Agile Coach, Internal Strategy Consultant, or whatever trendy titles you can come up with. The trick is to give these roles just enough authority to cause headaches. Like managers, these people will feel the need to justify their existence, so they’ll fill everyone’s calendars with meetings and complicate workflows with unnecessary processes.

The best part? If anyone dares to complain, you can accuse them of not caring about deadlines or, worse, not being "agile" enough. To make it foolproof, you can cherry-pick success stories—like when a project manager saved a ton of money or a Scrum Master turned around a struggling team. That’ll shut down most arguments pretty fast.

For maximum impact, combine both strategies. A bloated hierarchy of middle managers paired with an army of lower-level authority figures will create the kind of inefficiency you can only dream of!

3. Meetings: The Black Hole of Productivity

An email or a chat message? Trick question! The answer is always a meeting. Some people say, "This meeting could’ve been an email." I like to say "This email could’ve been a meeting." It’s all about perspective.

First things first, make sure your meetings are huge. The more people involved, the harder it is to have a meaningful discussion or make any decisions. And don’t forget to complain about inefficient meetings regularly—your colleagues will think you’re on their side. Then, as a "solution", suggest pre-meetings with smaller groups to "prepare" for the big meetings. If you play your cards right, the number of meetings will spiral out of control.

Amateur saboteurs might try to set up weekly or even daily meetings with no real agenda. Big mistake. Don’t do it. I repeat, DO NOT do it. You’ll eventually have to cancel those meetings as you’ll run out of topics to discuss. Even worse, those meetings could highlight and point the time-wasting problem directly at you. The plan is not to get caught, remember? Instead, structure the organization so that others would set up useless meetings for you (see step 2 on how to do that).

Push for mandatory recurring cross-team sync calls. It doesn’t matter that some teams barely cross paths. Spin it as a bold initiative to "foster collaboration across the entire company," not just within teams. And what better way to build that bridge than with a recurring, agenda-free meeting? And just like that, an hour's gone.

Don’t underestimate the power of a quick 15-minute meeting. Some researchers suggest that people can lose up to 20 minutes of productive work getting back on track after an interruption. So, schedule these short meetings often—they seem harmless on paper, but they’re a goldmine of inefficiency. Plus, they let you play the "plausible deniability" card. After all, "it’s just 15 minutes!" But here’s the kicker—many software engineers will blame themselves for the lack of progress, thinking they have plenty of time in the calendar but somehow getting less done. Two birds with one stone!

Lastly, make sure to introduce processes that guarantee a steady stream of meetings. Scrum is a perfect starting point (see more in step 1). Stick to week-long sprints, so you can fill the calendar with weekly refinement sessions, planning meetings, retrospectives, and, of course, daily standups. It’s the gift that keeps on giving!

With this formula, you’ll ensure everyone is buried in meetings and not getting any real work done!

4. The Great Committee Circus: More Clowns, Fewer Results

It’s crucial to agree internally on what needs to be delivered, how, and when. And guess what? This is the perfect opportunity for some good ol’ sabotage. Create committees for everything. Architecture Review Board? Check. Release Management Committee? Check. Quality Assurance and Risk Review Group? Check. Seriously, the more, the merrier. These committees will be in charge of approving every tiny detail.

But, as with most of these steps, there’s a bit of strategy here. You’ll want to pick the busiest people for these committees. A good way to do that is by checking their calendars—if it’s a struggle to book a meeting with them, it’ll be even harder to get them to focus on committee work. Also, make sure they’ve got other "more important" tasks on their plates. That’ll help you push committee meetings down the priority list. And don’t forget to look for the right personality traits—someone with a massive ego and a superiority complex is a killer combo!

To take it up a notch, you could push for a "veto" system, where one committee member can block the whole approval. But, let's be real—you might not get away with that. Instead, casually mention that you’ve heard your competitors are doing it, or even the European Union is, and hope someone bites.

With enough committees in place, things will slow down on their own. Mission accomplished!

5. Zero Trust? More Like Zero Limits for Security

The most secure code is no code. The balance between security and productivity? Forget it. You’re here to go all-in on security and grind everything else to a halt.

Start by beefing up your IT Security department. Hire a team of people who are inexperienced but super opinionated. The kind who think they know everything. Then give them total control. No oversight, no pushback. The crazier their ideas, the better. Make sure their rules are absolute. You’re aiming for an IT Security Gestapo vibe here!

Next, ask the IT Security department to block all internet downloads and some of the popular websites, like GitHub or Stack Overflow. Work-related? Doesn’t matter. If someone absolutely has to access or download something, make them jump through hoops with a ridiculous process (see step 1 for tips on that).

Make sure everyone updates their passwords every week or two. No reusing, multiple special characters, numbers, and random patterns. Whatever you do, don’t let anyone use password managers—that would just make things way too easy. Bonus points if you turn password recovery into an epic saga, complete with tickets, approvals, and lots of waiting (see step 1 for more on that).

Don’t forget to restrict engineers’ local admin privileges so they can’t install or update their own software. Everything has to go through that glorious, inefficient IT process, with a two-week wait for approvals.

Introduce multi-layered security checks and manual approvals for every deployment, ensuring that even the simplest bug fix takes days to roll out. Continuous deployment? More like continuous delay. Consequently, people will start batching their changes, turning every deployment into a ticking time bomb. Kaboom!

Now for the fun part: install every security tool you can think of. Pile them on. Get multiple antivirus programs running on every computer at the same time. Make sure they’re always scanning, slowing down everything. Pair this with step 6 for maximum chaos. Push it as far as you can—after all, "you can never be too secure," right?

Many people, especially in sectors like healthcare, finance, or government, are terrified of appearing careless about security. Use their fear to your advantage. Go nuts. Better yet, let your IT Security team go nuts. They’ll make life miserable for everyone else while you sit back and enjoy the show.

6. Upgrade to Downgrade: The Hardware Trap

Downgrading employee hardware isn’t going to sabotage the company overnight. It’s more of a "death by a thousand cuts" strategy. And it’s probably one of the safest ways to stir up some trouble.

The trick is not to overdo it. Don’t hand your $200k-a-year software engineers (or whatever you pay them) a $500 laptop—that’s too obvious. Instead, aim for something in the $1,000 to $1,500 range. It’ll be cheap enough to annoy and slow them down, but not bad enough to stop the work completely. If you’re feeling extra evil, throw in some low-quality keyboards, blurry monitors, and other barely usable accessories.

As a first-time saboteur, you might think, "What if these highly paid employees just buy their own gear? It’s not that expensive." Don’t worry—this is where IT Security comes in. Partner with them to block all non-standard equipment for "security reasons." Say that you’re being extra vigilant and don’t want to take any chances, even if there’s the slightest risk. IT Security will think you’re a champion for prioritizing security. And the best part? When people start complaining, you can pin the blame entirely on the IT Security department. They’ll be your perfect scapegoat.

At the end of the year, no one will be able to measure how much productivity was lost. On the other hand, they’ll definitely notice all the money you saved. Who knows, you might be labelled as a cost-saving hero and even get a bonus for all your effort!

7. Metrics Mania: Counting Everything, Achieving Nothing

Start with a classic: lines of code per developer. If a certain high-profile tech company (formerly known as Twitter) allegedly used it to decide who stays or goes, why shouldn’t you? Sure, it’s an easy metric to game, but that’s the beauty of it. Reassure your team it’s "just one of many metrics" and isn’t tied to any decisions. They’ll believe you—at least at first. But once people know it’s being tracked, watch the codebase grow with unnecessary changes. More code, less quality. Perfect.

Next, track the number of code commits. To keep software engineers on the edge, frequently compare their commit numbers. This will push developers to flood their teams with tiny, meaningless pull requests. Each one will have to be reviewed, wasting everyone’s time. Want to take it up a notch? Start tracking how quickly pull requests are reviewed. Engineers will rush through reviews to keep their times low, sacrificing quality for speed. No one will complain, because, on paper, smaller pull requests and quick reviews sound like good practices. In reality, you'll be pushing it to the extreme and wreaking havoc.

Then, there’s task completion. Count how many tasks people finish, but completely ignore the fact that not all tasks are created equal. When someone complains, shrug it off with "It all balances out in the end." It doesn’t. As a result, your top performers—the ones taking on the hardest work—will start to burn out. Meanwhile, everyone else will go for the easiest tasks, leaving the meaningful work unclaimed.

Don’t forget individual velocity in Agile. This metric will single-handedly kill collaboration. Instead of helping each other, team members will compete for better numbers. Say goodbye to mentorship, teamwork, and problem-solving. Why bother with any of that when everyone’s focused on their own score?

Let’s talk about test coverage. Set a mandatory threshold, like 80-90% or higher. Who cares if it’s useful? Engineers will pour hours into writing pointless tests to hit the target. Tests are still code, which means it’ll need maintenance, creating more busywork. Instead of solving actual problems, your team will drown in unnecessary tests. And here’s the kicker: no one will challenge you on this, because who’s brave enough to argue against "better testing"?

Finally, track bug counts per team. Sell it as a way to encourage accountability. Teams working on legacy code or complex systems will get punished for things outside their control. Better yet, people will start avoiding bug fixes or not report bugs at all to keep their numbers low. If you’re lucky, this will spark a lovely blame game across teams.

The beauty of metrics is that you can try so many different things. Experiment to see what works best in your case. The trick is not to introduce too many metrics at once. Introduce them gradually, watch the confusion grow, and, most importantly, have fun with it!

8. Combine All Roles into One: The Chaos Recipe

Remember how, as someone working in software, you’re automatically the go-to tech support for fixing printers, installing Windows, or setting up the internet for your older relatives? Now take that same logic and apply it at work. I hope you can already see where I’m going with this.

DevOps? FinOps? Front-end? Back-end? QA? IT security? System administration? Data engineering? Site reliability engineering? Why bother with so many roles? You’re already paying software engineers—why can’t they handle everything? It’s not like they’re experts in all these areas, but who cares about expertise? Why settle for paying them to do what they’re good at when you can stretch your budget on things they have zero knowledge or interest in? Sure, it’ll take them longer, the work will be subpar, and you’ll spend more in the long run. But hey, efficiency isn’t the goal here!

If you think overloading software engineers is your only play, think bigger! Why stop there? Engineering managers could double as HR specialists and individual contributors while project managers could pretend to be business analysts and UX designers. Toss in six other hats for good measure. It doesn’t matter if they lack the time or skills—as long as you pile an unreasonable amount of responsibility onto one person, you’re guaranteed a disaster.

Want to spice it up? Expect them to perform at the same level as if separate specialists filled each one of those roles. Apply a little pressure (or a lot) from the top down and watch productivity crumble under the weight of impossible expectations. Results? Oh, they’ll be bad. But that’s exactly what you’re going for!

9. Build It All Yourself: The Longest Path to Delivery

In addition to "the longest path to delivery," I like to call this step "the scenic route to failure." 

Build all your non-business-critical software in-house instead of buying much cheaper off-the-shelf solutions. To begin with, you won't have to deal with all that nasty paperwork—contracts, terms of service, the usual. On top of that, you'll be able to send your best software engineers on an expensive side quest—a fun adventure where nothing that gives your business a competitive advantage ever gets done. Finally, you’ll be able to puff out your chest proudly while bragging about not being afraid of third-party vendors going bankrupt. Google, Microsoft, Amazon... who knows how much longer they’ll last.

As for Open Source, well, if some random people on the internet can do it, surely you can do it better. After all, who’s going to trust random people on the internet? And if everyone can see your source code, doesn’t that just make you a target for cyberattacks? These are just a few of the solid reasons you can give when explaining why you’re not letting your software engineers use Open Source anymore. Better safe than sorry... or, you know, productive.

10. Ensure No One Knows What’s Important

This step might just be the most important. Have way too many urgent priorities and critical goals—all at the same time. Bonus points if you manage to make some of them subtly contradict each other, but don’t make it too obvious. And whatever you do, avoid creating a clear, prioritized overview. Let your employees figure it out on their own.

If people start asking for clarity, don’t give in. Instead, group goals into multiple lists of priorities (i.e. business and IT) to make things even more confusing. As I like to say, if you don’t know what’s important, chances are your employees won’t either. And when they don’t know what’s important, very little meaningful work gets done. Ka-chow!

To maximize the chaos, keep changing priorities throughout the year. If someone dares to complain, just remind them that this isn’t some old-fashioned "waterfall" company—you do things differently here. You’re "agile". And if the issue happens to involve IT Security, regulations, or anything like that, you’ve struck gold! You can double down by labelling the complainers as reckless, irresponsible, or—my favourite—cowboys. The possibilities for name-calling are endless!

Bonus: Why Train When You Can Blame?

One of my favourite quotes is, "If you think it’s expensive to hire a professional, wait until you hire an amateur." If you think hiring only amateurs is the way to go, you’re missing the big picture. The thing is, some enthusiastic amateurs—given the right environment—could turn into seasoned professionals faster than you’d expect. And that’s exactly what you want to avoid. External conferences? Just tell them they can find the same stuff online for free. Certifications or courses? Nah, it’s just to pad the CVs, no need to pay for that. Internal training? Pfft, they’ll figure it out on the job. In other words, the less training your employees get, the less likely they are to improve or become good at what they do. Rule of thumb: in an office full of amateurs who constantly mess up, you’ll always have someone to blame when things go wrong.

Thanks for reading! Did you enjoy this article? If your response is that you came here "to lead, not to read," then you totally get the vibe of this piece. And if you recognize where that quote comes from, drop it in the comments and claim your bragging rights!