The way to cripple a company is to get bad people promoted into management and have them optimise something plausible but not profitable. Like what happened in a lot of slow-fail engineering companies - insist on maximising the profit metric to the point where the actual product becomes compromised. That strategy can be intiated from almost anywhere in management too because a constant "what if we optimise for profit" [1] usually does well at meetings.

Being a destructive CTO is almost too easy. Just don't do anything much, weed out any competent people in the level below you and develop a culture of pushing blame aaaaalllllllll the way down the org chart, ideally out of the technical part of the tree, so that nothing broken gets fixed. When people catch on, allow blame to move 1 level up the org chart and do a big shakeup to clear out any institutional knowledge that might have built up in spite of you. That game can go on for years.

[0] I've seen people where "do things through official channels" and "demand written orders" would have made them more productive. We are our own worst enemies.

[1] Yes, the irony here is that naive optimising for profit is typically not profitable.

Not quite right. The Office of Strategic Services did that. The CIA was created only in 1947 several years after the end of the second World War in 1945.

I think in that light, number 1 is to foster an atmosphere of fear where anyone attempting to make things better will be confronted if things don’t go perfectly.

I feel like this, in some capacity, is borderline inevitable in the modern architectures with a bunch of external services, or at the very least will 100% require that your devs are connected to the Internet all the time to be able to do anything, vs systems that are 100% self hostable.

Or even just running a complex Kubernetes cluster with a service mesh and other solutions on the test/staging/prod infra vs loosely mapping to more lightweight options locally, unless you have a super beefy setup. And even then, if everything is split into multiple separate services far enough, you just won't be able to run everything locally, meaning that you need to use some of the components from shared dev environments which will inevitably lead to stepping on each other's heels.

Once you go past something like Docker Compose for local environments, things can go sour.

It's a miracle that somehow the company remains in business.

(Some may counter this with Hanlon's razor [2]; Never attribute to malice that which is adequately explained by stupidity.)

[1] https://www.eff.org/

[2] https://en.wikipedia.org/wiki/Hanlon's_razor

Plus calling these things "sabotage" isn't right even as a metaphor, and IMO confuses the issue. These people aren't on a third-party payroll, they are just self-serving.

No one is creeping into your office in the middle of the night. You invited them over, let them in, watched them piss in the fish tank, and then gave them a promotion and a raise. Now you're surprised everyone is lining up to fuck up the place? As usual the value judgements are just a distraction in matters of economics, look at the incentives.

Deploying infrequently doesn't necessarily sabotage things if it results in well-written and tested code before deployments, which tends to create stable systems. If anything, it's the opposite of "move fast and break things." If you want to sabotage things, urge frequent deployment and minimal testing.

> This is from the 1994 music video Sabotage by Beastie Boys. The lyrics are mostly about technology leadership and developer productivity.

That caught me off guard. Well done.

Security and compliance benefit heavily from this approach, and I'm sure it can be extended elsewhere as well (architecture reviews etc).

The article kind of missed that detail, but this form of sabotage doesn't even need to be that effective to deeply sabotage the organization/product, it just has to be bad enough to scare off good talent and keep turnover high. The stuff in the "hiring" section makes it even worse by preventing good people from even getting in the door in the first place, but eventually a company like this would be scraping the bottom of the barrel for candidates even without deliberately bad hiring practices.

Is the sabotaging bit here the "complex" part?

> Encourage a complex dev setup: running a service mesh with a dozen services at a minimum.

...

> Build in-house versions of almost anything that's not a core competency.

So if you need functionality A, B, C ... H, what do you do? Do you build them all in-house or do you have 9 different services each providing the functionality required?