The Manager-to-IC Resume Teardown, Every Bullet Tagged Keep, Rewrite, or Cut

This guide is for people managers who want senior individual contributor (IC) roles in the same field and need a resume that reads as hands-on, not as a manager in retreat. It follows one illustrative engineering-manager history through every cut: each bullet gets tagged and decided, an IC target level gets mapped from published dual-track ladders (career frameworks with parallel manager and IC levels at matching grades), the titles stay true to HR records, and each core skill gets a dated recency line. Keep your own resume open and make each decision on it as the example does.

What a recruiter checks on a former manager's resume

A recruiter reading a manager-to-individual-contributor resume is screening for four worries: that you'll leave for the next management job, that you expect manager pay, that your hands-on skills have faded, and that you'll resent being managed. Your titles can't change, so the rewrite has to answer all four in the bullets and in one intent line.

Here are the four worries, in the words hiring managers and recruiters use in public:

One senior-engineer screening guide puts the recruiter's question bluntly: "are they an IC or have they drifted into leads/management?" Nobody has published which part of a resume each worry keys on, so the right-hand column is my reading, not a measured finding. You can test it yourself: after each screen call, write down which worry the recruiter raised and which line of your resume they were looking at when they raised it.

Two facts make these worries less fatal than they feel:

• The move is common. Philip Su switched from manager to individual contributor three times at Microsoft and once at Facebook.
• You're not alone, which also means you have competition. A LeadDev survey of 600 leaders found that one in three managers is considering leaving management to become an IC. I've only seen that figure second-hand, so check the primary report before you quote it. If many managers are making the same move, the resume with dated hands-on work wins.

The worked example: one people-lead history

The example is an engineering manager with four years leading a backend team of seven. Before that she spent three years as a Senior Software Engineer and two as a Software Engineer. Every count in this teardown is illustrative. Nobody has measured how real manager resumes split between hands-on, team, and people-management bullets, so read the numbers as a worked example, not a benchmark.

Her starting resume:

• Engineering Manager, 4 years, 14 bullets
• Senior Software Engineer, 3 years, 5 bullets
• Software Engineer, 2 years, 3 bullets

The older IC roles are already mostly hands-on, so the real work is in the manager role. A recruiter uses those 14 bullets to decide whether she is still an IC or has drifted. The four years matter on their own too. Charity Majors, who writes about engineers moving between management and IC, says that after two or three years of management "your skills begin to decay". Every bullet from her Senior Software Engineer years is more than four years old, so none of it proves she's current.

The first fork is where to start. HBR and Fast Company put mindset and self-reflection first. Background-check sources put records first. I side with records, because every later decision depends on what the HR file actually says: which title to use, which dates, whether there's a gap. In the example, her memory of her manager start date was two months off the offer letter. Failure mode 7 below covers why that matters.

The manager-to-IC resume procedure

The procedure has eight steps. It starts with records and ends with an audit against those same records. Everything in between turns manager bullets into IC evidence. The timings are my desk estimates, not measurements, and total roughly 7 to 9 hours: 1 to 2 for records, 1 for tagging, 1 to 2 for decisions, 30 minutes for level, 15 for titles, 1 for recency, 15 for the intent line, and 2 for probe-testing.

Steps 2 and 3 change the most text. Steps 4 to 6 carry the most risk, because that's where a wrong choice either shrinks your options or creates a mismatch someone can check.

Tagging and cutting the bullets: where the 14 went

Tag every bullet as hands-on (H), team-attributed (T), or people-management (P). Then keep the H bullets, rewrite the T bullets to show your personal share, and cut the P bullets down to one scope line per role. In the example, 9 of the 14 manager bullets survived. It took two wrong turns to get there.

The three tags, and how each one misleads

