Happy Sunday dear reader.
I have been thinking about a distinction for a while. Not one that comes from a textbook but instead from the world of cars — one that keeps surfacing when I look at how businesses actually get run.
Think of two kinds of people who understand cars. The first is the driver, he has been driving for twenty years. They know their vehicle intimately — how it sounds when something is wrong, how it handles on a wet road, when to push and when to hold back. The more enterprising among them keep up with developments: car magazines, YouTube reviews, conversations with others who drive the same roads. Through accumulated experience, they have built something real. A felt sense of the car. Genuine expertise in operating it.
The second is an automobile engineer. Before they were legally old enough to drive, they were studying engine schematics — how a camshaft works, what a head gasket does, why the compression ratio matters. Some of them even found themselves early in their careers in the passenger seat, giving technically correct advice to drivers who had been on the road for years. You can imagine how that landed.
These are not the same kind of knowledge. The driver knows how the car behaves. The engineer knows why — and what to do when it stops behaving at all.
Most of the time, you do not need an engineer to drive your car. But that one time the engine starts billowing smoke and you are stranded, you wish you had brought one along.
More importantly: you cannot ask your driver to build you a working car. If the car needs to be driven, the driver wins every time. If it needs to be fixed — or rebuilt from the ground up — the driver has no tools for the job.
I kept coming back to this when I started thinking about healthcare practices in India.
There is a cardiologist in Ludhiana who does forty consultations a day. He has been doing this for eleven years. He knows his OPD flow the way a long-distance car driver knows a highway — by feel, by reflex, by accumulated intuition about when to slow down and when to push through. He knows which ward boy shows up late on Mondays. He knows which insurance company will reject a claim if the diagnosis code is off by one digit. He knows that his cash crunch in February and September is a collections pattern, not a revenue problem.
He is an excellent driver.
What he does not know — what he has never had reason to learn — is how his car is built.
Driving vs. Engineering
I want to be precise about what that distinction means, because it is not a compliment dressed as an insult. Driving skill is real skill. Running a 30-bed nursing home in Ambala for eight years, building a referral network from nothing, managing nurses, resident doctors, an OT roster, and a family’s expectations — that takes genuine operational intelligence. The people who have done this have earned something. I am not dismissing it.
What I am saying is: driving skill and engineering knowledge are different kinds of knowledge. And running a practice that actually performs — not just survives — requires both.
Here is where the gap shows up.
On cash
Ask a practice owner whether their business is profitable, and most will say yes. Ask them why they are perpetually short on cash and they will say: collections are slow, February is always bad, TPA payments take forever.
The driver feels the cash tightness. The engineer understands its structural source.
A nursing home collects cash upfront for most procedures. It also buys consumables — sutures, IV fluids, surgical supplies — on cash. But 30–40% of its revenue is billed on credit to insurance companies and corporate empanelments, with actual payment arriving 60 to 90 days later. The working capital gap is not a February problem. It is a permanent structural condition created by the mismatch between when costs are incurred and when revenue lands.
An engineer asks: what is my average collection period by payer type, what is my working capital requirement at any given volume level, how do I size a credit buffer without turning away patients? A driver asks: why is my account always running dry?
Both questions register the same symptom. Only one diagnoses the cause.
On revenue
Most practice owners know their monthly gross collections. Very few know their revenue by service line. Fewer still know which service lines actually contribute margin after you allocate the cost of space, equipment, staff time, and the doctor’s opportunity cost.
A cardiologist in Chandigarh added a TMT and echo facility to his clinic three years ago. Revenue went up by ₹1.8 lakh a month. He called it a success. What he did not calculate was that the technician’s salary, the annual service contract on the echo machine, the additional power draw, and the amortised cost of the equipment itself added up to ₹1.4 lakh a month. He had bought ₹40,000 of monthly margin for ₹18 lakh of capital. The return on capital deployed was around 2.5% annually.
This is not a failure of ambition. It is a failure of unit economics. He had never had reason to think in those terms. His training — clinical, not commercial — never required it. And there was no moment of visible crisis to force the question.
The machine is still running. He still calls it a success.
On people
The most common staffing complaint from practice owners sounds like this: nurses leave for the Gulf, visiting consultants split their time across three hospitals, the front desk doesn’t push packages, the billing team is sloppy with codes. The driver’s response is to find better people, pay more, or manage more tightly. It rarely works, and the practice owner ends up with a dim view of the Indian healthcare workforce.
The engineer asks a different question: why do the incentive structures I’ve designed produce exactly the behaviour I’m seeing?
A visiting cardiologist who splits between three hospitals is not disloyal. He is responding rationally to a structure where his income is tied entirely to procedure volume, and no single hospital has given him a reason to anchor. A nurse who leaves for Qatar is not ungrateful. She is making a reasonable calculation about income, safety, and career trajectory that the practice has never bothered to compete with on its own terms. These are not attitude problems. They are incentive design problems — and they have engineering solutions.
The driver manages by feel and authority. The engineer asks why the system produces the behaviour, then redesigns the system.
The passenger seat problem
Here is where I need to be honest about the limit of this metaphor. An automobile engineer who has never driven cannot give you useful driving instructions. The fact that they understand how the clutch plate works does not mean they can tell you how to merge onto a highway without stalling. Instruction from the passenger seat — technically sound, operationally useless — is one of the more frustrating experiences a driver can have.
The same is true in healthcare. Business knowledge that floats above clinical and operational reality is expensive jargon. The unit economics of a nursing home only make sense if you understand the OPD-to-admission conversion, the surgical throughput constraints of your OT, the actual load a nursing team can carry at 80% bed occupancy. You cannot model a practice from a spreadsheet alone. Anyone who tells you otherwise hasn’t spent time on a ward.
What I am arguing is not that operational experience should be replaced by business theory. I am arguing that it is totally possible for a practice to have accumulated significant driving skill and almost no engineering knowledge, both at the same time — and that the gap is invisible until something breaks in a way that driving skill cannot fix.
The question worth sitting with is not whether your practice is well-run. It probably is, by the standards you’ve used to measure it.
The question is: do you understand why it performs the way it does, at a structural level? Not just what works — but why it works, and what will break when the conditions change?
Because conditions always change. And when the engine starts billowing smoke, you will wish you knew how it was built.
Leave a Reply