Breaking a role to multiple titles
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 blockage, territorialism, and stepping on each others’ toes.
When issues happen, the distributed accountability and ownership leads to finger pointing and blame game.
Narrow titles typically create single-minded professionals who only care about their perception. The problem is that many decisions are multi-dimensional and require building a perspective from multiple perceptions. This is very tricky to get right, and leads to delay, expensive, and sometimes wrong decisions.
If a title cannot objectively fill a full-time job, the carriers may end up slacking (working less time than paid), or generating work: putting up unnecessary presentations, workshops, demos, processes, etc.
Those dependencies are reflected in the services provided by the organizations due to Conway’s law.
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:
Role is focused on the outcome regardless of the activities required to deliver the outcome
Title is focused on functions and services to realize an outcome
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.
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.