From Database Admin to Tech Lead: A 12-Year Roadmap

In 2011, I was a database admin at Rural Shores Technologies in Ahmedabad. I wrote SQL all day. Stored procedures, triggers, index tuning. I didn't know what an API was. I didn't know what a framework was. I knew how to write a JOIN and I thought that was a career.

In 2026, I'm a Tech Lead at Pranshtech Solutions. I lead 10 developers, own the architecture of a multi-tenant SaaS platform, review production deploys, and run 1:1s every week. I've also shipped three products of my own.

This is the honest version of how that happened not the LinkedIn version.

2011–2013: The SQL Years (and the Realization)

Rural Shores was a rural BPO company. My job was database administration MySQL, mostly. Writing reports, maintaining tables, occasionally writing stored procedures for the operations team. It paid the bills and I was good at it.

The realization came slowly: I was optimizing something with a ceiling. Stored procedure speed doesn't compound. I could get 20% faster at writing SQL, but there wasn't a multiplied career above it. The developers I saw the ones building things people actually used were doing something fundamentally different. They were making systems, not just queries.

I started learning PHP at night. W3Schools, then PHP.net, then stack overflow. I built a small inventory management tool for my own use to practice. It was ugly and probably insecure. But it worked, and it was mine.

2013–2016: PHP and the First Real Developer Job

Global India Technologies hired me as a PHP developer in 2013. CodeIgniter was the framework. My job was to build CRUD applications admin panels, reporting dashboards, e-commerce backends.

Looking back, these were the most important years of my career for one reason: I shipped things constantly. CodeIgniter was simple enough that I wasn't fighting the framework, so every problem I solved was a real problem. I debugged production issues. I designed database schemas from scratch. I built things that had actual users who complained when they broke.

The skills that formed in this period:

Reading other people's code most of what I was doing was maintenance and extension, not greenfield
Database design my SQL background actually helped here; I thought about data modeling more carefully than most junior devs
Debugging without a debugger var_dump() and logs. I got fast at it.
Estimating work badly, at first. But the feedback loop was fast.

2016: Laravel Changed Everything

I moved to Siddhi Infosoft as a Senior PHP Developer. They used Laravel. The first time I saw Eloquent ORM, route model binding, and Artisan, something clicked that I hadn't felt since my first working SQL query.

Laravel wasn't just a better framework it was evidence that software design matters. The code I wrote before had worked, but it had been inelegant in ways I hadn't had words for. Laravel gave me the vocabulary and demonstrated what well-designed code felt like to use.

I became mildly obsessed. I read the source code. I understood the service container, dependency injection, and middleware pipelines not because someone told me to, but because I was curious how it worked. This is a habit that has paid dividends every year since.

2017: React and the Paradigm Shift

I returned to Global India Technologies as a full-stack developer. They were starting to use React. This was a bigger mental shift than Laravel had been.

Server-rendered HTML meant the server was in charge. React meant the client was in charge, and the server was an API. Separating those concerns forced me to think about the contract between frontend and backend explicitly what data does the UI need, in what shape, at what latency?

The practical skills that came out of this period:

REST API design how to structure endpoints, handle pagination, version APIs
Async JavaScript Promises, then async/await, then understanding what the event loop actually does
State management Redux first (too much ceremony), then lighter patterns
CORS, authentication tokens, refresh flows the plumbing nobody teaches you

2018–2022: The Trap of Just Shipping Features

This is the period I'm most honest about in retrospect. I was technically solid. I could build almost anything you asked me to build React frontends, Node.js backends, Laravel APIs, MySQL schemas, Redis caches. I shipped constantly.

But I had zero leadership skills. I didn't know how to run a meeting. I didn't know how to give a junior developer feedback that made them better rather than just telling them what was wrong. I didn't know how to communicate project status to stakeholders without getting technical and losing them. I didn't know how to push back on a bad product decision in a way that got heard.

“Technical skills get you to senior developer. The skills after that are almost entirely about communication, influence, and systems thinking.”
Something I wish someone had told me in 2018

The trap is that shipping features feels productive, so you keep doing it. Years pass. You get better at shipping features. But you plateau as a lead candidate because the skills for the next level are orthogonal to what you've been practicing.

2022: Moving to Pranshtech First Real Leadership Responsibility

I joined Pranshtech Solutions in 2022 and immediately had responsibility I hadn't had before: a team of developers, project timelines that I owned, and architecture decisions that I couldn't escalate to someone else.

The first three months were humbling. I was good at doing I was bad at enabling others to do. My first instinct when a junior developer was stuck was to solve the problem for them. It's faster. It feels efficient. It is deeply wrong.

The things I had to unlearn:

