I started in 2018 as a Software Engineer in an R&D team at FlyTxt, working on a telecom and CRM platform. I am now a Lead Product Engineer at Zafin, architecting an event-driven pricing and billing platform and mentoring 10+ engineers. Between those two points are three companies and a set of decisions I can describe precisely, because I made most of them badly the first time.
Almost none of the acceleration came from working more hours. It came from three things: learning along a structured path instead of absorbing whatever the current ticket happened to teach, taking ownership of problems nobody had assigned to me, and understanding the product rather than only my slice of it.
Build skills on a path, not by accident
My first real lesson was at FlyTxt, and it was humbling. A core platform component was slow, and my instinct was to read the code and improve the parts that looked inefficient. That produced nothing. What produced a 10x latency reduction was learning to use JProfiler properly and letting it tell me that the cost was in how Hibernate was loading data, not in the logic I had been staring at.
The transferable part is not “use a profiler”. It is that I had a real gap — I did not understand how the ORM I used every day actually issued queries — and the gap was invisible to me until a measurement pointed at it. Reading Hibernate's own documentation on fetching strategies end to end taught me more in a weekend than the previous six months of using it had.
That is the argument for structured learning over osmosis. Work teaches you what your current tickets require, in the order they happen to arrive, and leaves everything else as an unknown unknown. A syllabus is somebody having already worked out the dependency order — you cannot reason about consistency trade-offs before you understand what a transaction guarantees, and PostgreSQL's isolation-level documentation is a very different read once you know why you are there.
This is also the reason I eventually wrote my own courses, and I will be straightforward that they are the curriculum I wish someone had handed me in 2019: Java done properly, then architecture and design principles, then system design and deployment patterns, then Kafka and caching, then resilience and high-scale design. The order is the value. Each one assumes the previous one, which is exactly the thing you do not get from watching disconnected talks.
Two things I would insist on regardless of whose material you use. Go to primary sources — the Kafka documentation and Spring Boot's reference guide are better and more current than almost any secondary explanation of them. And build something that can fail: I learned more about deployment from running my own site on a serverless platform, where a cold start re-runs migrations and a bad one takes the whole thing down, than from any amount of reading about it.
Take ownership of problems nobody assigned you
The clearest inflection in my career was at Udaan, and it did not come from a ticket. Deployments were causing incidents. That was not my remit; I was writing application code. But nobody owned it, so I built a canary deployment framework with feature flags and A/B testing, and deployment incidents fell 70% while release velocity doubled.
Two observations about that, both important.
The first: it was unassigned, not unsanctioned. There is a failure mode where “ownership” means going quiet for three weeks and reappearing with a framework nobody asked for. What worked was naming the problem out loud with a number attached, proposing something small, and shipping it where the people affected could see it.
The second: I picked a problem with a measurable before and after. “I improved our deployment process” is unverifiable. “Deployment incidents fell 70%” is the same work with a number on it, and the number is what makes it legible to anyone deciding what you should be trusted with next. The instinct generalises — the monitoring work in the same period took mean time to detect from 15 minutes to under 3, which is likewise a claim rather than a feeling.
Ownership scales along with you. At Udaan it meant fixing the deployment pipeline. At Zafin it means being technical SPOC for a bank's first production go-live, which is the same instinct applied to something with a client's name on it.
Understand the whole product, not just your service
This is the one I was slowest to learn, and the one with the most leverage.
At SunTec I worked on the Xelerate banking platform — an automated test framework that took the regression cycle from 5 days to 8 hours, streaming pipelines for billing and payments, real banking functionality like payment follow-up and bill generation. The framework work was good engineering. The career-relevant part was that I learned what billing and payments actually mean to a bank, because I was implementing the functionality and not just the infrastructure under it.
That domain knowledge is the reason I could later architect a pricing platform rather than only its plumbing. There are a great many engineers who can wire up Kafka. There are far fewer who can wire up Kafka and tell you why an effective-dated rate change cannot be modelled as an update in a regulated domain. The second group does not compete on the same axis as the first.
Way.com is where this became explicit. As Technical Lead I partnered directly with the CEO on technical strategy, and took feature time-to-market from 6 weeks to 3. You do not get invited into that conversation by being the strongest coder in the room. You get invited because you can talk about the 30+ features across parking, carwash, roadside assistance and CRM — with partners like Amazon and Travelers attached to them — in terms of what they earn and what they cost, rather than only in terms of what they are built from. Time-to-market halved mostly because we stopped building things carefully that should not have been built.
Practically, “understanding the whole picture” is unglamorous. Read the tickets from the team downstream of you. Ask what the revenue line for your service is. Find out what support gets paged about. Bounded contexts are usually taught as a modelling tool, but the reason they are hard to draw is that they require exactly this knowledge — where one part of the business genuinely ends.
How the three compound
They are not independent, which is why the arc bends rather than stepping.
Structured learning is what makes unassigned ownership safe: I could build a canary framework at Udaan because I had deliberately learned deployment and observability, so I was not experimenting on production. Product understanding is what makes ownership worth anything: the reason to take on delivery safety rather than a more interesting technical problem was knowing what an incident cost. And ownership is what turns learning into evidence — a certificate says you studied something, a 70% reduction says you used it.
The compounding is the point. At Zafin, mentoring 10+ engineers through SOLID and CQRS adoption cut defect leakage 40%, and that is all three at once: the knowledge had to be structured enough to teach, the work was leadership nobody wrote a ticket for, and the reason to care about defect leakage at all is what a defect costs a bank.
If I had to compress seven years into one sentence: pick a learning path and finish it, find the problem nobody owns and own it with a number attached, and learn the business well enough that you can argue about what to build and not only how. The titles follow. They have never once led.