Hey. You. Come over here, friend, I want to chat with you.
You look like someone who wants your company to be less profitable. Success keeps hounding at you even though you're trying damn hard to fail. With every fibre of your being, you wish this place would go bankrupt and shut down: with a chain on the front doors and boards nailed over the windows.
Well... don't give up hope. I have a solution that should wipe all chance of success off the roadmap! And I'm willing to share it with you today... for free. 😉
Failed Strategies
I'm sure you're thinking, "I've tried it all. Wreck the customer journey. Become apathetic and expensive, let the competitors eat up our market share."
The problem is, that takes too long to achieve... because your strategy isn't addressing the root of the problem. And that's where you have to go to really muck it up - to the roots!
Identifying the problem
The core of the issue is those stinkin' developers you hired. They keep producing... and they're not just slinging any old crap into production, they're turning out work that delights your customers. Heck, even YOU are impressed with it, despite the fact that you don't want success - you can't help but give them some respect. Every time you implement some price hike or add a new "customer service" process that makes it harder to get support, the dev team comes along and releases some new incredible feature. If we want to well and truly wreck our company's balance sheet, we can't have them being so effective.
Can't we just fire them all?
Unfortunately, no. HR will get wind of that and then Legal and then it's just nasty. The kind of thing that'll make you late for dinner. And even if we succeeded in firing them all, they'll just hire more! So we'll have to be a little more indirect - we can't let on that our goal is to sink the ship. Since we can't just get rid of the developers, we have to make them wish we'd fired them... but what would cause that kind of reaction in really smart, dedicated folks?
The Next Best Thing
The problem with developers is that they're smart AND dedicated. If they were ONLY smart, and not dedicated... they probably wouldn't stick around in an environment where they could see how hard we were trying to fail. If they were ONLY dedicated, and not smart... they'd be much more controllable, and that would actually help us. What we need to do is take one of these traits off the table. We can't make them less smart, so we'll need to make them less dedicated. How could we do that?
Attack their Motivation
Developers are often intrinsically motivated. They love the dopamine hit that comes from solving a hard problem in code. They love the challenge of getting these little rectangles of light to show the lights in the pattern they want.
If we want to destroy the developer, we have to deny them that!
...but HOW?
Add Obstacles that lead to dead ends.
They love a challenge... but it's because they feel so good when they solve the puzzle. If we're going to destroy their motivation, we have to make sure that the puzzles they solve don't have those same kinds of payoffs anymore! Here are a few ideas:
Make it hard to obtain developer tooling... both 'new' AND 'old'
This one's a great place to start - if it's hard to get to the "old" approved tools, new hires will be slow to on-board. This will frustrate them more than anything - they know they're well-paid for their work and they don't like feeling useless or idle. If it's hard to try out "new" tools, they'll chafe at the fact that technology outside the company is changing rapidly, but they can't use it themselves. There are several ways to make tools harder to obtain:
- Make the "approval process" long and cumbersome, and slow down the fulfillment process so that opening a ticket for an installation means they have to wait a few days, even if the software install is 'pre-approved'. Adding wait time is the most frustrating thing you can do.
- Install Corporate Spy-ware tools whose policies lock down their workstations beyond usefulness. "Won't someone think of the Security?" is a wonderful battle-cry, because they can't say they don't care about it!
These two tactics will crush the soul of a developer in just a few weeks. The most 'gung-ho-change-the-world' coding genius will become a mere shell of themselves, curled up in the fetal position underneath their desk, before a month is out. Guaranteed.
Documentation is a Problem.
Even with the previously-mentioned changes, a few really scrappy developers will resist. They'll start making documentation to share with each other... "here's how to bypass all the organizational crap that makes it hard to onboard"... and they'll start giving this to new hires, in hopes that having the workarounds documented will help the newbies' souls not be sucked out of them before they have a chance to make things better.
We may not be able to find and delete all of their documentation, but we can surely make it hard to access!
- Add policies to the "official docs" tool that bottleneck all document changes with one single team. Use the excuse of "needing things reviewed before they're published" or something like that. You can't just add indefinite wait time here or it will backfire on you, but a little increase is possible without them getting wise to your intent.
- Shut down "unofficial" documentation sources as quickly as you can... developers are likely to store them anywhere they can find a quiet corner. Make them hide it - because then it's hidden. The easier it is to find, the more useful it will be.
- When someone makes an official request to research a new "official docs" tool, GET POLITICAL. You can bog them down in proceedings for DECADES if you play your cards right!
Write Processes for ALL THE THINGS.
This is a two-pronged approach; on one hand, you show up under the guise of "researching how things are done today", ostensibly so a product evaluation team can gather requirements for the next developer tooling project. This is you raising their hopes. Then in reality, this is your chance to harden your process manual and make "how we do it today" permanent... dashing their hopes against the rocks! Make sure your processes require SPECIFIC outputs that are only available from the current toolset and would be impossible to modify other products to deliver. Insist that process changes be reviewed by a Board that meets infrequently (quarterly is a good sweet spot; long enough to make process changes cumbersome while not tipping your hand that you never plan to actually change anything). Then, all you have to do is find one pedantic person who can derail the proposal each quarter with some minutiae, or by asking a question that was answered 6 months ago but everyone's forgotten!
All-in-one SaaS Platforms are your friend.
You will eventually be worn down in this battle - developers are tenacious like that. So when you can't hold them off any longer, offer to research a GIANT ALL-IN-ONE SOLUTION and try to reimplement the whole universe at once.
Bonus points if you can get to two finalists here, and insist on a long and costly Pilot implementation! You can siphon a lot more cash by running extensive tests that are based on your process documentation... which is almost certainly not up-to-date, and therefore isn't representative of what you'll actually do with it.
This will come with an easy first obstacle - the price will be exorbitant. You can milk that for a few years... "We can't spend $15 Million on replacing everything now! Sunken Costs Fallacy!"
Shortly after that, you can begrudgingly agree to the huge price tag, with the caveat that ONE TOOL is being purchased so IT MUST DO EVERYTHING. This ensures that the implementation project will go over budget and fail to deliver.
Slow the software release cycle down.
This is a tough one to pull off rapidly, it usually takes some time. In the alleged words of Winston Churchill,
How can you do this?
- Wait for an outage, then knee-jerk your response. Insist that the problem can never, ever, ever happen again. Initiate an Inquisition. Add complexity or wait times to the delivery process in the name of safety and security. You can do it "in the name of the Customer" and if you're really convincing, you might even convince the developers that your goals are noble long enough to gain a foothold without them fighting back!
- Add Approvals EVERYWHERE. Do you need to move some code? Create a Change Advisory Board made up of people who have never written code before. Insist that they approve/deny all requests to push changes to Production. Have an urgent hotfix? Require a VP or higher to sign off on "going outside of process". Convince people that 'urgent' changes are somehow of a completely different class than 'standard' changes.
- WARNING: Under NO CIRCUMSTANCES should you allow the developers to have input into how these developer tools are configured! Again, focus on getting people into decision-making positions for software delivery who have never written code. Or at least, haven't written code since Minecraft was first released! (If you don't know what that is... ask your kids. They can tell you.)
Wrapping up
It's hard to get a company full of intelligent, dedicated folks to fail, but I believe in you. I hate being profitable and successful too, and I wake up every morning just like you, hoping I can cash out my golden parachute and leave a disaster in my wake.
I hope these tips help you to understand the importance of the Developer to your efforts, and give you some practical ideas for how you can prevent them from thwarting your attempts to fail!
Postscript... Blink, are you okay? What did I just read?
Look, I get it. You don't wake up and try to bankrupt your company. I'm using the hyperbole intentionally: to highlight that if you're struggling to improve things in your shop, you've likely overlooked the opinions of the biggest potential force-multipliers on your team. A developer who's empowered and enabled can make entire other departments more efficient. It follows, then, that Developer Experience (defined by Microsoft as "how easy or difficult it is for a developer to perform essential tasks needed to implement a change") needs to occupy a very high-priority space on your to-do list.
I really liked the phrasing in this Psychology Today article:
Cater to the emotional needs of the people who actually do the work.
Focusing on your developers, making sure they're empowered and not impeded... this is what will make the changes that you want possible. Start there.
Top comments (0)