Many product teams struggle to collaborate well on projects — making websites, building apps, creating content, authoring documentation, etc. — because they have not distinguished jobs from roles. Too often, teams allow roles to be merely inferred by job title, rather than slowing down to have a conversation about who’s doing what and why. This is anywhere from inefficient to downright dangerous.
Ultimately, I believe that project roles are more important, useful, and relevant to design work than job titles.
In this article, I’m going to explain how I define jobs and roles, talk about why the distinction is important, and give some tips on sorting through the mess.
Jobs describe your relationship to the company
Jobs — or positions, if you like, you fancy lad — describe the relationship of an individual employee to the company that they work for. Repeat after me: Jobs = company. Jobs = company.
This one’s easy, right? We all know what jobs are. They’re the things we apply for, the things listed in the classifieds, the content type that populates job boards. They’re the things we take and the things we quit and the things we get paid for having.
Jobs usually have at least two components: a job title, and a job description.
In product/platform-focused tech companies, it’s common for one’s title and description to hew closely to a particular technical skillset or design discipline. For instance: You hire a Content Strategist, with a job description that pulls heavily from a general description of what a content strategist does, and that hire leads content strategy for your product. Cool, nice. Or you hire a Lead Javascript Engineer, and that person leads a team of Javascript engineers already working on the product. Simple! Certainly this 1:1 job:work model will scale easily without problems for the life of the product. Or…not. (More on this in a bit.)
Meanwhile, in enterprise-scale / multi-product / multi-business-line organizations (and big institutions like universities or hospital systems), job titles are often more abstract. Rather than specifying a discrete skillset needed on a product team, these titles tend to be representative of things like core competency, experience level, tenure, and funding area. Business Analyst II, Junior Communications Associate, Technical Engineer IV, that sort of thing. Applicants for these jobs have to do a little more work to understand exactly where they’ll be assigned and what kind of work they’ll be doing day-to-day. This model is my strong preference, and I’ll explain more about why in a minute.
Jobs exist at the organizational level. They are the unit represented on an org chart. Org charts tell you who can fire whom. But most org charts don’t tell you how to get the work done. To figure that out, we have to use things like project plans, self-organizing frameworks like Scrum, RACI charts, workflow and process diagrams, governance plans, and so on. And those things all work better with well-articulated roles.
Roles describe your relationship to the work
Roles describe an individual’s relationship to a bit of work that needs doing. They typically exist at the project level, or as part of some sort of governance plan or accountability chart. Repeat after me: Roles = project. Roles = project. (Or assignment. Or build. Or sprint. Or whatever unit you’re using to divide and plan the work.)
Any collaborative undertaking of human effort creates roles. Let’s say you volunteer to organize a birthday celebration for your coworker Carol. Good for you! Your role on this project is now, say, Party Planner. Or Birthday Czar. Whatever you want to call it. You probably won’t call it anything. The point is, you’ve taken on a specific role (party planner) on a specific project (Carol’s birthday party). If you’re sick or overloaded, you could pass that role — that named or unnamed set of responsibilities to organize the party — off to someone else.
Let’s now say that your job title at this company is Senior User Experience Designer. Does organizing Carol’s birthday party mean that you are now, in addition to being a UX designer, also an Employee Engagement Specialist? Do you need to start going to Employee Engagement conferences instead of UX conferences? Do you need to jump on Lynda and find a course on how to facilitate human resources training seminars? Obviously not, mate! You’re just planning a party.
Roles are powerful because they can be assigned to teams, or to positions, or even to other organizations. For instance, I rarely see org charts that represent vendors and contractors. Yet these vendors and contractors are often critical partners in getting the design work done.
Where organizations get it wrong with job titles
Articulating and assigning roles is often one of the first steps I have to take to help teams get their work back on track. Job titles and descriptions are often outdated and overly-restrictive. They make people territorial, and they often prevent people from using the full set of skills available to them because it “isn’t their job”.
This mindset – Role Articulation Deficiency Syndrome (RADS), let’s call it – sucks all of the energy out of the room and makes every bit of work feel like you’re fighting your way uphill. RADS symptoms include:
- Identity politics – “Making wireframes would help me solve this problem, but I’m a content strategist! We don’t make wireframes, we use our words!”
- Office politics – “That’s not what our department does.”
- Vocabulary misalignment – “Oh, is THAT what a content designer does? I thought you guys were just making our infographics!”
This nonsense doesn’t happen when a group of well-intentioned people come together without preconceived notions about the work and their relationship to it, which is exactly what we get with overly-specific job titles. Instead, smart people who want to get some work done come together and ask:
- What needs doing? (Articulating roles)
- Who’s the best person/team to do it? (Assigning roles)
That’s it, that’s the whole trick for creating roles: have a conversation about it with the people who will be doing the work. You can use fancy tools if you like, but a three-column table in a Word document gets it done, too:
- Column 1: Role (a descriptive label)
- Column 2: Description (bullet points outlining the responsibilities)
- Column 3: Assignment (position/team occupying this role)
Jobs and roles, like peanut butter and jelly
Jobs and roles can work together. In my work as a content strategist, I encourage teams to assign roles to positions rather than people — the position of VP of Marketing might change hands every year, for instance, but the position persists no matter how many people sit in that office.
Roles can even be called out in job descriptions. E.g., “In this position, you will serve as the [Role Name] on [Product X].”
In a startup company with a single product with relatively few features and a clear understanding of the work that needs done, job descriptions are often written such that the overlap between the job description and the role the person in that job will inhabit on their projects approaches 100%. But that overlap is a happy coincidence of being small and focused, not some sort of ideal that needs to be maintained through the life of the company. The overlap gets lost as the product, and the work, gets more complicated. Overly-specific job titles encourage people to get territorial, either by avoiding work they should contribute to or protecting work they’d be better off inviting collaboration on.
There are two nasty drawbacks of the hiring process that roles can help us overcome:
- Job descriptions are generally written before we’ve hired a specific person, with a specific set of skills and experiences.
- Job descriptions are written to support the work that we’re aware of, which does not include: work we were not aware of, and work that reveals itself in the future.
Roles, meanwhile, can be carved out right then and there to respond to who’s on the team and the work that needs doing. An example from my consulting work: Organizations usually underestimate the type and amount of effort that will be required to support their websites. Underestimating leads to under resourcing, which means that there’s lots of work to be done and seemingly no one to do it. But the website has to be maintained, the content has to be published, and so we’ve got to figure it out. That’s why I so often find myself helping these teams articulate the work that needs done and assigning people to do it.
Here’s another way to think about it: if our job titles and descriptions are so important, why does it so often feel like we have to scramble to capture and reassign someone’s responsibilities when they announce they’re leaving? It’s almost like in the course of their employment, they ended up inhabiting a variety of … roles … on different projects … hmm, hmm.
Using job titles and roles together means that you can attract and recruit people with the right skill set, and help people get the titles they want for their resumes, while still ensuring that the actual work that needs doing gets done.
If you want to fight RADS and create a more collaborative design culture, I invite you to strongly consider more generic job titles for your design and product teams … and way, way, way more RACI charts and role articulation.