# Hiring as a team lead **Hiring as a team lead** means carrying process ownership beside technical work. You may define the role, brief interviewers, and recommend a hire while an engineering manager controls headcount, compensation, and the formal offer. That split can work well when authority is written down. It fails when former peers think you are only another interviewer, candidates receive mixed answers, or you absorb hiring work without reducing coding and delivery commitments. ## Team lead and engineering manager are different seats A team lead usually owns technical direction and daily coordination without every people management authority. An engineering manager may own performance, compensation, and formal staffing decisions. Companies use the titles differently, so do not infer the boundary from the label. Ask who defines the work, who recommends, who approves level, and who can commit money. The team lead often has the clearest view of the actual gap. You know which service has fragile ownership, where reviews stall, and what kind of judgment the team needs. That context makes you a natural owner of the role brief and evidence plan. It does not automatically give you authority to promise title, salary, location, or reporting changes. A written split protects everybody. Recruiting knows whose answer is final. Interviewers know where to take concerns. Candidates do not receive a tentative promise from somebody who cannot approve it. The split also protects the lead from being held responsible for delays controlled elsewhere. ## Define the work from close range Describe what the new person will do with the team, not an abstract ideal engineer. Perhaps they will take ownership of a billing service, reduce review delays across two product areas, and improve incident learning. Include the constraints you see: weak tests, a fixed migration date, or a product partner with limited technical context. Check your definition with the engineering manager. A lead may optimize for immediate technical relief while the manager expects broader growth or a different level. Resolve that tension before recruiting begins. If the role must serve both needs, explain how. If priorities conflict, somebody with the right authority must choose. Invite peers to test the brief, but do not turn it into a wish list. One engineer wants a database expert, another wants better frontend support, and another wants a mentor. Return every request to the role outcomes and likely capacity. A hire cannot repair every frustration. Focus is part of your ownership. ## Former peers now interview with you as owner The social change can feel awkward. Yesterday you joined a loop and submitted an opinion beside everyone else. Today you assign evidence areas and make the recommendation. Avoid pretending nothing changed. Tell peers that you own coherence for this opening, explain which decisions remain shared, and invite disagreement through a clear route. Do not use ownership to override expertise. A peer who operates the service may see a risk you missed. Ask them to connect it to the role and identify what evidence would reveal it. You make the final process choice, but good authority remains open to relevant facts. Likewise, do not surrender the process to preserve comfort. If an interviewer wants an unrelated puzzle or writes only “no hire,” ask for a role connection and observable notes. Former equality does not remove your responsibility to protect candidates and decision quality. Be clear without performing rank. ## Keep coding without hiding the load Hiring arrives as small interruptions that can destroy technical focus. A screen at noon, a note reminder at three, and a candidate question at five may leave little room for a difficult code change. Track the full cost and reduce your planned engineering work. Do not rely on evenings to preserve the appearance that both jobs fit. Choose technical work that tolerates interruption during an active search. A bounded review, small improvement, or pairing task may be safer than sole ownership of a risky migration. This is not a permanent retreat from engineering. It is a temporary portfolio choice that keeps both hiring and delivery credible. Tell the team what moves. If you own fewer tickets because you are running the opening, name the tradeoff. Silent load shifting makes peers cover work without understanding why and can make the lead seem detached. Visible planning lets the team challenge an unrealistic schedule before frustration grows. ## Clarify authority at every stage | Decision | Team lead may own | Manager may retain | | --- | --- | --- | | Work outcomes | Draft and explain | Approve scope | | Interview plan | Design and brief | Check policy | | Evidence | Review and recommend | Challenge gaps | | Level | Provide role evidence | Approve level | | Offer | Close on team and work | Approve and sign | The table is an example, not a universal rule. Your company may give team leads more or less authority. The important practice is making the split explicit before a live decision. If level disagreement first appears after the final interview, the candidate waits while leaders discover their own process. Clarify who communicates each answer. The lead can describe engineering challenges and team practices. The manager or recruiter may handle compensation and policy. If a candidate asks outside your authority, say who owns it and follow up. Honest boundaries build more trust than an improvised answer. ## You still must make a clear recommendation Lack of final offer authority does not reduce your recommendation to a vote. Summarize the role outcomes, the strongest evidence, material concerns, and missing information. State whether you recommend proceeding and why. A manager can then exercise their authority with a clear technical and team argument. Do not hide behind consensus. Former peers may split, or a senior interviewer may sound certain. Review the underlying observations. If the process failed to test an essential area, say so and propose a focused next step. If the evidence is sufficient, choose. Ambiguity passed upward is not collaboration. Be ready to say no to a person you enjoyed meeting. A team lead will work closely with the hire and may feel pressure to fill the gap quickly. Return to the work. Friendly conversation and familiar technology do not substitute for evidence that the candidate can handle the role's constraints. ## A team lead hiring sequence - Write the authority split with your manager. - Draft outcomes from the team's real work. - Choose what is fixed and flexible. - Plan delivery capacity for hiring. - Brief former peers on their evidence areas. - Record notes before group discussion. - Write a clear recommendation. - Support the close without promising beyond authority. Share the sequence with recruiting so they know when to involve each owner. A candidate should not wait while the lead and manager debate who answers a simple question. Establish response times and a backup when one person is unavailable. Team lead ownership should make the process faster and closer to the work, not add another approval layer. After each loop, inspect both evidence and load. Did peers understand assignments? Did your coding commitments remain realistic? Did the manager receive enough context to decide? Adjust early. The most useful process is one the lead can actually operate without degrading the team they are trying to strengthen. ## Protect the team you are hiring into A rushed hire can seem like relief, but the team will carry the consequences. If ownership expectations remain vague, the new person may enter conflict with peers who expected something else. If the loop rewards command without listening, the person may amplify the coordination problem the role was meant to solve. Your close view of daily work is essential. Protect current engineers during interviews too. Rotate participation, cover their tasks, and avoid asking the whole squad to approve every candidate. Explain how evidence will be used and where their input matters. People support hiring more readily when the process respects their expertise and attention. Hiring as a team lead is a leadership test because authority and accountability do not align perfectly. You cannot solve that by acting like a full engineering manager or by retreating into an interviewer role. Define the boundary, own the work inside it, escalate decisions outside it, and make a recommendation that can survive careful questions. ## How do you escalate without giving away ownership? Escalate a decision when it exceeds your authority, not whenever it feels difficult. Bring the manager a compact account of the role, evidence, tradeoff, and choice needed. For example, explain that the candidate fits the defined work but interview evidence supports a different level than the approved opening. Ask for the level decision while keeping ownership of the technical recommendation. Avoid becoming a messenger between recruiting and the manager. If compensation or location policy is blocking the process, bring the owners together and stay long enough to preserve the role context. Passing fragments between people creates delay and distortion. You do not need to decide the policy, but you do need to keep its effect on the hire visible. Tell former peers when an escalation changes the plan. They should not discover during a decision discussion that the level moved or a requirement disappeared. Explain what changed, who decided, and how their evidence will now be used. This keeps process authority credible even when final authority sits elsewhere. Escalation can also protect a candidate. If leaders want another broad interview because they feel uncertain, ask which unanswered role question it will resolve. If nobody can name one, recommend making the decision with existing evidence. Your limited formal authority does not prevent you from challenging unnecessary candidate load. Over time, record recurring boundary problems. If every opening stalls at the same approval or peers repeatedly misunderstand your role, propose a clearer standing agreement. Team lead hiring becomes sustainable when the organization learns from these frictions instead of renegotiating authority around every candidate. ## What are common questions? ### Can a team lead be the hiring manager? Yes. A team lead can own the role, loop, and recommendation while an engineering manager retains headcount, level, compensation, or offer authority. ### What authority should be written down? Clarify who defines outcomes, designs interviews, recommends, approves level, discusses compensation, signs the offer, and communicates each decision. ### How can a team lead keep writing code while hiring? Reduce planned engineering work, choose tasks that tolerate interruption, and make the hiring tradeoff visible instead of moving work into evenings. ### How should a lead brief former peers? Explain the ownership change, assign distinct evidence areas, welcome role based concerns, and require specific notes without relying on status. ### Does the lead still need to make a recommendation? Yes. Even when another manager approves the offer, the lead should state the role evidence, concerns, missing information, and a clear recommendation. Related: [becoming a hiring manager](https://isilta.com/blog/becoming-a-hiring-manager/), [moving from interviewer to hiring manager](https://isilta.com/blog/from-interviewer-to-hiring-manager/), [hiring without burning the team](https://isilta.com/blog/hiring-without-burning-the-team/).