Wrong tech stack will kill your project

Throughout my childhood my dad used to say "If you start with a wrong button, the entire shirt is going to look crooked."

If you start a project with an unfitting stack, you will not be able to finish it. The worst thing? You will find out that it's doomed 60% into it, after spending most of your budget.

There are multiple scenarios why you might end up with a wrong stack:

  • You might have been sold something that looked good in a demo
  • You might not have had all the business requirements before start
  • The discovery phase was limited in time or access to various stakeholders
  • You might have inherited technology decisions made before your time

What do you do in this situation? I would suggest several steps:

  1. Step back and re-evaluate. When a project is failing it's natural for strong leaders to thow themselves into the mix and start doing something. That would be a mistake. As leaders we have to think 5 moves and several years ahead. You need to ask youself: will fixing short term problems dig you even deeper long trem? Do we need to make a rollback to come up with a better solution that would solve a particular cluster or problems we are currently experiencing? Do we need to go back to square 1? What would be the impact on the business side? How would proceeding or rolling back impact organizational tactical goals?
  2. Negotiate a multi-phase mitigation plan. It's very rare that you have to tear everything down and start anew. Can you salvage anything and release the project with a smaller scope? For a lot of technical leaders it's a matter of professional pride to build products properly the first time, I'm one of them. But we all have to contend with other constraints, like business goals, committments to clients, etc. As a tech leader, you can negotiate release of a slimmer project to meet outside requirements with a multi-phase plan to catch up on the functionality and technical debt. In that case you can still deliver value and buy yourslef some time for refactoring.
  3. Hold an extended discovery phase and start to building a solid foundation. Once you've been able to take the temperature down by releasing a temporary solution, it's time to do a proper discovery phase where you can hear and evaluate needs of all stakeholders. This will inform your choice of underlying technology. This also would be a good time to get some people off the bus and pick up strategical fits for your team.
  4. Follow-up with stakeholders regularly. What has worked yesterday will not necessarily be satisfactory today. Keep regular contact with all internal and external groups who depend on your system for everyday operations. Their feedback will give you a plan for future adjustments, ideas for new applications and ensure good adhesion between business and tech.

Innovation is not a destination, it's a journey. Good luck!

Yuri Kurat
Seattle