With over two decades of experience in technology-driven organizations, I’ve consistently observed that most companies regardless of industry tend to develop multiple layers of management across their business lines. However, in smaller organizations with fewer than 300 employees or less, these layers often flatten. It’s uncommon to see long tenured leaders managing many managers in such settings. Instead, leaders in smaller companies frequently take a hands-on approach writing code, building prototypes, or spending hours alongside junior engineers to solve technical challenges, regardless of the seniority of their title. They often balance both technical and people management responsibilities. In contrast, in large public organizations like major banks or fintech enterprises, the higher one moves in the hierarchy, the less direct interaction they tend to have with employees several levels below. These differences inspired me to reflect on and write about one particular role that embodies this shift the manager of managers.

Large organization often have multiple levels individual contributors (ICs, engineers, testers, designers), then first‐line managers (engineering managers, team leads) who directly supervise those ICs, and above them, managers of those managers (senior engineering managers, directors, portfolio leads). The manager of managers(MoM) is the role that sits above one or more first‐line managers, and often has responsibility for multiple teams, engineering managers, or product streams.

Why do we need managers of managers ?

Here are some of the core reasons:

Span and Complexity
As the organization grows, a senior leader cannot directly manage each individual engineer that span becomes too large and becomes ineffective. Manager of managers reduces span of control by delegating direct supervision to first‐line managers. The concept of span of control explains how many direct reports a manager can meaningfully lead.

    Example: Suppose you have 8 teams of 8–12 engineers each (≈ 80–100 engineers). It would be unmanageable for a single manager to meet with each of those 80 engineers weekly and maintain quality coaching. Instead, you have 8 team leads (engineering managers) each managing ~10 engineers, and one senior engineering manager above them coordinating across teams, aligning strategy, budgeting, resource allocation, and so on.

    Strategy to execution alignment
    The manager of managers links strategic goals (from senior leadership) to the execution of multiple teams. They translate higher-level objectives into team-level targets, ensure cross-team coordination, manage dependencies, remove impediments that span team boundaries, and allocate resources between teams. They serve as a bridge between tactical work (by the teams) and macro-organizational objectives.

    Example: The company decides to improve latency of a core service by 50 %. Teams A and B are responsible respectively for frontend and backend. The manager of managers works with both engineering managers to ensure their plans align, dependencies are identified (e.g., data model changes), and that the execution schedules sync.

    Consistency, standardization, process, and culture
    As you scale engineering, you need standard engineering practices, consistent processes (e.g., code reviews, CI/CD pipelines, deployment standards, quality metrics), architectural coherence, and a shared culture. This is often beyond the purview of a single team lead and requires oversight at the managerial layer above. Manager of managers ensures there is a coherent engineering function rather than dozens of siloed teams doing their own thing.

    Developing managers and leadership pipeline
    The manager of managers plays a key role in developing the engineering managers coaching them, helping them grow, providing leadership development, helping them build the right kind of team culture, helping them manage up and down. Without that layer, managers may end up isolated or repeating mistakes.

    • Handling cross‐team issues and scaling blockers
      Many blockers in larger engineering orgs are cross‐team architectural decisions, platform choices, shared services, infrastructure, operations, organizational dynamics, budgeting, priority conflicts, resource tradeoffs, etc. Manager of managers is positioned to handle these broader issues. They can elevate issues to senior leadership or work across peers to resolve them.

    Problems they solve :-

    • Overload of individual contributor management: If a senior leader tried to manage all engineers directly, they’d be overwhelmed with 1:1s, escalations, personal development, performance reviews. The manager of managers alleviates this.
    • Tactical focus misalignment: Without that middle managerial layer, senior leaders risk focusing too much on day-to-day rather than strategic view, and teams may drift in inconsistent directions.
    • Knowledge silos and duplicate efforts: The senior manager of managers helps coordinate across teams, reduce duplication, enforce shared infrastructure, and spread best practices.
    • Poor feedback flows / information bottlenecks: The manager of managers helps propagate information up and down, ensures leadership hears what’s happening on the ground, and ensures the ground hears what leadership expects.
    • Weak leadership development: Without managers of managers, team leads may lack mentorship, miss leadership capability growth, and the organization may struggle to scale People/Leadership maturity.

    Strengths of the manager of managers role

    • Scale of impact: Manager of managers can influence dozens or hundreds of engineers (via the managers) rather than a single team. Their decisions and actions ripple across the org.
    • Broader perspective: They see across teams, understand broader dependencies and systemic issues, and can optimize at the team of teams level.
    • Leadership leverage: Their time is spent more on coaching and leadership rather than purely delivery tasks. they elevate managers, enabling the organization to be stronger overall.
    • Strategic alignment: They can ensure strategic objectives are embedded into team plans and that teams are working toward common goals.
    • Culture steward: They have the ability to influence engineering culture at scale e.g., standardizing practices, improving quality, impacting morale, removing toxic behaviors.

    Weaknesses / potential pitfalls

    • Distance from the work: As you climb up the hierarchy, you get further from the day-to-day work. There is risk of being out of touch with what engineers actually do or feel, leading to decisions that don’t match reality.
    • Information distortion: With multiple layers, information may become filtered or sanitized; the manager of managers may rely heavily on inputs from their direct reports (engineering managers) and may miss what’s really going on.
    • Loss of agility: Having more layers can slow decision-making, increase bureaucracy, and reduce responsiveness. The middle layer may become gatekeeping rather than enabling.
    • Leadership vs. delivery tension: The manager of managers may get pulled into delivery or project tasks instead of maintaining leadership duties, thereby diluting their leverage. They might micromanage managers or teams, undermining them.
    • Over-control or under-visibility: If a manager of managers intervenes too heavily, they risk undermining the autonomy of the engineering managers. If they intervene too little, they risk being invisible and losing influence.
    • Burnout risk: They have to juggle many stakeholders, both upwards (senior leadership) and downwards (engineering managers and teams), while dealing with cross-team issues; the role can be high pressure.

    Example –

    You are Senior Engineering Manager overseeing three engineering managers (A, B, C), each with a team of 10 engineers working on micro-services. The organization’s goal for the quarter is to reduce service outages by 40%. As the manager of managers, your duties include:

    • Working with A/B/C to ensure each team aligns a plan to improve resilience (e.g., automated chaos testing, better monitoring, faster rollback).
    • Reviewing cross-team dependencies (e.g., shared service used by A and  C’s teams) and negotiating resource allocations.
    • Coaching A/B/C on how to lead their teams, manage risk, escalate effectively, build reliability culture.
    • Holding skip‐level meetings (more on that later) with engineers in their teams to sense morale, culture, bottlenecks.
    • Reporting up to the leadership about progress, risk, and resourcing, while translating senior leadership strategy into team-level objectives.

    In doing so, you will ensure that the engineering organization doesn’t devolve into siloed teams but moves together.

    Skip-Level Meetings

    Now let’s dive into the practice of skip-level meetings what they are, why they’re important (especially for managers of managers), how to run them, their benefits, pitfalls, whom to invite, and best practices.

    What are skip-level meetings?

    Skip-level meeting is typically a 1:1 (or small group) meeting between a manager and an employee who reports not to them directly, but via one intermediate managerial layer. For example, a director meets with an individual contributor whose direct manager they supervise. These meetings “skip” the manager in between.

    Skip-level meetings are typically semi-frequent meetings between staff who have a layer in the org‐chart separating them. Skip‐level meeting is a meeting where you, as a manager, meet one‐on‐one with the direct report of a manager who you manage.

    Who needs to hold skip-level meetings ?

    • Managers of managers (senior engineering managers, directors) who want visibility into what their teams are experiencing.
    • Leaders who want to build trust and relationships beyond their direct reports.
    • Organizations that are scaling and need to maintain connection between senior leadership and individual contributors.
    • First-line managers may invite the next level down for broader cross-team discussion, but the core value is when leadership meets leaf nodes of the organization.

    Why do skip-level meetings matter / what problems do they solve ?

    1. Break down the “good-news cocoon” / “ivory tower”
      Senior leaders can become insulated and only hear filtered, positive information. Skip‐level meetings give access to raw, unfiltered feedback from the people who do the work.

    Example: Engineer may have frustration with a process bottleneck that their manager doesn’t raise upward in a skip‐level meeting, the senior manager hears it and can act.

    • Build rapport and trust
      ICs feel seen and valued when senior leaders make time for them. They perceive that leadership cares beyond just the manager.

    Example: Engineer might feel their career progression is only seen by their manager. Skip meeting makes them feel their voice is heard further up.

    • Improve communication and alignment
      Senior leaders can share vision, strategy, and context directly to the people doing the work, reducing misalignment and we don’t know why we’re doing this.

    Example: Senior engineering manager can explain why reliability is a priority this quarter, so engineers in each team understand not just what but why.

    • Detect emerging issues early
      Because you engage people further downstream, you can pick up morale issues, hidden blockers, manager performance problems, cross‐team friction, or other soft signals before they become big issues

    Example: Several engineers mention repeated miscommunication in one team; senior leader hears this and coaches the team lead.

    • Develop leadership visibility and pipeline
      It gives senior leaders insight into up-and-coming talent, and for employees to see leadership beyond their manager (important for their growth).

    Example: Senior manager spots an engineer consistently raising smart suggestions in skip‐level and later sponsors them for a leadership development program.

    How to do skip-level meetings when you are a manager of managers

    Here are the steps and guidelines for doing it :-

    1. Set intention and communicate it
      1. Tell your direct reports (the managers) you plan to hold skip‐level meetings. Frame it as support rather than monitoring them.
      1. Tell the employees you’ll meet with what the purpose is getting to know them, hearing what’s going on, improving collaboration, not undermining their manager.

    Example invite :-

    “Hi Team, I’d like to set up a skip‐level conversation so we can talk about what’s going well, any challenges, and how you’re experiencing the organization. Your manager knows this is happening. I’m looking forward to connecting.”

    • Decide frequency / cadence
      • You can’t meet with everyone very often. For many teams, quarterly or bi-monthly is a reasonable interval.
      • Prioritize based on key teams, high changes, or high-risk groups.

    Example: If you manage 100 engineers including contractors via 10 managers, you might aim to meet every engineer at least once every month, or rotate more often for critical teams.

    • Prepare an agenda, but keep it flexible
      • Have open‐ended questions:- What’s going well ?, What’s getting in your way ?, What questions do you have for me or the organization ? , What support do you feel you’re missing ? .
      • But leave space for the employee to raise what matters to them. Some senior leaders prefer no strict agenda to make it less formal.

    Example agenda :-

    • Intro / check-in (5 min)
      • What’s been working well in your team (10 min)
      • What are the blockers you’re seeing (10 min)
      • How aligned do you feel with the broader company/vision (5 min)
      • Any questions for me (5 min)
      • Wrap up and next steps (5 min)
    • Invite the right people
      • Typically,  the senior leader (you) + the individual contributor (IC).
      • Sometimes: small group of 2-3 ICs (to share perspectives) rather than individual.
      • Do not regularly include the manager in between (unless part of a special meeting) the whole point is the skip level. However, the manager should be aware in advance.

    Example:- For your team you might schedule one skip‐level per week, alternating between different team leads’ teams.

    • During the meeting best practices
      • Build rapport, start with non-work chat, ask about how they’re doing, what recent wins they’ve had.
      • Listen more than you talk. These sessions are for them.
      • Ask about their view of their manager ‘What’s your manager doing well ? Is anything missing? ‘ (Careful to not undermine)
      • Ask about team culture, blockers, cross-team dependencies, career aspirations, alignment with company strategy.
      • Reassure confidentiality, emphasize you are not coming to judge them or their manager, but to support.
      • Note do not make major decisions on the spot that bypass the manager. Avoid undermining the chain of command.
    • Follow up and close the loop
      • After the meeting, send a short note ‘Thanks for our conversation, I’ll follow up on …’
      • Where appropriate, share aggregated/anonymous feedback with the manager in your 1-1 with them, or share positive feedback with the manager (so manager knows their report gave praise).
      • Track themes over time. Use what you hear to identify systemic issues, managers needing support, cross-team blockers.
      • Set next meeting or check-in.

    What types of folks do you invite on skip-level meetings ?

    • Individual contributors (engineers, QA, designers) who report to your direct reports (the engineering managers).
    • In some cases, team leads or senior ICs who are key to cross‐team initiatives.
    • High potential staff you want to develop or connect with leadership.
    • Teams undergoing change, or where you sense risk (e.g., high turnover, morale issues).
    •  You typically do not invite every manager’s manager directly (unless the structure is shallow). The idea is skipping one layer, not multiple.

    Why does having skip level meetings help and what problems does it solve?

    Let’s summarize the benefits a bit more with examples:

    • Visibility of reality: Suppose you receive quarterly updates from engineering managers and everything seems on track. But in skip-level meetings you learn that engineers are frustrated with slow build times, and morale is low. You can intervene earlier, coach the manager or look into infrastructure investment.
    • Trust and retention: An engineer who feels they are just a number may become disengaged. When they meet a senior leader, they feel seen, heard, and connected. That reduces risk of attrition.
    • Manager development :-  By hearing feedback directly from their reports (via you), you can coach the engineering manager ‘Several of your engineers would like more clarity on team goals.’ You support your manager rather than throwing them under the bus.
    • Cross‐team improvement: You might discover that Team A is reinventing a tool Team B already built. With skip-level meetings, engineers raise this, you coordinate across managers, avoid duplication.
    • Culture and alignment: You reinforce that “leadership is accessible,” that feedback matters, and that the chain of communication is not rigid. That helps build a healthier engineering culture.
    • Strategic messaging: You can reinforce broader strategy (“Here’s how your work fits into company goals”), which may not come through via direct manager.

    Problems / pitfalls of skip level meetings

    • If done poorly they can undermine the manager in between (making them feel bypassed).
    • If employees see them as surveillance they may be guarded and not share openly.
    • They require time, and if you meet too often you risk diminishing the value or interfering with manager‐IC relationships.
    • If you show up infrequently or don’t follow up, they may feel superficial and reduce trust.
    • If you use skip‐level meetings as a blame or catch exercise, morale may suffer.

    Example scenario of skip level meeting in software engineering

    You are Senior Engineering Manager “Alice” who oversees engineering managers Bob (Team X), Carol (Team Y) and Dan (Team Z). Alice schedules monthly skip‐level meetings rotating among engineers across the 3 teams.

    Meeting example: Alice meets with “Eve,” an IC on Team Y.

    • Introduction: “Hi Eve – how are things going? What’s one highlight from your last sprint?”
    • She asks: “What’s working really well in your team?” Eve says: “Our sprint cadence is smooth; our retrospectives are improving.”
    • She asks: “What’s getting in your way?” Eve says: “The build pipeline is slow, causing rework; our manager escalated it but it’s still a blocker.”
    • She asks: “Do you feel aligned with the company’s priority about reliability this quarter?” Eve says: “Not fully, I had to ask my manager; a lot of us don’t see how our work directly contributes to it.”
    • She asks: “What could I or the org do to help you?” Eve says: “More transparency about dependencies, maybe a cross‐team forum.”
    • They agree on next steps: Alice will talk with Carol and infrastructure team to review build pipeline. Alice will also share alignment message about reliability in the next all‐hands.
    • After the meeting: Alice sends a short note to Eve: “Thanks for your time – I’ll follow up on the pipeline with Carol & infra team; I’ll also brief you on next steps in our next meeting.”
    • Alice also in her next 1-1 with Carol says: “In my skip‐level with Eve I heard build pipeline delays can we take this on?” She frames it as “I heard a recurring issue across multiple engineers.”
      This sequence helps surface a problem (pipeline delay) that might not have come up in other forums, reinforces alignment, supports the manager and improves the organization.

    Bringing it together Manager of Managers + Skip Levels in Your Professional Life

    Here’s how this applies for someone looking into transitioning to this role

    Transition from Engineer Engineering Manager Manager of Managers

    • At the individual contributor (IC) level success was about delivery, code quality, technical leadership.
    • As a manager we focus on your team, hiring, mentoring engineers, sprint execution, backlog, team culture etc.
    • As we move toward director or senior manager (managing managers), impact has to scale we now care about multiple teams, cross‐team dependencies, engineering metrics (quality, cycle time, reliability), strategic alignment, manager capability.

    Key learnings

    1. Delegation and leverage: You cannot be in the weeds of every team’s daily delivery. You must empower your engineering managers, set clear objectives, remove roadblocks, and enable them while you hold the vision and orchestration across teams.
    2. Frameworks and culture at scale: Because you’ve seen many projects and technologies, you can now build processes, practices, engineering standards across teams enabling replication of success and avoiding repetition of past mistakes.
    3. Skip-level meetings as a tool: When you reach this layer, skip level meetings become critical. They help you hear what your engineering managers may filter out, sense morale, culture, and system issues early. They also help your managers by building transparency: your engineers know you care. For your personal brand, it shows you’re accessible and invest in people.
    4. Identifying emerging leaders: With skip levels you can spot engineers who are future managers or architects, and invest in their growth early helping your leadership pipeline.
    5. Balancing strategy & execution: You’ll spend less time in trenches, your job becomes more about enabling, aligning, removing impediments, and setting direction. You’ll operate at a team-of-teams level. Recognizing this shift is a key professional development step.

    Strengths you bring and how to maximize them

    • Your deep technical experience gives you credibility with both ICs and managers. Leverage that to coach managers and build trust.
    • Your experience in digital automation/group-based work (RPA, BPM, value streams etc.) means you’re familiar with cross-team value streams which is perfect for a manager of managers context.
    • Your mentoring background (you already have mentees) positions you well to develop managers, which is one of the key strengths expected in a manager of managers role.

    Weaknesses to guard against

    • Because you’re used to deep involvement, you might find it hard to let go of tactical detail or delivery tasks. You’ll need to shift mindset from I do to I enable .
    • Risk of being pulled into many meetings and losing strategic time, as a manager of managers you must guard your calendar, set clear boundaries, and ensure your role doesn’t turn into over-manager or bottleneck.
    • Risk of distance from the work- As you move higher you may lose the feeling of daily team life skip levels help mitigate this, but you need to make it a habit.
    • Information overload / filter distortion -You rely on your engineering managers summaries and your skip­-level efforts , ensure you use varied channels, data, and skip level feedback to triangulate reality.

    How this affects your personal & professional life

    • Personal development: Mastering the manager-of-managers role is a major career shift. It means focusing more on people, leadership, cross-team collaboration and less on writing code or designing modules. It’s more about influence than direct output. You’ll need to develop new skills, strategic thinking, system-level leadership, coaching leaders, far fewer hero mode moments, more help others be heroes.
    • Professional impact: You’ll be able to impact the engineering organization at scale through improved quality, reduced time-to-market, better cross-team synergy, improved retention and culture. Your role becomes a multiplier of value.
    • Work life balance: Because your role changes, you might find fewer deliverable milestones and more ongoing leadership expectations. It may require disciplined time management, focus on transitions and boundaries.
    • Legacy and growth: In mentoring managers and designing systems, you build not just features but organizational capability. The skip level meetings help you stay grounded and ensure your leadership remains relevant.
    • Connection and satisfaction: Rather than focusing solely on immediate deliverables, you’ll get satisfaction from seeing teams perform, seeing leaders you developed succeed, seeing patterns you unlock across teams. The deep connection with engineers via skip levels also keeps you connected to why you got into engineering in the first place.

    Posted in

    Leave a comment