Leading without losing the keyboard

The tension is not vanity

You did not become a tech lead because you dislike building things. You took the role because someone trusted you to steer delivery, grow people, and keep the system honest. Then your week turned into a staircase of thirty and sixty minute blocks.

At that point a specific anxiety shows up: if I am not in Git every day, am I still “real”? The industry loves keyboard mythology. Your team, though, mostly cares whether you help them ship safely and whether your technical calls survive contact with reality.

So the question is wrong if it sounds like “how many commits proves I belong?” The better question is what keeps your judgment grounded when coding is no longer your primary output.

What people are actually testing

Credibility with senior engineers is only loosely related to how much you ship.

They watch whether you listen before you steer, whether you treat depth in the codebase as distributed across the team, and whether your proposals match how work actually flows (reviews, incidents, migrations, rollout discipline). They notice when you confuse authority with expertise.

Camille Fournier, in The Manager's Path, describes an engineering lead as someone who spends less time writing production code but still takes on small technical deliverables when that supports the team, without becoming a bottleneck. The point is not performative hacking. It is continuing to touch the machine often enough that your instincts stay honest.

That gives you a usable standard: your technical work should reduce drag for others or reduce risk, not compete with them for the interesting roadmap items.

Why “gaps” between meetings fail you

Paul Graham’s essay “Maker's Schedule, Manager's Schedule” made the culture aware of an uncomfortable fact: deep technical work wants long uninterrupted stretches, while management work wants the calendar sliced into slots. When you live entirely on the manager shape, leftover holes of twenty or forty minutes feel like opportunity. Usually they are not. You pay a switching cost to load context, then the next alarm pulls you out before you produce something you respect.

That does not mean you must erase meetings. It means protecting a few real blocks each week is structural, not pampering. Treat those blocks like immovable infrastructure: same length, repeated, labeled clearly, and defended the way you would defend a launch checkpoint.

Batching helps: stack one on ones, syncs with product, and cross team forums so you create longer contiguous maker time, not a peppering of interruptions across every afternoon. The exact pattern depends on your org; the principle is to stop letting the default calendar tool choose your cognitive rhythm.

Triage before you optimize tactics

Overload is not a moral failure. It is a queue problem. A pattern that shows up often in writing on tech lead work is simple and worth stealing: capture every request in one system (tracker, tickets, a single list you trust). Chat and unread email are terrible databases.

Each day or two, run a blunt triage:

1. Is this important relative to what we already committed to?
2. Must it be me? If not, delegate with context, not a careless handoff.
3. If we say yes here, what do we stop or delay? Make that trade visible to stakeholders when it matters.

This is how you claw back calendar without drama. Saying “we can take that if we slip X” is leadership. Saying yes to everything until your team burns out is not.

Where to spend scarce technical attention

When you cannot own a whole subsystem, follow risk. Put your reps where mistakes are expensive or hard to reverse:

• High blast radius reviews: migrations, auth, billing, anything that corrupts data or leaks trust.
• Thin evidence, not big features: a spike that resolves a design fight, a script that proves a rollback path, a failing test that encodes an invariant nobody wrote down.
• Pairing during real heat: outages, tricky production bugs, gnarly customer incidents. People learn your standard of thinking when the system is noisy, not when you lecture in a retro.
• Platform and sharp edges: remove friction you only see if you still build. Small refactors that delete whole classes of bug are worth more than another deck.

If the only artifact you produce is slides, you will drift. If your artifacts are mostly code in the critical path without coordination, you will block. The narrow path is occasional, deliberate work plus clear ownership of technical standards (who decides, how you escalate, what “good” means).

Replace depth with intellectual hygiene

When you are not the deepest expert in the room, your job is to run a good process and to stay explicit about epistemic limits. “I have not touched that module this quarter” is strength, not weakness, if the next sentence is “here is who I am relying on and what would change my mind.”

Publish short decision records when you kill or bless a direction. Ask better review questions than generic “LGTM”. Ask about invariants, failure domains, observability, and operational ownership. People forgive a lead who writes less code. They rarely forgive one who guesses from authority.

When overload is structural

If triage and calendar boundaries still leave you drowning, raise it with your manager as a capacity issue, not a personal confession. Misaligned expectations between you and leadership are a bug. Naming it early is part of the job.

What to do next week

Pick one recurring forum and either shorten it, rotate ownership, or replace it with async notes. Take the reclaimed time and put a two to four hour maker block on the calendar at your best energy part of the week. First use of that block: review or pair on the change your team would miss most if nobody senior looked at it.

That single habit does more for credibility than pretending you can code like a full time IC while carrying a tech lead calendar.