Your Runway Is Not an Emergency
Teams that treat eighteen months of cash like a crisis ship panic code that outlasts the panic.
The hook
A founder I advise pinged me last Tuesday. Series A freshly closed, eighteen months of runway in the bank. The Slack DM read: "We need to ship the v2 API in six weeks or we are dead." They were not dead. They were not close to dead. They had more cash than most seed-stage companies ever see. But someone had put a red countdown chart in the Monday all-hands, and now the entire engineering team was writing code like the building was on fire.
आम्ही तरी आस · We Have Cast Off Longing
आम्ही तरी आस । झालो टाकोनी उदास ॥
गेले मानामान । सुखदुःखाचे खंडन ॥
तुका म्हणे चित्ती । नाही वागवीत खंती ॥
The person who has stopped swinging between hope and despair acts from a steady center that no outcome can move.
What I keep seeing
The following week I sat in their sprint planning. The tech lead proposed skipping database migrations and writing raw SQL inserts "because we don't have time for proper schema work." A staff engineer wanted to defer integration tests for a payments flow. The PM was cutting scope on onboarding by removing error states. Nobody was making these decisions because the product demanded speed. They were making them because a spreadsheet on a Monday slide had made them feel like the ground was disappearing.
I have done this to teams myself, years ago. Put the burn chart in front of engineers thinking transparency meant showing every number to every person. It does not. Transparency without context is just anxiety with a data source.
The mechanics
Runway math is simple: cash in the bank divided by monthly burn rate. $3.6 million at $200K burn gives you eighteen months. That number moves slowly. It does not change between Monday and Friday. It does not spike because a competitor launched a feature. It is one of the most stable numbers in your business.
But human threat response does not calibrate to the rate of change of a number. It calibrates to the framing. A countdown timer produces urgency regardless of the duration it counts. Kahneman's work on loss aversion showed that the prospect of losing something activates decision-making circuits measurably worse at long-horizon planning. When you put a runway chart in front of engineers every Monday, you activate loss aversion on a weekly cycle for a number that moves on a monthly cycle. The cognitive response, ship now, cut corners, skip tests, is rational for a two-week timeline. It is destructive for an eighteen-month one.
The architecture decisions made under artificial urgency have a specific signature. Hard-coded configuration that should be in environment variables. Synchronous API calls where a queue would prevent cascading failures. A single Postgres instance doing double duty as a job store because "we will fix it later." Later never comes. Next Monday the chart is still red.
Where Tuka comes in
Tukaram is not describing calmness as a personality trait. He is describing it as a structural result. Once you stop oscillating between hope (आस) and despair (उदास), you do not become passive. You become capable of action not driven by the oscillation itself. सुखदुःखाचे खंडन (the severing of pleasure and pain) is not numbness. It is removing the feedback loop where each good sprint makes you euphoric and each missed deadline makes you catastrophize.
नाही वागवीत खंती (not carrying sorrow in the mind) is not advice to ignore reality. It is an observation that sorrow carried forward corrupts the next action. The engineer writing a payments flow while carrying Monday's runway anxiety writes a payments flow shaped by anxiety, not by the requirements of moving money safely.
What I would actually do
Stop showing runway charts in engineering all-hands. Full stop. Finance and founders track burn rate monthly; engineers should never see a countdown timer for a number they do not control. Replace the runway slide with a single quarterly statement: "We are funded through Q4 2027. Here is what we are building this quarter and why." Let technical leads make architecture decisions based on the actual time horizon of the product, not the emotional half-life of a red bar chart. If your runway is genuinely short, under six months, that is a conversation for the executive team and the board. Not a weekly anxiety ritual for the people writing your code.
Chetan Dhandal