• H, hands-on. You did the work yourself. It proves current craft. It misleads when "I" covers work the team did, and the deep-dive question will expose that.
• T, team-attributed. The team delivered it while you led. It proves scope and judgement. It misleads when it's the only evidence of craft on the page, because then the resume reads as pure management.
• P, people-management. Hiring, reviews, coaching, headcount, process. It proves you can lead. To an IC screener it signals that management is still your job.

First pass, and the wrong turns

Her 14 manager bullets came out as 3 H, 6 T, and 5 P. On the first pass she kept all 3 H bullets, rewrote all 6 T bullets to start with "Designed and built", and cut all 5 P bullets. That left 9 bullets that all read as personal work, and two wrong turns were baked in.

Wrong turn: deleting all team scope. With every P bullet gone, nothing on the page said she had led seven people. Scope of responsibility counts as material on a resume, and her references would describe her as a manager. So she restored one P line that states hiring and team size, along the lines of "Hired four engineers and grew the backend team to seven."

Wrong turn: overclaiming team output. "Team migrated the payments service to an event-driven architecture" had become "Designed and built the event-driven payments pipeline." The deep-dive question senior loops ask is: "Which parts of the design did you own personally versus inherit or delegate?" Her honest answer: she wrote the design doc and built the consumer prototype, and the team wrote most of the production code. The final bullet says exactly that: "Wrote the design doc and built the consumer prototype for the event-driven payments migration; a team of five delivered the production rollout."

A second T bullet, about the team cutting deploy time by [X]%, had no commit or design doc of hers behind it, so it went.

Final count for the manager role:

• H: 3 of 3 kept
• T: 5 of 6 rewritten to state her share, 1 cut
• P: 1 of 5 kept as the scope line, 4 cut
• Survivors: 9 of 14

What IC level is equivalent to a manager?

Most published mappings put a first-line engineering manager at the same level as Staff Engineer. Of 8 secondary level-mapping pages I tallied, 6 say Staff, 1 says Senior, and 1 ranks manager above Staff and Principal. Nobody has published a share computed from companies' own ladders, so use the tally to set expectations and use the target company's own ladder to decide.

Two more pages, em-tools and leonstaff, also map a first-line manager to Staff. They don't give a separate senior-manager mapping, so they aren't in the table. That makes 6 of 8 (75%) for Staff.

Why the sources disagree

The disagreement is mostly about names, not levels. The pages broadly agree on where a first-line manager sits: careerclimb says Staff (L6) and EM (L6) are the same level at Google. What differs is the name each company gives the IC title at that level. Third-party charts also get this wrong. Dropbox's own framework lists "IC4 Software Engineer IC5 Staff Software Engineer", while a third-party page labels Dropbox's IC4 as Staff. A chart that's one row off sends you to the wrong level.

To find a company's own ladder, start with its engineering blog or a ladder index such as progression.fyi, then confirm on the company's primary page. If a company publishes nothing, ask the recruiter which IC title sits at the level of a first-line manager there.

One thing to look for on your own past employer's ladder: Dropbox's updated framework added technical craft expectations for engineering managers. If your company did something similar, your performance packets may already hold dated hands-on evidence you can use in step 6.

The example's decision

She was a first-line manager and never a senior manager, so the tally points her at Staff. Her level claim, though, is limited by her deep-dive stories, not by her old title. She has two design-ownership stories inside the last two years: the payments migration and one other kept H bullet. Her rule became:

• Staff where the company's own ladder puts first-line manager beside Staff and a kept H bullet matches the posting's core system
• Senior everywhere else, as a deliberate target rather than a fallback

If you were a senior manager or director, the same tally points higher: Senior Staff according to sph.sh, Principal according to smithspektrum. The same limit applies. Claim the level your design stories can carry.

Is aiming only at Staff a mistake?

Usually yes, if Staff is the only level you apply for. Staff seats are rarer than engineering manager seats at most companies. In Refolk's index of professional profiles, US Engineering Manager profiles outnumber US Staff Software Engineer profiles 1.31 to 1.

