Mastery Before Management
Get technical skill into your bones before you leave IC — then stay technical by listening, not coding
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 4
- Confidence
- 93%
Fournier's answer to the perennial 'when should I become a manager, and how do I stay technical?' Don't leave hands-on work until your craft is at the level where you'd be rusty but not clueless picking it back up — roughly a decade of serious practice. Once you're a manager, technical credibility is not maintained by writing code; it's maintained by asking good questions and surrounding yourself with hands-on people you listen to.
Origin
Camille Fournier, author of The Manager's Path — the widely-used guide to the engineering management career path. Her own benchmark: an undergraduate degree, a graduate degree, and four to five years of full-time coding before the transition. She invokes (and flags as disputed) the 10,000-hours idea of mastery.
Core principles
- 01Mastery is the second-language / instrument / sport test: leave it for years, come back rusty, get there quickly, never clueless.
- 02Mastery bought before the transition stays with you — it buys confidence, empathy for good engineering, and much less anxiety about being hands-off.
- 03Once hands-off, prescriptive technical advice ('use this library, not that one') is not credible and is actively irritating. Guiding questions are.
- 04Technical currency comes from proximity to smart hands-on people, not from writing code yourself.
- 05Underrepresented engineers get their technical ability discounted by default, which makes pre-transition mastery even more important as internal armour.
- 06Keep up with what's changing in your corner of tech, but don't obsessively chase every fad — what makes one person fast rarely makes a hundred people fast.
How to run it
- 1
Run the rusty-not-clueless test
Ask whether you've reached the point where, after a long gap, you'd come back slower and out of practice on tooling but fundamentally competent. That's the bones-level mastery threshold. If you can't say yes, stay hands-on.
Pro tip Roughly a decade of serious practice, education included — for Fournier, undergrad plus grad plus four to five years of full-time work. Heavy high-school/college coding can compress the working-years portion to four or five.
Watch out Plenty of people never reach mastery, become managers, lose it entirely, and can never get it back.
- 2
Don't take the first management offer, and don't take a project-manager detour
If you're still enjoying writing code, don't rush. And when a big company praises your communication skills and nudges you toward management, check what role they actually mean — being pushed into project management is, in Fournier's view, the worst path to real leadership.
Pro tip Ask directly whether the role is people leadership with technical scope, or coordination work dressed up as leadership.
Watch out Founders are a separate case — the calculus doesn't apply if you're building your own company.
- 3
Switch from directing to asking
Once hands-off, drop library-level prescriptions. Replace them with guiding questions: have you considered this, tell me how you plan to handle that, what are the major technical challenges here — and then actually listen to the answers.
Pro tip Engineers rate technical leaders on whether they seem to understand the work and can ask good questions that lead to better decisions — not on whether they still commit.
Watch out Engineers simply don't believe long-hands-off leaders who tell them what to do in the domain the engineer currently owns.
- 4
Build and maintain a hands-on network
Deliberately surround yourself with smart technical people and stay interested in their war stories — down to the level of 'I'm trying to debug this database issue'. Conferences, group chats, former colleagues, tech commentary and discussion boards.
Pro tip Fournier stays technically credible not by writing code but by listening to very smart people talk about technology, constantly.
Watch out If you find you're no longer curious about any of it, that's a signal worth reading — though genuine nerdiness isn't a strict prerequisite for the job.
In the wild
She counts an intense undergraduate degree, a graduate degree, and four or five years of full-time hands-on work before she had what she'd call mastery — landing her in the ten-year range overall. She notes she didn't start coding heavily in middle school the way people might now.
→ Her heuristic: somewhere around ten years, education included, of really spending your time writing code and learning to be a technical expert.
Asked to name an overrated technology, Fournier says she wouldn't tell a team to use or not use GraphQL — it's out of her expertise zone and not her job at her level of management. She'll only offer the pattern she hears from senior people she trusts: it's popular but poorly regarded, it implicitly promises front-end engineers they won't have to collaborate with back-end engineers, and if you're not Facebook you'd better know exactly what problem you're solving.
→ A live demonstration of the hands-off leader's stance — no prescription, but a sharp guiding question aimed at the decision.
Common mistakes
Becoming a manager the first time it's offered
If you care about being technical, taking the first management offer before mastery is set means you lose the skill and never rebuild it. Waiting is cheap; the skill compounds.
Trying to stay technical by dictating tools
Telling engineers which library to use after years hands-off signals insecurity rather than expertise, and engineers discount it immediately.
Chasing every new framework as a proxy for staying sharp
What makes one person productive doesn't necessarily make ten or a hundred productive. Awareness of what's changing is valuable; obsessive chasing is not.
Is it for you?
Best for
Senior engineers deciding when to make the leap into management, and new engineering managers anxious about losing technical credibility.
Not ideal for
Founders and very early-stage builders, non-technical managers who never intended to be technical, and anyone who no longer wants technical credibility at all.
From the transcript
“one piece of advice I give everybody is don't stop being a Hands-On technical until you feel like it's in your bones”
“I do think it's probably a like somewhere in the 10year range of like really having spent a lot of your time over those years…”
“what people care about with technical leaders in my experience is they want people who actually seem like they sort of understand what you're doing…”
“the last thing I would say is like surround yourself with smart technical people also as much as you can”
“if you're still having fun writing code don't rush becoming a manager”
From the episode
The things engineers are desperate for PMs to understand
Camille Fournier (author of “The Manager’s Path,” ex-CTO at