Managers & Leaders

"Manager" is a job title. Leadership is a behavior. The two overlap constantly, but they aren't the same thing — and "manager" itself splits into roles that have almost nothing in common with each other.

Try It
1

Manager vs. Leader

Management is a formal role: authority over resources, people, process, or budget, granted by the org chart. Leadership is a behavior: setting direction and moving people toward it, with or without that authority. You can hold the title and never really lead. You can lead with no title at all — anyone on a team who moves it forward is leading, whether or not "manager" is anywhere in their job description.

Management

A role, granted by the organization. Comes with formal authority over some mix of people, budget, or process — and the accountability that comes with it.

Leadership

A behavior, earned through influence. Setting direction and moving people toward it — independent of whether you have formal authority over any of them.

Mark Sanborn makes exactly this case in You Don't Need a Title to Be a Leader: the title is an org-chart fact, the leading is a daily choice, and the second one doesn't wait on the first.

2

Managers of Work vs. People Managers

"Manager" job titles split into two groups that get conflated constantly. One group owns a piece of work — scope, timeline, dependencies — and typically has no direct reports at all. The other owns people — hiring, growth, performance, comp — and is accountable for the humans regardless of what they're currently working on. Product Manager sits in the first group without quite fitting it — flagged below. (The specific titles below lean tech/product-org, since that's the shape of work this site defaults to — the underlying work-vs-people split holds in other industries too, just under different names.)

Managers of Work — usually no direct reports

Project Manager

Owns a single initiative end to end — scope, timeline, budget, risk. Drives the plan, not the people executing it.

Program Manager

Owns a group of related projects — the dependencies and risk that live between them, not inside any one of them.

Technical Program Manager

A Program Manager with deep technical fluency, usually inside engineering — close enough to the system to drive execution across teams that don't report to them.

Product Owner

i

Owns the backlog and sprint-level priorities for a single Scrum team. No direct reports — moves the team by sequencing what's next, not by deciding what the product should become.

Relationship to PM varies by org: sometimes a stepping stone toward Product Manager, sometimes a parallel, more execution-focused track. At scale, one PM can oversee several POs, each running a slice of the same larger product.

IC Product Manager

i

Owns a single domain or feature. No direct reports, and no formal authority over the engineers or designers building it — moves the team by making the case, not giving an instruction.

Not quite a peer of the first three: doesn't own the mechanics of delivery — prioritizes what gets built and drives alignment to strategy instead, through influence alone.

People Managers — formal reports, accountable for the humans

Engineering Manager

Formal reports: hiring, growth, performance, comp. Not a people-manager-only role, though — most EMs were engineers first, and stay close enough to the architecture to flag a real concern in a design review, not just unblock the work. As they rise, their systems knowledge is expected to scale right along with their people scope, not get traded away for it.

Director / VP / CTO / CPO

A people manager of people managers — Director of Engineering managing EMs on the way to CTO, Director of Product managing Product Managers on the way to CPO. The scope widens from individuals to the org, but the accountability for the humans underneath doesn't change shape, just size — and it's the one point where an IC Product Manager's career path finally becomes a people-management path too.

Watch-out

Knowing which kind of manager you are — or want to become — changes what you should actually practice. Growing as a Project or Program Manager means getting sharper at scope, dependencies, and risk. Growing as an Engineering Manager means getting better at hiring, coaching, and hard conversations without losing the technical depth that earned you the room's trust on architecture in the first place — the people skills are additive, not a replacement for the engineering judgment. Growing as a Product Manager means getting sharper at prioritization and strategic alignment — real people management doesn't enter the picture until Director. They're different jobs wearing the same job-title word, and conflating them is how a strong IC gets promoted into a people-manager role they never wanted.

Try It

Paste this into ChatGPT, Claude, or whatever AI tool you use:

Help me get clear on whether I'm built for managing work or managing people, or whether I'm actually leading without either kind of formal authority (like a Product Manager does). Ask me about my current role, what parts of it energize me versus drain me, and whether I actually want direct reports — then tell me which track (work-manager, people-manager, or influence-only) fits best and what I should develop next for it.