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.