by Marco Massenzio

From Scrum Master to VP of Engineering: why job titles matter

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.”

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

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. And I’m now a Senior Architect at Apple.

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).

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

What’s in a Name

The reality is that title and responsibilities are tightly interwoven. And while they will obviously vary from one company to another — and vary across industries, they set the scene for the expectations you will be asked to meet (or, ideally, exceed). They dictate what kind of work leadership will call upon 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. Add 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 running my own company (developing a Waze equivalent — in 2002!) I was also a Managing Partner of 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 — which was actually more of a scrum master role, with no real authority over the team’s direction.

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 of the spectrum, they may be a very accomplished member of the engineering team, helping move things along.

Main day-to-day task:

Track and manage Jira issues and ensure they are up-to-date.

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).
as someone put it, serves as a “bridge between Sales and Engineering”

Main day-to-day task:

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

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 engineers and making sure blockers are taken care of. Engineering Managers also spend a significant amount of time coding.

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 responsibile 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.

Some 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.

Time horizon

Strategic — from several quarters to years out.

I hope this article has given you a better idea of the rich ecosystem of managers within software engineering. I also hope it has reinforced to you the importance of accurate job titles. Take them seriously!

Thanks for reading!

Originally published at codetrips.com on June 12, 2015.