How to decide a technology change
Engineers chase percent gains and costly rewrites. Learn a system to price ROI in money, compare A/B/current, set stop-losses, and switch only when it pays.
Note: Template for paid subs at the end of the article, scroll down to check it out!
I almost rewrote a Go service to Java because internal tooling is stronger in Java at Amazon. The rewrite looked like a good option on paper. Then I did the math, and it was this kind of “80% of cost to bring only 20% of results”. That is not real progress. That is creating our own busywork.
A productive engineer does not chase percent gains. A productive engineer converts gains to money, headcount, number of alarms... When you do that, fake ROI shows up fast. The more you walk in one direction, the bigger the gain has to be to switch.
This is the system I use to evaluate options and make a decision. It prevents the shiny object syndrome. It also puts decisions into paper so they can be used for a promotion or performance review because leaders understand risk, cost, and time.
In this post, you’ll learn
How to convert performance gains into money, incidents, and headcount saved.
How to compare A vs B vs cur…