Tech lead from A to Z: influence, management, and the delegation I got wrong at first

The first month I was a tech lead, I closed more Jira tickets than anyone on the team. I thought that was the job. I reviewed every pull request the same afternoon it landed. I jumped into every Slack thread in #payments before anyone else could type. I rewrote a flaky GitHub Actions workflow at 11pm because “it would take me twenty minutes and them two hours.”

I was useful. I was also the bottleneck. And I was slowly training eight competent people to wait for me.

This is the A-to-Z I wish someone had handed me: not the org-chart definition of a tech lead, and not the LinkedIn version where you “empower others” in the abstract. Influence, management, and the specific delegation mistakes that look like dedication until you measure throughput.

What the title actually is

A tech lead is not a junior engineering manager and not a senior IC with a louder calendar. The useful definition I landed on: you are accountable for the technical outcome of a slice of the product, and you get that outcome through other people’s code.

That sentence has two halves, and I only believed the first half for a year. I treated “accountable for the technical outcome” as “I should be able to write or rewrite any of it.” The second half — through other people’s code — is the actual job. If the service ships because you personally merged the last three PRs, you did not lead the slice. You rented it.

At the company where this finally clicked, we ran a Kotlin/Spring payments service, a TypeScript BFF, and a small Go sidecar that talked to a card processor. I could have written any of those. That was the trap. Being able to write them made it emotionally cheap to take them back.

Influence is not a personality trait

People talk about influence like it is extraversion or political skill. In practice it is a pile of small, boring deposits:

• You write the design doc in Notion before the meeting, so the meeting is about the two decisions that are actually open.
• You put the constraint in the Linear ticket — “this has to survive a Stripe webhook retry” — instead of hoping the implementer discovers it in review.
• You say the same architectural sentence in standup, in the doc, and in the PR comment, until it is no longer your sentence. It is the team’s default.

Influence is repetition with receipts. I used to think I was being ignored when someone reopened a debate I had already “won” in Slack. Usually I had won a chat thread and lost the written record. Six weeks later the same argument came back in a different channel because the decision lived in my head.

The fix was unglamorous. We kept Architecture Decision Records in the repo, short ones, in the same pull request as the first code that depended on them. Not a Confluence garden. A markdown file next to the module. When someone asked “why is the ledger write synchronous?” I could point at docs/adr/0017-sync-ledger.md instead of reconstructing a Tuesday.

That is influence. It is also the first thing I stopped doing when I got busy, which is how I started being “the guy who remembers why.” Being the guy who remembers why is a status symbol. It is also a single point of failure wearing a hoodie.

Management without the title

Most tech lead roles I have held did not include hiring, firing, or compensation. Those stayed with the engineering manager. What I still had to do, every week:

• Protect focus. If product dropped three “quick” requests into Slack, I was the person who said which two waited, and I said it in the same channel, not in a sidebar.
• Make work visible. A ticket that only exists in a huddle will be done by whoever feels guilty. That is usually you.
• Run 1:1s even when I was “not the manager.” Fifteen minutes. Not a status report. “What is stuck that I cannot see in Linear?”
• Give the EM the performance picture they cannot get from GitHub graphs. Who unblocked whom. Who is carrying a tacit on-call load. Who is bored.

I resisted the 1:1s. They felt like I was pretending to be a manager. Then I watched a mid-level engineer spend three weeks politely failing at a Kafka consumer because they did not want to look lost in standup. A 1:1 would have caught it on day four. The standup format rewards “I am on it.” The 1:1 format rewards “I am not.”

You do not need Workday access to do this. You need a recurring calendar invite and the willingness to hear that your last design was confusing. If that sentence makes you flinch, you are still optimizing for being the smartest person in the room. That is an IC habit. It does not scale past about five people.

The delegation I got wrong

I thought delegation meant assigning tickets. I assigned tickets constantly. I also pre-solved them.

A typical pattern: I would write a three-page design, break it into Linear issues with acceptance criteria so tight they were a spec, then “delegate” the implementation. When the PR came back with a different folder structure or a different error type, I requested changes until it matched the picture in my head. The engineer shipped my code in their name. I called that mentorship. It was remote-controlled typing.

The damage was specific:

1. People stopped proposing designs. Why bother, if the real design would arrive in review comments.
2. I never learned who could own a whole problem. Everyone looked mid when the ceiling was my checklist.
3. When I took a week of PTO, the payments retry path stalled. Not because the team was weak. Because the decisions still required my taste.

The correction was not “be less detailed.” Vague tickets are another way to stay in the middle. The correction was to delegate outcomes and constraints, then let the shape of the code be theirs unless it violated a constraint I could name.

