Previously published on Forbes on 4/14/2021
As CTO, you know when the current code base is too old: it takes forever to get new features out, response time for end-users is slow, tools are outdated, etc. Yet these issues barely trigger a raised eyebrow from your CEO. So, how do you get your point across?
The first step in convincing your CEO that a new tech stack is needed is to articulate the point in the context of the company’s objectives, rather than solely the engineering team’s perspective. I’ve written about a similar approach to technology debt, except the impact on the success of the company is much higher in this instance.
“Rearchitecting the tech stack” refers to any project that requires more than roughly 25% of the engineering resources for more than a quarter to refactor or rewrite existing functionality without adding any major features visible to end-users. The rewrite is typically driven by:
• The need to scale in performance (e.g., number of users and transactions, reduce response time)
• The need to increase development velocityMORE FOR YOUUniqlo Intends To Become The World’s Top Fashion Retailer By Distancing From H&M And Zara
• The need to migrate to new technologies (e.g., open up the application via REST APIs, adopt a new data storage technology, move to the cloud)
Notice the use of the word “need” rather than “want.” The need has to be imperative.
It’s A Normal And Good Thing
No one would expect a company generating a billion dollars in revenue to be using the same technology stack it was using when it was a three-person startup. Consequently, we must anticipate that a company on its journey from $0 to $1 billion will morph its business a handful of times and, in parallel, its technology will go through “nonlinear” transformations.
Tech stack rewrite, being a natural consequence of the growth of a company, can and must be anticipated. You may not know two years in advance when exactly the current tech stack will reach its limits, but know that it will happen. In order to prepare for this event, you must:
• Review the business plans, technology and product roadmaps regularly (e.g., quarterly) to identify future disruptions
• Continuously monitor core performance metrics of the application and interpolate them 12-24 months according to business projections
• Reserve funding for the time when the tech rewrite will be required (e.g., allocate a portion of any new VC round of funding toward a tech stack rewrite)
It’s A Business Decision
CTOs often find it difficult to convince a CEO and the exec team of the imperative to perform the technical rewrite. Typically, this is because the two parties are not speaking the same language: one is talking about technical pros and cons while the other is talking about customer benefits and dollars.
As much as possible, the CTO must make a “bottom-line” argument tied to the company’s core metrics: dollars of revenue, monthly users and daily transactions. For example, “Our current infrastructure can support 1 million transactions per day. Our tests show that at 1.5 million transactions, we’ll experience service degradations while our business projections predict 2 million daily transactions in 12 months. Half a million of lost transactions represent a $2 million loss of revenue per quarter, whereas the tech stack rewrite will cost $3 million; as a result, we break even in less than two quarters.”
The CTO can articulate the business case in four basic points:
1. Why? What problems will we solve? What benefits, to customers and investors, will we derive?
2. How much? How long will it take? How much money will it cost? What customer-facing features will be delayed? What will “no action” cost?
3. Why now? Why we cannot afford to wait and why we cannot do less.
4. What are the risks? What are the risks of not doing it now? What are the risks (technical, financial, schedule) of the project?
Like any investment decision, setting the proper time frame is important. By nature, tech stack rewrites are infrequent, and thus the proper horizon to present the ROI should be two or three years (not quarters). Finally, the CTO needs to look “over the horizon” to account for the time it takes to deliver the first installment of the new architecture but also all the prior preparation: making the business case, securing approval, designing the new architecture, hiring the team, etc.
Doing Nothing Is Also Risky
While it is clear that allocating funds to a complex and lengthy project presents risks, doing nothing presents another type of risk that cannot be ignored. If you are lucky enough to experience high growth, the last thing you want to deal with is buggy software that fails at times of peak demand.
First, customers are upset because the current software does not behave. This creates stress for everyone in customer service, operations and engineering. This stress, in turn, creates pressure to cut corners in coding standards, processes and testing, when they are needed more than ever on this brand new code. Finally, and most importantly, the company risks missing out on its growth potential. If the upgrade comes too late, dissatisfied customers will go to the competition.
The architecture and technical stack of a software product evolve incrementally most of the time, yet periodically require a fundamental rewrite. This is an expected result of the growth of the company. As such, it needs to be monitored through a 24-month technology roadmap and informed by the product roadmap and business projections. In particular, each funding round should allocate part of the proceeds to a new round of architecture and software stack upgrades.
Because of the large investment required and impact on the product roadmap, technical leaders need to translate the technical analysis into a business case that can be debated with the rest of the executive team, presenting not only costs but also risks (including that of doing nothing), as well as long-term benefits to the company’s end users and its bottom line.