I was working with a client that was experiencing significant pain trying to implement a major enterprise system. One of the recurring issues was around the boundaries of responsibility between business operations groups and IT. With the new enterprise software, which offered extensive user-configurable capabilities, who should be responsible for what?
Who’s On First?
Business operations wanted the maximum flexibility implied by the enterprise software package, while IT was mostly concerned about “control” and protecting the users from doing something in the name of “configuration” that might damage the integrity of the system or its data. I suggested an intervention where we would move beyond territorial issues to collaboratively build the process that would be used to manage configuration changes. The process would point to “roles” that in turn would identify “competencies” needed to fill given roles.
My suggested intervention did not get very far! It turned out that the term “roles” had a very different meeting at this client – one that was 180 degrees reversed from what I was intending, and from what I have found to be the common interpretation of the “role” concept.
You Say Role, I hear Job
Wikipedia defines role as a “set of connected behaviors, rights and obligations as conceptualized by actors in a social situation.” In the organizational (rather than social) setting, the concept of role has been important to decoupling the rigid characteristics of “job” from “organization”. Roles, when properly implemented, offer certain advantages compared with other organization design constructs. Roles allow organizations to increase flexibility and agility as individuals can take on multiple roles to suit the need at a given time under certain conditions, regardless of formal “job description” or position on an organization chart.
Roles can be achieved or ascribed. For example, many of us are familiar with the “power PC user” – the person in the office who is something of a PC jockey (or MS Office Jockey, or PowerPoint whiz). This is the person you know to go to if you are trying to figure out how to do something. They were not especially trained for this role, are not formally compensated for it, it is not in their formal job description, but they fill the role, and we are glad they do (and they are usually happy to do it!) This is an example of an achieved role.
Similarly, some organizations do have the notion of the “power user” officially ascribed. In this case, everyone knows that Mary is the ERP power user – if you have questions or a problem doing your job through the ERP, Mary is your first point of contact. She has been trained, ERP support is part of her job, and she may be able to answer your question, or if not, knows who to go to for the answer.
Professional consulting organizations are very familiar with roles. On engagement “A” I might be the Client Relationship Officer, responsible for the overall client satisfaction and quality assurance for the engagement. On engagement “B” I might be the Engagement Director, responsible for day-to-day project delivery. On engagement “C” I might have more of a cameo role as a subject matter expert in Enterprise Architecture. And while I am Client Relationship Officer on one engagement, Engagement Director on another engagement, Subject Matter expert on yet another, I might also fill the role of Research Director on a multi-company research project.
This type of “role” structuring create flexibility and increases the ability for people to work across silos. My competency footprint, and my ability to fill a range of different roles now become the key indicators of my value and worth, rather than my “seniority” and the number of people I have working for me.
Breaking down the silos
So, if you are trying to transform to a more agile, flatter organization, with increased agility and improved collaboration across traditional organizational boundaries, think about how you can decouple rigid job structures from the individuals that fill them. Think about using the notion of “role” with people taking on multiple roles to suit the circumstances.
Roles fit in well with the shift from vertical to horizontal management, and to process-centricity. Roles fit particularly well in the context of Web 2.0, and the shift to Enterprise 2.0. Processes call out roles needed to execute them; roles prescribe competencies (knowledge, skills and behaviors) which people must demonstrate to fill a given role, and all of this works regardless of who you “report to,” who “reports to you,” and where you are on the dreaded organizational chart. As we move from positions in organization charts to collaboration across silos, the concept of roles as a unit of analysis for work understanding and design becomes an important tool.
Photo from ‘‘Beetlejuice’’ (1988) courtesy of Boston.com
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=00303f7a-09e3-41f3-82df-24a2ba58264d)
Filed under: Change Management, IT Management, IT Maturity, Web 2.0 | Tagged: collaboration, Enterprise 2.0, Organization, organizational change management, Web 2.0
Vaughan, Perfectly said!
All business process frameworks (at least that I am familiar with!) are keyed into that concept of a’role’ (eg sub-process owner)
And attempting to discuss the difference between funtional responsibilities (eg Job) and roles often causes;
a) finger pointing
b) hackles to rise
Because too often individuals feel that ‘role’ must equate totheir status, number of reports etc.
Thank You!
Unfortunately, Elliot, some organizations have institutionalized the term “role” when they mean “job.” This makes introducing the role concept especially challenging!
Vaughn. Your blog underscores how organisations have changed over the last decade. With increasing automation of processes, employee’s roles are becoming more context specific. In the past, people were hired into a fairly stable function. Today the processes in which you participate define what your job is. The result is more flexibility for individuals and boundaries between functional silos becoming increasingly blurred. An organization with this elasticity is a good candidate for gaining the benefits of continuous process refinement that lean IT has to offer.
Excellent point, Pradeep – the continuous improvement perspective really depends upon the flexibility that the “role” construct offers compared with the traditional “job” construct.
‘elasticity’ is a good term for that –
However – in many cases can we not look at a role as a superset of responsibilities that may or may not include regular tasks?
A good example is GM’s IT with its full matrix of what we call ‘job’ tasks, (eg X Axis) and then roles (Y Axis)
Because in some situations I can imagine that *all* a persons tasks are ‘context specific’ and driven by various roles- but also in some cases (as in your original post) where they are external to the various ‘task’ that may make up that job.
You make a good point. Not all job types are created equal, and the ways that “roles” (and other organizational constructs) are applied to achieve agility and efficiency will differ depending upon the the nature of work processes, complexity, and so on.
Years ago, Prof. Henry Minztberg described work design as an exercise in standardization – in some cases, standardize the process (e.g, bake a cookie), in other cases, standardize the deliverables (e.g., designing a bridge), and in other cases, standardize the training (e.g, brain surgeon). In each case, as complexity increases, the ability to separate “role” from “job” decreases.
[...] Bustin’ Silos with the “Role” Bomb! [...]
Vaughan,
I greatly appreciate this post. Having the concept of “role” burned deep into my psyche early in my consulting career I relate very well to the concept. Moving my clients to the concept is more of a challenge. In the lower maturity organizations, the fluidity of “role” does not seem to exist. What I have seen more of are cultures which everyone has their place and everyone does things their own way (differently). It is horribly inefficient, but culturally the norm.
I have hope for change as the social networks take hold in the lower maturity organizations. Point to point – not hierarchical – behaviors may become much more common, and with this a transition to a real recognition of roles and both the structure and freedom than the concept provides.
Russ
Well stated, Russ! I find that some organizations just don’t have the language to convey the meaning of role properly – in fact, they use the term role to mean a fixed job with a defined slot on an organization chart!
[...] posted before on organizational silos (see Bustin’ Silos with the Role Bomb!), the inefficiencies they introduce and how silos tend to dampen the magic of innovation and [...]