Most people assume sabotaging a technology company requires sophisticated espionage, malicious insiders or perhaps someone accidentally deleting the production database.
This is unnecessarily complicated.
There is a much easier approach.
You can destroy an enormous amount of value while appearing, to the casual observer, to be doing an excellent job.
In fact, if you use enough sufficiently impressive terminology, people may actually congratulate you for it.
Here is how.
1. Replace boring technology that already works
Nothing says “technical leadership” like replacing something reliable.
Perhaps the company has a boring Ruby on Rails application. It serves customers. Developers understand it. Deployments are straightforward. Incidents are relatively easy to diagnose.
Unacceptable.
Move it to Kubernetes.
Ideally, introduce several new services, a service mesh, distributed tracing, multiple queues and at least three different forms of configuration management.
When somebody asks what problem this solves, explain that you’re “preparing for scale.”
Do not allow the company’s complete absence of scaling problems to distract you.
The important thing is that the architecture now resembles the architecture of a company approximately 500 times your size.
2. Replace things that are 95% good with things that are 100% unfamiliar
Successful companies accumulate boring systems.
Databases. CI pipelines. Deployment systems. Authentication providers. Frameworks. Libraries. Monitoring tools.
Some of them will be imperfect.
This presents an opportunity.
Whenever you discover something that could theoretically be 5% better, replace it entirely.
Ignore migration cost.
Ignore retraining cost.
Ignore the bugs you will introduce.
Ignore the organisational knowledge embedded in the existing system.
Most importantly, never compare the theoretical improvement with the switching cost.
A useful rule is:
If the new technology looks slightly better in a benchmark, you should probably rewrite production immediately.
For bonus points, call this “reducing technical debt.”
3. Learn new technology in production
You could experiment with unfamiliar technology in a prototype, a side project or a low-risk internal application.
But where is the excitement in that?
Instead, identify the most strategically important part of the company and use that as your learning environment.
Never built an agentic AI platform?
Excellent.
Build the company’s core operations around one.
Never operated a large distributed system?
Time to introduce one.
Never operated a critical platform you don’t fully control?
Perfect moment to make the company’s core operations dependent on one whose behaviour, roadmap and economics you don’t control.
The less experience you have, the more ambitious the implementation should be.
Confidence is a perfectly acceptable substitute for competence.
4. Build everything yourself
Buying software is what unimaginative companies do.
Smart engineers build things.
Authentication?
Build it.
Workflow engine?
Build it.
Deployment platform?
Build it.
AI orchestration system?
Absolutely build it.
Internal developer platform?
Obviously.
The ideal outcome is an important piece of company infrastructure that is understood by exactly one person.
This has two advantages.
First, you become indispensable.
Second, any attempt to change ownership becomes operationally terrifying.
Some people call this a “key-person dependency.”
You should call it “platform ownership.”
5. Solve tomorrow’s theoretical problems before today’s real ones
Customers may be complaining about onboarding.
Revenue might be flat.
Deployments might be unreliable.
The support team might be drowning.
Ignore these distractions.
The highest-value technical work is always the problem the company might theoretically experience three years from now if growth increases by several orders of magnitude.
Build for that.
Your ten-person engineering organisation should have infrastructure suitable for Google.
Your database should be designed for billions of events you do not currently generate.
Your architecture should support geographic distribution across markets the company has never entered.
Whenever somebody questions the investment, explain that you are “avoiding future rework.”
Never calculate the enormous amount of current work required to avoid this hypothetical future work.
That would ruin the argument.
6. Make the largest bets in the areas where you have the least expertise
Experts are irritating.
They understand edge cases.
They worry about operational characteristics.
They ask boring questions about recovery procedures, cost, vendor lock-in, maintenance and failure modes.
Beginners have none of these limitations.
This makes unfamiliar domains particularly exciting places to make enormous architectural bets.
There is even a convenient psychological mechanism to help.
The less you understand a domain, the easier it is to believe the domain is simple.
This allows you to confidently announce things such as:
“How hard could this be?”
“We can build that ourselves.”
“This vendor is ridiculously expensive.”
“We’ll have this rewritten in six weeks.”
If someone with actual experience disagrees, remember that they are probably just resistant to change.
7. Optimise engineering sophistication instead of company outcomes
This is the most important rule.
Never allow engineering decisions to become contaminated by commercial considerations.
Revenue is somebody else’s problem.
Customer retention is somebody else’s problem.
Time to market is product’s problem.
Gross margin belongs to finance.
Your responsibility is architecture.
The best technical strategy is therefore the one that produces the most technically impressive system.
Extra points are awarded for architecture diagrams that require multiple monitors to view.
If an engineer can explain the system to a new starter in ten minutes, it is probably insufficiently sophisticated.
8. Confuse irreversible decisions with innovation
Good engineering teams run experiments.
That is dangerous because experiments are small, measurable and reversible.
Instead, make enormous commitments.
Replace the architecture.
Change the database.
Introduce a new language.
Migrate the infrastructure.
Build a proprietary platform.
Then announce that the company is “moving fast.”
There is a crucial distinction here.
Moving fast means increasing the rate at which you learn.
Making enormous irreversible decisions quickly simply increases the rate at which you can discover you’ve made an enormous mistake.
Fortunately, by the time that becomes obvious, you can describe the resulting remediation project as another transformation.
9. Drive away anyone who remembers why things are the way they are
Long-serving engineers possess dangerous information.
They may remember why certain architectural decisions were made.
They may know which experiments previously failed.
They may understand obscure customer requirements.
They may even point out that your exciting new proposal was attempted eighteen months ago.
This can seriously interfere with progress.
Fortunately, experienced engineers are quite easy to remove.
Dismiss their concerns as negativity.
Exclude them from decisions.
Rewrite systems they own without consulting them.
Describe caution as resistance.
Eventually they will leave voluntarily.
You can then explain that their departure demonstrates why the architecture needed modernising.
10. Make yourself the bottleneck
Finally, ensure every important technical decision passes through you.
Create systems only you understand.
Introduce tools only you know how to operate.
Own the documentation.
Own deployment.
Own the roadmap.
Own the architecture.
This produces a remarkably effective form of organisational leverage.
The company cannot easily challenge your decisions because doing so risks breaking infrastructure that only you understand.
At this point you have achieved the ultimate engineering leadership milestone:
the business now works for the technology instead of the technology working for the business.
Congratulations.
You have successfully sabotaged a technology company without ever needing to behave maliciously.
In fact, you may have done the entire thing while sincerely believing you were improving it.
Which is what makes this particular form of sabotage so effective.
Of course, none of this is actually advice.
The interesting question is the opposite:
What does responsible technical leadership look like when you remove the architecture astronautics, résumé-driven development and uncontrolled experimentation?
That is the subject of the next post: How to Make Technology Boring, Reversible and Extremely Valuable.