The Financial Side of Engineering

As engineers, understanding the financial implications of our work is just as important as mastering code optimization. By integrating financial insights into system design, we bridge the gap between engineering and business goals.

The Financial Side of Engineering
Photo by John Cobb / Unsplash

It might surprise you, but grasping the financial implications of your work is as essential as mastering algorithms or optimizing code. Why? Because every system you design inevitably incurs costs, and understanding these costs can be pivotal for your role and your organization’s success.

As engineers, we're accustomed to evaluating time and space complexity in our code. However, there's another dimension to consider—what I like to call "cost complexity," whimsically represented as $(n). This concept urges us to think about how costs scale as our systems expand, making financial acumen a vital skill in our engineering toolkit.

With costs being arguably the most critical aspect of business finance—as a business might operate without revenue, but never without expenses—exploring this angle is essential. By integrating financial insight into your engineering practice, you can bridge the gap between technical and strategic decision-making, ultimately benefiting your projects and your career.

Understanding Cost Complexity

Cost complexity is all about understanding how costs evolve as your system scales. While it might seem straightforward to calculate costs over recent months, predicting future expenses as your system expands is anything but simple.

Consider a scenario where you host a straightforward app on AWS using:

  • A single serverless Lambda function
  • A single DynamoDB table

Assume a user interacts with your app once a month, triggering the Lambda function to perform a single read operation on your table. Initially, it might seem that costs grow linearly with users, suggesting $(n) is n. But hold on—what about AWS's free tier allowances? Is your DynamoDB table billed per request, or do they have provisioned throughput?

A savvy engineer might even question whether a serverless function remains optimal as user numbers soar. Would a persistent EC2 instance or implementing caching solutions offer better resource efficiency at scale? Are there any savings plans in use or can be used? Spot instances? Reserved instances?

Understanding and communicating how your costs are structured—your system's cost complexity—is crucial for business stakeholders. This involves differentiating between variable costs, like AWS Lambda’s usage-based pricing (billed per request and compute time), and fixed costs, akin to EC2’s flat-rate pricing (yes there are some variable costs associated with EC2 usage as well) over a given period. The way that such costs of the system add up to the final bill are commonly referred to as the cost structure of a business. Knowing the cost complexity of your system is vital to communicating how the costs of the system will evolve over time to your business stakeholders.

Collaborating with Finance: A Critical Partnership

💡
If calculating cost complexity is challenging for engineers, imagine the difficulty finance teams face in estimating cost structures without technical input. Engineers are uniquely aware of the system's tipping points where variable costs might shift to fixed costs and vice versa.

Effectively communicating this information is vital for enabling accurate financial planning and analysis. An open dialogue between engineering and finance ensures informed decision-making, helping the organization to strategically plan for growth and resource allocation.

Understanding Each Other

Effectively communicating the intricacies of your system to stakeholders like a business cofounder, CEO, financial planning and analysis (FP&A) team, or accounting department can be challenging. However, when it comes to financial matters, these teams primarily seek three key pieces of information from engineering:

  1. Service Costs: The financial team needs a clear understanding of the costs of delivering services, often referred to as the cost of goods sold (COGS). This includes direct operational expenses, such as those associated with Lambda functions and DynamoDB tables in the example illustrated earlier. Accurately assessing these costs is crucial for determining the business's profit margins.
  2. Current Cost Estimations: It is essential to provide estimated costs under current business operations. This includes recognizing any impending changes that might impact cash flow, like the expiration of free AWS tiers or reaching usage thresholds. Communicating such information promptly helps the finance team manage cash flow and avoid unexpected budgetary surprises.
  3. Cost Variability with Business Changes: As business activities evolve, costs will fluctuate. Understanding how costs scale with changes like increased user sign-ups allows the finance team to conduct sensitivity analyses and refine financial models. A key metric of interest here is the variable cost ratio, which expresses variable costs as a percentage of net sales.

Optimizing Performance per Dollar

As your business grows, you'll need to adapt your systems accordingly. For example, a SaaS business with a subscription model incurs variable costs that rise with user numbers, such as those from AWS services. As the system develops, engineers may transition from variable cost solutions to more fixed cost solutions (with the caveat being that nothing is ever truly fixed costs, they are merely "fixed within a certain range of usage"). This shift can improve the business's profitability and operating leverage, a concept known as the degree of operating leverage (DOL). DOL measures how changes in business activity affect profitability.

In engineering we may be hastily jump to the "most performant" architecture when designing systems. But in the case of start-ups and even larger enterprises, businesses are more concerned with optimizing the performance per dollar.

