Managing Team Leaders

You've been managing engineers. Now you're managing the people who manage engineers. This is a fundamentally different job, and if you treat it the same way, you'll either suffocate your Team Leaders or leave them stranded without support.

Let's talk about how to do this well.

1. Managing Managers is Different

When you managed ICs, you were close to the work. You could review code, see the pull requests, watch the sprint board, and have a pretty good sense of whether things were on track. You were one step from the output.

Now you're two steps away. You're managing someone who manages the work, and that changes everything.

Your job is no longer to ensure the work gets done correctly. Your job is to ensure the person responsible for the work is equipped, supported, and growing. The skills shift dramatically:

From directing to coaching. You're not telling them what to do. You're helping them figure out what to do.
From evaluating output to evaluating judgment. You care less about whether a specific technical decision was right and more about whether your TL's decision-making process is sound.
From solving problems to asking questions. When a TL brings you a problem, your first instinct should be to ask "What do you think we should do?" not to jump in with the answer.
From managing tasks to managing context. Your value is in giving TLs the bigger picture — the company direction, the political landscape, the cross-team dependencies — so they can make good decisions without checking with you every time.

This is hard for many new EMs because it feels like you're doing less. You're not writing the code, you're not even reviewing the designs, you're just... talking to people? But this is the job. And when you do it well, you multiply your impact far beyond what you could accomplish hands-on.

2. Coaching TLs vs. Coaching ICs

With an IC, coaching often looks like: "Here's how to structure that API better," or "Let me show you how to break this problem down," or "You should read about this pattern." You're coaching on skills — technical skills, communication skills, time management.

With a TL, coaching looks completely different. You're coaching on judgment, leadership, and people skills. The conversations sound like:

"How did you decide to prioritize that project over the other one?"
"Tell me about the conversation you had with that struggling engineer. How do you think it landed?"
"You've got a conflict between two team members. What's your read on the situation?"
"Your team seems stretched. How are you thinking about capacity?"

The key difference is that you're not giving them the answer. You're helping them develop their own framework for finding answers. Every TL will develop their own leadership style, and that's not just okay — it's what you want. Your job is to help them find what works for them, not to create clones of yourself.

Here's what good TL coaching looks like in practice:

Don't say: "You should have that difficult conversation with Alex this way..." Do say: "What outcome are you hoping for with Alex? What have you tried? What's your gut telling you?"

Don't say: "You need to run your standups like this." Do say: "Your team seems disengaged in standups. What do you think is going on? What have you considered changing?"

Don't say: "I would have made a different technical decision there." Do say: "Walk me through how you arrived at that decision. What tradeoffs did you weigh?"

The goal is that over time, your TLs internalize these questions and start asking them of themselves. That's when you know the coaching is working.

3. Giving TLs Autonomy

This is where a lot of EMs get it wrong, especially those who were strong TLs themselves. You know how to lead a team. You have opinions. And it's tempting to keep your hands on the steering wheel. Don't.

Your TLs need space to lead. If they can't make decisions, take ownership, and occasionally make mistakes, they'll never grow. And their teams will sense it — they'll start going around the TL and coming straight to you, which undermines everyone.

Rules for preserving TL autonomy:

Never undermine them in front of their team. If a TL makes a decision you disagree with, talk about it privately. The moment you override a TL in a team meeting, you've told that team "your leader's judgment doesn't matter." It takes months to recover from that.

Don't override their decisions casually. If you're going to reverse a TL's call, it should be because the decision has significant consequences and you have information they don't. And even then, explain your reasoning. "Because I said so" destroys trust.

Trust, verify, coach. Trust them to handle things. Verify through outcomes, skip-levels, and regular 1:1s. Coach when you see gaps. This cycle is the foundation of the relationship.

Let them fail safely. Some lessons can only be learned through experience. If the stakes are low enough, let the TL make the call even if you suspect it won't work out. Then help them reflect on what happened afterward. These are the lessons that stick.

Give them credit publicly. When their team succeeds, make sure the organization knows it was the TL's leadership that made it happen. Your job is to make your TLs look good, not to take the spotlight.

