Burn multiple and the engineering story behind cash use

Why burn multiple feels far from the work

A finance dashboard can turn a messy month into one clean ratio. Burn multiple asks a simple question: how much cash did the company burn to create one unit of new growth?

That is useful. It is also why the metric can feel distant to engineering teams.

Engineers do not spend their week thinking in ratios. They think about the backend hire that took two months to fill, the outage that pulled senior people off planned work, and the release that slipped because support kept piling up. Those are the real events. The ratio is what they leave behind.

That gap creates tension. Finance sees one number moving in the wrong direction. Engineering sees several smaller pressures at once: too few people covering too much work, incidents eating roadmap time, support tickets turning developers reactive, and infrastructure costs rising before revenue catches up.

When nobody connects those dots, spend starts to look careless. Often it is not. A team may be paying for old architecture choices, carrying too much manual support, or losing speed because the same people build, fix, and answer customers all week.

The fix is simple, but it takes discipline. Trace daily work back to cash use. Which delays pushed revenue into next month? Which incidents added cloud cost or contractor time? Which support problems blocked new delivery?

Once that story is clear, burn multiple stops sounding like a finance complaint. It becomes an operating result. That changes the conversation, because people can discuss causes instead of arguing over the ratio itself.

What moves the number each day

Burn multiple shifts long before finance closes the month. It changes in small daily choices: who handles customer issues, which services still run in the cloud, and how fast product work reaches users.

Salaries are the biggest cost for most software teams, but payroll alone does not explain much. Two teams can spend the same amount on people and get very different results. One team ships each week, fixes support pain quickly, and keeps infrastructure lean. The other spends half its time on rework, waits on slow releases, and pays for tools nobody really needs.

Cloud costs usually drift upward in boring ways. Old environments stay online after a migration. Test databases run all month. Logs, monitoring, and third party tools pile up because nobody owns cleanup. A few leftovers can quietly become a monthly habit that costs tens of thousands.

Support load changes the picture just as much. If engineers spend hours each day answering tickets, digging through incidents, or fixing accounts by hand, that time does not go to new features or revenue work. Payroll stays flat, but output drops.

Then there is delivery speed. Slow releases delay experiments, product improvements, and sales follow-up. If a team needs six weeks to ship a simple change, revenue moves later while costs keep running on schedule. Burn multiple looks worse even if spending did not spike.

Seen this way, the metric is less about finance and more about operations. People, infrastructure costs, support load, and delivery speed all push the number. Put them together and the ratio starts to make sense.

How team shape changes cash use

Team shape changes burn faster than many founders expect. The salary line is obvious. The hidden cost is coordination.

Every handoff between product, design, engineering, QA, and support adds waiting time, meetings, and rework. A small team with clear ownership often uses capital better than a larger team split into narrow roles too early.

If one engineer can make a change, test it, ship it, and check support feedback, the work keeps moving. If four people touch the same task, the company pays for the gaps between them.

It helps to count those handoffs on one normal feature. If a simple change moves through six people before release, that is not just process. It is cash.

Managers matter too. A good manager removes blockers, makes decisions, and cuts delay. A manager who mainly asks for updates can turn one problem into three meetings. That cost rarely appears in a budget line, but it still pushes burn in the wrong direction.

Company stage matters when you compare senior generalists with narrow specialists. Early on, generalists usually win. They cost more per person, but they need less oversight and can move across code, infrastructure, and product decisions. Later, when work grows and repeats more often, specialists can make more sense.

Onboarding time is another blind spot. If a new hire needs six to eight weeks before shipping useful work, burn rises long before output does. Measure how long it takes that person to merge code, fix a real issue, and handle work without constant help.

A startup with five strong generalists can spend less and ship more than a team of ten built around handoffs. Capital use looks deliberate when the team can decide, build, and support the product without waiting on itself.

How infrastructure choices raise or lower burn

Infrastructure spend grows quietly. A team adds a hosted database, a second error tracker, faster build runners, and a bigger Kubernetes cluster for safety. Six months later, the bill reflects old fears, not current traffic.

Start with a plain inventory. Write down every paid service, its monthly cost, and who actually uses it. Include cloud instances, managed databases, CI runners, monitoring, logs, feature flags, and the SaaS plans engineering forgets because finance books them somewhere else.

Most audits find the same kinds of waste. Teams pay for tools that do the same job, enterprise plans used by only a few people, storage that keeps old backups and logs too long, and capacity bought for traffic that never arrived.

Overlap is common. One company pays for GitHub Actions, a separate CI service, and extra cloud build minutes at the same time. Another keeps two monitoring stacks because one group likes dashboards and another likes alerts. That is not a technical requirement. It is double billing.

