Coding vs Leading: Where Your Time Goes

Scenario

Example team: Priya (from What a Tech Lead Owns) agreed her scope with her manager. Two months later she still carries a full sprint of tickets, plus reviews, design questions, interviews and incident follow-ups. Her tickets are always the last to finish.

What you see on the team

• The sprint board shows the lead's tickets "in progress" for a week or more.
• Critical-path work waits on her; she becomes the reason the sprint slips.
• Reviews and design answers happen late in the evening, in a rush.
• She feels guilty about meetings because "real work" is coding.

The common mistake

Keeping a full individual workload and doing leadership "on the side" — or the opposite, stopping coding entirely and losing touch with the code base.

Why it happens

Leadership work is fragmented and invisible: a review here, a question there, a meeting. It never appears on the board, so it never gets capacity, and the lead's coding time is quietly consumed. The simulation below models a week.

HOURS = 40
# Hours per week spent on leadership work (example numbers for a team of 7)
leadership = {
    "code reviews (7 people)": 6,
    "design questions / pairing": 5,
    "planning, refinement, standup": 4,
    "incidents and on-call follow-up": 3,
    "1:1s with manager and product": 2,
    "interviews": 3,
    "cross-team syncs": 3,
}
used = sum(leadership.values())
coding = HOURS - used
for task, h in leadership.items():
    print(f"{task:34} {h:>2} h")
print(f"{'leadership total':34} {used:>2} h")
print(f"{'left for coding':34} {coding:>2} h  ({coding / HOURS:.0%} of the week)")

# A full sprint of tickets assumes ~30 focused hours.
planned = 30
print(f"\nPlanned ticket work: {planned} h -> share finished this week: {min(1, coding / planned):.0%}")

code reviews (7 people)             6 h
design questions / pairing          5 h
planning, refinement, standup       4 h
incidents and on-call follow-up     3 h
1:1s with manager and product       2 h
interviews                          3 h
cross-team syncs                    3 h
leadership total                   26 h
left for coding                    14 h  (35% of the week)

Planned ticket work: 30 h -> share finished this week: 47%

Twenty-six hours of leadership work leave fourteen for coding — and those fourteen are fragmented. Planning a full sprint of tickets for the lead guarantees they slip.

The playbook

Plan the lead at ~30–50% coding capacity and make the leadership work visible: put "reviews", "design support" and "interviews" on the board or in planning as capacity.

Keep work that keeps you close to the code but off the critical path:

• spikes and prototypes for upcoming designs;
• tooling and developer-experience fixes;
• pairing on hard problems, with someone else as the driver;
• small, well-bounded tickets that can wait a day.

Give away work that creates bottlenecks:

• the riskiest critical-path ticket (delegate it with support — see Mentoring and Delegation);
• sole ownership of a subsystem;
• being the only reviewer for an area.

Batch interruptions. Review twice a day; hold "office hours" for design questions; protect two half-days a week for deep work.

What to say

In sprint planning:

"I'm going to plan myself at 40% this sprint — the rest is reviews, the payments design and two interview loops. I'll take the reporting script and the flaky-test fix; Ana, can you own the refund API change? I'll pair with you on the ledger part."

Trade-offs

• Too little coding erodes judgement and credibility; keep at least some regular hands-on work, even if it's tooling or prototypes.
• Office hours can slow urgent questions; keep an escape hatch for real blockers.
• Delegating the hard ticket costs time now (support, review) and pays back as team capability.

Signals it's working

• The lead's tickets finish within the sprint; none are on the critical path.
• Review latency is stable even in weeks with interviews.
• Others own and deliver the risky tickets, with the lead pairing.
• The lead still knows the code well enough to review designs credibly.

Key points

• Leadership work is real work: plan it as capacity, not as overhead on top of a full sprint.
• Plan a tech lead at roughly 30–50% coding, on work that keeps them close to the code but off the critical path.
• Delegate critical-path tickets with support; batch reviews and questions.
• Never stop coding entirely — keep prototypes, tooling or pairing.