The Meta-Skill of Managing Engineering Managers Effectively

The hardest transition in an engineering leader's career is not going from IC to manager. It is going from managing engineers to managing managers. The skills that made you a great engineering manager — technical guidance, detailed code review, hands-on problem solving — become liabilities when you try to apply them one level up.

When I first managed a team of five engineering managers, I made every mistake possible. I reviewed their PRs, attended their team standups, and gave technical guidance directly to their reports. Within three months, my managers felt undermined, their teams were confused about who to listen to, and I was working 70-hour weeks while accomplishing less than when I managed a single team.

The lesson took time to internalize: managing managers is a fundamentally different job that requires fundamentally different skills. It is the natural evolution once you have successfully scaled your engineering team past the size where one person can be in every room.

The Manager-of-Managers Operating Model

Your job is no longer to produce great code or even to produce great engineers. Your job is to produce great managers who produce great engineers. This requires a shift in your mental model:

┌─────────────────────────────────────────────────────────┐
│        IC Manager vs. Manager of Managers               │
├────────────────────────┬────────────────────────────────┤
│  Managing Engineers    │  Managing Managers             │
├────────────────────────┼────────────────────────────────┤
│  Review their code     │  Review their decisions        │
│  Unblock their tasks   │  Coach their problem-solving   │
│  Define their work     │  Align their priorities        │
│  Grow their skills     │  Grow their leadership         │
│  Shield from politics  │  Expose to context             │
│  Direct their effort   │  Set boundaries & outcomes     │
└────────────────────────┴────────────────────────────────┘

The fundamental shift is from doing to enabling. You are now coaching people who coach people. Every layer of indirection makes direct intervention less effective and more harmful.

The Five Failure Modes

Through coaching dozens of engineering leaders making this transition, I have identified five common failure modes:

1. The Puppeteer

You tell your managers exactly what to do, how to run their teams, and what decisions to make. Your managers become executors of your vision rather than leaders of their own. Their direct reports sense this and start going directly to you, creating a bottleneck.

The fix: State outcomes, not methods. "I need your team to reduce P1 incidents by 50% this quarter" is correct. "I need you to implement on-call rotations with 4-hour shifts and automated runbooks" is overstepping unless they asked for help.

2. The Absent Landlord

You give your managers full autonomy and check in once a month. Without guidance, teams drift in different directions. Standards diverge. One team ships daily while another has not deployed in three weeks. By the time you notice problems, they are entrenched.

The fix: Weekly 1:1s with each manager are non-negotiable. Supplement with a weekly leadership team sync where managers share context across teams. Absence is not the same as empowerment.

3. The Skip-Level Addict

You love talking to engineers. You hold regular skip-levels that turn into direction-giving sessions. Engineers start expecting answers from you instead of their manager, undermining the management layer.

The fix: Skip-levels should gather information, not give direction. If an engineer raises a concern, your response is "Have you raised this with [their manager]?" followed by coaching that manager on how to address it.

4. The Meeting Multiplier

You attend all of your managers' team meetings, architecture reviews, and sprint planning sessions. You are present everywhere but effective nowhere. Your calendar is packed and your managers cannot run their meetings authentically with you watching.

The fix: Trust the system you built. Attend your managers' team meetings quarterly at most, and only as an observer. Get updates through your managers, not through omnipresence.

5. The Technical Oracle

You remain the final technical decision-maker for every team. Architecture decisions wait for your approval. Your managers cannot develop technical judgment because you never let them exercise it.

The fix: Define a clear delegation of authority. Your managers own technical decisions within their domain. You weigh in on cross-team decisions, architectural principles, and technology bets. Everything else is theirs.

The 1:1 Framework for Managers

Your 1:1s with engineering managers should cover different ground than 1:1s with individual contributors. I use a rotating framework:

Week 1: Team Health

• How are your people doing? Who is thriving, who is struggling?
• Are there any retention risks?
• How is the team dynamic? Any interpersonal issues?
• What are you doing to develop your top performers?

Week 2: Delivery and Strategy

• Are you on track for your quarterly goals?
• What is blocking your team?
• Are there any technical decisions you are wrestling with?
• How are you managing stakeholder expectations?