The reason is structural. Each team has one manager, but Staff is a subset of ICs that you only reach by promotion. The index counts people who hold a title, not open roles, so read the ratio as the shape of the market, not a count of vacancies. Title matching also has some noise, such as "Managing Director Engineering" landing in the manager count, and the Staff count excludes "Staff Engineer" variants.

Where these people sit, from 25-profile samples in the same index:

Samples of 25 are small, so treat these as a rough steer. The employers in the samples point the same way. The US Staff sample included Databricks (two profiles), GitHub, Vanta, and Airbyte. The UK manager sample's top employer was Meta at 3 of 25, followed by Deliveroo, Zopa Bank, and Marks and Spencer. Staff titles exist well outside the largest companies, so a list built only from big-tech names misses a lot of them.

Pay is less of an obstacle than most managers assume. One published comparison says that at the first-line manager level, IC and manager pay is "functionally identical or within a few percent". Dual-track pay bands are built for parity, and the gap opens at Director and above. That's one source, so check it against the posted ranges for your actual targets.

Targeting two levels means two versions of the resume, one leading with Staff-scope design stories and one with Senior-scope delivery. Refolk writes the resume from your own history and tailors it to each posting you apply to, so both versions come from one tagged master instead of two hand-edited copies that drift apart.

Which title goes on the resume?

Use the official title, word for word, as it appears in your contract or HR records. Put any hands-on context on a clarifier line underneath it, not inside the title.

The title is one of the few fields anyone actually checks. Employment verifiers say they "often can only verify job titles, dates of employment, and rehire eligibility". Your bullets are where you position yourself, and nobody checks bullets against an HR system.

Two sources seem to pull in opposite directions. Resumly lists "Keep the old 'Engineering Manager' title without context" as a mistake. Precise Background says to "list the title as it appears in your employment contract or HR records." You can satisfy both: keep the title verbatim and add context next to it. No standard has been published on parenthetical clarifiers. My preference is a separate line under the title, so the title field stays clean for application portals and for anyone comparing it to the HR record. To check locally, paste your resume into a target company's application portal and see what its autofill puts in the title field.

This is where the example's first wrong turn happened. Her first draft retitled the manager role "Senior Software Engineer (Tech Lead)." It reads well to an IC screener and fails verification. One recruiter guide warns that a significant gap between the resume title and the official HR record is seen as "a major breach of trust." SHRM, citing HireRight, reported that 85% of respondents had found lies or misrepresentations on candidate resumes. That's a second-hand citation, but either way, verifiers expect to find mismatches.

Engineering Manager | [Company] | [MM/YYYY] to [MM/YYYY]
Hands-on scope: [systems you designed or built yourself], while leading a team of [N] engineers.

Summary line (top of resume, or first paragraph of the cover letter):
[N] years building [craft area], the last [N] also leading a team of [N]. I am looking for a senior individual contributor role where I can use my skillset in a more hands-on environment.

The last sentence of the template comes from a manager who described their move in a cover letter as wanting to use their "skillset in a more hands-on environment." It answers the flight-risk worry without apologising for anything.

The title is the field they check. The bullets are where you position yourself.

The recency line for each core skill

A recency line is one dated line per craft skill: what you built, the month and year, and the artifact that proves it. Everything you claim should be dated within the last two years, because that's the window senior deep-dive questions use: "Tell me about a system or service you designed end-to-end in the last two years."

Majors gives the time limits. "After two or three years of management, it's still pretty easy to go back to engineering," she writes, and she advises staying in management at least two years but less than five. She puts the refresh at "the six months or whatever it may take." If you've managed for three years or more, plan for that refresh before you apply, not during the loop.

In the example, she listed three core skills: service design, data modelling, and production coding. Two had artifacts inside the two-year window: the payments design doc, and a schema migration she wrote herself. Production coding didn't, because her last substantial code was more than two years old. She started a scoped refresh project and kept production coding off the resume until it had a dated artifact.

