The Best Project
This project was the best. Everything the company had done like this before ended up being a mess, full of stupid decisions, built by idiots. We weren’t going to make the same mistakes again; we knew better. We avoided the terrible legacy systems and built things better from scratch. We did things right the first time, avoiding the failures of previous, similar projects. We had a well-staffed team with a well-planned backlog. We would deliver something big and exciting that we know our customers want and will love. We delivered it. Customers hated it. What the hell went wrong?
Ignorance 🤨
We knew everything that needed doing, and we did it. It turns out, whenever you think you know everything: you actually know nothing. If you believe you have a great memory, you probably forget to do things all the time. Any project that assumes a perfect understanding of the existing systems or your superiority over those that built legacy systems will fail.
(G.K.) Chesterton’s Fence provides a great way of thinking about this.
If you see no reason why a legacy system works the way it does: you are not allowed to change or remove it.
Until you can explain why something was once necessary: you are not in a place to say it is not needed today.
If you can’t explain why but need to change or remove it: tread carefully and remember your ignorance.
Incompetence 😫
We did things right the first time without making mistakes like those idiots before. It turns out that when you aren’t willing to make mistakes: they will be more severe and public.
The Cautionary Tales podcast used two great examples to illustrate this.
The Billy Joel musical was a disaster in previews, but: they learned from this, and it was a sensation on Broadway.
The MacCready Gossamer Condor was the first human-powered aircraft capable of the criteria for the Kremer prize.
The Condor did not win from a perfect first attempt.
The Condor won because it repeatedly failed, iterating and improving each time.
Building software is the same. Don’t try to avoid failing. Try to fail faster and improve faster. Try to fail earlier when it’s just personal embarrassment in front of your coworkers and not your company’s embarrassment in front of customers and competitors.
Remember that some failures will only happen at production levels of system load. Try to get a high system load without customers relying on it. Even after all this: things will fail. You are incompetent, but know you are and plan accordingly.
Insignificance 😕
We had all the needed resources and more; we had complete buy-in from leadership. It turns out that this made the team unwieldy, and the scope exploded to justify the headcount. Instead of trying to get more and make things better, we should have kept things smaller.
Tiny ships get to production quicker where actual customers can test them. Tiny teams build closer bonds, have more shared context and cannot silo. Tiny scope forces you to think about only what’s essential.
You’re calling that a MVP? It’s not minimal at all. Not being minimal means it might not get released in any form, to anyone, ever. An insignificant project is a project set up for success.
The Worst Project 🎉
This project was the worst.
The timelines were aggressive from the outset.
Compromises were necessary everywhere.
We had to use that existing system that was unstaffed and in maintenance mode.
We didn’t know how the existing systems worked, so we had to rely on trial and error.
Failures kept happening, and we didn’t know why.
We didn’t have as many engineers, designers or product managers as we needed.
We delivered something.
Customers loved it.