Week 3: Their Development

• What leadership skills are you working on?
• Where did you struggle this week?
• What feedback have you received from your team?
• What do you want to be doing in 12 months?

Week 4: Organizational Context

• Here is what is happening at the company level...
• Here is how your team's work connects to company strategy...
• What cross-team dependencies need attention?
• What organizational changes are coming?

This rotation ensures you cover all dimensions of a manager's job without cramming everything into every meeting.

Coaching vs. Directing

The most important skill in managing managers is knowing when to coach and when to direct. The decision matrix is simple:

Situation	Approach
Manager is capable but stuck	Coach — ask questions that help them find the answer
Manager is developing a new skill	Coach with guardrails — let them try, debrief after
Crisis or urgent deadline	Direct — give clear instructions, debrief later
Manager is making a reversible mistake	Let it happen — learning from failure builds judgment
Manager is about to make an irreversible mistake	Intervene immediately — explain your reasoning

The default should be coaching. "What options have you considered?" and "What would happen if you tried X?" are almost always better than "Here is what you should do." But coaching is inappropriate when someone is about to walk off a cliff or when a production system is burning.

Calibrating Your Managers

One of your unique responsibilities is ensuring consistency across teams. Without calibration, each manager develops their own standards for hiring, performance, promotions, and technical quality. This creates fairness problems and organizational dysfunction.

Hiring calibration: Have all managers participate in each other's hiring debriefs monthly. Discuss borderline candidates together. Share interview scorecards across managers and discuss where assessments diverge.

Performance calibration: Before performance review cycles, run calibration sessions where managers present their ratings and justifications. Challenge ratings that seem inconsistent with peer teams.

Technical calibration: Establish shared architectural principles and review significant technical decisions as a leadership group. This is not about approval — it is about shared context and consistent standards.

Process calibration: Document your team's operating model explicitly. How do teams plan sprints? How do they communicate status? How do they handle on-call? Consistent process reduces cognitive load when engineers move between teams.

Developing Your Managers into Leaders

Your long-term leverage comes from developing your managers into independent leaders who can eventually replace you. This means progressively expanding their scope:

Year 1 (New Manager): Own team execution. Make decisions within their domain. Develop their direct reports. Handle routine escalations.

Year 2 (Established Manager): Own cross-team initiatives. Represent their domain in company-level discussions. Mentor other managers. Drive technical strategy for their area.

Year 3 (Senior Manager / Director-ready): Own organizational outcomes. Drive engineering-wide initiatives. Handle executive-level stakeholder management. Make staffing and budget decisions.

At each stage, you are explicitly expanding the boundary of their authority and reducing your involvement. If your managers cannot operate effectively without you for two weeks, you have not developed them enough.

The Information Flow Problem

The biggest challenge managing managers is information asymmetry. You are further from the ground truth. Engineers will not escalate concerns to you. Problems get filtered through your managers' perspective. You need intentional systems to maintain awareness:

• Quarterly skip-level conversations (listening, not directing)
• Engineering satisfaction surveys with team-level breakdowns
• Metrics dashboards that show team health indicators (velocity trends, incident rates, PR cycle time)
• Informal touchpoints — lunch with different teams, attending a demo day, being present in engineering channels

The goal is not to bypass your managers. It is to have enough context to know when something needs your attention and enough trust in your managers to handle everything else.

Key Takeaways

Managing managers is a distinct skill set that requires deliberate development:

• Shift from doing to enabling — your job is to produce great managers, not great code
• Avoid the five failure modes: puppeteer, absent landlord, skip-level addict, meeting multiplier, technical oracle
• Use a rotating 1:1 framework that covers team health, delivery, development, and context — see 1:1 meetings that develop engineers into leaders for the tactical framework
• Default to coaching over directing — let managers develop judgment through experience
• Calibrate across teams on hiring, performance, technical quality, and process
• Develop your managers along a clear progression from team execution to organizational leadership
• Build information systems that give you awareness without bypassing your managers

The measure of your success is not how well your teams perform when you are present. It is how well they perform when you are not.