There's a balance here, of course. Autonomy doesn't mean abandonment. You should be available, you should provide guidance when asked, and you should step in when things are going seriously wrong. But the default should be: they lead, you support.

4. Skip-Level 1:1s

Skip-level 1:1s — meetings with the people who report to your TLs — are one of the most valuable tools you have. They're also one of the most misunderstood.

What skip-levels are for:

Understanding team health and morale from multiple perspectives
Getting unfiltered feedback about how things are going
Building relationships with people across your organization
Spotting patterns that a single TL might not see
Identifying high-potential people and retention risks

What skip-levels are NOT for:

Spying on your TLs
Making decisions that should be the TL's to make
Giving direction or assignments that bypass the TL
Hearing complaints and acting on them without involving the TL

How to do them well:

First, tell your TLs you're doing this and why. Frame it as: "I want to build relationships across the org and understand how things are going at the team level. This isn't about checking up on you — it's about me doing my job well." If your TLs feel threatened by skip-levels, that's a coaching conversation about trust and security.

Second, keep a regular cadence. Monthly or every six weeks works for most organizations. Put them on the calendar. Don't make them feel like an inquisition.

Third, keep the conversation open-ended. Good skip-level questions:

"How are things going on the team?"
"What's the most frustrating thing about your day-to-day?"
"Do you feel like you're growing? What would help?"
"Is there anything you wish leadership understood better?"
"What's working well that we should make sure to keep doing?"

Fourth, when you hear something concerning, bring it back to the TL — not as "someone complained about you" but as "I'm noticing a theme around X, what's your take?" Protect the individual's confidence while still addressing the issue.

Fifth, if someone raises something truly serious in a skip-level — harassment, ethical violations, safety concerns — you have an obligation to act on it directly, regardless of the TL dynamic. Make that clear to everyone.

5. Calibrating Across Teams

If you manage multiple TLs, you now own something subtle but critically important: consistency across teams.

Left to their own devices, different TLs will develop different standards, different cultures, and different expectations. Some variation is fine — even healthy. But too much divergence creates real problems:

"Second class" teams. If one team gets better projects, more support, or clearer communication, the other teams will notice. Resentment builds fast.
Inconsistent performance standards. If one TL rates generously and another rates harshly, your engineers will feel the unfairness acutely. This kills trust in the performance process.
Knowledge silos. If teams don't share practices, learnings, or tooling, you're losing a huge efficiency multiplier.
Uneven workload. If one team is consistently overloaded while another coasts, you'll burn out the first team and bore the second.

What to calibrate:

Performance expectations. What does "meets expectations" look like? What does "exceeds" require? Get your TLs aligned on this, especially before review cycles.
Process maturity. Teams don't need identical processes, but they should have comparable rigor. If one team does thorough incident reviews and another shrugs off outages, that's a problem.
Workload distribution. Regularly review how work is allocated across teams. Advocate for rebalancing when needed.
Growth opportunities. Make sure interesting projects, conference slots, and visibility opportunities are distributed fairly, not just given to the loudest TL's team.
Hiring standards. If your TLs are involved in hiring, align on what you're looking for. One team's "strong hire" shouldn't be another team's "pass."

The best way to do this is to bring your TLs together regularly. A weekly or biweekly TL sync where you discuss cross-cutting topics, share challenges, and align on standards. This also builds camaraderie among your TLs, which pays dividends when they need to collaborate.

6. When a TL Struggles

Not everyone who steps into a TL role thrives in it. And sometimes a TL who was doing well hits a rough patch. You need to recognize the signs and know how to respond.

Early warning signs:

Team morale drops. People seem disengaged, frustrated, or anxious. You hear about it in skip-levels or see it in engagement surveys.
Delivery slows. Projects slip, quality drops, technical debt piles up. The team seems to be spinning.
People leave or ask to transfer. One departure might be coincidence. Two or three is a pattern.
Complaints increase. Other teams or stakeholders start raising concerns. People come to you instead of the TL.
The TL seems overwhelmed. They're working excessive hours, seem stressed, can't articulate priorities, or are visibly struggling in meetings.