A constraint I can name: “We cannot add a new Redis key pattern; the existing cache invalidation in LedgerCache is already a known hazard.” A preference I should swallow: “I would have put this mapper in a different package.”

I still fail this weekly. The tell is how I feel in review. If I am irritated that they did it differently, I ask whether I wrote a constraint or a preference. Preferences go in a note to myself. Constraints go in the ticket before work starts.

The usefulness trap

Being useful is how you got the role. Senior IC usefulness looks like: you pick up the ugly ticket, you know the history of the schema, you can land the incident. Tech lead usefulness looks like: the ugly ticket has an owner who is not you, the history lives in an ADR, and the incident runbook was written by the person who will be on call at 3am.

I kept score the old way for too long. I watched our Datadog dashboard during incidents and jumped on the Zoom bridge first. I was fast. I also prevented the next person from being fast. After the third Stripe signature-verification outage, I forced myself to stay on mute unless asked, and I wrote that rule in the incident channel topic. It felt like negligence. The fourth outage was slower by about eight minutes and then we never needed me on that class of page again.

If you need a metric: count how many production issues you personally closed this month, and treat a high number as a smell. Count how many issues were closed by someone who had never closed that class of issue before, and treat a rising number as the job working.

Code, still — just not as a habit

I did not stop writing code. A tech lead who only writes documents becomes a tourist in their own system. I still take a thin vertical slice when we are entering a new surface — the first TypeSpec for a new API, the first test that pins a gnarly Temporal workflow, the spike that proves we can move a batch off our homegrown cron into a queue.

What I stopped doing was taking the middle of the stack because it was familiar. Familiar work is the most expensive work for a lead to hoard. It is comfortable, it looks productive in GitHub Insights, and it starves the people who need those reps.

A rule that has held: if I have done this kind of change three times on this team, the fourth time is someone else’s, with me as reviewer of the design, not author of the diff. Exceptions exist — a security patch on a Friday, a regulator deadline, a one-line production fix. Exceptions are not a lifestyle.

Pairing is the compromise I trust more than “I will just do it.” One hour in a Tuple session on the ugly part of the Hibernate mapping is worth more than a perfect PR comment left at 6pm. I used to leave those comments as a way to stay involved without blocking my calendar. They blocked theirs instead.

Meetings I would keep, and the ones I killed

I inherited a weekly “tech sync” that was a status meeting wearing an architecture badge. Twelve people. No doc. Every conversation restarted from Slack lore. I killed it and replaced it with two things:

• A thirty-minute design review only when there was a written doc older than 24 hours. No doc, no meeting. People learned to write.
• A weekly 20-minute “risks only” with the EM and the PM. Not a demo. Just: what will make us miss the date, and what are we pretending is fine.

Standup stayed, but I stopped letting it be a tour of tickets. If Linear is up to date, standup is for surprises. If Linear is not up to date, the problem is not standup.

I also stopped attending every product grooming. I sent a deputy — usually the engineer who would implement the next slice — and I read the notes. Showing up to every grooming was another usefulness costume. It signaled care. It also told the team their judgment was decorative.

The first ninety days I would run now

If I were dropped onto a team tomorrow, I would not start by “fixing the architecture.” I would spend two weeks on three questions:

1. Where does work wait? Not where it is hard. Where it sits. PR queue, design review, product answers, staging data, a single AWS account owner on vacation.
2. What decisions only I (or the last lead) can make? Those are the first ADRs and the first delegations.
3. Who is already leading without the title? Give them a named slice — “you own the Go sidecar, including on-call for it” — before I invent a new process.

Then I would pick one painful interface and make it boring. Not a rewrite. A contract. An OpenAPI file that matches production. A runbook that a new hire can follow without Slack. A test that fails when someone “helps” by changing a column type.

I would not start a “tech lead operating system” in Notion with twenty templates. I have written those. They die when the first incident hits. One written decision, one delegated slice, one removed meeting. Then another.

What I still get wrong

I still grab incidents that are interesting. I still rewrite a paragraph in someone else’s RFC because I like my verbs better. I still feel a flush of pride when GitHub shows me at the top of the contributor chart for a week, and I have to treat that pride as a warning light.

The job is influence you can leave on a plane, management you can do without a title, and delegation that includes the right to make a choice you would not have made. I got the last one wrong because I confused quality with resemblance. The code does not need to look like mine. It needs to survive the next person who is not me.

If you are useful every day, check whether the team is becoming less useful without you. That number, not your ticket count, is the score.