A concise editorial brief on the tech lead trap: responsibility without authority, with the trade-offs and questions that matter before your next move.
The title arrives with a longer meeting list
A developer in Pune becomes tech lead after a release goes well. The new title appears in a chat announcement; the old sprint work remains on the board. Suddenly the developer is expected to review designs, answer incidents, mentor two colleagues, explain trade-offs to product, and still finish the tickets that made the promotion feel deserved. This is the tech lead trap when responsibility expands faster than authority. The title can be a valuable apprenticeship, but only if the organisation decides what the lead may change, stop, prioritise, and delegate. Start with the nearest observable fact. Write down what happened, who said it, and which document or recurring meeting could confirm it. Do not turn one awkward interaction into a theory about an entire employer. A useful question is narrower: what would I expect to see again if this interpretation is correct? Give that question a date, then revisit it with the evidence rather than the anxiety of the moment. A useful habit is to separate what you know from what you infer. Put the direct observation in one line and the interpretation in another. This makes it easier to ask a neutral follow-up and harder for a single rumour to become a career decision.
Technical leadership is not senior ticket delivery
A senior developer can be excellent at solving hard problems and still need a different practice as a lead. The lead makes context available, frames trade-offs, sequences risk, and helps a group make decisions it can defend. That work may produce fewer visible commits and more durable system behaviour. The counterargument is that a lead who stops understanding implementation can become a coordinator detached from reality. The role needs enough technical depth to challenge assumptions, but not an expectation that one person remains the fastest individual contributor and the team’s operating system. There is a counterargument worth preserving. The same arrangement can be a sensible apprenticeship for one person and a dead end for another. A junior employee may value access and feedback; a senior employee may need authority and a credible progression path. The point is not to label the arrangement good or bad. It is to match its trade-offs to the work you need next. The person asking for evidence should also say what evidence would change their mind. Otherwise a request for proof can become an unspoken demand for certainty that no manager or source can provide. Good decisions leave room for revision.
Name the authority before accepting it
Ask which decisions the lead owns: design approval, technical priorities, incident command, standards, staffing input, vendor choice, or release readiness. A lead may recommend without deciding, or decide within a boundary that a principal engineer or product manager can override. Neither arrangement is wrong if it is explicit. Responsibility without a lever is a predictable source of blame. Write down the decision rights and escalation route before the title becomes an informal promise. When a claim affects money, status, or a possible exit, ask for the smallest written clarification that would change your decision. A polite message is usually better than a broad accusation. Keep the answer with the relevant offer, policy, review note, or project record. If no authorised person will clarify it, record the uncertainty as a cost. Do not treat a reassuring phrase as a document. Keep the comparison fair. A role with less prestige may provide a stronger manager, cleaner scope, or a healthier schedule. A role with a famous employer may provide access but little control. The trade is personal, so make it visible rather than borrowing the market’s priorities.
The product boundary
A tech lead is often accountable for technical consequences while product controls priority and scope. That division can work when both sides agree on risk, sequencing, and the conditions for a release. It fails when product promises a date and the lead is expected to absorb every compromise silently. Ask who can negotiate scope, who accepts residual risk, and how a disagreement is recorded. Technical leadership is not a veto over product. It is also not a licence for product urgency to erase engineering evidence. Test the choice against an ordinary Tuesday, not the most flattering version of the future. Imagine the commute, the recurring meeting, the manager's response to bad news, and the work left after the interesting launch. Ask what you would still learn if the promised project slipped. A role that only works in its best case deserves either a better safeguard or a smaller commitment. If a process is unclear, ask for one example from the last cycle. Examples reveal the operating rule better than adjectives. They also let the other person correct an oversimplified question without having to defend the entire organisation.
The incident at 2 a.m.
During an outage, the lead is called because people trust their judgement. Afterward, the lead is asked why detection was late, why the rollback was difficult, and why the team had not rehearsed the path. Those are fair questions only if the lead could influence monitoring, runbooks, staffing, and change controls. Incident ownership should include authority to improve the conditions that produced the incident. Otherwise the title turns accountability into a personal shock absorber. India-specific conditions matter without making every Indian workplace identical. City, family duties, notice periods, language, travel, the shape of the local labour market, and the authority of a global team can alter the same job materially. Avoid importing a US career rule or a friend's Bengaluru experience as universal. Verify the local policy and the actual manager's expectations. A document can be accurate and still incomplete. Read the clause, policy, rubric, or rota alongside the conversation that gave it meaning. When the two conflict, pause and ask which governs. Do not silently choose the version that is most convenient.
India’s distributed-team complication
An India-based lead may coordinate with architects, product managers, or operations leaders in Europe or North America. The team can be local while the decisions are global. Time-zone overlap, office expectations, and escalation norms shape the role more than the title does. Ask who attends the decisive meeting, which hours are protected, and whether the lead can make a call when the parent team is asleep. Global exposure is useful; global responsibility without access is a different bargain. Keep a boundary between editorial reasoning and professional advice. Employment contracts, deductions, tax, equity, and benefits depend on the exact wording and the person's facts. This discussion identifies questions to take to HR, a qualified employment professional, or a tax adviser; it does not resolve them. Read the governing document before acting, and preserve uncertainty where the document is silent. This is why a private decision note is valuable. It records the assumptions you made before accepting, joining, or escalating. Later, you can compare the actual experience with the assumption and learn whether the issue was bad information, a changed business, or a poor fit.
The people work nobody budgets
Code review, onboarding, coaching, interview loops, and conflict repair are often added to a lead’s week without a corresponding removal of delivery work. These tasks are not overhead; they are how a team becomes more capable. But they need capacity and recognition. Ask which commitments will be reduced, how mentoring is evaluated, and whether the lead has help from a manager or staff engineer. If every request is described as a small addition, the total role will be impossible to perform well. A decision becomes easier when its reversible and irreversible parts are separated. An informational interview, a small project, or a written question is usually reversible. Resigning, relocating, signing an undertaking, or accepting a lower cash floor is less so. Spend your certainty budget on the irreversible part. Do not use a confident headline to justify a commitment you have not priced. People often wait for a dramatic breach before asking for clarity. A smaller question earlier is cheaper: who owns this, when will it be reviewed, and what happens if the plan changes? Specificity protects relationships better than a late accusation.
Architecture authority has a shape
A lead does not need unilateral control of architecture to be effective. They do need a route from concern to decision. Is there a design review? Who can reject a proposal? How are exceptions documented? What happens when a dependency team refuses the interface? A mature process can distribute authority while preserving accountability. An immature one leaves the lead to persuade indefinitely and then blames them when a decision made elsewhere fails. Look for the person who controls the lever, not only the person who describes the outcome. A manager may promise exposure without owning the roadmap; HR may describe a policy without deciding exceptions; a senior engineer may carry an incident without authority to change the system. Ask who can approve, stop, fund, or review the thing you are being asked to own. A manager’s inability to answer immediately is not automatically a warning. Distributed organisations have genuine approval limits. The useful test is whether the manager returns with the owner, the policy, or a date. Silence without a route is the more meaningful signal.
When the title is an experiment
A company may use tech lead as a trial before formal promotion. That can be fair if the experiment has a scope, sponsor, duration, and review criteria. It becomes exploitative when the person performs the role indefinitely for the promise of future recognition. Ask whether the title changes pay, level, or only expectations. If the organisation cannot commit to a promotion date, it can still commit to a written decision point and a limit on unpaid scope. A good record is not a private dossier of grievances. It is a compact account of baseline, decision, action, result, and remaining limitation. It helps a manager give specific feedback and helps you explain your work outside the team without taking confidential material. If you cannot describe the result without a title or a brand, the evidence may be thinner than it feels. Do not make a private record so detailed that it becomes impossible to maintain. A few dated examples with consequences are more useful than a diary of every irritation. The aim is to support a decision and a conversation, not to preserve every mood.
The evidence of good technical leadership
Keep examples that show a decision, not only an output. What constraint did the team face? Which options were considered? What risk was accepted? How did the lead make the trade-off legible, and what happened afterward? Include cases where the best leadership meant not building something. A lead’s impact may appear in fewer incidents, faster onboarding, simpler interfaces, or a team that can make good decisions without constant escalation. Do not claim causation the evidence cannot support. Do not confuse the absence of a metric with the absence of value, but do not use vagueness to avoid accountability either. Some work protects reliability, reduces confusion, or makes later decisions possible. Name the mechanism and the trade-off. Then ask how the organisation itself knows the work mattered. If nobody checks, the contribution may be appreciated without being promotable. Where evidence is confidential, describe the category of work: a deployment, a customer process, a control review, or an incident. You can show judgement without publishing names, data, source code, or internal documents. A responsible portfolio has boundaries.
The counterargument: authority is earned
Leads do not always receive broad authority on day one. A team may need to observe judgement before handing over a production gate or a cross-team decision. That is reasonable. The test is whether the path is visible. A manager can say: first own the service review, then lead a design decision, then evaluate the result at a named checkpoint. “Earn trust” without a defined arena asks the lead to prove themselves in an unbounded role. Trust grows faster when the experiment has edges. The strongest next question often sounds less impressive than the original claim. Instead of asking whether a team is strategic, ask what it decided locally last quarter. Instead of asking whether reviews are fair, ask how a disagreement was resolved. Instead of asking whether on-call is manageable, ask for the rota, escalation path, and a recent incident. Specificity is a way to reduce both hype and cynicism. A role can improve while the headline remains unchanged. A better manager, wider decision surface, or more reliable schedule may be worth more than a title. Conversely, a title can improve while the underlying bargain deteriorates. Inspect the work, not just the label.
What to negotiate with a manager
Do not negotiate only title and pay. Negotiate the work that stops, the decisions that move, the support that arrives, and the evidence that will be reviewed. A useful opening is: “If I am accountable for reliability, I need authority over the runbook and a route to change the dependency. Which existing priority should move so I can do that?” The manager may decline. That answer reveals whether the organisation wants leadership or merely wants a name attached to risk. Compare alternatives on the same dimensions: cash certainty, learning, authority, time cost, health cost, and exit options. A list of pros and cons hides unequal consequences. A delayed promotion may be tolerable with strong learning and a sponsor; the same delay is costly when extra scope is indefinite. Make the trade-off explicit so urgency does not silently choose for you. If the answer depends on a policy, ask for the current version and effective date. Policies change, and a search result or colleague’s memory may describe an earlier rule. Where the issue is consequential, check the governing document and obtain appropriate professional advice.
The lead as translator
Technical leadership often means translating between reliability, product value, customer impact, cost, and delivery time. The lead should not hide technical uncertainty behind jargon or reduce business pressure to ignorance. A short decision note can state the options, consequences, recommendation, owner, and review trigger. This makes disagreement safer because the group is arguing about a visible choice. It also protects the lead from being remembered as responsible for every assumption nobody wrote down. Evidence can be incomplete without being useless. A source may describe a global pattern while saying little about one Indian team. A job description may show intended scope while omitting the manager's habits. A rating policy may describe process without revealing calibration. State the limit, then use the evidence for the smaller claim it can support. Precision is more credible than certainty. The most useful comparison is often between staying and accepting, not between two offers. Staying has a cost too: delayed learning, continued stress, or foregone cash. Name those costs without treating departure as inevitable. A fair comparison includes the status quo.
When delegation goes wrong
A lead who keeps every difficult task becomes a bottleneck and teaches the team that quality depends on one person. A lead who delegates without context creates avoidable failure. Start with the decision boundary: what must be reviewed, what can be owned independently, and what signal should trigger help? Delegation is not abandoning quality. It is building a system in which more people can exercise judgement. The manager should protect time for this work rather than measuring the lead only by personal output. Before making a move, name the failure mode you can tolerate and the one you cannot. Someone supporting parents may prioritise predictable cash; someone rebuilding technical confidence may accept a narrower title for a strong mentor. Neither preference is a lack of ambition. The practical test is whether the choice protects the non-negotiables while creating evidence for the next move. A decision made under time pressure still deserves a boundary. Say what you need confirmed before signing or resigning, and what you are willing to leave unresolved. This keeps urgency from turning every unanswered question into an automatic yes.
The performance-review mismatch
A lead may be evaluated using an individual-contributor rubric while being asked to deliver team-level outcomes. That mismatch makes the role structurally unstable. Ask whether the level framework recognises influence, risk ownership, mentoring, and cross-team decisions. If the company has no separate path, clarify how these contributions will be considered. This is not legal advice about promotion or pay; it is a question about the evidence the organisation says it values. Keep the answer in writing. A useful conversation leaves both parties with an action, an owner, and a review point. “We will see” has none of these. Ask what will be done, who can do it, and when the result will be discussed. If the answer cannot be made specific because the business is genuinely uncertain, ask what signal would reopen the decision. Uncertainty can be managed; invisible uncertainty cannot. Career evidence is strongest when another person could reasonably verify it. Name the partner, system, review, or decision without claiming more than you observed. This is especially important for senior work, where influence can be real but difficult to measure.
A thirty-day authority audit
In the first month, list every responsibility assigned to the lead and the lever attached to it. Mark each as decide, recommend, execute, or escalate. Circle the items with no owner or no route to change. Review the list with the manager and product partner. This simple audit can reveal whether the trap is a misunderstanding, an overloaded design, or a deliberate expectation. It also gives the lead a professional way to discuss boundaries before an incident makes the question personal. The conclusion should remain modest. A pattern may justify asking a sharper question, not predicting a company-wide outcome. A source may establish context, not an individual guarantee. A personal experiment may reveal fit, not prove a career law. Use the evidence to choose the next check. Keep the claim no larger than the record that supports it. A reversible experiment can reveal more than another hour of speculation. Shadow a meeting, review a sample rota, request a redacted policy, or take on a bounded responsibility. Set a stopping rule. Experiments work when they are small enough to complete and honest enough to disappoint you.
Stay, renegotiate, or leave
A tech lead role may be worth keeping when the scope is expanding, the manager protects capacity, and decisions become more local over time. Renegotiate when the work is valuable but the mandate is vague. Consider leaving when responsibility stays high, authority stays absent, the review route is fictional, and the role is harming health or credibility. There is no universal tenure to wait. Use the evidence from the authority audit and the response to your questions. The final check is personal runway. Count time, cash, health, family support, and the credibility you can spend while learning. There is no universal safe reserve and no shame in choosing stability. There is also no virtue in staying indefinitely because a move feels risky. Decide what evidence would make the risk acceptable, and what evidence would make you walk away. A source may be authoritative about its own method and still limited for your question. Read its population, date, geography, and definition before transferring a conclusion. The right response to a limit is not to discard all context; it is to make a narrower claim.
The lead should not be the system’s scapegoat
A good tech lead accepts accountability for decisions they can influence and makes constraints visible when they cannot. A good organisation gives the lead enough authority, time, and support to act on the risks it assigns them. The title is useful when it names a real operating role: someone who helps a team decide and learn. It is dangerous when it merely places one person between ambitious promises and the systems, budgets, and dependencies that actually determine the result. Return to the original promise and translate it into a sentence with a verb: decide, ship, review, coach, respond, or earn. If the promise has only nouns such as exposure, culture, ownership, or growth, it is not yet a testable offer. Ask for the missing verb. Careers compound around actions that can be observed, explained, and carried into the next context. The choice should leave you with an explanation you can live with if the hoped-for outcome arrives late. That is not pessimism. It is a way to keep your finances, health, and professional identity from depending on a promise nobody has documented.