Traffic assumptions matter too. Many teams run production as if next year's scale has already shown up. If traffic is still modest, a simpler stack can carry far more than people think. Oleg Sotnikov has done this kind of right sizing in production systems by cutting redundant services, keeping uptime tight, and avoiding oversized cloud spend.

Logs and licenses deserve their own review. Log bills climb fast when debug events stay on forever. Storage keeps growing in the background. Seats pile up after contractors leave or teams switch tools. A few forgotten enterprise licenses can cost more each month than a small product fix.

When you explain burn multiple, do not treat infrastructure as a fixed line item. Show the choices behind the bill, who made them, and whether current traffic still justifies them. That makes monthly burn look deliberate instead of messy.

How support load cuts output

Support work looks small when you see it one ticket at a time. In practice, it can eat a big share of engineering hours. When that time stays invisible, burn multiple looks worse for reasons the finance sheet does not show.

Start by separating the work. A bug report is not the same as a setup question, and neither is the same as an account issue like billing access or a broken login. If you lump everything together, you miss the pattern and engineers spend the week reacting to random interruptions.

A simple weekly log is enough. Track total support hours from engineers, rough ticket categories, repeat problems that came up more than once, and any support work that turned into a code change.

The hours matter more than most teams expect. If five engineers each lose four hours a week to support, that is roughly half a person's time gone every month. Salaries do not change, but delivery slows and planned work slips.

Repeat problems usually hide the easiest wins. A confusing setup flow can create the same question every day. A weak admin tool can force engineers to fix account issues by hand. One product change, a clearer error message, or a small internal script can remove dozens of interruptions.

Support pressure also creates more support pressure. Engineers jump between feature work and urgent customer issues, lose focus, rush, miss details, and create new bugs. Then those bugs generate more tickets. The cycle is expensive.

Support load is not only a customer service issue. It is part of engineering efficiency. Oleg often frames it as a basic operating choice: count the hours, find the repeat pain, and remove the cause. Teams usually get faster without adding headcount.

Why delivery speed changes the ratio

A team can spend the same amount each month and still look much better or much worse on burn multiple depending on how fast work reaches customers. Burn runs every day. Revenue impact waits until a change ships, gets used, and solves a real problem.

Small releases help because they test assumptions early. If a pricing page change, onboarding fix, or workflow improvement goes live this week, the team learns quickly. Customers adopt it, ignore it, or complain. That feedback is much cheaper than building the wrong thing for two months.

Slow delivery hides waste. When engineers sit on long branches for six weeks, product managers guess, QA piles up at the end, and release day becomes a bottleneck. Salaries stay the same, but proof of value arrives late.

Rework bends the ratio more than people expect. A feature that ships late and misses the mark often gets redesigned, rebuilt, retested, and explained again to users and support. The company pays for the same learning twice.

A simple startup example makes this obvious. Suppose five people spend two months building a large reporting module. After launch, users care about one export and one filter. Half the work never mattered. If the team had shipped the filter first, they could have learned that in week two and stopped the rest.

Fast feedback does not mean pushing sloppy code into production. It means using a release process that helps the team learn early, cut weak ideas sooner, and spend money on work that can earn it back.

How to trace it step by step

A useful burn multiple review starts with one rule: compare the same period on both sides. If you use one quarter of net burn, use the same quarter of net new ARR. Mixing monthly costs with quarterly revenue makes the number noisy.

Then break burn into buckets the team can actually change. For most software companies, that means people, infrastructure, software tools, and support effort. Keep it plain: salaries, contractor fees, cloud bills, third party services, and the time engineers spend fixing customer issues.

1. Write down net burn and net new ARR for the same period.
2. Split major costs into people, infrastructure, tools, or support.
3. Next to each line, note what it buys or what it blocks: shipped work, uptime, customer help, incidents, or waiting time caused by handoffs and rework.
4. Mark which lines the team can change this quarter. That might mean removing duplicate tools, fixing the part of the product that creates repeat tickets, or cutting a slow approval step.
5. Recalculate the ratio after operational changes, not only when you prepare a board report.

This mapping matters because cost alone says very little. A bigger cloud bill may be fine if it supports paying traffic or prevents outages. A larger support load is a warning sign if engineers spend half their week on tickets instead of shipping.

Short notes help more than a perfect spreadsheet. "Database cost rose after we added replicas to stop latency spikes" tells a real story. "Infrastructure went up" does not.

When the review works, finance and engineering stop arguing over the number. They can point to the same line items and explain what changed, what caused it, and what they can fix in the next 90 days.

A simple example from a software startup

