Introducing a new tech stack

To introduce a new tech stack for the entire team, it’s important to bring “why?” and a strategy to make it happen among the team because it will affect everyone.

Why that new tech stack?

To decide whether to use a new tech stack or not, remember that it is a team decision, according to the standardization and maintainability of the project when introducing such a new tech stack. But, most importantly, what problem do you want to solve by introducing it? Is it because it is “cool”? Or is there an actual “necessity” that this tech helps you with?

The direction of the technology

When proposing adopting a new library, framework, or entire new technology, an important aspect to consider is to be aware of its background and the direction where they are moving forward.

What is the motivation for that tech, and why are you considering introducing it in your current stack?

Coupling and dependencies

When adopting new technologies in our daily business, it’s not rare that we tend to couple ourselves with them. This makes it harder later to roll back if, after a while, we regret that decision.

Don’t get me wrong, learning and experimenting with new technologies is great, but introducing it in your daily work is another story because it will affect the whole team. So we need to be a bit more careful with this.

The focus of the conversation

• What does this new tech contribute to the project?
• What problem do we want to solve by introducing it?
• Can we solve that problem with our current tech?
• If we already have a similar tech, do we want to have a mix of both?
• What are the tradeoffs when using it vs. not using it?
• Does it worth the incremental complexity over time?
• What is the team strategy to onboard everyone if we aim to use it?

Architectural Decision Records (ADRs)

Whatever the outcome, you should write it down as an ADR to revisit it as time passes. An ADR will record your team’s decisions regarding the pros and cons, among any other arguments you have found together, to decide what to do and why.

ADRs are useful to understand old decisions and keep them in the version control – in the same project if possible. They are helpful for the current team, but also for new joiners.

Thanks to my friends Manu, Antonio, and Jesus, who helped me come up with this summary of ideas after brainstorming together.