Week 19 Day 3: 'How' Is Your Team's Job -- Stop Doing It for Them

The leader's distance from the work is both an advantage and a liability. The advantage is perspective -- you see patterns, connections, and priorities that the team cannot see from inside the work. The liability is outdated expertise -- your technical knowledge decays with every month you spend in meetings instead of in code. The 'how' requires current expertise. The 'what' and 'why' require perspective. Play to your actual strengths, not the strengths you had three years ago.

This is a particularly painful lesson for leaders who were promoted from technical roles. You were the best engineer, so they made you a manager. Now you are in meetings all day, reviewing architecture diagrams drawn by people who write more code than you do. Your instinct is to specify the 'how' because the 'how' used to be your strongest contribution. But your 'how' is increasingly stale. The team is using frameworks you have not touched. The deployment pipeline has evolved since you last shipped code. The patterns you learned are two generations behind current best practice. When you specify the 'how,' you are often specifying yesterday's approach to today's problem. Here is the test: if you would need more than an hour to implement your own recommendation, you probably should not be making it. Instead, state the outcome and the constraints, then ask: 'What approach would you take?' Listen to the answer. If it meets the constraints, endorse it -- even if it is not what you would have done. Especially if it is not what you would have done. The discomfort you feel when the team chooses a different approach than yours is the feeling of your relevance being renegotiated. That discomfort is healthy. It means your team is growing beyond your technical shadow.

The expertise decay phenomenon is documented in what psychologists call 'knowledge depreciation' (de Holan and Phillips, 2004) -- the rate at which domain knowledge loses relevance due to environmental change. In technology fields, Deming and Swaffield (2011) estimated that technical skills have a half-life of approximately 2.5 years, meaning that half of what an engineer knows becomes obsolete or superseded within 30 months. For leaders who transition from technical roles to management, this depreciation accelerates because they lose the practice-based learning that maintains current expertise. Ericsson's (2006) research on deliberate practice demonstrates that expertise maintenance requires ongoing, effortful engagement with domain-specific tasks -- which management responsibilities systematically prevent. The identity conflict described in level_2 -- the discomfort of relinquishing the 'how' -- maps to what Ibarra (2003) calls 'identity transition' in leadership development. Her research found that new managers who clung to their technical identity (continuing to specify how) were rated lower by their teams than managers who developed a new identity centered on enabling others. The 'one hour test' is a practical application of what March (1991) calls the 'exploration-exploitation tradeoff' -- the leader should exploit (use) their current strength (strategic perspective) rather than explore (attempt to maintain) a depreciating asset (technical specification).