Overview and Context
âJobsâ vs. ârolesâ. What is a job, versus what is a role. Itâs a bit of a baseline-setting, foundational topic to support future posts. Some folks might consider jobs and roles to be the same, or at least very similar. My perspective is that not only are they different, but that itâs important to understand how they are different when it comes to training, skills, and other âhow can I fulfill the requirements of my job or even exceed expectationsâ topics.
The dictionary definitions:
Job â a paid position of regular employment.
Role – the function assumed or part played by a person or thing in a particular situation.
Or, to make it a bit more readable:Â Â Â the function played by a person.
While the definitions tell the difference, there are some nuances. Iâve seen the terms used somewhat interchangeably in business â often when talking with management or folks in HR. I donât think this is horrible or worth correcting, but it can lead to confusion.
A job is your employment â described by who you work for, where you work, the âwholeâ of the expectations of you, etc. It aligns with a title you put on your resume, your business card, your LinkedIn Experience section. Job responsibilities likely include many roles, often capped off with: âother duties as assignedâ.
A role is usually one of the many things you do, roles you play in your job. Some of those roles are related to soft skills, some are related to tech skills or platforms. In some cases, your job and role might overlap 100%. In my experience, most folks have one primary job with many roles.
To make things a little more confusing, if you work in or around the IT space, terminology used when developing and marketing products, apps, and solutions can overlap here as well. We have terms like âpersonaâ, âuser storiesâ, and âuse casesâ. These terms tend to have a lot in common with what the rest of us refer to as ârolesâ and are important when it comes to training and communications. These terms flip the perspective â from the personâs perspective to the productâs perspective. Thankfully the perspectives often meet in the middle and everyone gets along.
Examples
A number of technical products have some or all of the following roles associated to them.
User â A person that uses the capabilities of a tool or service. A consumer of the content or tool. Folks that use Word, Excel, OneDrive, etc. In most, if not all, cases, users have other more primary business roles. Their *job* is not âuserâ. More often than not these folks donât think about tech or tool-aligned roles until they are forced to (communications from IT, training, etc.)
Administrator â An administrator might be at a product (M365, Teams, SharePoint, Workday, ServiceNow, etc.) level, or at a more granular team level. They have responsibilities for keeping the system running and configurating the tools and services. In some situations (team, site, or channel), administrators might have both admin roles and business roles. In other situations, administrators may administer many sites or platforms, but not have other business roles.
Developers â Developers customize or extend functionality of existing platforms or create new solutions. They might be exclusively developers but work with a variety of tools or platforms. They might have other business roles but do some development or coding as a part of that job. There are a lot of options. Development vs. low-code developer vs. maker vs. other names, titles, and roles might be a topic for another dayâŚ
There are many other variations. Often folks have more than one role with âuserâ generally being a more-or-less common denominator.
Note: Another potential post topic – When an admin or developer is NOT familiar with user capabilitiesâŚ
Application of Roles
Why is it important to understand roles? Because roles often define the target audience and the context used for effective communication, training materials, and even functionality in products and services. When roles arenât accurately understood, communication and training can drop in effectiveness.
HR is another area where understanding roles is important.
- Understanding existing organizational capabilities and identifying skill gaps
- Finding resources within a company
- Assisting hiring managers when creating job descriptions
- Finding appropriate candidates to hire
- Assisting employees with skill and career progression
There are, of course, many more examples. Topics to dig into in follow-up postsâŚ
Resumes and Job Sites
When looking for job opportunities in other organizations, we have resumes, LinkedIn, and other services that help folks describe both their jobs and the roles that they fulfill. Thatâs a lot of information to share â hence the art of writing resumes and getting as much information into as concise a description as you can, with enough teaser info to warrant a second look. Understanding roles, and sometimes giving a name to them, helps folks define themselves more effectively. If there are known, common, role names within an industry or product area, this can help. But individuals are often left on their own to tell their story.
Wrap-up
Why am I interested in clarifying this? Iâm working on a project (a SaaS startup) that has to do with technical skills and learning. A core concept in this area are roles â specifically related to technology platforms.
Example: In years past, folks in my industry/community might say: âI do SharePointâ. Cool. Except what the heck does that mean? How do you work with it? What do you do? What are your capabilities? Ultimately, âWhat can you do for ME?â. It didnât take long to drill down a bit if you were familiar with the platform. Are you a developer, a site administrator, a platform administrator, a user? Not everyone was familiar with the platform, so that made for challenges. We face similar challenges with platforms today and will likely continue to as new platforms come online and the services we have continue to evolve.
Navigating the skill requirements of roles is key to working effectively. Itâs just one of many perspectives â soft skills, etc. are obviously also critical. As employers, managers, trainers, employees, consultants, and team members itâs critical to understand scope and context, to set expectations, and more. The more we understand these roles, the better we can train for them, align them with work, and ultimately set folks up for success.
Other Duties as Assigned
Itâs easy to dismiss this often joked about phrase or caveat on many job descriptions. But itâs also useful to note that many folks have found their calling, or at least jobs theyâve really enjoyed because of âother duties as assignedâ. I expect the examples are limitless. I spoke with someone this weekend at an aircraft company that got to his current position (and the last few within the company) because of seemingly random knowledge and experience paired with an open mind and open ears. He saw a need, had some input, and eventually moved into a new role.
Weâve seen this happen plenty of times within the IT space as well. Again, plenty of examples. Folks in business departments assigned a tech platform role – or to use a specific tool for the department (e.g., SharePoint Site Owner, Microsoft Teams channel owner, etc.) â that leads down a path they hadnât considered before.
Itâs a fun topic but can come with other challenges and use-cases to address in another post.
