IC vs. Management Track — Career Growth for Engineers, Part 3
Career Growth for Engineers · Part 3
A team loses its engineering manager, and the director asks the strongest senior engineer to step in. It feels like recognition. Six months later the team's delivery is fine, but the new manager is miserable. Their calendar is one-on-ones, hiring loops and planning meetings. They still review every pull request at night because it's the only part of the week that feels like real work. Two of their engineers have noticed they never get feedback on anything except code.
Nobody asked whether they wanted the job or would be good at it. The organisation picked its best engineer, which is how many organisations pick managers.
The working claim for this part: management and senior individual contributor work are different jobs, not two rungs of one ladder. Choose between them on evidence about the work you'd actually be doing, test the choice before you commit, and treat it as reversible.
Before you start
Find out whether your company has a parallel IC ladder above Senior, and how its levels line up with management levels. Part 1 covers how to read a ladder.
Write down the three parts of your week you'd most hate to lose, and the three you'd happily give away.
Think of one manager you'd follow and one Staff-level engineer you admire. You'll use both in Step 4.
Step 1: Stop treating management as a promotion (10 min)
Many companies with a published IC ladder deliberately put the two tracks side by side. GitLab's handbook says Engineering IC Leadership "is an alternative career path to Engineering Management", and it places Staff Engineer at the same layer as Engineering Manager and Principal at the same layer as Senior Engineering Manager. Dropbox's framework likewise runs IC levels up to Senior Principal alongside its management levels.
Where that structure exists, moving into management is a sideways move into a different job. Where it doesn't, the company is telling you something important: the IC track tops out, and you'll need to weigh that.
There's also evidence that picking managers by individual performance costs organisations. Benson, Li and Shue's 2019 study in the Quarterly Journal of Economics, using data on sales workers at 131 firms, found that firms promoted their best salespeople, but those people performed worse as managers than colleagues with lower sales and better-suited characteristics. That's the Peter Principle, measured. The research is on sales teams, not engineering, but the mechanism is the same: the job you're excellent at is a poor predictor of the job you're being promoted into.
Test you can run: ask your manager, "If I stayed an IC, how far could I go here, and who's done it?" If nobody has, the IC ceiling is real at your company.
Step 2: Compare the actual work, not the titles (10 min)
The day-to-day work of the two tracks overlaps less than people expect. This comparison generalises across many teams; check it against people doing each job where you work.
Senior/Staff IC | Engineering manager | |
Main output | Technical decisions, designs, code, reviews | A team that delivers and grows |
Feedback loop | Days to weeks: it works or it doesn't | Months to quarters: retention, growth, delivery |
Hard problems | Ambiguous technical trade-offs | People, priorities, conflict, hiring |
Calendar | Long focused blocks, some meetings | Mostly meetings and one-on-ones |
You fail when | The system is wrong | People stop growing or leave |
Fournier's The Manager's Path (2017) describes the shift well: as a manager, your job becomes the team's output and its people, and the technical work you keep is in service of that.
Test you can run: look at your "lose" and "give away" lists from Before you start. Count how many items on each list appear in the manager column. If the work you'd hate to lose is mostly in the IC column, take that seriously.
Step 3: Clear out the common myths (10 min)
Three beliefs push people into the wrong choice.
"Management pays more." At companies with parallel ladders, pay bands are usually tied to level rather than track, so a Staff engineer and a first-line manager at the same level sit in similar bands. Check your own company's bands before you assume.
"ICs don't lead." Staff and Principal engineers lead through design, standards and influence across teams. Part 4 covers this. Leadership without reports is still leadership.
"Once you switch, you can't go back." Charity Majors's 2017 essay "The Engineer/Manager Pendulum" argues the opposite. She writes that "the best frontline eng managers… are never more than 2-3 years removed from hands-on work" and "the best individual contributors are the ones who have done time in management." Moving between the two is how many people build depth in both.
Test you can run: for each myth, find one person at your company who disproves it, or confirm it really does hold where you work. Either answer is useful.
Step 4: Ask the two people you admire (15 min)
Take the manager you'd follow and the Staff engineer you admire, and ask each of them the same three questions:
"What does a normal Tuesday look like for you?"
"What's the part of your job that drains you, and how much of the week is it?"
"What did you have to stop doing when you took this role?"
Listen for the drains. Everyone likes the good parts of their job. The question is whether you can live with the bad parts for years.
Test you can run: after both conversations, write down which person's drains you'd find harder to live with. That's often more telling than which person's highlights you liked.
Step 5: Try it before you commit (6–12 months)
The cheapest way to find out is to do a slice of the job. Many companies offer a tech lead role, a small team of two or three engineers to manage, or an acting manager stint while a role is open. Each gives you real management work, with a way back.
Agree the terms in writing before you start: how long the trial runs, what you'll be measured on, and what happens if you decide it isn't for you. Without the last part, a trial can quietly become permanent.
Test you can run: at the halfway point, ask two of the people you're managing for one thing you're doing well and one you should change. Then ask yourself whether you want to get better at their answers.
Step 6: Plan the way back before you need it (10 min)
People return from management to IC work for good reasons: they miss deep technical work, they found the people side draining, or the organisation changed around them. A healthy company treats this as normal. If yours treats it as a demotion, factor that in before you leave the IC track.
If you go into management, keep your technical judgment current. Review designs, stay close to incidents, and pair occasionally. Majors's two-to-three-year guideline is a useful prompt to reassess, whichever direction you're facing.
Test you can run: ask your manager directly, "If I moved into management and it wasn't right, what would moving back look like here?" A clear answer is a good sign. Discomfort is information.
Worked example (composite)
A composite scenario, not a real company or person.
A senior engineer at a logistics company was offered a manager role when their manager moved on. Their instinct was to say yes, because it seemed like the only way to keep progressing.
They checked first. The company had a published Staff level that matched first-line management in pay band, and two people had reached it in the last year. That removed the "only way up" reason. They then spoke to a manager they respected and a Staff engineer. The manager said the drain was "telling people things they don't want to hear, every week." The Staff engineer said theirs was "arguing for a design in five meetings before anyone builds it."
The engineer realised the second drain sounded tolerable and the first didn't. Instead of a yes or a no, they proposed a six-month trial as tech lead for three engineers, with a written agreement that they could return to a pure IC role. Halfway through, the feedback from the three engineers was good, but the engineer noticed they dreaded every one-on-one about performance. At six months they moved back to IC work and set their sights on Staff, with a much clearer idea of the job they wanted.
Trade-offs to make deliberately
Choice | You gain | You risk |
Move to management | Leverage through a team; people skills | Slower feedback; technical skills fade |
Stay IC | Depth; faster feedback | IC ceiling at companies without a Staff track |
Trial first | Real evidence before committing | Trial drifts into permanent without written terms |
Alternate over a career | Depth in both | Each switch needs time to rebuild skills |
Common failure modes
Treating management as the promotion. At companies with parallel ladders, it's a different job.
Choosing for pay without checking bands. Same-level bands are often similar across tracks.
Accepting because you were asked. Being the best engineer doesn't predict being a good manager.
No trial, no way back. You commit without evidence and with no exit.
Apologising for staying IC. Senior IC work is a destination, not a holding pattern.
Final takeaway
Management and senior IC work are two different jobs with different work, feedback and ways to fail. Choose on evidence about the actual work, test it with a written trial, and treat the decision as reversible. Your next action: ask your manager how far the IC track goes at your company, and who has done it.
Sources
Benson, A., Li, D. and Shue, K. (2019). Promotions and the Peter Principle. Quarterly Journal of Economics, 134(4), 2085–2134. doi.org/10.1093/qje/qjz022
Majors, C. (2017, May 11). "The Engineer/Manager Pendulum." charity.wtf
Fournier, C. (2017). The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change. O'Reilly Media.
GitLab. Engineering IC Leadership and Organizational Structure, GitLab Handbook. handbook.gitlab.com, accessed October 2026.
Continue the Career Growth for Engineers path
Previous — Part 2: Write a Promo Packet
Part of the Career Growth for Engineers learning path. Related: The Tech Lead Transition · Run Effective One-on-Ones · Engineering Leadership.
