WHAT IS A ROLE? WHAT ARE RESPONSIBILITIES?

Because it is our nature to assume that the meaning and understanding of words is universal ” your understanding of a word or phrase is the same as mine ” people in organizations often use the words role, responsibilities, job, position, and title interchangeably because there are no consensus definitions for these words. That s where the trouble begins. Let s say I am responsible for leading CMMI-based process improvement in your organization and I ask you what your role is. You respond, senior manager. That answer doesn t really do me any good, because I still don t know the relationship between your work and my work.

There are many academic definitions for the terms role and responsibilities, but the definitions your organization should use are those that have relevance to your culture and to which people can agree. For organizations that haven t yet defined these two terms, which probably includes most of the organizations using this book, here are some starter definitions for these two terms which experience tells us work.

Role

A role is a brief, summary description of a person s function in relationship to a particular aspect of the business. Thus, roles are relative to both the hierarchical structure of the organization and a particular endeavor or aspect of business. For example, a systems engineer may have the role of producer in relationship to engineering and could have the role of sponsor in the organization s CMMI process improvement effort. Hence, the words associated with roles are phrases such as:

• Process improvement sponsor

• Project stakeholder

• Project X manager

• Process user

• System quality assurance

• Requirements analyst

• Software developer

• Purchasing approval authority

• Facilities manager

• Customer service representative

You ll notice that there are a few items in the list above that you have heard referred to as titles, not roles. That is because all roles can be given titles, but not all titles necessarily imply the role. This is why you will sometimes hear a person who has one title say that she wears many hats. Hats is a reference to the many roles in which the person performs .

Responsibilities

As a starter definition for responsibilities, the organization can say that they are a summary list of the primary tasks , activities, or type of work performed in a role. So, unlike a role, which is relative to both organization structure and endeavor, responsibilities are primarily relative only to the role, even though the same responsibility may be repeated in different roles. Responsibilities describe the work a person is expected to perform and can be used to measure job performance. Responsibilities include statements such as:

• Review and approve project plans

• Develop process descriptions

• Perform quality assurance audits and report the results

• Plan organizational training

• Deliver project management training to project managers and leads

• Create the project management plan

• Produce project review slides

• Collect, analyze, and report customer satisfaction measures

• Participate in peer reviews as requested by project management

• Attend product design reviews

• Monitor subcontractor performance and report status

Notice the language used in the above sample responsibilities. They all start with an imperative verb, with the implied agent being you in your role. They are also all verbs which explicitly or implicitly generate physical actions or outputs that can be observed or measured. The use of this language is intentional; it is the style of language that gets people to do things. If I documented in your responsibilities the statement peer reviews are performed, that lets you and everyone else off the hook to actually perform peer reviews. You can just assume that if they re performed, somebody else must be doing them; you were not explicitly directed to perform peer reviews.

The Difference between Titles and Roles

Once upon a time in America you could look at an organizational chart or a list of titles in a company and make some accurate guesses about the roles of people in certain boxes or people with certain titles. John in the sales box was a marketing person. Donna, with a VP before or after her name , was told by the president what to do and consequently told the people reporting to her what to do ” you know, VP stuff. Organizations were organized vertically in silos , with each business unit or department ” accounting, IT, marketing, engineering, manufacturing, quality assurance, etc. ” operating as its own fiefdom, almost independent of the other organizational units within the boundaries of the company or larger organization. We all knew what we were (our roles) and what we were supposed to do or not do.

But vertically structured organizations, if they have somehow managed to survive, are today mostly useless sentimentality. The postmodern organization is an integrated system of systems: people (social) systems integrated with systems of nearly intelligent tools (technology) integrated with process systems. These systems and their subsystems ” people, processes, and tools ” are inextricably interwoven throughout the traditional organizational functions and units. Additionally, people today are required to know more jobs and do more jobs as the need for specialization in people is replaced by specialization in technology or migrates to advanced fields of science. We can no longer make accurate guesses about the role of the person with the project manager title; we can only make reasonable inferences about her role at this moment by observing the work she is performing at this moment.

Traditionally, we have also consciously and subconsciously ascribed characterizations such as power and authority to people having certain titles or appearing near the top of the organizational chart. Though there are still some sectors of American enterprise ” namely, the defense industry ” in which title comes with power, authority, and influence, this paradigm is also disappearing from the postmodern business landscape. In some industries such as manufacturing, capital still dominates talent in the never-ending struggle between the two forces. However, software and systems engineering is driven by invention and innovation, so talent holds all the trump cards and, when talent walks, the capital follows . Thus, in a software or systems engineering shop, you can find power and influence held by the talent, irrespective of their titles or positions in the organizational chart. In leading edge technologies, talent is the capital.

This picture is mostly accurate in Western society and is mostly not accurate elsewhere. I remember sitting in a class at SEI in which about half the students were from Southeast Asia and Japan. In class exercises in which we had to make determinations about decision authority in hypothetical case studies, the students from non-Western cultures would inevitably point to a name sitting in a top box on the organizational chart as the obvious authority and influence figure in the fictitious company. During breaks, I asked these people about their thought processes. At first, they were confused as to how I could be so dense as to not understand that a person high up in the organizational chart or having an executive sounding title is always in charge. Once I explained to them that such assumptions were not always true in American businesses, they then knew we were all dense.