Take a SaaS team of 12 people shipping on a cycle of six weeks. On paper, the company looks expensive. It burns about $180,000 a month, and net new ARR is growing too slowly, so burn multiple looks weak.

Finance sees one problem. Engineering sees four. The team pays for three cloud services that overlap, nobody owns the bill, support spends hours on the same product issue, and large releases create rework after launch.

The cloud waste is easy to miss because each tool looked reasonable when someone bought it. One team added logging, another added monitoring, and a third kept an older service running for backup. Together, those bills keep adding up. Once one person takes ownership and removes overlap, the company saves money without slowing product work.

Support tells an even clearer story. A setup bug keeps confusing new customers, so the team gets 400 tickets a month. One product fix cuts that in half. Support answers fewer repeat questions, engineers get pulled into fewer escalations, and roadmap work stops getting interrupted.

The release process changes too. The team stops packing so much work into each launch. They tighten the release checklist and make sales test the new flow before customers see it. That sounds small, but it cuts rework after release and gives sales a cleaner story to bring back to prospects.

Three months later, payroll is almost the same. The company did not cut heads to improve the ratio. Monthly burn falls because the infrastructure bill is lower, and new ARR rises because the team ships cleaner releases and follows up with prospects faster.

That is the engineering story behind a better burn multiple. The number improved because the work changed.

Common mistakes when teams explain burn

Teams often explain burn with the easiest number in the room: headcount. That misses the larger leak. Ten engineers can look expensive on paper, but the real drag may be two weeks of waiting for reviews, fuzzy ownership, or support issues that keep pulling the same people away from planned work.

Another mistake is cutting the wrong costs. A team drops monitoring, testing, or deployment tools because the invoice is easy to spot. Then it keeps old software nobody uses. The bill gets smaller for a month, but labor cost rises because people do more work by hand, miss bugs, and spend longer fixing releases.

Outages and slow fixes also disappear from many burn discussions. That is a serious gap. If customers cannot use the product, revenue slips, renewals get harder, and support volume climbs. A cheap infrastructure choice can turn into a very expensive month once the team starts chasing incidents instead of shipping.

Hiring before fixing process is another common error. When delivery slows down, leaders add people. If nobody clearly owns releases, triage, or technical decisions, new hires mostly add meetings, handoffs, and confusion. More people help only after the team decides who owns what and how work moves from idea to production.

The weakest burn update is one ratio with no story under it. A better explanation is concrete: support tickets rose 30%, two engineers spent half their week on urgent fixes, one outage delayed a launch, and the expected revenue from that launch moved into next month. Now the burn multiple means something.

Quick checks before reporting the number

Before you share a burn multiple, check whether the story matches the work. A clean ratio means very little if support fires slowed releases, infrastructure spend jumped without more usage, or a new hire has not changed throughput yet.

Start with the three biggest cost drivers for the month. Keep them plain: payroll, cloud, contractors, tooling, customer support, or something similar. If you cannot name the top three in one sentence, the explanation will sound vague as soon as someone asks why burn changed.

Then review the month from a few angles. Did support work go up or down? Did release speed improve or slip? Did infrastructure costs rise along with real usage, or did they rise while traffic stayed flat? Did the last hire remove a bottleneck, or are they still ramping up? When you put those changes on one timeline, the connections usually show up fast.

This check does not need a huge spreadsheet. One page is enough if it shows cost, workload, and output side by side.

If the month looks worse than expected, say why in direct language. "Support load rose 30%, releases slipped by one sprint, and cloud spend increased without more customer usage" is stronger than a polished summary that hides the cause. It gives the team something concrete to fix next month.

What to do next

If burn multiple looks worse than expected, do not start with a defense. Start with one shared view of four things: where money goes each month, how much time support and incidents consume, how often the team ships, and what changed in headcount or infrastructure. When those numbers live in different tools, people fill the gaps with their own story.

Then pick one change and watch it for two full cycles. Remove a noisy service that wakes engineers at night. Fix a release process that turns every deploy into a mess. Change a support heavy workflow so customers need less manual help. One move is enough if you measure it honestly.

A short working sheet usually covers what matters: monthly spend by team and infrastructure, hours lost to support and rework, releases shipped, lead time to production, one change made, and the result after two cycles.

Keep the explanation plain. A founder should be able to say it in a minute, and an engineer should not wince when they hear it. "We spent more because incident load pulled two engineers off roadmap work for three weeks" is much better than a vague line about growth or efficiency.

If the picture is still messy, an outside operator can help connect architecture, delivery speed, support drag, and infrastructure costs into one operating plan. That is the kind of work Oleg Sotnikov does as a fractional CTO through oleg.is, and it is often enough to turn a hard to explain ratio into one the whole team understands.