Let’s be real—nobody tells you how weird career growth in tech can get. You start out writing code, fixing bugs, shipping features. You get better. You start mentoring, leading projects, doing more design reviews. Eventually someone says, “Hey, you ever thought about managing a team?” And maybe you say yes, because it sounds like the next logical step. I did. And it was good. I learned a ton. But a few years in, something shifted. I missed being in the weeds—not just advising on architecture, but owning it. Not just coaching engineers, but building with them. So when the chance came to go back to IC and help lead a new, high-stakes product at DocuSign, I took it. No title, no direct reports. Just me, some messy code, and a lot of trust. This is what I learned by going "backward"—and why it might actually move you forward. Finding My Groove in the Stack Back when I joined DocuSign, my days were spent knee-deep in code. JavaScript and AngularJS on the frontend, backend services behind the scenes. Nothing fancy, just clean, thoughtful full-stack work. Except... it never really stays “just coding,” does it? I got pulled into performance issues, accessibility audits, gnarly bugs that surfaced only in production. I started poking at our testing setup, pushing for more automation. Then I dove into CI/CD. And somehow, suddenly, I was leading features that looks simple on a roadmap but takes multiple teams and careful coordination to actually ship. That one was a beast. It required tight frontend-backend coordination, graceful state handling, and extra love for accessibility. I wasn’t just coding—I was facilitating conversations between PMs, design, QA, and compliance. That blurred the line between IC and something more. I loved it. I started guiding others, reviewing more code than I wrote, spotting patterns in PRs, and asking annoying questions in design reviews. That’s when leadership started to notice—and nudged me toward management. So... You're a Manager Now Let me say this upfront: managing engineers is hard. You go from solving technical puzzles to solving people puzzles. No more PRs. Now it's calendars, 1:1s, team morale, and performance reviews. At first, I felt totally out of my depth. Like, was I even helping? I wasn’t writing code. I wasn’t shipping anything myself. What was I doing? But over time, it clicked. My job wasn’t to do the work—it was to clear the way for others to do their best work. That meant setting goals that actually meant something, making sure roadmaps were realistic, unblocking engineers, and defending their time from endless distractions. I learned how to give feedback that didn’t feel like a lecture. I started building hiring plans. I worked cross-functionally with product and design. And honestly? The best part was watching people grow—seeing someone step up, lead a feature, and crush it. But... I also missed building. There were moments I’d be in a design review and catch myself wishing I could take the ticket. Not because I didn’t trust my team (I absolutely did)—but because I missed being in the thick of it. I missed the flow state. I missed shipping. The Hard Pivot (aka Career Identity Crisis) At some point, a new project came into view—a greenfield initiative, still early, with a lot of complexity and visibility. I wasn’t asked to manage the team. I was asked to build. build Now, if you’ve ever gone from IC to manager, you know this moment. The choice. Do you keep climbing the ladder? Or do you step off and rejoin the builders? Honestly? I wrestled with it. I talked to mentors. I talked to peers. I spiraled a little. Would this be seen as a step back? Would I be closing doors? Or was this actually the smarter play? What helped me decide was this: the project was big, messy, and critical. I wouldn’t just be writing code—I’d be helping shape the thing from the ground up, working with principal engineers and product leads, using every bit of technical and organizational knowledge I’d picked up over the years. So I made the jump. No direct reports. No skip levels. Just deep work, real impact, and a clean slate. Building Again—But Different The project was already moving when I joined, but still early enough that I could help shape direction. It was meant to reimagine a major part of the DocuSign experience—no pressure, right? I wasn’t handed a spec. I was expected to figure things out. So I did what any good IC does: asked a ton of questions, pulled in the right people, and started identifying what was missing. I leaned on my past technical chops and the relationships I’d built across teams to start connecting the dots. I worked closely with platform teams, PMs, and designers. I helped establish guardrails, testing patterns, and release cadences. I got in the code, sure—but I also helped others get unblocked, make decisions faster, and avoid tech debt that would bite us later. What surprised me most? I was still leading. Just... without a title. People started coming to me for input. I found myself mentoring junior devs again. I was facilitating more than I expected. But the difference was, I also got to scratch that technical itch every single day. It reminded me why I started coding in the first place. Leadership Isn’t a Ladder If you’re in a management role and feeling the itch to build again, here’s what I’ll say: it’s okay to pivot. It’s okay to pause the climb. You’re not going backward—you’re recharging a part of yourself that may have been running on fumes. Going back to IC helped me grow in ways I didn’t expect. I sharpened my technical skills. I expanded my influence. I showed up as a leader even without the org chart saying so. And maybe down the line, I’ll manage again. But now I know I can choose based on where I’m most useful—not just what comes next on some pre-baked career track. So yeah. This isn’t a story about leaving management. It’s a story about rediscovering the part of leadership that lives in the code, the reviews, the architecture docs—and sometimes, in the bugs you fix at midnight. rediscovering the part of leadership that lives in the code, the reviews, the architecture docs—and sometimes, in the bugs you fix at midnight It’s all leadership. And it’s all valid.

This story contains new, firsthand information uncovered by the writer.

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

I Left Management to Code Again—and Found a New Kind of Leadership

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

What No One Told Me About Being a Product Manager at an Early Stage Startup

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

10 Things Every New Developer Should Know

10 Steps for Landing a Job at a Startup

10 Skills You Need For Your Post-Pandemic Career

10 Ideas To Make You A Better Product Manager

What No One Told Me About Being a Product Manager at an Early Stage Startup

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

10 Things Every New Developer Should Know

10 Steps for Landing a Job at a Startup

10 Skills You Need For Your Post-Pandemic Career

10 Ideas To Make You A Better Product Manager

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps