Tech leads
A tech lead carries the technical direction of one team: how the work will be built, in what order, to what standard, and which compromises are acceptable for now. It is a hands-on job rather than a management one, and it runs on credibility rather than reporting lines. What follows describes the remit, where it stops, and how to recognise someone able to hold it.
What does a tech lead do?
A tech lead is the engineer accountable for the technical direction of a single team’s work. The job covers deciding how a piece of work will be built, reviewing designs before they turn into code, keeping the quality bar consistent across everyone contributing, sequencing delivery against accumulated debt, and clearing the obstacles that stop other engineers making progress. Tech leads normally keep writing code and normally carry no line-management duties: pay, performance and progression sit elsewhere, while the shape and soundness of what the team builds sits with them.
The role is defined by responsibility without command. A tech lead rarely has the standing to instruct anyone, so direction has to be earned through reasoning other engineers find convincing, and through a track record of calls that held up. The engineers who struggle most in the job are usually those who expected the title to settle arguments, and the ones who do best treat every decision as something that must survive being questioned.
The permanent tension is between doing the work and enabling it. An hour spent building the hardest part personally produces a known result; an hour spent unpicking a colleague’s design produces a better team and nothing visible today. Tilt too far towards personal output and the lead becomes the only person who understands the system. Tilt too far the other way and technical credibility erodes until the reasoning stops carrying weight. Deciding that split, week by week, is much of the craft.
The horizon is short and the scope is narrow, and that is the point. A tech lead reasons in weeks and months about one team’s codebase and the systems it owns, which is what allows the decisions to be specific and to land immediately. Questions that reach across several teams, or bind the organisation for years, belong to a wider role — and mistaking one horizon for the other is the most common way the position is scoped badly.
When teams need this capability
Most teams run without a named technical lead until the absence starts producing a recognisable set of symptoms. These are the ones that show up first.
Locally sensible decisions are adding up to an incoherent whole
Each engineer is choosing reasonably, and nobody is joining the choices together, so the codebase acquires three approaches to the same problem. Nothing looks wrong in any single review, which is why this state can persist for a long time before anyone names it.
Work stalls waiting for questions nobody owns
A ticket sits half-finished because the approach is contested and no one has the standing to close the argument. The cost appears as slow delivery, and the actual cause is an unresolved decision that has no owner.
The quality bar depends on who reviews
Two engineers submit comparable work and receive incomparable scrutiny. Standards that live in individual heads rather than in a shared understanding produce a codebase whose quality varies by author, and reviews that feel arbitrary to the people receiving them.
Debt is discussed constantly and scheduled never
Everyone agrees the migration matters and it loses to feature work every planning session. Trading remediation against delivery credibly requires someone who can price both sides in the same conversation and defend the result.
A manager is holding technical direction alongside people work
One person doing both tends to do the urgent half. Design questions get answered late or with insufficient context, and the people work suffers in the weeks when a hard technical problem takes over.
The team has outgrown informal coordination
What worked when a couple of engineers shared a codebase stops working once several are changing it concurrently. Merge conflicts become architectural conflicts, and someone has to hold the shape of the thing in mind on everyone’s behalf.
Core capabilities
Closing technical decisions
Gathering enough context, weighing the options, choosing, and making the choice known — including the reasoning and the conditions under which it should be revisited. A decision that stays open is more expensive than a decision that turns out to be wrong, because the team pays for the ambiguity every day.
Design review
Reading a proposal for what it leaves out: the failure path, the migration, the operational cost, the assumption about data volume that will not hold. Catching those before implementation is where the role earns most of its value, because the same problems cost far more once code exists.
Holding a consistent standard
Making the quality bar explicit and applying it evenly, so that engineers can predict what will pass. This is as much about knowing where the bar should sit for a given piece of work — a throwaway experiment and a payment path do not deserve identical rigour — as about enforcing it.
Breaking work down and sequencing it
Turning an ambiguous requirement into increments that can be built, reviewed and released independently, ordered so that risk surfaces early and later steps are not blocked by earlier guesses. Poor decomposition is a leading cause of work that stalls just short of finished.
Unblocking
Noticing that someone has been stuck since Tuesday and would not say so, then resolving it without taking the work away. This is the least visible part of the role and often the highest-return use of a lead’s time.
Balancing delivery against debt
Deciding which shortcuts are worth taking, recording them so they remain visible, and knowing which ones must be repaid before they compound. The judgement is about which debt accrues interest and which is simply untidy and harmless.
Choosing what to build personally
Staying hands-on selectively: taking the work that genuinely needs the deepest context, and deliberately declining the interesting problem so someone else grows into it. A lead who takes every hard task produces a team that cannot function without them.
Explaining technical risk to non-engineers
Translating a structural problem into its business consequence — what becomes impossible, what gets slower, what will fail and when — without either overstating it to force action or softening it into something that gets ignored.
Developing engineers through the work
Using delegation, review and framing as the means by which people improve, which is distinct from managing careers. A tech lead influences how quickly someone grows without owning their appraisal, their objectives or their progression.
Operational ownership
Making sure the team can run what it ships: alerting that means something, runbooks that are current, incidents followed through to a cause rather than closed at recovery, and the resulting fixes actually scheduled.
How the discipline is practised
Technical leadership is not defined by a toolchain, so what follows is not a stack. Set out below are the practices, methods and artefacts commonly associated with the role across the industry — a description of how the discipline works in general, and not an account of how any individual works. Familiarity with the vocabulary matters far less than evidence that the underlying judgement is present.
Deciding and recording
- Design documents
- RFC and proposal review
- Time-boxed spikes
- Trade-off write-ups
- Decision logs
Quality mechanisms
- Code review conventions
- Definition of done
- Test strategy
- Static analysis gates
- Refactoring budgets
Delivery practice
- Story slicing
- Backlog refinement
- Work-in-progress limits
- Risk-first sequencing
- Release planning
Operational practice
- On-call rotations
- Runbooks
- Alert tuning
- Blameless incident review
- Service-level objectives
Technical health
- Debt registers
- Dependency upgrade cadence
- Build and pipeline health
- Flaky test tracking
- Delivery flow metrics
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
Judgement is what this position is assessed on, and judgement is genuinely difficult to interview for. Candidates arrive carrying a title that means something different at every company, so the strongest evidence is nearly always a specific account of a decision and what followed it, rather than any description of how they lead.
Deciding without enough information
Every meaningful technical call is made with gaps in the picture. Ask about one where the information never arrived, and listen for how they bounded the risk rather than how confident they were.
- Names what they did not know and how they compensated for it
- Set a trigger for revisiting the decision rather than treating it as final
- Can describe a call that proved wrong and what the recovery cost
Whether they multiply the team or absorb it
The characteristic failure of this role is a lead who becomes the single point through which everything must pass. Probe how work was distributed and what happened when they were away.
- Gave away work they wanted to keep, and can say which
- Describes the team continuing to decide well in their absence
- Notices when their review queue has become the constraint
Design review practice
Ask what they look for in a proposal before implementation starts. Weak answers describe style and structure; strong ones go straight to failure modes, operational cost and the assumptions that will not survive contact with production.
- Asks about failure and rollback before asking about structure
- Treats a proposal with no rejected alternatives as incomplete
- Can describe changing their own mind during a review
Handling technical disagreement
Disagreement among capable engineers is normal and how it resolves reveals more than any architecture answer. The concerning responses are at both extremes: leads who always defer, and leads who always prevail.
- Distinguishes disagreements worth resolving from those worth leaving open
- Has adopted an approach they initially argued against
- Escalates on substance rather than on frustration
Pricing debt against delivery
Ask how they decided to postpone a remediation, and how they knew when postponing further would be unsafe. The answer distinguishes engineers who talk about debt from those who have managed it under commercial pressure.
- Distinguishes debt that compounds from mess that is merely untidy
- Made the shortcut visible rather than silent
- Can name a repayment they successfully argued into a delivery plan
Current hands-on ability
The role needs someone whose technical instincts are still calibrated to the work as it is done now. A candidate whose last serious contribution was years ago will review against a system that no longer exists.
- Discusses recent code in specifics rather than generalities
- Comfortable being wrong about a technical detail in conversation
- Has an informed view on a tool their team adopted recently
Knowing where the role ends
A tech lead who quietly absorbs people management, or who starts making decisions binding on teams they do not work in, creates confusion that surfaces months later. Boundary awareness is a positive signal, not a lack of ambition.
- Separates their own remit from a manager’s cleanly
- Raises cross-team concerns rather than settling them unilaterally
- Can describe working alongside an architect without friction
Interview questions worth asking
Material for the interview process you run yourself. Every candidate is assessed by you, against your own context, and the notes below describe what to listen for rather than a correct answer.
Describe a technical decision you made for your team that you later reversed. What made you reverse it?
What a strong answer shows
Whether they run decisions as revisable positions or as commitments to defend. Look for a specific signal that prompted the reversal, and for whether the reversal was cheap because they had designed for it.
Two engineers on your team disagree about an approach and both cases are reasonable. Walk me through what you actually do.
What a strong answer shows
How direction is exercised without authority. Strong responses find the disagreement’s real root, judge how reversible the choice is, and match the effort spent to the cost of being wrong.
What did you deliberately not work on last quarter, even though you were the fastest person to do it?
What a strong answer shows
Whether they understand that their own throughput is not the measure. A candidate with no answer here is usually the team’s hardest-working constraint.
How do you know your team’s quality bar is being applied consistently rather than depending on the reviewer?
What a strong answer shows
Whether standards have been made explicit or remain tacit. Look for artefacts, calibration and worked examples rather than an assurance that everyone knows what good looks like.
Tell me about a shortcut your team took under delivery pressure. What did you do to make sure it stayed visible?
What a strong answer shows
Debt handled deliberately rather than accumulated by default. The strongest answers include the mechanism that kept it on the record and what eventually happened to it.
A design comes to you that will work but that you would not have chosen. What happens next?
What a strong answer shows
Proportion. Overriding a workable design because it is not the preferred one is a reliable way to stop a team thinking for itself, and the answer should show a threshold rather than a reflex.
Which parts of your team’s system would you struggle to explain if the person who built it left tomorrow?
What a strong answer shows
Honest awareness of knowledge concentration. Candidates who claim complete coverage of a real system are usually describing an aspiration rather than a situation.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- A team is delivering steadily but its codebase has drifted: comparable problems are solved several different ways, design questions are settled in code review rather than before it, and a long-postponed remediation has started to slow ordinary feature work. The engineers are capable and no one is holding the technical shape of the work.
- Approach
- An additional senior engineer joins the team under its existing arrangements — the client’s architecture, the client’s standards, the client’s planning cadence and the client’s roadmap. Technical direction remains the client’s to set; the added capacity works inside it, contributing to design review and daily delivery alongside the team rather than beside it.
- What this adds to the team
- The client gains senior engineering capacity while keeping full ownership of product decisions, architecture and engineering standards. Nothing about who decides the team’s technical direction changes.
Related disciplines
Frequently asked questions
- What is the difference between a tech lead and an engineering manager?
- A tech lead owns how the team’s software is designed and built; an engineering manager owns how the team functions as a group of people. Hiring, growth, performance, pay, team composition and cross-functional coordination belong to the manager. Technical decisions, design review, standards and delivery sequencing belong to the lead. Some organisations merge them into one job, which is workable in a small team and tends to fail as it grows, because the two sets of duties compete for the same attention and the urgent one always wins.
- What is the difference between a tech lead and a software architect?
- Scope and horizon. A tech lead is responsible for one team’s work over weeks and months and stays close enough to the code to review it. An architect works across systems and teams over years, on decomposition, boundaries, integration and non-functional requirements, and is normally less hands-on. A poor architectural decision is expensive because it is hard to reverse; a poor tech lead decision is usually contained within one team and can be corrected in a sprint.
- Does a tech lead still write code?
- Usually yes, and the amount matters less than the selection. Writing enough to keep technical instincts current and to feel the friction the team feels is close to essential; writing so much that reviews queue behind personal delivery defeats the purpose. Leads who write nothing gradually lose the standing the role depends on, and leads who write everything become the reason the team cannot proceed without them.
- Is tech lead a promotion or a different job?
- A different job, though it is often awarded as a promotion. It draws on different skills from senior individual contribution — persuasion, prioritisation, comfort with unfinished work owned by other people — and an excellent engineer can be poor at it without that saying anything about their engineering. Treating it as a rank rather than a set of responsibilities produces reluctant leads and a route back that feels like demotion when it should be routine.
- How much authority does a tech lead actually have?
- Formally, usually very little. The role is nearly always accountable for outcomes it cannot compel, which is why the reasoning has to be good enough to persuade and why credibility is the working currency. Organisations that expect the title alone to carry decisions tend to produce leads who either escalate constantly or issue instructions nobody follows.
- Can one person lead more than one team?
- It is possible and it usually degrades. The role depends on proximity — knowing who is stuck, what the review queue looks like, which assumption is quietly wrong — and that awareness thins out quickly across teams. Splitting a lead across two teams often produces one team with a part-time lead and another with none.
- How does a tech lead work with an existing engineering team?
- Within your arrangements rather than in place of them. In a staff augmentation model, your organisation continues to set architecture, engineering standards, technical direction, roadmap and priorities, and daily direction of the work stays with your own people. The employment relationship sits with Talent.ID — payroll, employee benefits and talent administration — and that is the whole of it. Engineering leadership is not transferred, and nothing in that arrangement moves technical decision-making outside your team.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.