Who Is the Engineering Manager, Really?

In India, "Manager" is one of the most overloaded titles in tech.

I've sat in interview panels where a candidate introduced themselves as a "Senior Manager" and I still had no idea what they actually did. I've worked with Project Managers who had 200 direct reports on paper and zero accountability for anything. I've seen Engineering Managers who were really Delivery Managers with a better salary, and Product Managers who were really Business Analysts with a better title.

If you're confused about what an Engineering Manager actually is — especially in the Indian IT industry — you're not alone. You're just paying attention.

This is the first part of a six-part playbook for engineering leaders navigating the AI transition. Before we can talk about how to lead teams through the AI era, we need to establish what we're even talking about. So let's start at the beginning.

The Manager Alphabet Soup

Walk into any mid-sized Indian IT company and you'll encounter this list of titles. Most of them say "Manager." None of them mean the same thing.

• EM — Engineering Manager
• PjM — Project Manager
• PgM — Program Manager
• PdM — Product Manager
• PO — Product Owner
• DM — Delivery Manager
• SM — Scrum Master
• TL — Team Lead / Tech Lead
• BA — Business Analyst
• TPM — Technical Program Manager
• AM — Account Manager
• EM (again) — Engagement Manager
• PM (again) — Practice Manager / Portfolio Manager / People Manager

That's before we even get to Senior, Associate, and Assistant variations. Or the beloved Indian IT services ladder: SE → SSE → TL → STL → PL → PM → SPM → DM → SDM → AVP → VP, where "M" shows up three different times with three different meanings.

No wonder people are confused.

Why This Is Worse in India

Every country has title inflation. The services industry heritage makes it particularly acute in India. Three reasons:

1. Titles got used for compensation, not clarity.

In traditional Indian IT services, the ladder was designed to give people a promotion every 18-24 months to keep them from leaving. The problem: the company didn't actually need fifteen different roles between "developer" and "VP." So titles proliferated to justify the steps. A "Manager" in year 7 wasn't necessarily managing anything — it was just the next rung on the ladder.

2. Hierarchy matters more than function.

In many Indian workplaces, "what's your title?" is the first question, and it determines who speaks first in meetings. This creates pressure to give impressive-sounding titles even when the role doesn't match. "Senior Project Manager" sounds authoritative in a client meeting. "Delivery Coordinator" doesn't. So the title drifts upward even when the job doesn't.

3. Product companies imported US titles. Services companies kept old ones. Now we have both.

A Bangalore office might have an Engineering Manager (imported from product-world) sitting next to a Project Manager (from services-world), and no one is quite sure who does what. When those roles interact with Delivery Managers, Account Managers, and Scrum Masters, it becomes a game of organizational Tetris.

The result: engineers don't know whose feedback matters. Managers don't know what they're accountable for. Leadership doesn't know who to hold responsible. Everyone is busy, no one is clear.

We need a better map.

The 3-Lane Model

Here's the framework I use to clarify who does what. I call it the 3-Lane Model because every manager title in tech fits into one of three lanes. Your role determines your lane. Your lane determines your work.

Lane 1: People

The People Lane is about humans: hiring them, growing them, retaining them, letting them go when needed, and making sure they're set up to succeed.

Titles in this lane:

• Engineering Manager
• Director of Engineering
• VP Engineering
• CTO (at smaller companies)

The core accountability is team health and individual growth. An EM's quarterly review is judged on: did you hire the right people? Are they growing? Are you losing the best ones? Do they trust you enough to give honest feedback?

People Lane managers usually have direct reports. They own career conversations, performance reviews, comp discussions, and the uncomfortable call when someone isn't working out.

Lane 2: Process

The Process Lane is about execution: turning plans into outcomes. Timelines, dependencies, risk, status, coordination.

Titles in this lane:

• Project Manager
• Program Manager
• Delivery Manager
• Scrum Master
• Agile Coach
• PMO / Project Coordinator

The core accountability is delivery against plan. A PM's review is judged on: did the project ship on time? Was scope managed? Were risks communicated early? Did stakeholders have what they needed?

