Questions to ask when adding new tech to your infrastructure

I have often been often faced with the choice of adding a new piece of technology to a company’s tech stack. In the past, I would always find my reasons to advocate for the addition. After all, part of the “fun” of being a software engineer nowadays is constantly learning and experimenting with the latest technology so as not to get left behind.

Nowadays, I approach this decision much more carefully than in the past because frankly, I have come to realize that there are no silver bullets. A few times, I have also ended up regretting the decision.

Aside from the initial cost of time it would take to add the new piece of technology, here are some things you can do to evaluate whether a new change is even right for you and your development team:

  1. What is the problem I am trying to solve by adding this new technology to the stack? If you cannot clearly articulate what you are hoping to accomplish and how it will clearly improve the current state of your technology infrastructure, it should be a red flag for your new piece of tech.
  2. Time to realize benefit of added change. If adding the technology will not improve something immediately, at what point will your development team or stakeholders realize these benefits? Will it be in 1 week? 1 month? 6 months? Unless you are a hot startup exploding exponentially into the stratosphere, if you stand to only realize a benefit in six months, you are better off just letting it go.
  3. Cost of convincing and training other team members. Taking up the role of evangelist for XYZ service or app is no easy task when you have work as a team. Aside from the technical challenges involved, you will also need to get a good sense of how your fellow team members will receive this new change. Will they respond with enthusiasm or with skepticism? This is where you need to be diplomatic and have conversations with people who are opposed to the idea. Try to get a handle on what their concerns are. Seek to move forward together as a team. In my experience, there has never been a time when adding a piece of tech turned out to be more valuable than potentially losing good developers.
  4. Do some form of quantitative analysis to figure out if the added change actually helps the bottom line. May be overkill for most mid-small sized companies but definitely useful. This allows you to be less fanboy and/or “hand-wavy” with your decision. Courses like HEXT’s CSCIE-43 will allow you to communicate about risk in a much more structured way (It is an excellent course for any developer and I recommend it highly). One technique is to perform a Monte Carlo Analysis to convey risk with respect to likelihood and magnitude. For those that are interested, I will be posting a case study of Monte Carlo analysis that I did very soon.

If at the end of the day, you can still find the benefits outweighing the cost, then pat yourself on the back for putting your idea through some form of rigor.

What other ways can you think of to introduce new changes to your tech stack without it significantly affecting cost?