Solving instead of coaching taking a problem away from someone prevents them from learning to solve it
Reviewing code for correctness only code review is a teaching surface, not just a bug filter
Treating estimates as commitments estimates are guesses; the work is managing the gap between guesses and reality
Assuming shared context what's obvious to me after 8 years isn't obvious to someone in year 2

2023: Tech Lead Title and What I Wish I'd Known

Tech Lead at Pranshtech. Ten developers. Full ownership of the technical direction for a multi-tenant SaaS platform.

Three things that made an immediate difference:

1. 1:1s matter more than standups

Weekly 30-minute 1:1s with each developer. Not status updates those belong in Jira. 1:1s for: what's frustrating you right now, what do you want to learn, are there blockers I don't know about, is the work interesting? The signal-to-noise ratio on problems I can actually fix is far higher in 1:1s than in standups.

2. Architecture documents save you

I started writing Architecture Decision Records (ADRs) short documents (one page max) that capture a decision, the context, the options considered, and why we chose what we chose. When someone new joins, they can read the last 20 ADRs and understand why the codebase looks the way it does. When someone challenges a decision six months later, you have the reasoning documented.

docs/adr/0012-use-bullmq-over-bee-queue.md

# ADR 0012: Use BullMQ for Job Queue

## Status
Accepted  2023-09-14

## Context
We need a reliable background job queue for email delivery, PDF generation,
and webhook processing. Current setup uses ad-hoc setTimeout which loses
jobs on restart.

## Options Considered
- **Bee-Queue**: Simple, fast, Redis-backed. No repeat jobs, no job priority.
- **BullMQ**: Redis-backed, TypeScript-first, repeat jobs, priorities, rate limiting.
- **pg-boss**: PostgreSQL-backed. No Redis dependency, but slower throughput.

## Decision
BullMQ. We already run Redis for caching. TypeScript types are first-class.
The repeat-job functionality replaces 3 cron scripts we currently maintain.

## Consequences
- Adds BullMQ as a dependency
- Team needs to learn BullMQ API (estimated 2h ramp)
- Workers run as separate Node.js processes  deployment slightly more complex

3. Code reviews are mentoring, not gatekeeping

I changed how I write code review comments. Instead of "This is wrong", I write "This will cause an N+1 query because Eloquent loads each relationship lazily in the loop. Try `with(['user'])` on the query here's why: [link to docs]". The diff isn't the point. The developer reading the comment is the point.

This takes longer per review. The return is that the same mistake appears less often over time.

The Skills That Actually Moved My Career

Not the technologies. The meta-skills:

1.Writing clearly. The ability to explain a technical decision in two paragraphs to a non-technical stakeholder is worth more than knowing any specific framework. I got better at this by writing Notion docs, Slack messages, ADRs. Practice makes it faster.
2.System design thinking. Understanding how pieces fit together at a level above "does this function work." How does this service behave under load? What happens when this queue backs up? Where are the failure modes? This is the difference between senior developer and staff/lead.
3.Saying "I don't know" confidently. This sounds counterintuitive but it builds trust. "I don't know, let me find out and get back to you by EOD" is more trustworthy than a confident-sounding guess that turns out to be wrong.
4.Estimating with explicit uncertainty. "This will take 3 days" is a commitment. "My best estimate is 3-5 days; it could go to 7 if the third-party API integration is as undocumented as the docs suggest" is honest and useful.
5.Reading code you didn't write. Senior developers spend more time reading code than writing it. Being fast at understanding unfamiliar codebases is a force multiplier.

What I'd Tell 2011 Rahul

Learn data structures and algorithms sooner. Not for LeetCode for real problem-solving. Understanding tree traversal, hash maps, and time complexity changes how you approach code.
Read _The Pragmatic Programmer_ in year 3, not year 8. Hunt and Thomas's advice on "don't live with broken windows", "DRY", and "invest regularly in your knowledge portfolio" would have compressed my learning significantly.
Network more, but genuinely. Attend meetups. Write one blog post a year. The jobs and opportunities that moved my career came through people, not job boards.
Build things for yourself. Every side project taught me something I couldn't have learned in a client project because client projects have constraints that prevent certain experiments. Your own projects have no such constraints.
The first three years of any new level will feel incompetent. Database admin → developer felt incompetent. Developer → senior felt incompetent. Senior → tech lead felt incompetent. This feeling is the signal that growth is happening, not that you've made the wrong move.

✦

Twelve years is a long time. The compounding is real not just in skills, but in perspective. The problems that felt career-ending in year two are the kind of thing I solve before lunch in year twelve. If you're early in your career: it gets faster. If you're mid-career and wondering whether the next level is worth pursuing the skills required are learnable, and most of them are about people, not technology.