Coding is a perishable skill.<\/p>\n
I’ve placed hundreds of engineering leaders.<\/p>\n
And I see the same pattern:<\/p>\n
The moment a tech lead or principal stops writing production code, their career clock starts ticking.<\/p>\n
Not dramatically. Not overnight. But within 18 months, they realize they’re no longer the person peers would hire as an IC \u2014 and that stings.<\/p>\n
They can’t debug a production outage without help. They can’t contribute to a design doc with confidence. They can’t pass a senior IC interview \u2014 at their own company.<\/p>\n
And worst of all: Their engineers notice.<\/p>\n
You get promoted. Your calendar fills:<\/p>\n
You tell yourself:<\/p>\n
“I’m unblocking the team.” “I’m thinking strategically.”<\/p>\n
But you’re not coding. And no one’s forcing you to.<\/p>\n
The reality check: Forward-thinking companies are noticing this pattern too. Pedro Franceschi, co-founder of Brex, explains why Brex doesn’t hire “people managers” anymore<\/a> \u2014 because they’ve seen what happens when leaders stop being hands-on. The market is shifting toward leaders who stay technical.<\/p>\n Six months in, you realize:<\/p>\n “I haven’t touched the backend in 90 days.” “I don’t know how the new auth system works.” “I couldn’t build this feature from scratch.”<\/p>\n You’re not incompetent. You’re just out of practice.<\/p>\n And the longer you wait, the harder it is to get back.<\/p>\n You must<\/strong> stay hands-on. But how much?<\/p>\n Role: Hands-On Target |——|—————–| Startup CTO: 40\u201350% EM at <50 people: 30\u201340% Director at 100+: 20\u201325% VP at 500+: 10\u201315%<\/p>\n It’s not about volume. It’s about impact.<\/p>\n You’re not on the critical path. You’re not hoarding features. You’re proving you still understand the craft.<\/p>\n Fake Hands-On: Real Hands-On |—————|—————| Code reviews (passive): Shipping production features Pair programming (directing): Fixing a P0 bug at 2am Writing scripts: Building an internal tool used daily Attending standup: Rotating on-call<\/p>\n Rule: If it doesn’t ship to customers or save the team hours, it doesn’t count.<\/p>\n You can’t do everything. But you can’t do nothing.<\/p>\n Delegate (80%): Own (20%) |—————-|———–| Routine features: System architecture Bug triage: Critical path decisions Onboarding: Tech debt strategy Documentation: Tooling that scales the team<\/p>\n Example:<\/p>\n Bad: “Here’s how to implement rate limiting.” Good: “We need rate limiting to handle 10x traffic. Build it. I’ll review.” <\/strong>Warning: The 20% you own should compound over time \u2014 not keep you firefighting. If you’re always on the critical path, you’ve picked the wrong 20%.<\/p>\n Need: How to Deliver |——|—————-| Interesting problems: No legacy maintenance. No make-work. Visible impact: “Your PR unblocked 50K users” Growth: Stretch projects. New tech. Mentorship. Respect: Value their opinion. Protect deep work. Kill bad processes.<\/p>\n Why leaders miss this: They optimize for velocity metrics \u2014 but ignore satisfaction.<\/p>\n The paradox: Teams with high satisfaction also ship faster long-term. Burnout-driven velocity is a 6-month illusion. Make the business case to your leadership.<\/p>\n You can’t know everything. But you can stay dangerous in one domain.<\/p>\n Strategy: Action |——–|——–| Pick a lane: Infra? AI? Payments? Go deep \u2014 that’s your competitive advantage. Rotate through codebases: Spend 1 week\/quarter shipping code in a different service. Not observing \u2014 contributing. Learn with your team: “I don’t know Next.js 15 \u2014 let’s build this together.” Accept obsolescence: Delegate what you’re behind on. Own what you’re ahead on.<\/p>\n Habit: Why |——|—–| Block 4\u20136 hours\/week for coding: Non-negotiable. Like a 1:1. Rotate on-call: Nothing keeps you real like a 2am page. Do the boring work: Update deps. Write docs. Review PRs. Build one internal tool\/quarter: Saves team time. Proves value. Go to one meetup\/month: Stay connected outside your company. Admit gaps selectively: “I’m behind on this, let’s learn together” works. But don’t admit gaps on your core domain. That erodes trust.<\/p>\n Name: Jordan (VP Engineering, Series C startup) Year 1: Hands-on. Ships features. Respected. Year 2: “I’m strategic now.” Stops coding. Year 3: Can’t debug auth. Team bypasses him. Year 4: Laid off in downturn. No offers.<\/p>\n Why? During those 4 years, the stack evolved:<\/p>\n Jordan wasn’t there. When candidates asked about architecture decisions, he deferred to his EMs. A VP who can’t defend the stack isn’t hireable.<\/p>\n Recovery time: 9 months<\/strong> of deliberate practice to become IC-relevant again.<\/p>\n The industry is catching on: This isn’t just an individual problem \u2014 it’s a systemic one. Companies like Brex have made it policy to avoid hiring pure “people managers” because they’ve seen the pattern too many times. Pedro Franceschi, Brex’s co-founder, explains their approach<\/a>: leaders who stay technical are the ones who can actually scale with the company. The companies that get this right are the ones that win.<\/p>\n If you’ve already disengaged, here’s how to restart:<\/p>\n The best leaders I place can switch between IC and management \u2014 because they never stopped being engineers.<\/p>\n They just became engineers who:<\/p>\n That’s the goal.<\/p>\n Stay technical enough to earn respect. Lead well enough to earn loyalty. Build systems that outlast you.<\/p>\n Do that \u2014 and you’ll have a career that lasts decades, not years.<\/p>\n We place CTOs, VPs of Engineering, and Tech Leads who:<\/p>\nTrap #2: The Skill Fade<\/h3>\n
The 20\u201330% Rule (With Context)<\/h2>\n
Real Hands-On (Not Fake)<\/h2>\n
Master Delegation (The 80\/20 Rule)<\/h2>\n
The 80\/20 Framework<\/h3>\n
What Actually Motivates Engineers<\/h2>\n
How to Stay Current When Tech Moves Fast<\/h2>\n
Tactical Habits That Work<\/h2>\n
Failure Case Study: The “Strategic” VP<\/h2>\n
\n
Start Today (If You’re at Zero)<\/h2>\n
\n
The Long Game<\/h2>\n
\n
Ready to Hire a Leader Who Refuses to Become Obsolete?<\/h2>\n