How to intervene:

Step 1: Diagnose. Is this a skill gap, a motivation problem, a support problem, or a fit problem? Talk to the TL. Talk to their team (through skip-levels). Look at the data. Don't assume you know what's wrong.

Step 2: Coach first. Most struggling TLs can improve with the right support. Increase your 1:1 frequency. Get specific about what needs to change. Set clear expectations with timelines. Provide resources — a mentor, a training program, a book, whatever might help.

Step 3: Direct if needed. If coaching isn't working fast enough and the team is suffering, you may need to step in more directly. This might mean co-leading certain meetings, making some decisions jointly, or temporarily taking over a specific responsibility. Be transparent about why you're doing this.

Step 4: Evaluate fit. If sustained coaching and support don't produce improvement, you need to have an honest conversation about whether the TL role is right for this person. This doesn't have to mean failure — many excellent engineers stepped into leadership, found it wasn't for them, and went back to being outstanding ICs. That's a success, not a defeat.

The worst thing you can do is ignore the problem and hope it resolves itself. A struggling TL affects every person on their team. You owe it to everyone — including the TL — to address it.

7. Growing TLs into EMs

Part of your job is building the next generation of engineering leaders. Some of your TLs have the potential and desire to become EMs, and you should actively help them get there.

Signs a TL might be ready for more:

They think beyond their team — about org-wide problems, cross-team dynamics, company strategy.
They're curious about the business, not just the technology.
They handle ambiguity well and can make decisions without complete information.
They're good at influencing without authority — getting things done across team boundaries.
Other TLs and ICs naturally look to them for guidance.
They actively develop the people on their team, not just manage them.

How to prepare them:

Involve them in hiring. Let them participate in interview loops beyond their own team. Teach them how to evaluate candidates holistically, not just technically. Let them shadow you in hiring committee discussions.

Expose them to cross-team coordination. Give them a project or initiative that requires working across multiple teams. Let them experience the messiness of aligning different groups with different priorities.

Include them in stakeholder conversations. Bring them to meetings with product leadership, executives, or external partners. Let them see how priorities are set and trade-offs are negotiated at higher levels.

Give them budget and resource conversations. Let them participate in headcount planning, vendor evaluations, or tooling decisions. Understanding the business and financial side of engineering is critical for EMs.

Let them mentor other TLs. If you have newer TLs, pair them with your more experienced ones. Teaching leadership is one of the best ways to deepen it.

Debrief regularly. After each new experience, sit down and talk about what they observed, what surprised them, what they'd do differently. This reflection is where the real learning happens.

8. The Transition Conversation

At some point, a TL will come to you and say: "I want to become an EM." Or you'll initiate the conversation because you see the potential. Either way, this is a critical moment that deserves care.

What to look for before supporting the transition:

Sustained performance as a TL. They should be consistently strong in their current role, not just having a good quarter.
Self-awareness. Do they understand what they're good at and where they need to grow? EMs with blind spots cause a lot of damage.
Genuine motivation. Do they want to be an EM because they love developing people and building organizations? Or because they think it's the only path to advancement? The second reason leads to unhappy EMs and unhappy teams.
Resilience. EM work is emotionally taxing. They'll deal with layoffs, performance issues, interpersonal conflicts, and organizational politics. Are they equipped for that?
Comfort letting go of technical depth. Most EM roles require stepping further back from the code. Some TLs say they want this but struggle with it in practice.

How to prepare them:

Create a deliberate development plan. Identify the three or four biggest gaps between where they are and where they need to be. Give them specific experiences and projects to close those gaps. Set a timeline — not "someday" but "here's what I want to see in the next six months."

Pair them with a current EM (not you, ideally) who can serve as a mentor. Someone who can share the unvarnished reality of the role and help them prepare.

Give them progressively more EM-like responsibilities while still in the TL role. This is a tryout, and it benefits everyone — they get to experience the work, and you get to evaluate their readiness.

When to say "not yet":

Sometimes the honest answer is that they're not ready. This is a hard conversation, but it's better than promoting someone prematurely.

Be specific: "Here's what I need to see before I can support this move." Give them a concrete development plan and a timeline to revisit. Make it clear that "not yet" isn't "never" — it's "here's what it takes."

If they push back, listen. They might have a perspective you're missing. But don't cave just to avoid discomfort. A premature promotion hurts the person, their future team, and the organization.

9. Real-World Examples

Scenario 1: The TL Who Thrived with Coaching

Priya was promoted to TL after being the strongest IC on her team. Within two months, she was drowning. She was still reviewing every pull request, attending every design session, and doing half the coding herself. Her team felt micromanaged, and she was working 60-hour weeks.

Her EM, David, noticed and started coaching. In their 1:1s, he asked questions like: "What would happen if you didn't review that PR?" and "Who else on the team could own that design decision?" He helped Priya identify which activities were truly TL-level and which she was holding onto out of habit or anxiety.

David also connected Priya with another experienced TL who had gone through the same transition. Having a peer who understood the struggle made a big difference.

Over three months, Priya gradually let go. She started delegating technical decisions, investing more time in 1:1s with her reports, and thinking strategically about the team's roadmap. Her team's velocity actually increased because engineers felt more ownership. Priya went from overwhelmed to thriving, and two years later, she became an EM herself.

Scenario 2: The TL Who Returned to IC

Marcus was a brilliant architect who was promoted to TL because of his technical vision. But the people side of leadership didn't come naturally to him. He avoided difficult conversations, struggled to give constructive feedback, and found 1:1s draining rather than energizing.

His EM, Sarah, invested heavily in coaching. They practiced difficult conversations together. Sarah recommended books and paired Marcus with a leadership coach. But after six months, Marcus was still struggling, and his team's engagement scores were declining.

Sarah had an honest conversation with Marcus: "I can see you're working hard at this, and I respect that. But I want to check in — are you enjoying this role? Is this the kind of work that energizes you?"

Marcus admitted that he missed the deep technical work. He felt guilty about it, like he was failing. Sarah reframed it: "Going back to a senior IC role isn't a demotion — it's choosing the path where you'll have the most impact and the most fulfillment."

They worked together on the transition. Marcus moved to a Staff Engineer role where he could focus on architecture and technical strategy. His replacement as TL was someone who genuinely loved the people work. Both Marcus and the team were better off. The key was that Sarah made the transition feel safe and respected, not punitive.

Scenario 3: The TL Who Grew into an EM

Jin had been a TL for eighteen months and was clearly operating above the role. He wasn't just managing his team well — he was thinking about how his team connected to the broader organization. He proactively identified cross-team dependencies, mentored newer TLs informally, and consistently asked his EM, Rachel, about the "why" behind organizational decisions.

Rachel started deliberately expanding Jin's exposure. She brought him into quarterly planning meetings. She asked him to lead a cross-team initiative to standardize the team's on-call process across three teams. She gave him a role in the next hiring panel and walked him through how headcount decisions were made.

After each experience, they debriefed. Jin reflected on what he found energizing (the cross-team influence, the strategic thinking) and what he found challenging (the political navigation, the ambiguity). Rachel helped him develop strategies for the challenging parts.

When an EM position opened up eight months later, Jin was the obvious candidate. He stepped into the role with confidence because he'd already been practicing the skills. His transition was smooth because it wasn't really a transition — it was a formalization of what he'd already been doing.

10. Common Mistakes

Micromanaging TLs. You hired or promoted them into leadership. Let them lead. If you're dictating how they run their team, what decisions they make, or how they structure their processes, you're not managing TLs — you're doing their job while paying them to watch.

Not doing skip-levels. If your only view into the team is through the TL's perspective, you have a single point of failure in your information flow. Skip-levels aren't optional. They're how you understand what's actually happening.

Inconsistent standards across teams. If your TLs have wildly different expectations for performance, process, or quality, you'll create resentment and confusion. Calibration is your responsibility.

Not investing in TL development. TLs are in one of the hardest roles in engineering — they're caught between IC work and management, often without formal training. If you're not actively coaching them, you're setting them up to struggle.

Undermining TLs publicly. The moment you override a TL's decision in front of their team, or give direction to their reports without going through them, you've damaged their authority. It might take months to repair. Handle disagreements privately. Always.

Treating all TLs the same. Different TLs have different strengths, different growth areas, and different motivations. Cookie-cutter management doesn't work. Tailor your approach.

Avoiding hard conversations. When a TL is struggling, the kindest thing you can do is address it directly. Waiting, hoping it gets better, or hinting around the issue wastes everyone's time and lets the team suffer.

Hoarding information. Your TLs can't make good decisions without context. Share the org strategy, the political landscape, the upcoming changes. Information is the raw material of good judgment, and good judgment is what you're trying to develop in your TLs.

Business Value

Why does managing TLs well matter to the business? Because it's one of the highest-leverage activities in an engineering organization.

Multiplied leadership capacity. A single EM can directly manage maybe 7-10 engineers effectively. But an EM who manages 4 TLs, each leading a team of 5-7 engineers, is effectively leading 20-30 people. That only works if those TLs are well-supported and well-developed. When they are, your leadership capacity scales dramatically.

Team scalability. Organizations grow by adding teams, not by making existing teams bigger. Every effective TL you develop is another team you can create. Every TL who struggles is a bottleneck on growth. Investing in TL development is investing in the organization's ability to scale.

Succession pipeline. What happens when an EM leaves, gets promoted, or takes on a new scope? If you've been growing your TLs, the answer is simple: one of them steps up. Without that pipeline, every EM departure creates a crisis — external hiring takes months, and parachuting in an outsider disrupts team culture and continuity.

Organizational resilience. Teams led by strong TLs are more resilient to change. They can absorb new mandates, navigate reorgs, and handle crises without falling apart. That resilience has direct business value — it means fewer dropped projects, fewer attrition spikes, and faster response to market changes.

Retention multiplier. Good TLs retain good engineers. It's that simple. People leave managers, not companies. Every TL you develop into a great leader is keeping a team's worth of engineers engaged and productive. The cost of replacing even one senior engineer — recruiting, onboarding, ramp-up time — easily justifies the investment in TL development.

The bottom line: managing TLs well isn't a nice-to-have. It's how engineering organizations scale their leadership, maintain quality, and build the bench strength needed to keep growing. Every hour you invest in your TLs pays dividends across every person they lead.

Common Pitfalls

Micromanaging TLs instead of coaching them. Dictating how TLs run their teams, what decisions they make, and how they structure processes means you are doing their job while paying them to watch. Let them lead; coach when you see gaps.
Undermining TLs publicly. Overriding a TL's decision in front of their team, or giving direction to their reports without going through them, damages their authority in ways that take months to repair. Handle disagreements privately, always.
Not doing skip-level 1:1s. Relying solely on the TL's perspective for information about team health creates a single point of failure in your information flow. Skip-levels are essential for understanding what is actually happening across your teams.
Allowing inconsistent standards across teams. When different TLs have wildly different expectations for performance, process rigor, or quality, engineers feel the unfairness acutely. Calibration across your teams is your responsibility.
Avoiding hard conversations when a TL is struggling. When a TL is underperforming, every person on their team is affected. Waiting, hoping it improves, or hinting around the issue wastes time and lets the team suffer. Address it directly with coaching, clear expectations, and honest role-fit conversations when necessary.
Hoarding information and context. Your TLs cannot make good decisions without understanding the organizational strategy, political landscape, and upcoming changes. Information is the raw material of judgment, and sharing it is how you develop capable leaders.

Key Takeaways

Managing managers is a fundamentally different skill from managing ICs. Embrace the shift from directing to coaching.
Give your TLs autonomy. Trust, verify, coach — in that order.
Skip-levels are essential, not optional. Do them regularly, do them transparently.
Calibrate across teams to ensure fairness and consistency.
Address struggles early. Coaching first, direct intervention if needed, honest role-fit conversations when necessary.
Actively develop your TLs. Some will become EMs. Some will become exceptional TLs. Both outcomes are wins.
The transition from TL to EM is significant. Prepare people deliberately, and don't rush it.

Your TLs are your force multipliers. Invest in them accordingly.