Tech Job Titles

One of the most common questions I get on career panels, mentoring or coaching sessions and after talks is to explain what my job, my role actually is. There is no easy answer, because it requires an understanding of the complex dependencies of roles in "Tech" (for lack of a better word, information technology product) firms.

Information Systems, Computer Science or Design Thinking courses or books for career starters typically focus on explaining the Software Engineer (SWE) job, sometimes the Product Manager (PM) and partially process-specific rituals and roles (e.g. in Scrum the Product Owner). But rarely do they mention the difference between performing the SWE role in non-tech industry (for lack of a better word - firms or public entities that primarily exist due to non-tech “hardware” products even though they might claim to "digitalize" afraid of disruption), in consulting (firms that provide services, usually to the former, to "digitalize") and tech (firms that sell “software” products and services to gain an advantage with speeding up "digitalization"), and within tech between startups and established firms. I've never seen any mention tech-adjacent roles that might have "engineer' in their title but are not SWEs.

With recent hypergrowth, a lot has been published on "upwards"* career management and manager roles in Tech. But I haven’t seen a good resource on the continued blending of these archetypes and roles and responsibilities - with a list of observations and this article as background reading I'm trying to do so. Maybe later I’ll do a variation for non-tech industry companies and consulting firms.

tl;dr I've created a GitHub repo "awesome-tech-roles" modeled after the "Awesome Lists" with the goal of showing typical clusters of tech-adjacent roles and references to good articles that illustrate the variety within the roles - for career starters in the tech industry. The links are examples, observations, not endorsements of my personal view. Given the bias towards SWE and PM roles I've tried to keep roughly the same number of references per role cluster and focus on established tech firms.

Let me explain how I structured the observations going into the list, and by doing so trying to build a framework for career starters to navigate the different roles they might see - or get offered. To make this easy to read I'm going to break it down into a few principles / assumptions / axioms / catchphrases.

1. The product is less important than how people use it

Design Thinking courses often get very handwavey when it comes to turning a prototype into an evolving product. And engineering courses often pretend the best engineering makes the best product. But adoption is not guaranteed by perfection or brilliance in either, rather the interplay of them and user empathy..

Good engineering allows flexibility and fast learning (iterations, experimentations) not only on solutions but on problems and the mapping between. And a consistent, easy to grasp model telling a story that makes complexity understandable - to the point of appearing like simplicity (not magic). A good example are the swath of new products making common tools simpler yet more collaborative, for instance Slack, Figma or Notion to name a few. For that you need analysts, designers, even project managers, and yes, consultants and engineers working directly with customers. Even if it's just for the sake of keeping engineers (SWEs) happy and focused on core work, yet everyone feeling included in the product success. However, that’s also why the list limits articles on PM and SWE resources, as engineering culture is a vast, different area with many Awesome lists, frameworks, levels, university courses and career advisory.

Hence, the list only separates 3 main areas: Product, Operations and Customer-facing. There is no separation between “business” or “design” and “IT” like in most non-tech enterprises. For sake of simplicity we assume it’s mainly tech where the product is lean, with vertically integrated feature- or service teams. One could even argue operations should be part of Product, which it absolutely should, I just listed it separately because the functions listed are consolidated across many services and products.

2. User success is your success

For the longest time, IT has been treated by non-tech companies as a fixed asset (capital expenditure) and cost center, typically outsourced to services companies. Recently this has changed to an enabler view - where IT is seen as operating expenditure to create more or faster value. Often this is referred to as “digitalization”. Ideally this would have changed the default commercial model to “pay-as-you-go” services, checking for return on invest continuously. In the old world, tech firms were driven by strict, fixed, annual licenses, basically still throwing a CD over the fence to the customer. Today, customers understand services and expect IT to grow and move with their “lean” business dynamically, offering a portfolio of digital services with pricing on consumption. Tech companies with a consumer background are used to this flexibility and therefore thrive while traditional companies want to learn from them (until very recently).

This “agile” model can be a blessing or a curse (see No. 4 below), but it changes the role of services and tech firms from vendors or outsourcers to closer integrated co-innovators. Hence a surge in “value add” consulting services, often based on open source software. The trick is to avoid the IBM trap, turning a product company into a no-asset pure transaction business, which could become a race to the bottom. Contrast this with the Customer Success role in pay-as-you-go tech firms which helps non-tech companies use the best and most efficient services for their business goal, almost like a management consulting function - these days sometimes sales account managers are called success managers and incentivized via long term consumption as well. On the other hand, consulting and design companies try to build product focus and avoid becoming outsourcers by aligning to the business vision and actually building (prototypes).Hence, the list doesn’t talk about “sales” of a fixed asset but assumes the product drives consumption, often starting with a free tier. Deeper commitments to the products (see No. 4 below) without lock-in require a variety of customer-facing expert roles along the lifecycle of service usage.

3. Teams learn through iteration, expertise comes from experimentation, and manager is not a promotion

