Kolawole Olowoporoku is a seasoned expert in designing distributed systems, bringing over six years of experience from diverse industries. He currently serves as a Site Reliability Engineer at Sekai, where he manages and enhances their systems on a daily basis. His primary focus is on developing scalable applications through a combination of DevOps practices. Kolawole writes on how CTOs can adopt cost centric approaches in technology decision processes.
Traditional design principles suggest that cost should be evaluated last, after all design considerations have been met. However, without integrating cost into every design decision, suh designs are likely to fail over time. A cost-centric philosophy integrates cost considerations into the core of technology planning and execution. This means evaluating the financial impact of every design choice.
In traditional IT days, technology spending was managed by the Finance Department. A request for a server or products would be budgeted for and sent to finance for approval. Today, CTOs have taken on a finance-like role, effectively becoming CFOs of IT. No one else can have as deep visibility into IT spending as the CTO. In many businesses, technology spending accounts for around 12% of total expenses, and for startups, this is often higher. CTOs must understand that neglecting cost in every decision invites unnecessary financial pressure in the future.
CTOs or Engineering Managers should be responsible for overall technology budgeting. They’re the only ones who have full visibility into IT spend, and they’re the only ones who can balance performance and cost. CTOs are often praised for building performant systems, but they should also be evaluated based on building cost-efficient, performant systems. Gone are the days of considering cost after design. Technology cost today is as important as performance.
Balancing Cost-Efficiency and Innovation
Technology stacks often come with a significant price tag, which can act as a deterrent against wasteful spending. Even if all design decisions can be debated, justifying wasteful expenses is difficult. A phrase I like to use is “Know thy Stack” and know it well. Wasteful spending often arises from a lack of deep understanding of one’s own stack. When you truly know your stack, trends and external best practices won’t faze you. You’ll evaluate and move on.
There are many design patterns to follow today, with debates on which cloud to build on, the right platform (serverless, Kubernetes, managed containers, self-hosted DBs, or managed DBs), etc. The “Know thy Stack” philosophy means understanding which tools can deliver the expected performance over time at the best price point. Often, decisions are made based on projections that never materialize. Businesses spend hundreds of dollars expecting future scalability that may never be needed. If you truly know your stack, why make extensive plans for the future that may not be necessary?
It’s easy to waste money on technology due to the plethora of products and methods available. For most early-stage startups, terms like scalability, disaster recovery, and high uptime shouldn’t be primary concerns. While important, it’s essential to determine if and why you need them before investing heavily
Summary
Of Course, there are several ways to build and no one right way of building. But understanding exactly the purpose of a particular tool or technology at what stage a business is currently in is a skill only the CTO can truly know and it’s the only way to justify any and all technology spend.
I worked with a customer to migrate RDS DBs to Kubernetes. In theory, people today will tell you managed databases are a no-brainer, but for this customer, it led to a 40% reduction in cloud spend while still serving user traffic with good performance. Another customer moved containerized workloads from Managed Kubernetes to a Docker Compose Solution. The point is, the answer isn’t always Kubernetes, Docker, or serverless. The answer lies in providing value at the lowest possible cost. Find your solution and make it yours.
