Breaking a role to multiple titles
Why SMEs and specialists should be an exception and generalists the default?
Some organizations have a tradition of breaking one role to multiple titles which in turn are assumed by different people.
These are common symptoms:
The tight dependency between people carrying those titles leads to unnecessary blockage, inefficiency and friction. Any point of handover is fundamentally a risk for misunderstanding, delay, broken accountability, and service degradation. Those dependencies are reflected in the services provided by the organizations due to Conway’s law.
When issues happen, the accountability is distributed across titles. This leads to finger pointing and blame game.
Narrow titles typically reward narrow-minded professionals who only care about their perception. Any effort to diverge from this model, leads to stepping on toes and ensuing punishment.
Many initiatives are multi-dimensional and require coordinating those titles to build a holistic perspective from multiple perceptions. This is much easier said than done, and typically leads to a meeting frenzy, design by communities, long documents, and expensive workshops and offsides which are expensive, time-consuming, and yield subpar quality (if they even reach the finish line).
The duties that fall under a given job title may not qualify for a permanent full-time job. The ones bearing the title, may end up slacking (working less time than paid), or generating work: putting up unnecessary presentations, workshops, governance, demos, processes, etc. This is a desperate effort to create meaning out of something that’s incomplete by design.
We’ve previously discussed this phenomenon at an organizational level. TLDR; teams that own end to end customer journey are less likely to suffer from broken ownership and accountability:
Role vs title
For the sake of this article, we distinguish between the two:
Title defines responsibilities towards an outcome with narrow ownership. For example:
Front-end developer, develops front-end and doesn’t necessary touch backend or do QA or DevOps. Those concerns are handled by other titles.
Project Manager, manages the project and leaves the customers, strategy, empowerment and other aspects to other people with appropriate titles.
Role frames around the impact and broader ownership. For example
Software engineer uses engineering disciplines and methods to create technical solutions. That may involve coding, architecture, testing, operation, etc.
Product Manager effectively acts as a mini-entrepreneur for a product. That may formulating hypothesis, market research, collaborating with design and engineering, and even marketing and budgeting if the situation calls for it.
Title has limits while role’s boundaries are more fluid. You can think of the title as a piece of lego while the role can be thought of as a lego house.
Output, outcome, impact
If the point of a language is to communicate, it pays dividends to clarify what those words mean in this context.
At a high level, an organization has people and goals.
People make an effort. For example, programmer code, or workers on an assembly line put parts together.
The effort yields some output. The output is usually easy to measure. For example, number wines boxed by a worker
The output builds towards an outcome that the organization cares about: For example, selling those products or releasing software yields to business profit. The outcome is for the business to make money and pay the individuals.
Impact, connects the business outcome to a higher goal that the individuals can relate to. This is where mission and vision come to play. Not only it helps align the individuals but it also builds a collective story that connects them to the processes, goals, objectives, and strategy.
Title is typically not concerned with how the outputs add up to create an outcome or impact. This is partly due to the narrow ownership:
Knowledge: title doesn’t have the big picture
Mandate: title can only do so much without stepping on other toes
Responsibility: many titles are responsible for one outcome
The outcome typically has a dependency on multiple titles.
Role on the other hand is more outcome and impact-driven. It has more mandate, requires less gatekeeping, and has clearer accountability.
Example 1: Product
According to Marty Cagan Product Management is about ensuring that what gets built is both valuable and viable. It requires deep knowledge of the data, business, industry, users and customers.
Some organization instead have these titles:
Product owner
Business developer
Scrum master
Release manager
Product operations
etc.
These job titles held by respectable professionals each devoted to do a great job within their tiny box in the overall value stream.
Call it collaboration or synergy.
But are each of those titles a full-time job? Because if they’re not, you’re sure going to see some slacking or generated work.
Take release manager for example. On paper, it’s about coordinating the effort required to release a new version of the software. But how often do you release? And what happens when the release manager gets bored and wants to add processes, friction, and get in the way to be noticed?
Stepping back a little: why would a release need a manager? What makes regular software engineers incapable of releasing their own code? Isn’t it a case of broken ownership?
There might be lots of reasons, but having a dedicated babysitter is not the best solution.
Another example: business developer! Isn’t understanding the business, customers, value stream, and connecting them to product a key task for the product manager? Why have a separate role for that? What should the product manager (PM) do then? Oh right! Manage the backlog! Say hello to the dreaded product owner (PO) or Project Manager!
How about product operations? If the goal is for the PM to have a product-informed assistant, just call it PMPA (product manager personal assistant).
The list goes on. Each title claims territory and protects it. It feels good to be SME (subject matter expert), a go-to person, a cog in a system, and “add value”.
Example 2: Engineering
Software engineers are responsible for:
Architecture
Coding
Testing
Deploying
Troubleshooting
etc.
One would argue that these are different concerns and instead we should have:
Architect
QA for quality assurance
Operations (usually called DevOps but practitioners miss the basic DevOps principals to break the wall between developers and operations)
Infrastructure for integration, deploy, release, monitoring, and on-call
Coder for typing the code, unit tests and debugging (also known as “code money” due to limited concerns)
etc.
The problem is when these roles block each other and produce results that don’t fit.
For example:
QA acts as a gatekeeper that cause unnecessary friction in the flow.
Operations enjoys the learnings from the incidents without proper mechanisms to share that knowledge back to the development teams.
Infra treats the developers as code monkeys and controls access to the infrastructure resources.
Architects draw fancy boxes and arrows while adding friction with [premature-]“standards” and tech radars. We have a separate article for that one.
Developers are categorically smart and can pick up new skills given the chance. In fact that’s exactly what happened at one of my jobs when the company decided to deprecate the QA and DevOps titles in favor of handing those responsibilities to generalist software engineers.
The catch is of course, the cognitive load. It requires more time and energy to master all those areas and truly own the product.
With the advent of AI however, it is possible to quickly learn new skills and get copilot support.
As a company, you get what you pay for. Having all around senior engineers can improve the product quality and lifecycle, but those people aren’t cheap. You can either fill that role with multiple headcounts each with a dedicated title and concern, or have fewer generalists who are curious and aren’t afraid to pick up new skills.
Personally, I lean towards a 2-role model for engineering:
Creative thinking: concerned with making it work (functional and non-functional requirements, testing, deploying, and being on-call)
Critical thinking: concerned with what breaks the functionality (e.g. QA) and what to do in case of software failure (e.g. operations)
I don’t necessarily see them as two different types of engineers. Good engineers can do both types of thinking when needed but an individual typically is more effective in one of these modes.
Conclusion
The larger the organization, the smaller your seat. Larger companies (especially those which enjoy a high profit margin) are more likely to break a role into multiple titles. That’s one reason that enterprises are slower than startups.
When it comes to execution, people with diverse skillsets are typically more productive. One who can do design, code full stack, and deploy the code is generally more productive than a setup that requires 3 different titles to do those parts.
The feedback loop is often more rapid when there are fewer handovers. The ownership is clearer and there are less cracks for things to fall into. Moreover, there is less misunderstanding.
On the other hand, having dedicated specialists allows deeper specialization and typically improves quality at a higher price point.
My monetization strategy is to give away most content for free. However, these posts take anywhere from a few hours to a few days to draft, edit, research, illustrate, and publish. I pull these hours from my private time, vacation days and weekends.
You can support me by sparing a few bucks for a paid subscription. As a token of appreciation, you get access to the Pro-Tips sections as well as my online book Reliability Engineering Mindset. Right now, you can get 20% off via this link. You can also invite your friends to gain free access.