There is a particular kind of failure pattern that haunts engineering organizations the same way it haunts small businesses. Revenue looks fine. The dashboard is green. The retrospective sounded productive. And yet, three weeks later, the lead engineer is updating their LinkedIn at 11pm on a Tuesday, the on-call rotation is shedding people, and a senior IC quietly asks if anyone has a referral. Nothing exploded. Nothing was on fire. The team simply ran out of something more important than time, and nobody was tracking it. The same pattern, examined through the lens of small companies that look healthy until they aren't, is dissected in a sharp piece on the mechanics of business finance that actually prevents collapse, and the parallels to how engineering teams quietly bleed out are almost embarrassingly precise. The cash conversion cycle has an exact analog in software, and most teams have never measured theirs.
Revenue Is Velocity. Cash Is Capacity.
In a business, the seductive trap is mistaking revenue for cash. You can grow revenue by 40 percent and still go bankrupt, because money came in slower than money went out. Engineering teams have the same illusion, dressed in different vocabulary. Velocity is your revenue: features shipped, PRs merged, deploys executed, story points closed. It looks like progress because it produces visible artifacts. Capacity is your cash: the unallocated, recoverable hours your team can spend on incidents, refactoring, mentorship, deep thinking, and the unplanned reality of running software in production. A team can have heroic velocity for two quarters and zero capacity, which is exactly the state where one resignation triggers a cascade. The hard number behind this is not hypothetical. In the 2024 Accelerate State of DevOps Report, Google's research arm found that teams with unstable priorities had a forty percent higher risk of burnout, and that the effect was stubbornly resistant to mitigation even when leadership and documentation were strong. Velocity without capacity is the engineering equivalent of revenue without cash.
The Toil Conversion Cycle
In the source piece, the cash conversion cycle is broken into three levers: how long inventory sits, how long customers take to pay, and how long you take to pay suppliers. Map those to an engineering team and the picture sharpens immediately. How long does work-in-progress sit between started and shipped? How long does feedback take to reach the engineer who wrote the code, whether from CI, from production, or from users? How long does the team take to repay its own technical debts, security patches, dependency updates, and on-call follow-ups? Every one of those numbers, left unmonitored, expands silently. WIP balloons because nobody wants to push back on a PM. Feedback latency grows because flaky tests get retried instead of fixed. Debt repayment stretches because the next sprint is always more urgent than the last sprint's leftovers. None of these are visible on a release-train Gantt chart, and yet collectively they describe whether your team is solvent or quietly going broke. Google's Site Reliability Engineering workbook frames the same idea with surgical precision: toil scales linearly with service growth until it doesn't, at which point it spikes nonlinearly and the team breaks.
Unit Economics for a Feature
Businesses that survive learn to compute unit economics honestly, which mostly means refusing to lie to themselves about hidden costs. The same discipline transforms engineering decisions. Before merging anything non-trivial, a team can ask a small set of questions that almost nobody asks out loud:
- What is the fully loaded cost of this feature? Not just dev hours, but design, code review, QA, deployment risk, documentation, training, and the ongoing maintenance tax it will impose for every future quarter it exists.
- What is its realistic lifetime value? Will it be used in two years, or is it a hedge against a customer who might leave anyway? Features have churn, just like users.
- What does it cost to keep alive? Every endpoint adds surface area. Every config flag adds a branch in someone's head. Every integration adds a vendor that can break on Sunday morning.
- What is its payback period? Time from merge to measurable, attributable user benefit. Anything over a quarter without an honest signal is speculation, not engineering.
- What is the optionality cost? If we build this, what becomes harder to build later? Architecture is a series of doors you walk through one-way.
Most teams build features the way struggling businesses chase revenue: by adding more, faster, without computing whether the marginal feature is actually profitable in capacity terms. The features that get killed in this exercise are not the ones executives loved. They are the ones engineers were quietly dreading and nobody had permission to question.
Financing Choices, Engineering Edition
The source piece points out that capital is not just money, it is constraints. Bootstrapping buys control, debt punishes volatility, equity changes psychology. Engineering teams make identical tradeoffs without naming them. Building in-house buys control and forces discipline, but limits speed. Adopting a third-party SaaS is debt: cheap monthly payments, painful if your business model shifts or vendor pricing does. Hiring contractors is equity-like: fast acceleration at the cost of dilution, because every contractor takes context out the door when they leave. The mistake teams make is treating these decisions as technical questions when they are capital structure questions. A team running on heavy SaaS debt during a stable period looks efficient. The same team during a vendor outage or a price hike looks like a company that took out a variable-rate mortgage right before rates moved.
The Weekly Operating Review Engineers Refuse to Do
Almost every team has a sprint ceremony and almost no team has the equivalent of a CFO's weekly cash review. The fix is not another meeting. It is a fifteen-minute review, ideally led by the tech lead and senior IC together, that touches the same surfaces every week. What is the current WIP count and is it trending up? Where is feedback latency longest right now? Which on-call alerts fired more than once and were not addressed in code? What debt items have been on the deck more than two sprints? Who is carrying invisible load that does not show up in tickets? The point is not to produce a dashboard. The point is to make the team confront its own balance sheet weekly, when problems are still cheap to fix, before they become resignations and incidents.
What Actually Prevents Collapse
Engineering teams do not die in production outages. They die in the quiet quarters between outages, when the team mistakes the absence of fire for the presence of health. The prevention frame, borrowed honestly from the financial discipline of small businesses that survive, comes down to a few unfashionable habits. Make capacity visible the way velocity is. Track the conversion cycle from work-started to user-impact and refuse to let it stretch silently. Compute the real unit economics of features before, not after, you ship them. Treat your toolchain like a balance sheet of obligations, not a wish list. Run a weekly review that earns its name. Stop celebrating heroics, because heroics are exactly what happens when prevention failed. The teams that compound over a decade are not the fastest or the smartest. They are the ones whose leaders learned, usually the hard way, that the most expensive incident is the one you cannot see yet because no one is measuring the right thing.
Solvency, in code as in business, is mostly a discipline of looking honestly at numbers nobody wants to put on the slide.
Top comments (0)