When negotiating a new job, many companies treat the issue of job title with a certain amount of glibness. They seem to be saying, “We are oh-so cool and hip around here, and you are oh-so awesome. We’d do anything to have you: whatever title you want, you can have (within reason).”

This is all sounds great. Impressive-sounding titles for everyone! Until reality starts to intrude.

Over the past 20 years I’ve been a Senior Engineering Manager at Google. I’ve been a VP of Engineering at a couple of startups and Director of Engineering at a couple more. A Senior Architect at Apple. And now a Sr Principal Architect at Adobe.

As a consequence, in the last ten years I have directly hired more than 100 people in various technical functions, at various levels of seniority, for teams of all sizes.

Additionally, I’ve had decisive influence over whether to take senior executives on board (or not).

Not to mention, I have also been on the receiving end of some amazing (and many not-so-amazing) opportunities for new roles.

And I can tell you one thing for sure: your job title matters. A lot.

What’s in a Name

The reality is that job title and responsibilities are tightly interwoven. And while they will obviously vary from one company to another — and vary across industries, they do set the scene for the expectations you will be asked to meet (or, ideally, exceed).

It will determine the kind of work senior executives may ask you to undertake, and what kinds of work they won’t consider you for.

Taking on a role that does not meet your expectations, or vastly exceeds your current abilities, is oftentimes worse than negotiating the wrong salary: salary can usually be fixed one way or another, without much fuss (since your salary is only known to a handful of people).

Your job title is very public and known to anyone. Adding to this the cultural stigma of being “downgraded,” and errors related to job title are virtually unfixable.

Backstory

When she was around 5 or 6, my daughter asked me the sweetest question: “But, dad, what is it that you do for work?”

At the time, I was fund-raising for the company I had founded (developing a Waze equivalent — in 2002!), and I was also the Managing Partner for a consulting company I co-founded, where we advised companies on technical strategies related to planning, financing and deploying multi-purpose wireless networks. This didn’t quite fit the roles she was reading about at school: a fireman or teacher or plumber I wasn’t.

Many years later, I ended up having to ask myself a variant of that same question. I had just joined a then-fast-growing San Francisco startup as a “Senior Engineer” with an understanding (but, and that was my crucial mistake, not a written agreement) that, once I’d mastered the fundamentals of their technology and familiarized myself with the team, they would promote me to Director of Engineering.

Then reality intruded on that great story I was told, when they instead promoted me to Engineering Manager — much sooner than I had anticipated.

To add insult to injury, what my then boss really wanted me to be was a glorified Scrum Master, with no real authority over the team’s direction (which, due to his insecurity and addiction to micromanaging, he wasn’t prepared to let go of).

Needless to say, that story did not end well.

To help others avoid the same fate, in the following I will outline the roles and responsibilities typically associated with these titles:

Engineering Manager

Director of Engineering

VP of Engineering

Product Manager

Scrum master

At one time or another, I’ve held all of these roles, and I’ve hired and managed folks in these roles. Based on my experience, let’s dive into what each of these responsibilities ought to involve.

A Scrum Master…

supports the Scrum team in managing the various tasks, stories, and bugs in the Agile tracking systems du jour (such as Jira, Rally, Pivotal).

may double up as a Release Manager, ensuring all the critical features for the given release are being assigned and tracked.

ensures communication flow, especially around blockers and time-sensitive issues.

at one end of the spectrum, as someone else put it, can just be a “glorified admin.” At the other end, they may be a very accomplished member of the engineering team, helping move things along.

Main day-to-day task:

Track and manage backlog and Sprint issues and ensure they are up-to-date and open actions and blockers actively worked on and addressed; surface issues to the leadership, so that disagreements can be resolved in a timely manner.

Time horizon:

Very tactical. 1–2 sprints at most.

A Product Manager…

has full awareness of the product features, its positioning in the market (both with respect to customer segments’ needs and competitors’ strategic stance), and the future direction (aka roadmap).

has full responsibility over features’ relative priority, as well as their time criticality.

coordinates different sales’ and account teams’ requests across product development areas.

coordinates different engineering teams and dependencies (advisory).

serves as a “bridge between Sales and Engineering”

Main day-to-day task:

Managing the roadmap, Sprint planning and management, grooming the backlog.

Meeting with customers (existing and potential) to understand the product features gaps, and communicate the roadmap (and gather feedback).

Time horizon:

From tactical (Sprint) to strategic (up to several release, 6–12 month roadmap).

An Engineering Manager…

manages other engineers, of varied level of seniority and expertise.

has an in-depth technical understanding of (areas of) the product.

is responsible for the welfare of the engineering team, their professional development and growth, and is the primary person accountable for their job satisfaction.

deals with fine-granularity resource management (often at the individual level).

conducts hiring and firing (or, more broadly, performance management).

mainly interacts with engineers in the team, as well as other Engineering Managers, Product Managers and Scrum Masters.

as I once put it: “the human shield for the team”

Main day-to-day task:

Talking to other engineering managers and making sure blockers are taken care of.

Frequent 1/1 conversations with the team’s engineers, dealing with matters ranging from product/technical issues, to professional growth and career management.

Working with Product Managers on specific areas of the product, or ongoing projects, dealing with prioritization and resources allocation.

Engineering Managers may also spend a significant amount of time coding in smaller organizations.

Time horizon:

From tactical (never a dull day!) to Quarterly (engineers’ performance management).

An Engineering Director…

manages Engineering Managers (and possibly QA Managers, Product Managers, and Release Managers).

has a good technical understanding of the product as a whole.

has product architecture knowledge, and knows how the interactions of various teams impact it.

ensures coordination across teams and cross-functionally (such as with Sales, Product, QA).

oversees the end-to-end release management process (which includes Testing, QA, and Operations).

may have some (or all) of those functions reporting to them too (depending on size/complexity of product, team, or organization).

is responsible for the delivery of engineering practices and processes.

keeps managers accountable, and makes sure they continue their professional growth.

Main day-to-day task:

Mostly, meetings: ensuring all parts of the Engineering Organization are working at their most productive, ensuring cross-functional integrity and efficiency.

In smaller organizations they may also be involved in some high-level technical work, typically at the architectural level.

Time horizon

Medium-term strategic — typically several quarters.

A VP of Engineering…

owns the Engineering Vision, practices, and processes.

must have sound architectural understanding of the product and how it fits with other technologies/products (competing, complementary, and supporting).

may actually own the Product Architecture and actively participate in its inception and development.

is responsible for all the areas that participate in the product delivery process: Development, QA/QE, Testing, Release management. Depending on the organization, may own Product and Operations (Infrastructure), too.

is mostly focused on long-term product vision and customer/market needs.

works closely with other VPs (and the CTO/CEO) to ensure that the organization as a whole is fully aligned with the vision and the strategy.

ensures that all parts of the engineering organization operate at their best productivity and efficiency.

as far as product delivery is concerned, they are “where the buck stops.”

Main day-to-day task:

Meetings — with other VPs, customers, and C-level executives.

Coordination across teams, both “vertically” (dealing with cross-teams alignment within the engineering organization) as well as “horizontally” across the enterprise’s functions (Product, Sales, Operations).

They are also responsible for managing the overall budget (staffing) for the Engineering team; possibly owning the Public Cloud budget; as well as operational continuity of the product/services (the SRE team would be typically part of the VP’s organization too).

Time horizon

Strategic — from several quarters to years out.