It's crucial to recognize these transitions when scaling software systems. For instance, when a single EC2 instance no longer suffices during peak traffic, auto-scaling groups may be deployed. Alternatively, if memory demands increase, upgrading instance types becomes necessary. Each step in scaling affects the system's performance per dollar and overall operating leverage which demands strategic planning and communication between engineering and finance.

What's Cash and What's Not

For a startup, cash is oxygen—run out, and the game is over. But what exactly counts as "cash"?

Suppose your software system costs $1,000 per month, but you only pay the bill once at the end of the year. Now, what happens if the bill is due at the beginning of the year instead?

To manage finances wisely, simply tallying up monthly bills isn’t enough. Timing matters, and your finance team knows it—so should you!

When we launched our Built With Science+ app to our audience recently, our software vendor bills increased significantly. Like most businesses, we work with multiple vendors, each with different billing methods, frequencies, and time periods. As an engineer I wanted to measure exactly how much each user costs us to service while operating the system. However, our finance team primarily focused on cash flows using statements from credit card bills and bank accounts. Without any context, it would be difficult for them to calculate the operating costs associated with our software, especially with costs fluctuating as our user base increased in size.

💡
In order to truly determine the cost to operate your system, you need to be able to reconcile the usage activity within a time period across all your costs. The sooner you understand this concept the sooner that you will get along with your finance team.

Cash vs. Accrual: A Quick Introduction

In accounting, there are two primary methods of recording: cash basis and accrual basis.

Cash basis accounting records income and expenses only when money actually moves in or out of your bank account. This simpler accounting method works for most businesses where tracking cash flow is the primary concern. Cash basis accounting is also prevalent among early-stage startups where the need for accounting is simple, such as keeping track of expenses and taxes.

Accrual basis accounting records income and expenses when they are earned or incurred, regardless of when cash is exchanged. This method is mandatory for much larger enterprises with financial stakeholders who are interested in the flow of capital within the business. Although more complex, accrual accounting offers deeper insights into costs, sales trends, and overall financial health.

In the majority of cases, cash basis will be sufficient for most early-stage startup needs. Accrual basis is more complex and requires greater effort to implement correctly (and ensure accuracy!).

Even if your company uses cash basis accounting, tracking costs in an accrual-like manner can improve operational decision-making.

To Accrue or Not to Accrue

Does this mean you should use one method for everything? No. It simply means you must consider who cares about what.

Cash flow is typically more important for those monitoring the company's financial health, including the CEO, CFO, accountants, or perhaps even investors.

Costs within specific time periods matter to those focused on operating profit and loss (P/L), such as product managers or even engineers like yourself.

Even if your company is using cash basis accounting, you can set up metrics to track costs within time periods to help understand what the total cost to operate actually looks like. Useful metrics include:

  • Dividing monthly active users (MAU) by service costs helps measure cost efficiency per user.
  • Dividing monthly active paying users (MAPU) by service costs helps assess revenue efficiency per paying user.
  • Tracking variable costs per user helps identify scaling inefficiencies.

While this approach does not strictly transform your accounting methods into accrual basis, it makes these metrics much more relevant and useful to your stakeholders.

These metrics are particularly relevant for subscription-based software businesses but can serve as a starting point for developing financial metrics tailored to your organization.

Bridging the Gap

As engineers, we pride ourselves on writing efficient code and designing scalable systems. But true technical excellence isn’t just about performance—it’s also about cost efficiency. Understanding the financial impact of our decisions allows us to build smarter, more sustainable systems that align with business goals.

At the end of the day, businesses don’t just run on technology—they run on financial viability. The sooner we, as engineers, embrace this perspective, the more valuable we become—not just as technical experts, but as key contributors to the success of our organizations.

Bridging the gap between engineering and finance starts with asking the right questions. A shared understanding of costs, scalability, and financial planning ensures better decision-making. Here are essential questions each team should ask to align technical and business strategies:

How does our cloud spending fit into the company’s overall budget?
Understanding whether infrastructure costs are a top concern helps engineers prioritize optimizations.

Are there specific cost targets or constraints we need to meet?
If finance is aiming to keep cloud costs below a certain percentage of revenue, engineering can explore efficiency improvements accordingly.

What level of cost predictability do you need?
Finance teams prefer stable, predictable costs. If usage-based pricing is causing volatility, engineers can look into Reserved Instances or Savings Plans.

How do we measure profitability for our products or services?
If engineering knows the company’s unit economics, they can make technical decisions that align with profit margins and cost structures.

Are there upcoming business changes that could impact infrastructure needs?
Scaling plans, new product launches, or pricing model shifts might require infrastructure adjustments ahead of time.