Why I Quit Management to Code Again—and What It Taught Me About Real Leadership

Honestly, no one tells you how strange and challenging a tech career can be. When you start writing code, fixing bugs, and shipping features, you eventually begin to mentor others, lead projects, and conduct design reviews. Suddenly, people ask, “Hey, have you considered managing an R&D team?” It sounds logical, and I said yes.

I took the role, helped lead a high‑risk new product at DocuSign, and worked without a formal title or direct reports—just me and a mountain of messy code, but with a lot of trust. That experience taught me that leadership isn’t just about architecture advice; it’s about creating with people.

Back in the DocuSign team, I wrote full‑stack code: JavaScript and AngularJS on the front end, Java services on the back end. The job quickly expanded beyond coding to performance tuning, accessibility audits, and bugs that only appear in production. I dove into testing configurations, automation, and CI/CD pipelines, discovering that even seemingly simple features required tight coordination across multiple teams.

The role blurred the line between internal control (IC) and other responsibilities. I found myself coordinating project managers, designers, QA, and compliance, while still writing code and reviewing pull requests. I began spotting patterns in PRs, asking tough questions in design reviews, and eventually leadership encouraged me to move further up the management ladder.

Transitioning to a manager meant swapping technical problem‑solving for people‑problem‑solving: scheduling, one‑on‑ones, team morale, and performance reviews. At first I felt out of my depth—what could I actually contribute when I wasn’t writing code or delivering features?

Over time I realized my job was no longer about doing the work myself but clearing obstacles so engineers could perform at their best. I set realistic technical roadmaps, protected engineers from endless interruptions, gave non‑pedantic feedback, and helped shape hiring plans while collaborating cross‑functionally with product and design.

Even though I missed the pure engineering experience, I found a new kind of fulfillment in watching people grow, seeing products succeed, and leading without a formal title. When a large, ambiguous project appeared, I was asked to act as an architect, not a manager. I leveraged my development background and network to stitch together platform, project, and design teams, establishing safeguards, testing patterns, and release rhythms.

The most surprising part was that I continued to mentor developers, solve technical challenges daily, and rediscover the joy of coding that first attracted me to the field. I realized leadership exists in code reviews, bug fixes, and architecture documents—not just in meetings.

If you’re an engineer contemplating a move to management, you face a choice: keep climbing the ladder or step back to the creator’s side. Both paths are valid; stepping back can recharge you and let you apply your technical expertise in new ways.

Returning to an engineering role without direct reports let me focus on impact, deepen my technical skills, and grow my influence organically. I now choose projects based on where I can add the most value, rather than following a preset career track.

This story isn’t about abandoning management; it’s about redefining leadership through hands‑on development, design reviews, and architecture work, proving that effective leadership can thrive wherever you contribute.