David Loftesness has had a legendary run in engineering leadership. During stints at companies like Amazon, Twitter and eero, he steered teams from dozens to hundreds of engineers. But with such a stacked resume, you might be surprised to learn that his current title isn’t VP or CTO, but “Developer” at Nitid — and manager of none.
So why trade in his management duties some thirty years into his career? For one reason: “I just missed that feeling of shipping code,” he says. It’s an unconventional move for someone of his tenure, but he’s found it incredibly rewarding to return to his coding roots.
This wasn’t the first time he downsized his management scope, either. He’s switched between manager and IC engineer roles (and back again), even cycling between managing ICs and managing managers multiple times.
Loftesness knows a handful of fellow engineering leaders who’ve pulled off the same pivot, and suspects many more are curious about looping back to IC work, for a variety of reasons — but it can be a difficult subject to broach.
The transition to management isn’t a one-way door. Returning to hands-on engineering doesn’t signal failure as a manager. You can continue to be a leader without being a manager — they’re not the same.
So now, Loftesness wants to remind managers itching to get back to the technical trenches that this option is on the table — and it’s not a step backward. But there will be organizational, communication, and even psychological hurdles ahead, from navigating resistance from your manager to dusting off the cobwebs on your coding skills, especially with how rapidly the tech landscape is changing lately.
Several years back on The Review, Loftesness shared a hugely popular 90-day plan for newly minted EMs (which he later expanded into a helpful book on managing through hypergrowth called “Scaling Teams”). Now that he’s settled back into life as a dev, he’s following up with yet another 90-day plan — for EMs who want to transition back into IC work.
In this exclusive interview, Loftesness outlines a set of considerations to make sure this is the right call, offering a preview of the challenges and thorny emotions that lie ahead, with examples from his own cycles between EM and IC. He then walks through his transition plan, breaking down how to work with senior management, communicate the change to teammates and adjust to new rhythms over the course of a 90-day period. He’s also got plenty of guidance for how engineering orgs can do a better job supporting these pivots.
Whether you’re a veteran eng leader hungry for a change of pace or a newer manager at wit’s end, Loftesness has wisdom for every type of crossroads. And his advice isn’t just for engineers — managers of any function who are tempted by a move back into the IC domain can pull from the pages of his playbook. Let’s dive in.
COMMON SCENARIOS FOR A LANE SWITCH
Loftesness has observed a host of reasons that push EMs to return to IC work — and he’s had different motivations each time he made the switch. He sketches out the three most common candidates for this transition, alongside what each should keep in mind before making the decision official.
The new EM who’s not fit for management: Look before you leap
It’s a familiar story: a talented engineer who communicates well is rewarded with a management role and a host of new responsibilities. But with little to no training or mentorship, the new manager can easily crash and burn.
“I run a training course for engineers considering a management role — and I consider it a good outcome if roughly a third of the participants decide not to make the jump,” says Loftesness. “Strong technical skills aren’t sufficient to succeed as a manager. So as a class, we’ll practice management skills like giving difficult feedback, closing a candidate or handling conflicts between teammates. There’s even a scenario where I play a struggling engineer and a participant has to ‘fire’ me. These are critical responsibilities for managers and, just like catching bugs in your code, you want to find out as early as possible if there’s going to be a problem,” says Loftesness.
But of the engineers who do decide to make the jump, even those who go through ample training, many only realize management isn’t for them after the transition. If you fall into this camp, Loftesness cautions against jumping ship as a manager before you’ve given yourself enough time to fully recalibrate into your new role.
“Sometimes the initial shock of imposter syndrome will scare someone off within three months,” says Loftesness. “More common are people who never fully transition into management because they can’t let go of the code — they’re still jumping in to fix things instead of learning how to delegate.” (We highly recommend giving his original Review article a read for more pointers on this tricky transition period.)
“It can take six months or more to really lay down the keyboard and focus on the needs of your team: clear goals and priorities, effective 1:1s and productive communication,” he says. “And then you might need another six months to develop your skills and feel comfortable. After that, if the manager’s mantle still doesn’t feel right, you can go back to an IC role knowing that you gave it your best shot, and hopefully learned some things along the way.”
Even with adequate training, it can take a year to fully adjust to a new management role. Don't cut bait too quickly.
The seasoned EM who wants to get closer to the tech: Prepare for a steep (re-)learning curve
On the other end of the spectrum, there’s the senior EM who’s forged a career in management. They’ve successfully scaled teams, produced great outcomes and found leading others deeply fulfilling. But years fly by and one day, they zoom out of their planning meetings and 1:1s only to realize it’s been years since they shipped a single line of code.
That’s exactly where Loftesness found himself after his tenure as Head of Engineering at eero. He was hankering to go deep again and play around with the latest tech — the reason he fell in love with engineering in the first place.
“As a young engineer-turned-manager, my understanding of the developer experience was a strength that helped me manage better. But over the years I felt more and more out of touch. I’d have conversations with my team or listen to tech podcasts and I could grasp the concepts, but I knew I was missing the details. And sometimes, those details matter,“ says Loftesness.
He also felt that his lack of familiarity with the cutting edge was impairing his technical taste as a manager. “Even though I was still involved in architecture and technical design decisions, at some point I realized I was following much more than leading. I may not have been expected to code, but I couldn’t really review it anymore, much less write it effectively.”
If Loftesness’ code cravings resonate with you, the switch back to IC might be fulfilling. But know that you’ll probably encounter a steep learning curve and some uncomfortable emotions as you ease back into a routine you’ve likely not had for years (more on the exact flavor of those emotions below).
Loftesness has also seen these two secondary factors compel experienced managers to step into an IC role:
- The tour of duty to better understand the developer experience: “I’ve seen situations where a team’s productivity wasn’t at the level it should have been. I’d think, ‘This is a solid team. Why aren’t they getting more done?’” says Loftesness. “In one case, I asked the manager to temporarily get more involved in the development process while I helped cover her manager duties. By returning to the engineering front lines, she was able to find gaps in tooling and processes that were causing delays, and then prioritize fixes in the next milestone.”
- Stepping aside to let a rising star step up: A long-tenured manager may feel they’re inhibiting the growth of someone who’s ready to operate at the next level. This has happened twice in Loftesness’ career — which reaffirmed his personal desires to make the shift (and made succession planning easy). “Each time, I was already thinking about reducing my scope, moving from manager-of-managers to a frontline EM,” he says. “By handing the reins to a rising star and taking a new role myself, I gave them an opportunity to grow while remaining available for guidance and mentorship.”
The burnt-out EM who needs a break: Plan for a management hiatus
Even the best managers get burnt out. Daily meeting marathons, working nights and weekends, being on the hook for quarterly goals — and being responsible for your team’s happiness — can start to take a toll.
Loftesness has been in this boat, too. The first time he scaled back his management duties was for personal reasons. While a Senior Manager at Amazon, his first child was born. He’d enjoyed his run as a manager, but the demands of parenthood forced a change.
“After returning from paternity leave, I told my boss at Amazon ‘I’m so focused on my kid’s needs, I have no cycles left to worry about anyone else,’” he says. For whatever reason — a child, an illness, a major life event, burnout — there are times when forging ahead with your management responsibilities feels unsustainable, or even detrimental to your health, at least in the short term. But you might be worried that if you abandon your post now, you’ll never be able to return to management.
Loftesness’ own cyclical career proves otherwise: Stepping back from management doesn’t have to be a permanent change. You can take a one- or two-year detour to IC work and switch back to management when you feel better equipped to shoulder your responsibilities. Your management credentials won’t expire — and you’ll return with fresh technical knowledge to boot.
“Engineers are given a management opportunity in the first place because they’ve demonstrated good judgment, clear communication, and the ability to deliver. Those qualities don’t just go away,” he says.
If anything, you’re going to get asked to manage again — probably sooner than you want. So you should worry more about fending off a return before you’re ready, instead of not getting asked again.
Loftesness also reminds folks in this camp that taking on more and more management responsibilities isn’t the only way to grow as a manager. In his experience, taking breaks from management has actually made him a better manager.
“The cycle can feel like deep breathing. Breathe in to take on new levels of responsibility and challenges, then breathe out to step back, reflect, and prepare for what's next,” he says. “You may find yourself much more prepared next time around.”
Loftesness first ran into this phenomenon while honing an entirely different skill: snowboarding. “I'd make progress on a new technique up to a point, but then it felt like the harder I tried, the worse I got,” he explains. “I realized that taking a break was the key. After a few weeks, I’d hit the slopes again and surprise myself by nailing it the first time. I later learned that our brains have the ability to continue working on problems or skills subconsciously, a process called incubation. It’s the same for shifting levels of responsibility as a manager — when you get to the point where you’re like, ‘Oh boy, I’m struggling here,’ consider pulling back for a year or six months. Then when you return to it, it’ll feel easier and more comfortable.”
Every time I've taken a break to return to coding, I've become a better manager. Sometimes you need to step away from the trees to see the forest.
BRACE FOR THESE PSYCHOLOGICAL ROADBLOCKS
Whether it’s been a year or over a decade since you last contributed code on a daily basis, settling back into developer rhythms won’t happen overnight. It’ll take some time to retrain your coding brain — which will bring all sorts of pesky emotions.
These are a few of the uncomfortable feelings Loftesness has run into during these transitions:
- Some awkwardness with your new teammates. Remember when you first started managing and your peers suddenly became your direct reports? The same is true in reverse. You might now be working side-by-side with people with much less experience than you — maybe even people you used to manage — but who are much more comfortable churning out code. “It's tough to have a 25-year-old recent grad looking over my shoulder while I'm fumbling around with syntax details that I don't quite remember,” says Loftesness. “But you just have to be humble and power through. Take advantage and learn from your peers’ expertise and you’ll return to form more quickly.”
- Imposter syndrome 2.0. You felt it when you first became a manager — why should anyone listen to you? Now get ready for imposter syndrome in the opposite direction as you refresh your technical chops. “But it’s easier this time around because you’re familiar with the role, and you have the perspective of a former manager,” he says. “After all, you used to set the expectations for your team members, so you know what’s required to perform in your new role.”
- Leadership meeting FOMO. “ICs are often jealous of the management team because they have access to information that they don't have. There are meetings they can’t go to where juicy stuff is shared,” says Loftesness. “But your knowledge of communication channels can still be a huge asset — you just need to tap into them only when necessary. Remind yourself, ‘I don’t need to know that,’ and ‘That’s not my problem anymore.’ The feeling will dissipate with time.”
- Re-wiring your brain to find a flow state. Days that used to be stuffed to the brim with meetings will now be wide-open — so you’ll need to figure out how to get back into execution mode. “The longer you've been in management, the more your brain is wired around a tight loop. So it’s hard to get really into that focus state.”
- Technical rustiness. It’s probably been some time since you learned a new technical skill or got your hands dirty in a new environment, so you’ll need some patience with yourself as you brush up. “For example, the explosion of cloud computing platforms in the 2010s fundamentally changed how we build systems,” he says. “At the time, I was observing these changes while learning how to be a director of engineering — and was honestly more focused on the challenges of managing managers. It wasn’t until I handed the reins to my successor and took on a 4-person team that I started to fully internalize how the shifts in the industry impacted what we did day-to-day.”
When you flip back down to the IC level after years of leading engineering orgs, you’ll often find yourself paired with engineers who were in diapers when you were writing your first lines of code. It's humbling — and it’s healthy.
THE 90-DAY PLAN
Once you’ve decided the switch back to IC is right for you, you’ll face two options: find a parallel rung on the IC ladder within your current company — or seek a new role elsewhere.
Loftesness would recommend making an internal transition, if possible. “It's ideal to make the change within your current company where you have working relationships and lots of context,” he says. “But if your manager isn't supportive or you don't see an IC role that fits, consider looking externally. Make sure to reach out to former colleagues who know your past IC work."
After pulling off this transition several times and coaching a handful of folks through it, here’s how Loftesness would tackle the transition over the course of 90 days. You’ll find his advice from pre-day one through day 30 most helpful if you’re embarking on an internal transition, while the pointers from days 30 onward will come in handy no matter if you’re opting to start fresh at a new company or staying under the same roof.
We’re echoing the 90-day framing Loftesness used in his plan for becoming a manager, but these changes will often take much longer to play out, of course. Use this framework as a starting point for your own transition plan.
Before day 1: Break the news to your manager and help find your successor
Put together a transition plan.
You won’t just be able to update your title in your company’s org chart and call it a day. It’ll take some thought to figure out what your transition means for your team.
First, ask yourself: Is there someone at the company who’s ready to step into my manager role? Take some time to think about succession planning before you tell your manager. “Your boss has probably come to rely on you, so having a recommendation for a replacement at the ready will make the change easier to swallow,” he says.
If you don’t have a potential successor on the team, remember that hiring externally will take time. But by leading the search for your replacement, you can ensure that your team has the right leader going forward (while trimming back your boss’s workload).
Even if you know the perfect person to take over your role and have a compelling reason to switch to IC, your manager might not be on board right away. “You can allow room for negotiation, but don’t forget that you can’t take care of your team if you don’t take care of yourself. The reminder to ‘Put on your own oxygen mask first’ rings true here,” says Loftesness.
Finally, expect a range of reactions from teammates. “When I made my announcement, I got three different reactions,” he says. “It was a mix of, ‘Aww, I want you to stay being my manager,’ and ‘What happened? Are you getting demoted?’ and ‘Good for you!’”
Ask your burning questions about compensation and level.
You might be worried that switching to an IC role means a demotion or a reduction in pay. But most tech companies have parallel career ladders for ICs and managers.
Approach this conversation with your manager with the understanding that this is a lateral move and make sure your manager agrees, even if there aren’t precedents for this kind of transition at your company.
Here’s how Loftesness navigated the levels conversation with his manager back at Amazon, where he wound up coining a new title: “As a manager, I was at a high enough level that the equivalent IC level was principal engineer. It didn't feel appropriate to me or my manager to take on that title right away, so we worked out a custom title of ‘Product Search Architect’ to better reflect how I'd be able to contribute in the near term,” he says.
Don’t forget to tell candidates in the hiring pipeline about your plans.
Recruiting new team members while you’re planning your transition can be especially delicate. After all, working for you may be a key motivator for a new hire to join. Deciding how to handle this will depend on the specifics of your situation.
Loftesness made the mistake of not communicating his plans to a new hire while he was a Senior Manager at Amazon. “I’d been trying to hire a strong EM for months and even spent time during paternity leave talking with them. They signed their offer and started work almost exactly when I returned from leave. When I told them my plan to return to IC work, they said, ‘But I came here to work for you!’ I wish I’d thought more about the situation ahead of time and had a plan already in hand.”
Days 1-30: Communicate the transition and refresh your tech setup
This first month, focus on explaining your transition to the team and getting your replacement up to speed. Close out this phase of your management career by staving off disruption and ensuring a smooth handoff to your successor.
But Loftesness notes that all kinds of communication tripwires can crop up during this first portion of the transition. Here are his order of operations to bring your org into the loop:
- Draft up a plan with your (new) manager: Whether you have a new boss in a new org or you’re keeping your existing one, make sure to put a transition plan in writing, complete with milestones and success criteria.
- Circulate your plan with your new peers and former reports. Communicate with former and new colleagues that you’re beginning the transition into an IC role and what that means for their relationship with you.
- Hear out concerns from your team. Your former reports might be confused or upset by this change. “But unlike when you’re leaving the company entirely, you can signal to people that you’ll be around to collaborate and offer guidance,” says Loftesness.
- Train up your replacement. Keep your existing slate of management meetings during these first 30 days and bring in your replacement to shadow you. Once they’re settled in, switch to “reverse shadowing,” where the replacement takes the active role. And be prepared for this training to last well beyond 30 days. “I would keep that 1:1 with the person taking over your job for a while,” he says.
Loftesness would also recommend carving out some time in these first 30 days to dust off your favorite dev environment and play around with new ones — so you can hit the ground running when you do start coding.
“I’d lived inside Emacs for most of my coding career, but my default setup was pretty outdated,” he says. “When I started pairing with other devs at Nitid and saw what they were getting out of the box with VS Code or RedMine, I knew it was time to modernize my setup or switch altogether. Newer features like AI integration are a must-have, too.”
Days 30-60: Settle into the maker schedule
Around the one-month mark comes the exciting part — it’s time to shed your management duties and get fully back into the coding mindset. But remember that you can’t have your code and be a manager, too. This means winding down recurring meetings, 1:1s with former reports and teammates, and any other obligations that might get in the way of refinding your rhythm.
While the second month is a good time to start restructuring your calendar, Loftesness acknowledges that setting these boundaries is hard. “It takes a while to cut the cord. Folks are used to dropping by for advice or to escalate a problem. It’ll take some time to reset their expectations,” says Loftesness.
He’s made the mistake of hanging on to old manager meetings for too long in past IC transitions. “Even after it had been a few months, I kept a lot of one-on-ones on the books with people I worked most closely with, because it’s hard to just stop them cold — but that can fragment your calendar and get in the way of the focus time you need for your new work,” he says. “Catch up with them at lunch or after work instead so you can maintain the relationship without delaying the transition to your new role.”
Don’t try to do both jobs, or you risk failing at both.
Here are Loftesness’ tips for priming your schedule — and brain — for the technical learning ahead:
Deep-clean your calendar.
“The first time I returned to an IC role, I had no problem with small coding tasks and debugging, but felt like I was struggling with larger, more complex tasks. At first I chalked it up to being rusty, but I eventually realized that there were two other factors getting in the way: Lingering obligations and expectations,” says Loftesness.
“I knew I needed to shift from a manager’s to a maker’s schedule, so I cleared my calendar of most of my meetings. If there are people you still want to keep in close touch with, push these meetings to ad-hoc check-ins or catch up over lunch.”
But he adds one caveat — you should absolutely keep 1:1s with your replacement on your calendar for a while. “This is worth the cost of one hour a week,” he says. “You can help them figure out what’s appropriate to share from leadership meetings to the rest of the team.”
Holding on to this 1:1 also has the knock-on benefit of keeping you in the loop on leadership happenings while you step back from that orbit. “It’s an opportunity to know the kinds of things that happened in that meeting — I wouldn't have to feel like I was left out.”
Carve out long blocks of time to try (and fail) to refind your flow state.
“After managing for a few years, I had adjusted to the manager’s workload of frequent meetings, lots of interruptions and shifting priorities. But even after clearing my calendar, my brain kept interrupting itself,” says Loftesness.
“Instead of focusing on the task at hand, my attention would go to, ‘Am I prepared for my next meeting?’ or ‘Have I followed through on my action items for the day?’ I found it hard to focus on one task for very long.”
You probably won’t be able to go hours on end in your first 30 meeting-free days, and that’s okay. The goal is to keep pushing to work for longer and longer periods uninterrupted — with others or by yourself.
Loftesness is still working on finding his flow state a year into his stint as a developer. “I can lose track of time and go really deep, but only for an hour or two,” he says. “One thing that’s helped me is setting a timer for longer and longer time periods to try to stay focused until it goes off. This helps retrain your subconscious to stop worrying about being late to your next meeting or checking Slack.”
For some long-form reading on how to harness your deep focus, Loftesness recommends Finding Flow by Mihaly Csikszentmihalyi.
Days 60-90: Learn and lead with humility
“By now you have enough context to set specific goals for yourself and measure your progress,” says Loftesness. “Use these 30 days to build a training plan for the next 90 days. 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,” says Loftesness.
Firm up a self-education plan.
The good news is that there are also heaps more engineering educational resources available compared to the last time you picked up a new programming language. Take advantage of the wealth of information out there and build learning time into your schedule by signing up for classes, digging into YouTube tutorials, and leaning on Claude and ChatGPT to walk you through it. “Just take these resources with a grain of salt. Generative AI can answer a lot of questions, but make sure you understand its suggestions before you copy-and-paste them,” he warns.
Here are a few of the learning strategies he’s added to his own toolkit:
- Brush up with online learning platforms (like LeetCode.com): “For a month, I solved one coding problem a day on LeetCode. By the end, I definitely felt the solutions come to mind more easily and didn't need to stop and look things up as often,” he says.
- Lean on pair programming, or coding alongside peers: “It was awkward at first since pairing wasn't a common technique when I started coding,” he says. “But watching how other people approach problems and use their tools can really accelerate your progress. Your pair can answer questions quickly and provide guidance and context. And pairing helps keep you focused, since you won't be checking your email while sharing your screen with your pair.” Loftesness likes using pop.com for remote pairing or small group collaboration.
- Take advantage of your company’s education offerings. “My current company Nitid has a weekly professional development lunch session where one person presents on a specific topic. We've been working our way through Typescript tutorials, and the weekly cadence helps maintain momentum. It's also great to be learning with others — so you don’t feel like you're the one who's lagging behind.”
Loftesness would also encourage you to break out a pen and paper when you’re learning new technical skills. “Keep a work log. Write more things down. Your brain works differently now — it’s harder to retain new information.”
Embrace the vulnerability of the learning process.
A growth mindset is a must during this period. “It’s uncomfortable to shake off your rust and relearn stuff because it makes you vulnerable,” says Loftesness. “But that’s a good thing. Strong working relationships are built on trust, and you have to give trust to get trust.”Remember that everyone’s rooting for your smooth transition. “Nobody wants to make fun of you. No one is like, ‘Oh my God, I can't believe Dave couldn't figure that out.’ They want to see you succeed, too.”
Keep leading — but don’t manage.
As a manager, you’ve seen how strong ICs can help set the direction for the team. Now it’s your turn. “Your years of experience, seeing what’s worked and what hasn’t is a real asset. Use this to help your manager and the team see around corners,” says Loftesness.
“But don’t be the grumpy veteran and cry ‘Kids these days,’ or ‘They don’t make things like they used to,’” says Loftesness. “And remember that as a former big wig, you may be intimidating to folks on your team.”
He offers up an example of how he learned to adjust how he showed up during meetings back at Twitter. “As the Director of Twitter's Core Services org, I sometimes had to ask tough questions in technical meetings to make sure we were headed in the right direction. But after I handed the reins to one of my direct reports, I took on a smaller scope and had a different role in those meetings. I realized I needed to make space for her to ask those tough questions and provide direction. Otherwise, the team might get mixed messages or give my opinion too much weight,” he explains.
Loftesness also cautions against being overly dogmatic based on your past experience. Don’t assume that what’s worked in the past is the best thing in your current context. Ask your teammates questions instead of making sweeping statements. “You don’t want to be the guy at a party who’s talking the whole time. I find it’s more helpful to draw on your experience in the form of a question. For example, you might ask, ‘Do you think it would be better if we tried this?’ As opposed to, ‘This is what we did in my last job and it always worked better.’”
Apply your experience wisely — sensitive to the context of your new situation. Dispense wisdom as questions, not answers.
He shares an example of a time at Nitid when he was able to pull on his deep experience to catch a blind spot that younger devs wouldn’t have clocked. “I’m able to contribute at a different level than they can,” he says. “They knew the exact syntax to use the library, while I was able to recognize what was wrong architecturally.”
He also likes to implicitly demonstrate leadership to his junior (and even senior) teammates by showing that it’s okay to ask “dumb questions.” “Sometimes everyone is confused but no one feels comfortable asking for clarity,” he says. “So the question that seems silly is what actually helps move things forward. I’ve seen this happen enough times that I’ll take the risk of revealing ignorance for the chance of boosting understanding.”
With experience, you get more confident in your ability to put yourself out there for the sake of learning. Being embarrassed in front of your coworkers felt like the worst thing in the world when I was 28, but now I can take it when I have my own kids making fun of me all day.
After day 90: Take a temperature check on your new life as an IC
As you commit to your new routine and learning process, it’s a good time to take stock of how things are going — and how you’re feeling about this change.
A word of warning: The hardest work of the transition will extend far beyond 90 days. “Over a year in, I'm still not fully comfortable in the IC role,” says Loftesness. “I have high expectations for myself and want to contribute at the same level as other developers with similar tenure. That may be unrealistic, but by continuing to set learning goals, I can hopefully close the gap over time.”
Loftesness suggests asking yourself these questions after month three:
- Where are my knowledge gaps? Invest time with fellow ICs to observe how they do things or pick their brains about a new tool or domain that you haven’t been making huge strides with on your own. “Development environments have a lot more features now than 20 years ago,” says Loftesness. “So when I first started pairing, it became obvious that my old-school Emacs setup needed modernizing. With help from my coworkers, I set a goal to get a specific set of features working in my dev environment.”
- Am I still getting roped into old management duties? What can I do to protect my schedule? If you keep getting interrupted with asks that aren’t your responsibility anymore, have a conversation with your manager to make sure former reports and teams have the resources they need without you being on call.
- Do I see myself staying as an IC for the long term? Check in on whether your intentions before the change are tracking with your experience so far. Do you actually love coding as much as you thought you missed it? Do you miss having meaningful relationships with your reports? Be honest about how it’s going.
A CALL TO ENGINEERING ORGS: BUILD PARALLEL IC AND MANAGEMENT ROUTES (AND OFF-RAMPS)
Whether an engineer plans to return to management or wants to switch back to IC for good, org leaders need to create an environment that supports both outcomes. That starts with having parallel career tracks for ICs and managers — and being careful when messaging “promotions” into management.
“When an IC steps into a management role, avoid announcing it with a bunch of fanfare,” says Loftesness. “If the new manager eventually decides to return to an IC role, they may feel that they’ve failed — instead of feeling proud of making a difficult decision.” So when people do step into EM roles, message it thoughtfully. “It shouldn’t be, ‘Let’s have a party and celebrate this person’s new title.’ Because then it makes it really hard to go back — that’s how people end up stuck in a management role they hate.”
Announce management transitions as an opportunity, not a promotion. With too much fanfare, new managers will feel stuck in their new role, even if they decide it’s not for them.
If orgs don’t set up a landing pad for managers who want to pivot back, they’ll risk losing great engineers to opportunities elsewhere.