#What a senior or lead engineer is expected to do
AddedA senior engineer is trusted to deliver hard things well on their own. A lead engineer is trusted to make a team deliver hard things well, and is still an engineer while doing it. The job has four parts, and interviews for a lead role probe all four: technical direction (what we build and how: architecture, standards, the big technical decisions), delivery (that it actually ships: planning, sequencing, risks, unblocking), quality (that what ships is good and stays good: reviews, testing, operability, technical debt) and people (that the team grows: mentoring, delegation, feedback, a healthy way of working). A lead who only does the first is an architect; one who only does the second is a project manager; the role is the overlap.
The mental model: you're measured by the team's output, not your own. As a senior engineer, a great week is one where you shipped a hard feature. As a lead, a great week can be one where you wrote little code, but three engineers shipped because you unblocked the firmware question on Monday, caught the migration problem in review on Tuesday, and spent Thursday pairing with the newest engineer so they can own the next feature without you. Your leverage is in decisions, reviews, unblocking and teaching; your own commits are one input among many.
Will Larson's Staff Engineer (2021, staffeng.com) describes the Tech Lead as one of four common shapes of senior technical role, alongside Architect, Solver and Right Hand: the tech lead guides the approach and execution of one team (or a small cluster), partners closely with a single manager (sometimes two or three), scopes complex work, coordinates the team, unblocks it, keeps the essential cross-team relationships working and defines the team's technical vision, and by default delegates the team's most complex projects rather than building them personally. Titles vary a lot between companies ("Lead Engineer", "Tech Lead", "Senior Engineer, Team Lead", "Staff Engineer"), so in an interview it's worth asking what the role owns rather than assuming from the title.
The roles a lead works next to are easy to blur, and interviewers sometimes ask you to separate them:
| Tech lead (hands-on) | Engineering manager | Architect | Product manager / owner | |
|---|---|---|---|---|
| Owns | how the team builds: design, standards, technical risks | the people: hiring, performance, careers, team health | cross-team technical direction in a domain | what gets built and why: priorities, outcomes |
| Writes code | yes, typically a substantial part of the week | rarely | some, often prototypes | no |
| Decides | technical approach, review standards, task breakdown | staffing, promotions, process | platform and interface choices across teams | scope and priority |
| Success looks like | the team ships reliably and keeps a healthy codebase | people grow and stay; the team is effective | systems fit together and evolve | users and the business get the outcome |
These boundaries move by company. In many US companies leading offshore or contract teams, the "lead engineer" also does part of the manager's job day to day (one-to-ones on technical growth, onboarding, feedback) while a manager elsewhere owns hiring and performance. Clarify it in your first week, in writing, so nobody assumes you own something you don't, or the reverse.
A short role charter, agreed with your manager in the first couple of weeks, is the practical way to clarify it:
# Lead engineer: role charter (draft for discussion with <manager>, <date>)
## Scope
- Team: 6 engineers (4 in Bengaluru, 2 in the US), web UI + REST API for <product area>.
- I own: technical approach and design reviews, code review standards, sprint technical planning,
risks and status for the workstream, onboarding and technical mentoring.
- I don't own: hiring decisions, performance ratings, the product roadmap (I contribute to all three).
## Decisions
- I decide: design within the team's area, review and testing standards, task breakdown.
- We decide together: cross-team API contracts (with <other team>), release dates (with <PM>).
- I escalate to <manager>: scope changes over ~1 week of effort, staffing gaps, client conflicts.
## How I spend a typical week (target)
- ~30% hands-on: design spikes, the riskiest or most cross-cutting pieces, pairing.
- ~30% reviews and unblocking.
- ~20% planning, status, client and stakeholder conversations.
- ~20% people: one-to-ones, mentoring, onboarding.
## How we'll know it's working (after 90 days)
- The team ships to plan more often than not, and says when it won't, early.
- Review turnaround under one working day; no PR waits on me alone.
- At least two people can change each critical area of the codebase.- Scope lists what you own and, just as important, what you don't. "I don't own performance ratings" prevents the awkward discovery, three months in, that the team thought you did, or that your manager expected you to.
- Decisions splits them three ways: yours, shared, and escalated. This is the part that saves the most conflict later: when the client asks for a change, everyone already knows whether you can say yes, and when you must bring in your manager.
- The week is a target, not a timesheet. Writing "~30% hands-on" protects coding time from meetings and, just as often, protects leading time from your own wish to just write the code. The percentages are a starting point to discuss; they depend on team size and how much is still unknown.
- How we'll know it's working turns the role into checkable outcomes: delivery honesty, review turnaround, and knowledge spread across people. None of them is "lines of code I wrote".
- Everything in angle brackets is a placeholder. The point is the structure: one page, written early, agreed with your manager, revisited after 90 days.
For a lead role, interviewers listen for signals in each of the four areas, and for the word "we":
- Technical direction: you can explain a decision you'd make, the alternatives, and the trade-off, and you write decisions down (see Architecture decision records).
- Delivery: you talk about scope, sequencing, risks and dates, not just code; you surface bad news early.
- Quality: you have opinions about reviews, tests and CI that are specific, and you know when "good enough" is right.
- People: you can describe how you'd onboard, delegate, give feedback and grow someone, without micromanaging.
- Ownership language: "I made sure we…", "I decided…, because…", "the team shipped…", and honesty about what went wrong.
The clearest way to see the difference is to take one event and compare the responses:
| Situation | A strong senior engineer | A lead engineer, additionally |
|---|---|---|
| A production bug in device status | Finds and fixes it, adds a test | Makes sure the client is told, someone is fixing it (not necessarily the lead), a blameless review happens, and the class of bug gets a check |
| A vague feature request | Asks clarifying questions about their part | Turns it into scope, an Out list, milestones and risks; agrees it with the PM and the client |
| A slow, flaky CI pipeline | Retries, maybe fixes one flaky test | Treats it as a team delivery problem: measures it, plans the fix, protects the time for it |
| A junior engineer's PR with a poor design | Leaves detailed comments | Comments, and asks why the design wasn't discussed earlier; sets up a quick design chat for next time |
| A new engineer joins | Answers their questions | Plans their first month: a buddy, a starter task, a first real feature, check-ins |
The role charter says "~30% hands-on". Whether that's possible depends on your calendar, especially when the team is ten and a half hours ahead (New York in winter; nine and a half while US daylight saving time is on, from March to early November) and every meeting with them has to fit into your early morning. A quick audit of a typical week:
// A lead's calendar in New York (08:00–17:00), working with a team in Bengaluru. How much time is left
// for hands-on work, and is there any block long enough to do it? Times are local "HH:MM".
const DAY_START = "08:00", DAY_END = "17:00", FOCUS_MIN = 120;
const week = {
Mon: [["08:00", "08:15", "standup (India evening)"], ["08:15", "09:00", "1:1 Asha"], ["10:00", "11:00", "sprint planning"], ["13:00", "14:00", "design review"]],
Tue: [["08:00", "08:15", "standup"], ["08:15", "09:00", "1:1 Ravi"], ["11:00", "12:00", "client sync"], ["15:00", "15:30", "PM catch-up"]],
Wed: [["08:00", "08:15", "standup"], ["08:15", "09:00", "1:1 Meera"], ["10:00", "10:30", "hiring screen"], ["11:00", "11:30", "architecture forum"], ["14:00", "14:30", "1:1 manager"], ["15:30", "16:00", "incident review"]],
Thu: [["08:00", "08:15", "standup"], ["08:15", "09:00", "1:1 Karthik"], ["11:00", "12:00", "client sync"]],
Fri: [["08:00", "08:15", "standup"], ["08:15", "09:00", "refinement"], ["14:00", "15:00", "demo + retro"]],
};
// Every day also has a review block for the India team's PRs and lunch.
for (const meetings of Object.values(week)) meetings.push(["09:00", "09:45", "PR reviews"], ["12:00", "12:30", "lunch"]);
const min = (hhmm) => { const [h, m] = hhmm.split(":").map(Number); return h * 60 + m; };
const hours = (m) => `${Math.floor(m / 60)}h${String(m % 60).padStart(2, "0")}`;
let freeTotal = 0, focusTotal = 0;
console.log("day booked free longest free block focus blocks ≥ 2h");
for (const [day, meetings] of Object.entries(week)) {
const sorted = meetings.map(([a, b]) => [min(a), min(b)]).sort((x, y) => x[0] - y[0]);
const gaps = [];
let t = min(DAY_START);
for (const [a, b] of sorted) { if (a > t) gaps.push(a - t); t = Math.max(t, b); }
if (min(DAY_END) > t) gaps.push(min(DAY_END) - t);
const free = gaps.reduce((s, g) => s + g, 0);
const busy = min(DAY_END) - min(DAY_START) - free;
const focus = gaps.filter((g) => g >= FOCUS_MIN).reduce((s, g) => s + g, 0);
freeTotal += free; focusTotal += focus;
console.log(`${day} ${hours(busy).padStart(8)} ${hours(free)} ${hours(Math.max(...gaps)).padStart(19)} ${focus ? hours(focus) : "none"}`);
}
console.log(`\nweek: ${hours(freeTotal)} unbooked, of which ${hours(focusTotal)} in blocks of 2 hours or more.`);
console.log("Reviews and unblocking come out of the free time first; hands-on work needs the long blocks.");day booked free longest free block focus blocks ≥ 2h
Mon 4h15 4h45 3h00 3h00
Tue 3h45 5h15 2h30 2h30
Wed 4h15 4h45 1h30 none
Thu 3h15 5h45 4h30 4h30
Fri 3h15 5h45 2h15 4h15
week: 26h15 unbooked, of which 14h15 in blocks of 2 hours or more.
Reviews and unblocking come out of the free time first; hands-on work needs the long blocks.- The calendar is a plausible week for a lead in New York with an India team: a standup and a one-to-one every morning in the overlap (08:00 New York is 18:30 in Bengaluru in winter, 17:30 in summer), a 45-minute block for the India team's PRs straight after (so feedback is waiting when they start), planning, client syncs, a design review, a hiring screen and the rest.
- For each day the model finds the gaps between bookings in the 08:00–17:00 day. Booked time is the day minus the gaps, so overlapping meetings aren't counted twice.
- Wednesday is the warning: 4h45 unbooked, but the longest stretch is 1h30 and there's no block of two hours. Unbooked time in 30-minute fragments is good for reviews and answering questions, and nearly useless for writing a tricky piece of code.
- Across the week, 26h15 is unbooked, but only 14h15 is in blocks of two hours or more. If reviews, unblocking and ad-hoc questions take even half the fragments, a 12-hour hands-on budget (as in Leading by example in code) only fits if the long blocks on Monday, Thursday and Friday are protected.
- The practical moves: cluster meetings (Wednesday's could move to Tuesday afternoon), keep one or two meeting-free afternoons as a team norm, and choose hands-on work that fits the blocks you have: a spike on Thursday, not a critical-path feature that needs five uninterrupted days.
Companies define levels differently, but the direction of travel is consistent: scope widens, time horizons lengthen and more of the impact comes through other people.
| Senior engineer | Lead / tech lead | Staff engineer | |
|---|---|---|---|
| Scope | a feature or component | a team's whole area of work | several teams, or a domain across the organisation |
| Time horizon | this sprint to this quarter | this quarter to next | the next year or more |
| Ambiguity handled | a well-defined problem with open design | a fuzzy goal that needs scoping and sequencing | a problem nobody has framed yet |
| Impact mostly through | their own code and reviews | the team's delivery and growth | direction, standards and other leads |
| Typical artefacts | PRs, design notes for their parts | workstream brief, risk register, ADRs, plans | strategy documents, cross-team architecture, guidelines |
A client stakeholder emails the lead: "Can you add CSV export to the device list this sprint? Also, Karthik seems slow lately; is he going to be OK on this team?" Which parts does the lead own, and what's a good reply?
Show answer
The lead owns the technical answer about CSV export (effort, risk, what it would displace) but not the priority call, and not the performance question about Karthik. A good reply handles each part with the right owner.
- CSV export: the lead can estimate it and explain the trade-off ("about two days; it would push the groups page to next sprint"), but whether it displaces planned work is a priority decision for the product owner with the client. Answer with the cost and route the choice, don't silently absorb it.
- Karthik: performance concerns about a person are for their manager, discussed privately, not over email with a client. The lead can say "thanks, I'll pick that up with the team" and then talk to the manager (and to Karthik, if the lead has that responsibility in the charter) about what the stakeholder is seeing.
- The reply might read: "CSV export is about two days of work; we can do it this sprint if we move the groups page to the next one. I've asked <PM> to confirm the priority with you. On the team, thanks for flagging it; I'll follow up internally." Short, honest about cost, and each decision goes to its owner.
- This is why the role charter's "decisions" section exists: the lead doesn't have to improvise who decides what each time a stakeholder asks.