If you manage engineers and you're rewriting your resume, the first thing a hiring manager now wants to know is how much you still build. Most manager resumes never say.
Squarespace is cutting about 300 people (19% of staff), mostly in product and engineering. Anthony Casalena's memo says the change "means smaller teams, more player coaches, and a simplified organizational structure." If you manage engineers, designers, or PMs, that phrase is close to the whole job description. The managers who get hired into flatter orgs will be the ones whose first page says, as a number, how much they still build.
What Squarespace, Coinbase, and Block are actually asking for
They want managers who lead a team and still do real technical work, with fewer layers between the CEO and the code. Three companies have said so publicly, and Meta appears to be moving the same way.
- Squarespace: about 300 people, 19%. Casalena's memo calls for "more player coaches." Neither Squarespace nor The Verge tied the cuts to AI. The stated reason is restructuring, not a financial target.
- Coinbase (May 5, 2026): about 700 people, 14%. No more than five layers below the CEO/COO, some leaders with 15+ reports, and no "pure managers." Brian Armstrong: "Every leader at Coinbase must also be a strong and active individual contributor."
- Block (February): a 40% layoff, with Jack Dorsey planning to cut middle-management layers from five to two or three.
- Meta: reportedly retitling some managers "organisation lead."
The reasoning is simple. Remove layers and every remaining manager covers more ground, which leaves no room for a role that only coordinates. Gergely Orosz predicted the player-coach EM back in 2024. By April 2026, James Stanier was writing "The End of the Non-Technical Engineering Manager" for LeadDev. The idea used to be a forecast. Now companies hire for it.
What a player-coach job description actually says
A player-coach engineering manager is a people manager who also spends a set share of the week on hands-on technical work, usually capped at about 30 to 40%. The better postings state the number outright.
Lupa's EM posting asks for "roughly 30 - 40% of your time hands-on" and lists experience with Claude Code, Cursor, or Windsurf. Awesome Motive (the company behind WPForms) uses "player-coach" in its postings too. Guidance on marian.coach puts the usual ceiling for hands-on EM variants at "up to about 40%" coding.
The survey data shows how fast this moved:
LeadDev's 2026 Engineering Leadership Report surveyed 600 leaders; 37% of all leaders report doing more technical work.
So the posting has a number, and the hiring manager's first question about you is "how much do you still build?" Your resume should answer it before they ask.
The 300x gap between what managers do and what they show
About 35% of engineering managers now do hands-on work, but in Refolk's index of professional profiles, only 53 of 43,205 US Engineering Managers put "hands-on" in their headline. That's roughly 0.12%, or about 1 in 815.
Out of 43,205 people holding the title in Refolk's index, about 1 in 815.
Here's the full picture:
| Segment | Count | Source |
|---|---|---|
| Engineering Managers, US | 43,205 | Refolk's index |
| Engineering Managers, UK | 10,940 | Refolk's index |
| US EMs with "hands-on" in headline | 53 | Refolk's index |
| Share of US EMs signaling it | ~0.12% (1 in 815) | Derived |
| EMs doing hands-on work (survey) | 20% → 35% | LeadDev 2026 |
Keyword matching is loose, and some managers signal hands-on work in other words. Even allowing for that, the distance between 35% doing it and 0.12% saying it is roughly 300x.
The reason is history. Saying you still coded as a manager used to sound like a confession: it suggested you couldn't delegate or hadn't really made the switch to management. So managers left it off. The incentive has flipped and most resumes haven't caught up. With a management title and no stated split, a reader assumes you've stopped building.
That assumption costs you when someone else is searching. Recruiters filling a player-coach role search headlines and titles, so a manager who writes neither "hands-on" nor a percentage never shows up for the exact role they're best suited to. You can be the right person for the role and still never be found.
Why "30% hands-on" means nothing without team size
Always put your report count next to your percentage, because 30% hands-on with 3 reports and 30% with 15 reports are different jobs. The percentage alone tells a hiring manager very little.
KORE1 says it directly: 30% of a 5-person team and 30% of a 45-person org "are different jobs carrying different risk." It puts the realistic ceiling at 30 to 40% for managers with 2 to 4 reports. Now apply that to Coinbase, where some leaders have 15+ reports. A 40% hands-on claim at that span reads as a red flag. Either the claim is inflated or the team isn't getting managed.
A credible resume line has three parts:
- Reports: direct reports, plus total org size if it's bigger.
- Split: an approximate share of time, written as "~30%."
- What the time went to: the kind of technical work you did, which matters more than the number.
For example: "6 reports, ~30% hands-on: incident response, migration tooling, code review standards." In one line, a screener sees that you lead people, and a hiring manager can judge whether the split makes sense for the span.
Which shipped work belongs under a management title
List incident fixes, prototypes, migrations, investigations, and review standards under your manager title, not "built feature X." Feature ownership on the critical path tells a hiring manager that your team was starved of that work.
Ferit Topcu's framework in LeadDev is the best guide here. A hands-on manager should:
- Pick up small, unplanned work: bug fixes, on-call gaps, the flaky test nobody owns.
- Investigate complex work: spikes, proofs of concept, performance digs, vendor evaluations.
- Leave planned roadmap work to the team.
Take roadmap features yourself and you become "bus factor one," the single person whose absence stalls a project. Emma Bostian, an EM at Spotify, made a related point in LeadDev: a manager's biggest impact comes from empowering the team, not from their own coding output. Your bullets should show both. You built things, and the things you built made the team faster.
Here's how weak and strong bullets compare under a management title:
| Weak bullet | Stronger bullet |
|---|---|
| Built the new checkout feature | Prototyped the checkout redesign, then handed the build to two engineers I coached through it |
| Wrote a lot of code | Fixed the payment-retry incident on call and wrote the runbook the team now uses |
| Owned the database migration | Wrote the migration tooling so the team could move services without downtime |
| Did code reviews | Set the team's code review standards and reviewed every PR touching auth |
Which bullets you lead with should depend on the posting. A role that mentions Cursor and prototyping wants your spike work at the top. A platform role wants migrations and incidents first. Re-ordering for every application gets tedious fast, and it's the exact work Refolk takes off you: paste the posting, and I rewrite your resume from your own history so the hands-on bullets that posting cares about come first.
How to show technical skills on a manager resume, on page 1
Put your split in three places: your headline, the first line of your summary, and the first line under each management role. Recruiters search headlines and titles, so a split buried in role three never gets seen.
- Headline. "Engineering Manager, hands-on (6 reports, ~30% IC)." Remember that only 53 US EMs in Refolk's index use that word.
- Summary, first line. One sentence with span, split, and domain. "Lead a 6-person payments team and spend about 30% of my time on incident work and migration tooling."
- Under each management role. Open with the scope line ("6 reports, ~30% hands-on"), then two people bullets and two hands-on bullets. Leading with the scope line lets each bullet stay short.
- Skills. List only tools you've used hands-on in the last two years. If the posting names Claude Code, Cursor, or Windsurf (as Lupa's does) and you've actually used them, say so plainly.
- Match, don't mirror. If the posting says 30 to 40% and yours was 15%, write 15% and lead with what the 15% was spent on. A truthful split that's a bit low beats an inflated one you have to walk back.
The hands-on split used to be a confession. In a flatter org, it's a credential, so write it as one.
How to write a manager to IC resume after a layoff
If you already state your hands-on split, the same resume works for both an EM application and a staff IC application. You only change the order. This matters now, because LeadDev found that 1 in 3 managers are considering a move back to IC.
After a cut like Squarespace's, where departing staff get at least 16 weeks of base pay, benefits through May 2027, and career coaching, you have time to apply to both tracks at once. Work from one record of your history and reorder it per track, rather than keeping two resumes that drift apart.
The swap looks like this:
| Element | EM version | Staff IC version |
|---|---|---|
| Headline | Engineering Manager, hands-on (6 reports, ~30% IC) | Staff Engineer, payments infrastructure; previously EM |
| First bullets per role | People outcomes, then hands-on | Hands-on systems work, then technical leadership |
| Management work | Hiring, coaching, delivery | "Led" technical direction across 6 engineers |
| Skills | Leadership plus current tools | Current tools, with depth noted |
The hands-on bullets from the earlier section are what make the IC version believable. A former manager with no recent technical work can't credibly pitch themselves as a staff engineer. A manager with incident fixes, migration tooling, and prototypes from the last two years can.
FAQ
Should I put an exact percentage on my resume if I've never tracked it?
Use an approximate figure, such as "~30%," based on a real check of the last quarter. Look at calendar blocks, commits, PR reviews, and on-call shifts, then round down. Hiring managers ask about it in interviews, and an inflated number falls apart in the first technical conversation. A conservative number you can defend reads better than a round 40% you can't. Always pair it with your report count, because the percentage means little without it.
What if my hands-on time was close to zero?
Don't invent a split. List the technical work you did do, such as architecture reviews, incident command, code review standards, or technical hiring, and target roles whose posting states a lower hands-on share. If you want player-coach roles, start a small, real hands-on habit now (an internal tool, a prototype) so the next version of your resume has something true to report.
Does the player-coach model apply to design and product managers?
Yes. Squarespace's cuts were mostly in product and engineering, and the logic of fewer layers applies to any manager in those orgs. A design manager's hands-on work might be prototypes, design-system components, or running critique. A product manager's might be SQL, evals for an AI feature, or a clickable prototype. Use the same format: reports, approximate split, and what the time went to, framed as work that unblocked the team.
How do I stop a player-coach role from turning into two full jobs?
Get the employer's number in writing before you sign. Guidance on marian.coach warns that the coding share in the ad stays while the people work grows on top of it, and LeadDev's 2026 report found 45% of leaders working more hours than a year earlier. In interviews, ask what share of the role is hands-on and who set that number, how many reports you start with and what the plan is for the next year, whether you'll own roadmap features or unplanned and investigative work, and whether the coding share drops as the team grows. A resume that already states your split makes this conversation easier, because you've named your number first.