This week, a veteran engineering leader opens up about his experience returning to his coding roots — and shares a detailed plan for managers itching to make the leap back to IC.
This 90-Day Plan Turns Engineering Leaders Back into Frontline Developers
Somewhere in the early to middle innings of their career, senior engineers hit a fork in the road: Go for the EM promotion and climb the people management ladder, or stick to the IC route toward staff or principal and stay close to the code. Once you pick a direction, like it or not, it often feels like you can’t change tracks.
David Loftesness has criss-crossed the two — multiple times. He earned his stripes as an engineering leader at companies like eero, Twitter and Amazon, steering eng teams in the dozens and even hundreds, even cycling between managing managers and managing ICs. Then, about a year ago, he traded in his management duties entirely and assumed the humble title of “Developer” at a firm called Nitid.
It’s a career pivot he’s found incredibly rewarding so far, and now he wants to help other engineering managers make the same jump. But folks might be hesitant about optics, or even feasibility. “The transition to management isn’t a one-way door. Returning to hands-on engineering doesn’t signal failure as a manager,” he assures. “You can continue to be a leader without being a manager — they’re not the same.”
Engineering leaders might feel a pull to return to IC work for a host of reasons. Maybe management’s not a fit, or burnout has become unbearable. For Loftesness, it was this: “I just missed that feeling of shipping code,” he says — a desire many eng folks can probably relate to, especially as the tech landscape gets shaken up by each new AI announcement.
Some years back on The Review, Loftesness shared a 90-day plan to help engineers step into management. In this exclusive interview, he uses that same framing for the other side of that transition, offering a preview of the thorny emotions that might crop up along the way, plus super specific tactics for each step.
Here’s a snapshot of his 90-day plan:
- Before day 1: Break the news to your manager and help find a replacement. Whether you’re staying under the same roof or leaving for an IC role at another company, be proactive in designing your succession plan.
- Days 1-30: Communicate the transition and refresh your tech setup. Break the news to your former reports and train up your replacement. Take some time to dust off your old dev environment and play around with new ones so that you'll be ready to hit the ground coding.
- Days 30-60: Settle into the maker schedule. Focus on cutting the cord from old management responsibilities and deep-clean your calendar. “Don’t try to do both jobs, or you risk failing at both,” says Loftesness.
- Days 60-90: Firm up a coding (re)-education plan. “Figure out a plan to pair up with ICs on your team and build a week-by-week agenda of going through tutorials. It helps to have a more structured learning process,” he says.
- Day 90 onward: Take a temperature check on your new life as an IC. Loftesness cautions that settling into IC rhythms will take much longer than 90 days. “Over a year in, I'm still not fully comfortable in the IC role,” he says. But newly minted ICs can speed up the adjustment period by identifying knowledge gaps — and taking the initiative to learn alongside new peers.
While some of Loftesness’ advice isn’t exactly transferable to non-engineers (like using LeetCode to brush up on coding skills), leaders of any function who are mulling over a detour from management can take pointers from his thoughtful approach.
Thanks, as always, for reading and sharing!
-The Review Editors
Recommended resources:
-Why now might be a good time to make the leap back to IC product roles
-A peek under the hood of Calm’s engineering strategy
-A breakdown on what DeepSeek means for AI in the US