Do not let your developers play with your business
Business always needs things fast, which is why selling them a great but expensive architecture can sometimes be easy and other times, extremely hard. Programmers, on the other hand, love new things.
To them, each new framework, tool, package, or gem seems better than the last, and databases are no exception. Consequently, when a new project starts, there is a big temptation to pick whatever is hyped and cool. If it is a truly brand-new project, the business will likely agree. After all, what choice do they have when there is no baseline to show them any other way? But once the business has a concrete example of how things can run, selling them on an expensive refactoring becomes a much tougher sell.
Take, for example, a new product that once emerged from a legacy codebase. Extracting it and giving it its own home was a fully justified idea, and because there were big plans for its future, the business funded it generously.
Naturally, the programmers were thrilled. They got a greenfield project- a playground to try whatever they liked. A new programming language? Sure! A new database? Sure! A new architecture they had just read about on Medium? Sure! Well, they were not to blame. After all, we all seek opportunities to learn and gain new experiences, and this felt like the perfect time to explore.
From the business perspective, though, this setup was not such a great idea.
Some years later, when the product failed to meet expectations, the company decided to pivot- specifically, to build a new product drawing on past experiences. While this was a wise decision product-wise, the technical landscape was no longer a blank canvas. Instead, it was like renovating an existing house and adding an extension. Consequently, the business would no longer buy into the need for a new database, a new language, or a new architecture. After all, they now had a clear baseline showing what could be done, how fast, and what the results actually looked like.
And that is exactly when past decisions started hitting back. First, the database, hyped years ago, was now in a barely maintainable state due to a lack of experience working with it. Meanwhile, the programming language, though a great choice for other cases, had become a heavy burden due to a lack of team expertise. Finally, the architecture, built as a playground around the first two, was barely holding itself together.
In other words, the new project started not at zero, but at -100. It took the team at least a year just to untangle those past decisions and stabilize the legacy codebase before they could speed up and build new features. Sadly, that delay proved fatal, and the product died before it was even fully released.
As a tech lead, team lead, or business owner (depending on the company size), giving your developers freedom is important, but doing so without guardrails can come at a very high cost. One of the safer ways to channel this creativity is through regular hackathons. They offer the freedom to experiment and innovate without risking the core product and might even give birth to your next great feature.