The Decisions That Look Wrong on Paper¶
Thirteen years in tech. Led 30+ engineers across teams. One CTO role. Multiple production fires survived. One acquisition. One period of very deliberate unemployment.
None of that looks like a clean, ascending career graph. And that is exactly the point.
Most career advice optimizes for the graph. FAANG brand name, promotion cadence, total comp, LinkedIn endorsements. I am not going to tell you those things do not matter, because they do. But they are not the full picture, and in my experience they are often the wrong thing to optimize for in your 20s and early 30s, which is the only time you can afford to take the risks that actually compound.
Here are the four decisions people call mistakes when they look at my profile, and what I actually got out of each one.
Saying No to a FAANG Offer¶
The offer was real. The comp was good. The brand name would have looked excellent on a resume and I knew it.
I still said no.
Not because I lacked the skills. I had done the preparation, cleared the rounds, and understood the role. The reason I declined was simpler and harder to explain in a LinkedIn post: I knew that environment would bore me inside of six months. Structured sprints, well-defined scope, large teams where any individual contribution gets diffused across ten layers of abstraction. That is a genuinely good environment for many engineers at many stages of their careers. It was not the right environment for me at that point.
What I needed was chaos. I needed to be the person who decides what gets built, not the person who implements ticket 4,281 in a quarter. I needed to break things and fix them at 2 AM and understand, viscerally, why the thing broke and what the correct fix actually was. That kind of ownership does not exist at scale.
The real cost of the FAANG offer was not the salary I passed on. It was the road not taken, the uncertainty of whether I was making the right call. I second-guessed that decision for months. Looking back: it was correct.
Taking a Pay Cut to Join a Startup¶
This one is harder to recommend generally because it is genuinely a gamble.
I joined a startup at a lower base than I was earning. The equity upside was the stated rationale, and yes, when GetPlus was acquired by Paytm, the equity eventually converted to something real. But that is not the point I want to make, because equity is uncertain and you should not plan around it.
The actual return on that pay cut was the scope of work.
As CTO, I was responsible for architecture decisions I had never made before. I was in fundraising conversations where I had to translate technical credibility into investor confidence. I hired engineers, made calls on who to let go, and navigated the specific mess of building a team when the company’s bank balance is six months of runway. I learned how to help raise funds, how to build from scratch under real constraints, and what early-stage startup chaos actually feels like from the inside rather than as a spectator.
No amount of salary could have bought that education. The pay cut was the tuition fee. The startup was the program. The difference from an MBA is that I was learning with real consequences, on real systems, with real users.
Six Months of Unemployment After the Acquisition¶
This is the one people find hardest to understand.
After the acquisition closed and the integration work settled, I had time. Actual, unstructured time. No sprint, no on-call rotation, no quarterly OKRs, no one booking a meeting at 9am to discuss the meeting from yesterday.
My LinkedIn was quiet. My inbox was quieter. But my brain was the loudest it had ever been in years.
I started writing again online. The tagline is “Code Ka Jugaad” which roughly translates to finding the practical solution to the engineering problem in front of you, which is also a reasonable description of what those six months were. I was doing the mental version of the same thing: figuring out what I actually wanted from the next chapter rather than defaulting to whatever opportunity showed up first.
The grinding years had given me skills and experience and compensation. They had not given me clarity. Those six months gave me that. I came out of them with a much cleaner sense of what kind of problems I wanted to solve, what kind of teams I wanted to build, and what I was no longer willing to trade my time for.
That is not something you can manufacture. You have to stop long enough for it to happen.
Ignoring the Framework Obsession¶
This one is less of a single decision and more of a sustained posture over the entire 13 years.
JavaScript frameworks are a good example. Angular was the thing. Then React replaced Angular. Then Next.js. Then everyone has opinions about whether React is dying and what comes next. This cycle repeats in every language and ecosystem on a roughly three-to-five year cadence.
I have always spent my learning budget on the layer below the framework. Distributed systems. Database architecture and query planning. How the OS actually handles concurrency. How TCP works and what that means for your application’s latency profile. How to lead a team through a production incident at 3 AM without making it worse.
These things do not expire. The engineer who understands why a database query is slow at scale is more useful than the engineer who knows the current recommended way to handle server components in Next.js, because the second engineer’s knowledge has a shelf life of eighteen months and the first engineer’s does not.
The frameworks come and go. The fundamentals are permanent. Invest accordingly.
What 13 Years Actually Taught Me¶
Your LinkedIn feed will tell you to optimize for prestige: the company name, the title, the total comp number. These are not bad things to want. They are just incomplete metrics for a career.
The things that actually compounded for me over 13 years were not the prestige signals. They were the depth of understanding built through repeated, high-stakes problem-solving. The judgment built through leading teams through hard situations. The clarity about what I value that only came from periods of deliberate discomfort.
The real growth happened in the gaps: the pay cut, the six months of quiet, the startup that no one had heard of, the FAANG offer I turned down. None of those looked like growth from the outside. All of them were, from the inside.
Here is the question worth sitting with: are you making career decisions because they genuinely align with what you are trying to build, or because they produce a LinkedIn update that will read well to people you do not know?
The uncomfortable choices, the ones that do not fit the narrative of a correct tech career, the ones that make you second-guess yourself for months: those tend to be the ones worth making.
Because the comfortable choices compound too. Just in the wrong direction.