Stop caring about your job title
Stop caring about your job title
Care about the work instead
Welcome to The Overlap, a biweekly newsletter somewhere between product and organizational development. This is the eighteenth edition!
This one’s on two things:
How obsessing over our titles makes us worse at collaborating
How you can design your teams based on the work, rather than the individuals
Our nineteenth edition will come out on 2/24—three weeks from now. I’m climbing in Utah and taking a break from writing this weekend.
To contradict myself slightly and obsess over title just a bit: PdM in my newsletters stands for Product Manager.
Project Managers, we love you too.
Humans love labeling themselves.
“I’m a Product Manager.”
“I’m a Product Designer.”
“I’m a Socialist, but not a Communist.”
Humans also are quick to avoid labels:
“Not project manager. Pro-duct manager.”
“I’m not a developer.”
“That person I’m spending my weekends with? We don’t do labels.”
“I’m not a Socialist, but I’d like the US to experiment with universal basic income.”
Our relationship to labels can get in our own way. Especially at work:
“Oh, that’s a designer question. I’m just the developer.”
“That feels like a CEO-level call.”
“I shouldn’t touch Figma because I’m not a designer. The designers will get upset.”
Smart people getting to the best result
I’ve learned that being a product manager means being a copywriter, information architect, content strategist, or process designer. Your team will have clearly defined roles: designer, frontend dev, backend dev, QA engineer. Yours? Whatever the hell your team needs.
I imagine designers and developers experience a similar thing:
You learn that the job description you saw on Lever isn’t exactly what you do now.
Job descriptions rarely reflect what you actually do. They’re an educated guess at what the job is, not dogma.
But I think inaccurate job descriptions are a feature, not a bug. Jon Snydel shares:
My team at Sanctuary arrived at a similar insight. We don’t care for the delineation between PM/strategist/designer/developer. We care about tapping into each other’s strengths to arrive at the best possible result.
Hold me back though. I shouldn’t shit on job titles too much. I’m practicing patience this year. Remember what I shared with you on January 6th?
What I am sure of is that I have an opportunity to be more generous towards traditions. Even if I disagree with any assumptions behind them. Even when I think I see a better way. I’m doing the people I care about a disservice when I don’t do the work of understanding why that tradition exists in the first place.
In that light, let's understand why job titles exist.
What problem are we trying to solve with job titles?
What job are we “hiring” titles to do?
A way to quickly understand another person's skills and expertise
From What Do You Actually Do? by Jim Ralley:
Job titles are shortcuts to an assumed shared understanding of what a person does. They allow us to quickly make assumptions about that person’s skills, knowledge, and motivation.
Titles are a proxy for another person’s skills, knowledge, and motivation.
When you read VP of Engineering, you know this person knows their shit about technology. You vow never to argue with them about functional vs objective-oriented programming.
When you read Product Management Intern, you assume this person wants to be a PM one day. You want to help them get there. So you start asking them to weigh in on key product decisions.
When you read Organization Designer, you’re... not exactly sure of what I do. Are we going through a re-org? Will I need to start looking for a job? Don’t worry, I’m not like the Bobs from Office Space.
(Seriously, I don’t weigh in on firing decisions in org design consulting.)
So now that we know that job titles give us a glimpse into other people’s skills, knowledge, and motivation, let’s ask this:
How might we create shortcuts that help us understand what others do, while also enable the flexibility to act outside of our roles?
The answer, I think, has to do with uncoupling the work from the title.
Organize around the work, not the title
From The Overlap 11:
To distribute authority without going full out on self-management, learn to separate role hierarchy from positional hierarchy.
[...]
By separating role hierarchy from positional hierarchy, we get the fluidity that self-management enables without the high school drama.
“Separating role hierarchy from positional hierarchy” is jargon for organize around the work, not the title.
“I agree in theory! How do I do this?” Here’s one practice that’s helped the teams I’ve worked with: defining team roles. Here’s what I mean.
Define your team’s roles with your team
Roles are the many hats you wear. In self-management speak, roles are containers of purpose that team members step into.
For example, your title is “UX designer.” You believe UX designers should do user research. But you work with a Product Manager and are not sure if they’re in charge of user research. After all, their title is “Product Manager.”
Do you both do user research? Does one of you do it?
This is an opportunity for you both to detach from your title and define the work. You draft the role in Notion together:
Role: User Researcher
Purpose: Smarter team decisions on what features to prioritize
Accountabilities:
Designing minimum viable studies that are useful and feasible
Organizing user interviews
Facilitating user interviews
Sharing learnings with the product team
You and the PdM talk about who’d be best to fill this role, based on each’s skills, interests, enthusiasm, and time. The PdM says, “While I’m excited about this, I’ve got a ton on my plate. What does your plate look like?” You respond, “Kinda full... But it has room for research. 🥸”
Notice that you did not…
Ask your manager to decide who “gets to be the user researcher.” Your PM has less trust in you if your manager goes to them and says “hey, let’s have [your name] be the user researcher.”
Say “oh you can do it” and grow resentful toward the PM. You’re going to be miserable.
Externally hire a user researcher. This requires more time from you and the PdM. Think about all the prepwork, meetings, and debrief calls you now have. And your company spends more.
These are anti-patterns: bad practices that come from good intentions.
Rather, you both had a conversation and came to an agreement. What a feat!
Role Template
I’ve found this template to be useful at defining roles with teams:
Role
What is the title of this role?
I like to have teams not use words like “COO”, “Product Manager”, “UX Designer.” Not using these titles gets others to think more clearly about the role instead of slapping a title that carries baggage.
Purpose
What’s different about our customer, user, or team after their work is done?
Avoid phrasing the role’s purpose as an activity:
Facilitating user research
Understanding our customer
Phrase it as an outcome:
Smarter team decisions on what features to prioritize
Better assumptions
A specific, informed idea of our customer
Accountabilities
What is this role accountable for?
No more than five accountabilities, max. Any more than five feels restricting. Good role design gives the role filler the autonomy to decide how to achieve the role’s purpose.
Again, here’s the User Researcher’s accountabilities:
Accountabilities:
Creating hypotheses
Designing studies that test our hypotheses
Sharing learnings with the product team
Notice that “organize user interviews” and “make research decks” aren’t on the list. Those are tasks. Don’t phrase tasks; phrase accountabilities so that the person filling the role has the autonomy to come up with tasks on their own.
Decision Rights
What decision rights, if any, must be in place for this role to autonomously achieve its purpose?
If this is a new role, I would leave this blank. You’ll know the decision rights it needs after the role gets going.
For example, our User Researcher discovers that they need $ to move forward with their research. They add a Decision Right to their role and propose it to their team:
Decision Right: Research Spend
Anything under $1000 is fair game. If they want to use that money for their study, the User Researcher doesn’t need approval. If they need more than $1000, they should talk to the Finance role.
Role Filler
Who will steward this role?
Your team will be tempted to assign this role to multiple people. Resist this. If everyone is accountable, no one is accountable.
Ask your team to commit to one person per role. Choose the person collaboratively based on four things:
Who would be an expert at it?
Who is eager to get better at it?
Who is stoked about it?
Who has time to do it well?
Try to move away from one person (e.g., a manager) deciding who fills what role. Samantha Slade offers some nuanced guidance on how to fill roles in a fair, equitable, and inclusive way.
Notice that Role Filler is the last step in this template. This is so that we truly design the role around the work, not the person. If we assign the role filler first, our conversation will be about “who should own this role” rather than “what problem are we trying to solve with this role?” Challenge your team to do this last instead of first.
Define roles based on expertise rather than activities
So you now know to define roles instead of titles. Now, how do you know which roles to create?
I’ve noticed two schools of thought here:
1) Define roles based on the team’s purpose and strategy.
Define roles strictly based on the team’s purpose and strategy. This prevents us from over-fixating the title. Structure follows strategy, says Alfred Chandler (and many other CEOs, though they’re just paying lip service to Chandler to sound smart).
Self-management practitioners believe in defining roles based on the team’s purpose. However, this feels abstract in practice. Especially when your team’s strategy is not concrete, which is often a result of your org’s strategy not being clear.
So I’m warming up to another school of thought: define roles based on what we want everyone to increasingly know.
2) Define roles based on what we want everyone to increasingly know.
I learned about this through this essay by Jessica Joy Kerr. Here’s her:
Maybe defining roles by activity doesn’t lead to outcome. Maybe defining roles by responsibility doesn’t lead to shared ownership. How else could we define them?
Well, building software is knowledge work.
What does each person know?
A product owner knows why each feature is valuable to the business, and how to measure that. They know what the software does and how it fits into the larger business system.
A tester knows what the product does, and where to check for whether it really does, and how to recognize value drains like a glitchy UI.
A software developer knows how the system works, and how to troubleshoot it. And they how we want it to work, and can put that knowledge into code. Each software developer knows how to use the programming language and runtime. Each person knows varying amounts about infrastructure, delivery pipelines, security usability, tracing, monitoring, scaling, accessibility, and the other -ilities
Everyone on the team has a shared understanding of how the system works and how it fits in with the larger business. Areas of knowledge are not evenly distributed. Every person contributes their knowledge to the team, and all that knowledge goes into the product. (emphasis mine)
Of course no one starts out knowing all about the system. And no one ever knows everything about the business or the technology; the world is changing and there’s always more. So it’s more like, “what does each person increasingly know?”
We recognize three things by defining roles based on what people increasingly know:
Each team member is increasing knowledge that benefits the team
We respect that knowledge
We respect time spent sharing that knowledge
Defining roles based on what people increasingly know sounds a lot like defining roles based on people. And defining roles based on people is a red flag to self-management nerds. But I don’t think Jessica is advocating for designing around the individual. I think she’s saying design roles to optimize for learning, not for the individual.
I mean, imagine if your team valued the knowledge you bring. They want you to bring knowledge back to them. They depend on you learning more about your job. How cool is that?
Obsess over the work, not the job title
Three concluding thoughts:
Define your team’s roles based on the work rather than the person.
Define your team’s roles based on what your team needs to learn.
Notice when your fixation on your title gets in the way of you being a better collaborator.
We may not be able to get rid of titles entirely. But we can get rid of our obsession with them.
What I’m Reading
You, reader, appreciate the “What I’m Reading” section. But I’ve learned that you read this newsletter mainly for the enchilada (the essay). These articles are the pico de gallo: some add it to the enchilada, others just want the enchilada.
We’ll keep it brief this week:
The Consultant Out of Time - a framework to help consultants focus on outcomes rather than outputs. Applies to PMs too.
Meet us in the browser - Figma CEO Dylan Paton on how design is a collaborative activity.
Patagonia’s Philosopher King - can you tell that I’m thinking about getting a truck/van/SUV? Yo, I just want to climb. So does Yvon, the founder of Patagonia.
Jobs
Operations Director at Parabol. Jordan, their founder, is a joy to work with. And if you’re a product and process nerd, Parabol will excite you.
Product Manager at Torch. Torch owns a suite of products on digital learning, leadership coaching, and mentorship. Maybe you know someone interested in product and leadership development?
See you in two weeks,
-tim