Process Lane managers rarely have direct reports (Scrum Masters especially don't). They influence without authority, which is harder than it sounds.

Lane 3: Product

The Product Lane is about what gets built and why. User needs, market opportunities, trade-offs between features, business outcomes.

Titles in this lane:

• Product Manager
• Product Owner
• Business Analyst
• Product Analyst
• Systems Analyst

The core accountability is business outcomes through the right product decisions. A PM's review is judged on: did users adopt what you built? Did it move the metrics? Were you right about what to build next?

Product Lane managers usually don't own the team directly. They own the roadmap, the priorities, and the "why."

The Cross-Cutting Roles

Some titles don't fit cleanly into one lane because they sit at intersections:

• Technical Program Manager (TPM): Process + deep technical understanding. Sits between Engineering and Process lanes.
• Account Manager: Revenue + client relationships. Business side, usually separate from engineering.
• Engagement Manager: Delivery + client relationships in services firms. Process lane with Account overtones.
• Practice Manager / Head of Practice: Technical depth + people management for a specific technology area. People lane with strong technical roots.

The Common Mistake

The mistake most Indian IT companies make is trying to squeeze one person into two or three lanes at once.

The "Delivery Manager who is also an Engineering Manager who occasionally owns the product roadmap" is a real title I've seen. It doesn't work. Each lane has different skills, different success metrics, and different time horizons. Doing two lanes badly is worse than doing one lane well.

If your current role spans multiple lanes, that's not a sign you're a rockstar. It's a sign your organization hasn't thought hard enough about structure.

So What Is an Engineering Manager, Specifically?

Now that we have the model, we can answer the question precisely.

An Engineering Manager lives in the People Lane.

The real job, stripped to its essence:

1. Hire well. The single highest-leverage thing you do. Everything downstream is easier with the right people and harder without them.
2. Grow your team. 1:1s, feedback, career conversations, stretch opportunities. Not monthly. Weekly.
3. Unblock. Remove friction so your engineers can do their best work. This is the invisible majority of the job.
4. Retain. Keep the top 20% of your team by understanding what each of them wants next and helping them get there.
5. Make judgment calls. When to ship, when to refactor, whether a design is good enough, whether a candidate is strong enough. You're the fallback for every ambiguous technical-people question.
6. Shield and amplify. Absorb organizational noise so your team can focus. Amplify their work to the rest of the company.

Notice what's not on the list:

• Running standups (that's a Scrum Master)
• Writing status reports (that's a PjM)
• Defining the product roadmap (that's a PdM)
• Tracking dependencies across teams (that's a PgM or TPM)

If your EM job is 70% these things, you're not really an EM. You're a Delivery Manager with an EM title. That's fine, but be clear about it — especially in your own head.

Why EM Is the Safest Role in the AI Era

Here's the closing argument and the reason this entire playbook exists.

Every role in tech is being affected by AI. But the roles being hit hardest are the ones where work is documented, repeatable, and pattern-based. Manual QA. Junior coding. Technical writing. Status reporting. Basic business analysis.

The People Lane is structurally harder to automate:

• Hiring requires reading people in real time. AI can screen resumes, but it can't tell you whether this candidate will mesh with your team.
• 1:1s require psychological safety. You can't delegate someone's career conversation to an agent.
• Unblocking requires political awareness. "This ticket is stuck because the platform team doesn't like our PM" isn't a problem AI solves.
• Judgment calls require context AI doesn't have. When to ship a feature with known bugs because the customer deal depends on it.
• Difficult conversations require courage. "Your work isn't meeting the bar" is a conversation every AI model politely avoids.

This doesn't mean EMs are untouchable. The EMs who thrive will be the ones who use AI to eliminate their own administrative drag — so they can spend more time on the work that actually needs a human. Running fewer standups. Writing fewer status docs. Spending more time on growth conversations and hiring.

The EM role isn't shrinking. It's becoming more essential. The question is whether you're ready to lead your team through the transition — which is what the rest of this playbook is about.

Role Clarity Worksheet

Before you read Part 2, try this exercise.

Take your last two weeks of work. List the top 10 activities that consumed the most time. For each one, assign it to a lane:

• People — hiring, 1:1s, feedback, coaching, performance reviews, team design
• Process — standups, status reports, dependency tracking, scope management, timelines
• Product — roadmap decisions, customer research, prioritization, market analysis
• Technical — code review, architecture, debugging, technical research

Now count. How much of your time went to each lane?

If you're supposed to be an Engineering Manager and less than 50% of your time is in the People Lane, you're in a role-title mismatch. That's diagnostic information. It doesn't mean you need to quit — it means you need to either reshape the role, accept the actual role, or negotiate clarity with your manager.

You can't lead your team through AI if you're confused about your own role. Start there.

What's Next in the Playbook

The next five parts of this series build on this foundation:

• Part 2 — The 5P Framework: How to evaluate AI tools for your team without getting sold by vendors.
• Part 3 — Rolling Out AI: Change management for skeptical teams. Real scripts, real pilots, real outcomes.
• Part 4 — Measuring AI ROI: Metrics that actually matter. Why "hours saved" is the wrong number and what to measure instead.
• Part 5 — Hiring in the AI Era: The interview questions that separate AI-ready engineers from everyone else.
• Part 6 — Your Career as an EM: Where engineering leadership is going in 2027-2030, and how to position yourself.

If this framing is useful, subscribe to the playbook to get notified when new parts publish. If you disagree with any of it, tell me why — feedback from real engineering managers is what makes this playbook useful.

Now go look at your calendar. Start counting.