Over the course of our careers, we will encounter literally hundreds of different roles, both formal and informal. Occasionally, roles and actors have a one-to-one correspondence. More often, each individual fills multiple, often conflicting, roles. After going though a particularly nerve-wracking experience with this phenomenon, I finally learned a few useful rules of thumb for dealing with it.
I was working as a project manager and senior architect for a client who needed us to install a data center, refresh his distributed file server network, and redesign his online training system. My team consisted of network engineers, a handful of senior programmers, a project scheduler, and a bevy of client employees who changed job titles as quickly as they changed socks. We worked long hours, in typical IT fashion, claiming that it would somehow make a great difference.
During the project, I spent long hours working on team issues. After the team went to bed, I put in a few more hours spot-verifying the quality assurance data and then making architectural decisions. In between breaths, I worked on the follow-up surveys and managed the project communications for a 30-person team in seven countries with over one hundred target sites.
Predictably, things began to fall apart. As I worked harder, putting in even more hours, even less got done. Fortunately for me the project scheduler stepped up and demanded that I hand over the communications and follow-up tasks. Once I divested myself of them, I realized that my workload decreased disproportionately. Although the tasks involved with communications only took up about 10 hours a week, I was working 15 fewer hours.
Roles in project management and social science
Being the kind of person that I am, it occurred to me that the change might be due to something beyond the simple reallocation of workload. Or, to be more precise, that the reallocation of workload may have removed an even more fundamental problem. Could it be that I was the victim of something as classically simple as role conflict?
In project management, we refer to roles as sets of job activities. In sociology (or at least the outmoded functionalist school to which I subscribe) a role is a set of social responsibilities and norms that adhere to a specific function. I generally refer to these two as the formal and informal roles, respectively. Although the notion of role has come under theoretical fire in the last fifty years, it still retains a level of validity as a rough analytical tool.
Over a weekend break, I took a moment to roughly sketch my roles on the project:
- Project Manager: Responsible for leadership and communications within the team, communicating with the executive sponsors and stakeholders, establishing goals and monitoring the achievement of those goals
- Architect: Responsible for project vision, the identification of adequate (not perfect) solutions to problems, and ensuring that all aspects of the project contribute to the vision
- Communications Specialist: Responsible for distributing/gathering information to and from individual actors and team leaders outside of my immediate team
- Quality Assurance Leader: Responsible for directing and double-checking the work of the quality assurance team
The radical reduction in my scheduled work when I offloaded the Communications Specialist role proved to my mind that that role, and at least one other, were in conflict. But why? What about the roles, as they stood, brought them into conflict, and what could I do about it in the future?
The origins of conflict
After sketching out forty or fifty roles from my project notes and examining the team status reports, I came to realize that role conflicts occur along three possible axes:
If an individual has two roles that exert influence on radically different scopes of action then the roles may come into conflict. For example, my communications specialist and project manager roles in this particular project came into conflict. I had a very large team and a large number of executive stakeholders to manage as a project manager. Trying to reach outside of my team in the other direction, towards the sites and individual workers, was too much of a stretch in scope. By removing myself from the role, I both resolved my own conflict and created a logical path for escalation (from the communication's specialist to the project manager).
If a single person has two roles, one of which is the escalation point for the other, it creates the potential for conflict. Escalation procedures allow us to separate different levels of responsibility and potentially incompatible goals. In the above example, my role as QA leader and architect could come into conflict: The QA leader is concerned with the best solution, where as the architect tries to bring all of the solutions together into a coherent whole.
Sometimes roles' functions dramatically oppose one another. For example, it's very difficult to both create something and immediately critique it. The classic example from sociology would be the roles of employee and parent; these two time-intensive roles come into conflict constantly. In the above case there were no direct functional conflicts. But what if I were a line engineer rather than the project manager? Could I also run the QA process and stay focused on the intricacies of technical vision while building servers every day?
This simple analysis clearly can't cover all of the possible role conflicts. However, over the years, it proved its value to me by giving me a quick and dirty way to begin the analysis. Although each case of role conflict was as unique as the individuals involved, having some place to start helped me come to grips with the issues.
Conflict is in the mind of the role-holder
One other thing that this analysis showed me is that role conflict is literally in the mind of the role-holder. Each human being thinks differently, and therefore has radically different tolerances to specific kinds of role conflicts than others.
For example, from a functional perspective, production of an intellectual product and QA of that product have serious conflicts. Yet I know of at least two senior engineers in the field right now who can perfectly QA their own work. I've worked with an architect who could hold a technical vision for a Fortune 100 enterprise while slinging routers 60 hours a week. Something in their minds allows them to do what should, theoretically at least, be almost impossible. Frankly, more power to them.
When dealing with real human beings rather than pieces of paper, we as project leaders need to keep an eye on both their output and their morale. Their output (in terms of both work and thought) shows us which roles they can most easily execute. Their morale level, especially if it radically differs from that of the rest of the team, can help us to identify role conflicts that we never would have thought of. For example, on one project I dealt with an extremely talented architect who simply could not interface with exterior clients. It made him miserable. Within what I thought of as one role (architect) he encountered a functional conflict (communications vs. vision).
This simple tool set clearly cannot cover all of the possible role conflicts. However, over the years, it consistently proved its value to me by giving me a quick and dirty way to begin the analysis. Although each case of role conflict was as unique as the individuals involved, having someplace to start helped me to eventually come to grips with the issues.