The phrase “Burn the Boats” comes from historical military events. It’s a phrase used once in a while in the tech industry. I used it recently and thought to write about it.
In 1519, Hernan Cortez wanted Aztec treasure. He invaded the Yucatan shores with only 600 men. Clearly, he was vastly outnumbered by thousands of Aztecs. Some of Cortez’s crew thought they were going to be slaughtered and wanted to flee to Cuba. What did Cortez tell them?
“Burn the boats!”Hernan Cortez, 1519
By destroying his own boats, he eliminated retreat as a possibility. The only option was forward. The only option was success. His army did exactly that. They conquered the Aztecs and took the Aztec ships to replace their own.
When used in tech, it usually is related to decision where a big change needs to happen. It can be anything but some common ones are:
- New database
- New information architecture
- New client-side framework
- New project management tool
- New SDLC methodology
You can imagine lots of situations where the change is a big deal and many things in the organization would need to change. None of these things deliver “features” but features are not delivered in a vacuum. These things will affect performance, speed of development, quality, and user experience. Not having these things accomplished adds up to major problems with technical debt.
When faced with this situation, every option feels bad. You basically have three options:
- Delay the improvements and live with the old legacy stuff longer. This obviously causes a slow rot within the organization.
- Hybrid. Move forward with the new system and also support the old system at the same time. In some ways this is the worst of all choices because you get neither speed nor safety. You end up splitting your team’s minds into two and making everyone crazy.
- Burn the boats! This option is the stop development on the old and push everyone to the new as quickly as you can. The bad side of this is that you won’t have new features for a while.
Each of the choices has Pros and Cons. There is no free lunch. Most times this happens, companies choose to delay. This is the entire reason why disruption by new competitors is so common. When a company becomes large, it usually builds up enormous technical debt which slows improvements to a crawl.
I believe that burning the boats is the best option for a large company. If you make it a cultural value that technical debt is not something to be amassed, then you must replace systems once in a while.
User interfaces are often the most common thing requiring replacement. No technology has lasted more than 10 years and usually it’s much shorter than that. If you architect your system correctly and separate concerns with strong APIs you can replace pieces without disrupting the whole.
No one said making an amazing product and scaling it to enterprise levels was going to be easy. It takes courage and conviction to burn the boats and eliminate retreat.
Does your organization have this courage?