What the Markets Taught Me About Engineering
I've followed Indian equities for years. The transferable lesson wasn't about money — it was about how badly I read my own confidence.
I've been active in India's equity markets for a long time now. Not as a trader — I don't have the temperament or the attention for it — but as someone who reads a lot, holds positions for years, and reviews them a few times a year.
People assume the crossover with engineering is analytical: modelling, numbers, systems thinking. It isn't. The overlap is almost entirely about self-knowledge, and it's unflattering.
You are wrong more often than it feels like
In engineering you can go a long time without a clean scoreboard. A design decision that was wrong just becomes "how the system works," and by the time the cost shows up it's distributed across three years and six people. Nothing forces you to notice.
Markets are less forgiving. You write down what you think will happen, money changes hands, and reality answers within a period you can actually observe. Doing that repeatedly taught me something I did not want to learn: my confidence and my accuracy were only loosely related. I was most certain on exactly the calls I understood least, because unfamiliarity felt like clarity — there were fewer complications visible.
I now read strong technical conviction, in myself especially, as a signal to slow down rather than speed up.
Position sizing is architecture
The most useful idea I've taken across is that you don't have to be right, you have to survive being wrong.
In investing that's obvious — you size positions so no single mistake ends you. In engineering the same principle exists and gets ignored constantly. How expensive is this decision to reverse? What does it cost if this assumption is wrong in year three? Which choices are cheap experiments and which are load-bearing?
Teams routinely make load-bearing decisions with the casualness of a cheap experiment, because both take one afternoon to implement. The implementation time tells you nothing about the exposure.
Patience is a technical skill
The last one is the hardest, and I'm still not good at it. The right move is very often to do nothing — not refactor it yet, not adopt it yet, not rebuild it yet — and doing nothing feels like negligence when you're capable of doing something.
Most of the returns in both places come from a small number of good decisions held for a long time, and from resisting the urge to interfere with them in between.