Dogfood is a common technique in tech firms, using their own products to gain fast insights from experiments and improve accordingly. That’s a common differentiator to non-tech firms with long development cycles or simply products not everyone can use, so they have to rely on market research alone. In other words: Tech companies have iteration and expertise from experimentation with uncertainty a.k.a growth built into their company culture, which makes it hard to compare roles from tech and non-tech firms. Outsourcing of core functions for instance is ideally for startups in incubation but sadly more often a sign a tech company is not product focused anymore or wants to drive down cost at the expense of innovation. That’s why the list doesn’t include industry (non-tech) enterprises, consulting firms, managed service providers, service delivery firms or startups.

Iterations don’t only increase innovation, we also know that fast, safe, iterations increase reliability - your career should be the same. Building up a team as a manager is an exercise in reaching a product goal better or faster by bringing people together, not a promotion to a different rank of decision making. In Tech we often see a pendulum between manager and individual contributor, in startups even from CEO’s. We also know complexity in systems keeps increasing. And the only way to deal with complexity is by observing it, for which we create socio-technical systems specialized on identifying patterns while state is emerging. For managers this means being adaptive and change context, identifying and changing the small things iteratively, is the real art. It also means titles like “lead” or “manager” are often meaningless or, in the case of “senior” or “principal” vanity and don’t add value to a list of roles in my opinion.

Take for instance various “ops” roles, starting from DevOps or SRE to FinOps, DevSecOps and DataOps. All of those value horizontal, end to end knowledge and systems thinking instead of fixed silos (see point 2), especially after the pandemic. Getting more experienced in those roles, to be “senior” for lack of a better term means increasing breadth by changing roles laterally, while building out expertise and covering more skills. Instead of looking for a role title when looking for a role, understanding the interactions and influence in the particular tech company and team is key. Developer Relations is a great example, it can range from evangelism and community work to product research, documentation and even owning company-wide engineering culture.

Apart from the vanity title problem there are simply a lot of good lists on skills for “senior” engineers and a lot of literature on “staff” roles, even an Awesome list on management or for leadership. No need to create another.

4. Cost is an SLA like any other, and you optimize for it

As mentioned in point 2, ideally Pay-as-you-go is the standard commercial model in times of rapid change. But in reality it's usually combined with a subscription or other “commitment”. On the one hand because non-tech corporate accounting and procurement are slow to change and still think it’s better to “have” a software than use a service (which comes with free expert consulting) - a striking example of the Dunning-Kruger effect. On the other hand because tech companies also need to plan their own cashflow to build future capacity, and commitments keep customers close in an industry of often interchangeable products (e.g. S3 and Postgres have by now become de facto standard interfaces for competitors). So they offer discounts for recurring use and payments ("Pay less for our 1-year plan!"). These days even Apple products are barely usable without attached subscriptions and full of dark patterns (“Pay a subscription instead of buying this song!”). Behind that is cost planning, not anymore quarterly but based on customer or product lifetime value - the practice behind FinOps. In other words, cost, like reliability or performance, or sustainability, is a feature, with an SLA, and one can’t hide from it anymore.

Hence in my list I've grouped the roles roughly in pre-commit, which is basically people trying to increase a customer's confidence into the value proposition of the product in order to attach a commitment to their pay-as-you-go model. And post-commit, which are people making sure the chosen “solution” (the word is a good indicator it’s a customer-facing role), that can be a product, technology or transformation (consulting), actually delivers that value so that customers expand the use of product across the ecosystem. You could argue the product build teams also fall in that category but for readability's sake I've taken them out.

Take for instance the Solution Architect role. "Architect" in the enterprise sense sadly often means someone drawing hopelessly outdated “boxes and arrows” of technology (and organizational) components, in discussion with other "Architects" that define a business problem - hence the "solution". Tech companies have “Tech Leads” for internal products. Depending on the tech company's philosophy the Solution Architect may either be a pre-commit role, often as part of the sales team, especially if the product is "sticky" or expensive upfront, meaning hard to change, and customers want a "fixed" solution before committing (an illusion and fallacy of bad planning). Or it can be a post-commit “resident” role helping customers to continuously improve their use of the product, especially if it's a highly flexible and fast moving platform, similar to a Technical Account Manager (TAM) or Customer Success Manager (CSM). Depending on the target market audience it can be focused on a single customer, similar to a consulting role, in workshops, or more focused on mass-market consumer outreach, via publications and talks, more like developer relations. When you are offered such a role, try to find out how it is incentivized and what you can control or influence - and what not.

*) While it's good to give opportunities to everyone and not bias early, the focus on "upwards" leadership can also be problematic. Aside from the obvious problem with a hierarchical perception and rejection of hands-on expertise, it may simply lead to no one wanting to do creating instead of just creative work outside of startups - for instance I've had students ask me how long it takes to be a director "as I don't really like code" or not interested in network infrastructure "as it doesn't add value to my CV" or only finish a prototype "because outsourcing the coding is really easy". I feel this may as well add to imposter syndrome rather than reduce it.