Leadership · · 3 min read
From developer to founder: how the blast radius of my decisions grew
Developer, senior developer, lead DevOps engineer, principal engineer, co-founder. What actually changed at each step, and what I wish I had learned sooner.
My career has moved through five roles: software developer, senior developer, lead DevOps engineer, principal software engineer, and now co-founder of FinMoon AI. On paper that reads like a ladder. In practice each step was a change in the blast radius of my decisions: how much of the system, and how many people, a single choice of mine could affect.
Here’s what changed at each stage, and what I’d tell someone standing where I stood.
Developer: the function
As a developer, the unit of impact is the function, the class, the pull request. Success is correctness and clarity. The most valuable habit I built early was caring about what happens after merge: how code is deployed, how it fails, who gets paged.
Lesson: Learn how your code runs in production, not just how it compiles. It’s the fastest route to seniority.
Senior developer: the feature and the MVP
As a senior developer I started owning features end to end, and eventually led an enterprise MVP on Angular, Spring Boot, PostgreSQL and Docker. The unit of impact became the product slice. The hard problems stopped being algorithms and became scope: what to build now, what to defer, and where to leave seams so the MVP wouldn’t need a rewrite on success.
Lesson: The most senior thing you can say in a planning meeting is often “we don’t need that yet.”
Lead DevOps engineer: the platform
Moving into DevOps leadership was the biggest mental shift. Suddenly my users were other engineers, and my decisions affected every team’s deploys, every environment, and the monthly cloud bill. Leading a migration of legacy systems to Google Cloud — which cut infrastructure cost by 40% — taught me that infrastructure is a financial instrument as much as a technical one.
Lesson: Platforms are products. If engineers route around your pipeline, the pipeline is wrong, not the engineers.
Principal engineer: the architecture and the organisation
As a principal engineer, the unit of impact became the architecture and, implicitly, the org chart. Designing a microservices platform serving millions of users at 99.9% uptime was as much about team boundaries, ownership and on-call as about service boundaries. Conway’s law isn’t a warning; it’s a design tool.
This is also where influence replaced authority. Principals rarely tell anyone to do anything. You write the document, run the review, build the prototype, and make the good path the easy path.
Lesson: Your output is other people’s better decisions. Write things down.
Co-founder: the company
Co-founding FinMoon AI widened the blast radius to its maximum. Technology choices are now runway choices. Hiring, pricing, positioning and user research sit on the same whiteboard as model selection and data architecture. There is no one to escalate to.
What surprised me is how much of the earlier roles carried over. The developer’s care for production, the MVP instinct for scope, the platform lead’s eye on cost, the principal’s habit of writing things down — a technical founder uses all of them, often in the same afternoon.
Lesson: Every earlier role was CTO training. I just didn’t know it at the time.
If I could tell my younger self one thing
Seek out the job that increases your blast radius slightly beyond your comfort zone, then learn to be responsible for it. Titles follow responsibility, rarely the other way around.