Nobody has published which kinds of evidence recruiters accept. My working rule is anything with a date and your name on it that you could show on screen: a merged pull request, a design doc you wrote, a runbook, a public repository.

The loops will test whatever the recency lines promise. Senior loops commonly run four to six sessions: one or two coding rounds, one or two system design rounds, a behavioural round, and often a project deep dive. The Google L5 loop has been described as two technical phone screens followed by five onsite interviews. The Meta E5 onsite has been described as including an AI-enabled coding round. Loop formats change, so check each company's current interview guide when you get the invite rather than relying on these descriptions.

Recency line:
[Skill]: [what you built or designed], [MM/YYYY], [artifact: design doc / merged PR / runbook / public repo]

Deep-dive card (one per kept H bullet):
System:
Dates of my involvement:
Parts I owned personally:
Parts I inherited:
Parts I delegated, and to which role:
Artifact I can point to:
What I would change now:

How the manager-to-IC cut goes wrong

Seven failure modes, three of which showed up in the worked example. The dangerous ones get through the resume screen and fail later, either in the deep-dive round or in employment verification. That's why each one below comes with a check you can run before you send anything.

1. Demoting the title

What it looks like: "Senior Engineer" where the HR record says "Engineering Manager." Why it fails: titles are among the few fields verifiers confirm, and a significant mismatch reads as a breach of trust. Check: put each resume title next to your offer letter or HR title history.

2. Deleting all team scope

What it looks like: a manager role with no mention of people. Why it fails: scope of responsibility counts as material, so removing it can create a false impression, and it contradicts what your references will say. Check: does at least one bullet per management role still state team size or hiring?

3. Overclaiming team output as personal work

What it looks like: every T bullet rewritten with "I designed and built." Why it fails: it gets through screening and then fails the question about what you owned versus delegated, which can end in a downlevelled offer. Check: for each H bullet, can you name your own commits or design docs?

4. Trusting third-party ladder charts

What it looks like: targeting Dropbox's IC4 as Staff because a chart said so, when Dropbox's own framework lists IC5 as Staff. Why it fails: you pitch one level off before the first call. Check: confirm every mapping on the company's primary ladder page.

5. Matching level numbers instead of title names

What it looks like: assuming L6 means the same title everywhere. sph.sh puts Manager at Amazon L6 and Google L6, but the IC title names at those levels may differ; I haven't been able to confirm this for Amazon. Check: match on the title name the target company uses, not only the number.

6. Stale recency

What it looks like: craft skills whose last evidence is from before you became a manager. Why it fails: after five or more years in management you're past Majors' "less than five years" threshold, and the deep-dive question asks about the last two years. Check: does every listed skill have an artifact dated within two years?

7. Rounded dates hiding gaps

What it looks like: years-only dates, or dates written from memory, as in the example's start date that was two months off. Why it fails: "Employment gaps. Verifiers don't just check the jobs you listed." Check: every date in month and year form, matched to payroll or HR records.

Final audit before you send, and keeping it current

Before the first application goes out, check every title and date against your records, every kept bullet against a deep-dive story, and every skill against a dated artifact. The checklist below is that audit, and if it passes, the draft is ready to tailor per posting.

Keeping it current:

• After each recruiter screen, log which of the four worries came up. If one keeps coming up, fix the line that answers it, not the whole resume.
• When a refresh project produces an artifact, add the recency line and move that skill back onto the resume.
• Every few months, recheck the two-year window. Recency lines age, and a line that was inside the window when you started searching may not be by the time you're in final rounds.
• For each new target company, repeat step 4 on its own ladder rather than reusing the last company's mapping.

Each posting also needs its own cover letter, and the intent sentence has to go in every one. Refolk drafts the cover letter from the same history it builds the resume from, so the intent line and the tagged bullets stay consistent across applications.