roleI 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

Reblog this post [with Zemanta]