Job Titles
October 4, 2016 – 10:18 amJob titles don’t matter, because it’s the work that counts. But job titles matter because they get you meetings with partners, interviews for next jobs, etc. They send signals that can be useful so, conversely, life can be harder if you’re sending the wrong signal.
There’s an implicit hierarchy in American job titles. Kiwis have a different implicit hierarchy (“Managing Director”, etc.) but this post is about the American hierarchy. For the companies I work with, it is more important to signal to American companies than to signal to a Kiwi establishment. The hierarchy is a rough norm: there is variation in it between companies, but the basic shape holds.
It is:
- CEO
- CxO
- VP
- Director
- Manager
- an individual contributor who might be an “agent” or “operator” or so on.
(Big companies will have Senior and Junior VP, Director, Manager gradations as well)
There’s one big trap in nomenclature here: “Manager” implies “has an area that they oversee” which may or may not include managing people. “Director” implies has direct reports, aka is a manager (and is not a board-of-directors director). In New Zealand, “manager” carries the connotation of managing people.
So in a software-only company, the CEO does a lot of sales and visionary leadership PR and fundraising, and manages a team of CxOs (often including a COO who Gets Shit Done while CEO is out selling & fundraising). One of those is the CTO, who typically holds the future direction of the technology in her head. Reporting to the CTO is the VP of Engineering, who makes sure things are built and kept running.
The hierarchy above is for Sales, Marketing, Finance, etc. where you end up with Director > Manager > staff. Engineering teams often have a different hierarchy below VP, e.g. “Engineering Manager” being someone who leads a group. But they’ll designate individual engineers as “Lead” for a project or a team. Likewise there are Architects and Designers and whatnot as speciality roles below Manager. Engineering organisations typically define a ladder to bring clarity to that chaos.
The big philosophical question that an org chart tries to answer is “who fits with whom?”:
- Product figures out what to build, Engineering make it, Marketing tells people about it, Sales sell it, Operations keep it going, and Support keep the customer happy when Operations fail. If all goes well, info from Sales, Support, and Operations feed back into Product, informing what to build next.
- These are separate functions but each depends on the rest to do their job well.
- Companies generally have to place some functions under others in the org chart, if only to limit the number of people reporting to the CEO.
- Product sits between sales/marketing and engineering/ops, can live in either team. Product managers understand the customer and drive the requirements for & oversee software development. (Product = “build the right thing”, Engineering = “build it right”)
- Support often starts out in engineering but can end up in the customer-facing sales/mkt group because it’s relationships as much as tech.
You must be logged in to post a comment.