The clients with whom I work, the students that I have taught and the consultants who I supervise often believe that unclear roles and responsibilities often constitute a major component of what needs to be fixed in an organization.
The goal of this post is to illustrate why I believe that this role ambiguity is often a non issue or a misdiagnosis.
(Before I proceed, this post does not relate to government bureaucracies, financial organizations or other heavily regulated services where regulation dictates the need for role clarity and ultimate responsibility.)
Here are the top 4 reasons why “unclear roles and responsibilities” is a misdiagnosis:
1) You cannot define away complexity. For example, it is impossible to fully define roles and responsibilities between development, engineering and operations in the process of new product introduction; try as you may, there will always be many things that defy all definitions.
2) Many situations have built in “overlapping” ownership between several roles. For example, ultimate “client ownership” is next to impossible to define in the stages before a product is sold. Sales, technical presales and digital marketing folks may all point a finger at one another before the client has signed off and purchased the product.
3) When teamwork and cooperation are poor, a frequent symptom is the perception that roles and responsibilities are unclear. Better teamwork can make a lot of these role ambiguities disappear, but no amount of definition can fix teamwork issues between people who have poor acknowledged mutual dependency.
4) If one person is highly skilled and/or very dominant, or unskilled and passive, there can be a perceived problem of role ambiguity. For example, when the manager of a “Continuous Engineering” department is a unskilled engineer, Development Engineering and Continuous Engineering may argue about roles/responsibilities. In such a case, the Continuous Engineering manager will claim that most issues are “design related” and,not in his domain. The Development Engineering manager will demand that the Continuous Engineering manager “learn the damn product” and not force Development to do the role of Continuous Engineering. However, were the Continuous Engineering Manager more skilled, this apparent role ambiguity problem probably goes away.
There are examples of role ambiguity that need to be addressed. But this is the exception, not the rule.
Points well-taken Allon. I wonder – what do you have to say about the view held by many that complexity is not just increasing but also accelerating?
Do you mean axe-cellerating?
The issue of clarity of roles, in my experience, is more one of boundaries: the most critical aspect of any system. In essence, it is the nature of interactions between individuals and functions that make or break organizational strength. Boundaries can be formal, informal, fixed, fluid, permeable, impermeable, elactic, clear, forced or chosen. It is the decision-making ability that forms the primary component of a boundary. Whether fixed or fluid or flexible, within it, decisions get made. This means that the main question, for me, is: “Do they have the knowledge to make required decisions and the authority to do so?” My experience is that when authority is unclear, boundaries grow until they include those who have the right to decide. For example, time to market was a key success factor for a company; however, the right to decide on price of a new product involved six levels of hierarchy. Hence, responsibility, authority and accountability for pricing did not exist within the boundary where pricing analysis was done. Boundaries expanded until the decision for pricing met with the boundary where pricing analysis was done. In this case, such boundaries were obstacles to a key success factor. Attempting to address this issue through role clarification does not work because the fundamental issue is one of boundary management. In the Knowledge Era, organizations are required to identify which boundaries create organizational learning and core competence and then manage transactions across these boundaries in ways that ensure long-term corporate viability.
This was earlier known as intra-psychic conflict manifest in inter-role conflict for the same person. Ambiguity can do that? Nay, requisite socialization apart, lack of precedence and/or experience precipitates anxiety. Redundancy of knowledge and skills relevant to a task heightens tensions regarding boundaries of certainty and interpersonal respect too.
Much as Levis said above. In my experience the only thing that needs to be relatively clear (either through formal written procedures or in any other locally acceptable way) is “who decides?” (e.g. “who decides to purchase new computer”) and “who does?” (e.g. “who goes and buys the damn thing”) in relation to more or less any issue. In addition you might need to clarify who has the “veto” power on an issue, and a few cases where you absolutely must “consult” with a few specific “others” before making a decision (often anything related to safety and security).
Funny enough, in all cultures I worked in, these were precisely the issues people tried to avoid “clarifying” at all costs… 🙂
agree totally
Much of leadership is to enable relevant and meaningful transactions across organizational boundaries in order to integrate the human and technical relationships required to better serve the end user . My advice to a person new to OD would be:
Look out.
Look across.
Look up.
If you do this, you will never have to look down.
Lévis
Levis-this is you at your best!
Appreciate this post and Levis’ and Alexei’s comments. Often it seems that our task is to point out the whole “systems thinking” perspective. Role clarity is one thing in fast-moving, ambiguous environments, and yet another when no one wants to accept the responsibility of decision making and execution. Obviously the source of the problem is asking why – what are the consequences of taking responsibility within the organization? But how often are we “allowed” to address THAT issue? Organization culture spreads itself wide and far.
Pingback: The very basics components of Organization Development | Allon Shevat