A common theme in coaching engagements is that of high-performers grappling with the dynamics of their new roles. Transitions can be disorienting especially when it is a step change.
This happens at all levels, whether it's a first-line manager moving into a division head role or a senior manager moving into the C-suite. But it is doubly true for technical specialists/experts transitioning into a leadership or management role.
The common advice is usually tactical at the surface level. Instead we go deeper and use the domains of competence framework to understand how we can reduce blindspots and increase our capacity for action.
Developing self-awareness using upstream frameworks
Building self-awareness in ourselves and others is a critical leadership skill and this is widely understood. But, how to actually go about building this awareness is not as widely understood.
Often, what we think of as self-awareness is just self-consciousness, self-absorption, or just plain rumination. To develop self-awareness, we need models and frameworks that can help prevent blindspots and identify weak areas.
Powerful models tend to be more upstream, can explain a wide variety of phenomenon, and are universally applicable. They open up new perspectives and provide distinctions that enable new insights. This leads to different actions and thus different results.
James Flaherty’s domains of competence is one such model that is very relevant to the challenges of technical experts transitioning into leadership roles.
Flaherty/Habermas Domains of Competence Model
This model has a rich philosophical history. It is rooted in Jurgen Habermas’s theory of communicative action that has four shared domains of reality: language, human relations, the external world, and the internal world.[1]
Flaherty’s model simplifies it into the three domains of I (self-management), We (relationships with others) and It (facts & events).[2][3]
In order to accomplish anything of substance, we must be minimally competent in each of the three domains. Each of the domains requires a different kind of thinking and, consequently, different people will gravitate toward different domains.
– James Flaherty in Coaching, Evoking Excellence in Others
Each domain has its own unique characteristics and minimum requirements. Being competent in one does not necessarily translate into the other.
How careers get stalled
This model can help in understanding how careers get stalled at different stages. While all of us have an intuitive understanding, taking a closer look using the model gives more granularity that can generate specific actions.
All of us have biases and preference that make us naturally inclined towards one or two of the domains, and making us weak in the other. Both Peter Drucker and Marcus Buckingham have emphasized the importance of working on our strengths rather than our weaknesses. [4][5]
But there is a difference between “working on” vs “being aware of” our weaknesses. Not being aware of our weaknesses can blindside and trip us up. They start limiting our available set of opportunities. By being aware of them, we can take mitigating actions that can limit the damage caused by those weaknesses.
The “I” domain is the basis of achievement and undergirds the other two. In the early stages of a career, the “I” and “It” domains tend to dominate. Beyond a certain point though, self-management becomes less of a differentiator.
At a certain level of achievement and career stage, almost everyone is pretty good in the domain of “self-management”. In the middle and later stages, what starts differentiating and limiting careers is how balanced we are between the “We” and “It” domains and how skillfully we navigate between them based on what the role and situation requires.
The table below highlights some of the core differences across various dimensions between the “We” and “It” domains. While reality is much more nuanced and not as clearly defined, looking at the extremes can help with identifying some of our own stumbling blocks.
Most folks who struggle in transitioning from technical, specialist roles into a more generalist, management or leadership role, struggle because of not recognizing the differences between the two domains.
While this is a well recognized pattern, most so called solutions focus on the mechanics and tactics without actually trying to understand the underlying patterns.
Notice how the two domains have completely different language and expectations. Operating in one with assumptions from the other is a recipe for frustration. You will also notice why some people in your team excel in these transitions while others struggle. Many of those answers will be obvious in the list below.
Differences between the "We" and "It" domains
This challenge of clearly understanding the requirements of each domain was highlighted by Drucker. [6]
For a social discipline, such as management, the assumptions are actually a good deal more important than are the paradigms for a natural science.
The paradigm—that is, the prevailing general theory—has no impact on the natural universe. Whether the paradigm states that the sun rotates around the earth, or that, on the contrary, the earth rotates around the sun, has no effect on sun and earth.
But a social discipline, such as management, deals with the behavior of people and human institutions. The social universe has no ‘natural laws’ as the physical sciences do. It is thus subject to continuous change.
This means that assumptions that were valid yesterday can become invalid and, indeed, totally misleading in no time at all.
—Peter Drucker in Forbes
In what ways does an imbalance become a problem? What are the common mistakes that trips people up? What trouble do we typically have when trying to juggle and balance the domains?
Common Mistakes
Expecting excellence in one to make up for lack in others
The most common one is that of technical experts who are good at both the I and It domains but whose career stalls because of a lack of development in the We domain. This is equally true for both management and technical career ladders although it is more prominent in the management one.
The common assumption is that because we are standouts in the It domain that it should suffice for the rest. But one of the key learnings from the model is that for us to excel at anything we have to be minimally competent in all three domains.
Even extraordinary excellence in one domain will not make up for a lack of competence in the other two. All three have to meet minimal competence standards.
As to what those competence standards comprise of, that can easily be figured out based on the norms and culture of the organization. What might pass as stellar in self-management in one organization might be considered as mediocre in another.
Inability/unwillingness to participate in the conversations of the organization
Organizations from the perspective of a “We” domain are a network of conversations and promises. Leaders who rose through the ranks on their technical prowess might discount the nature of how conversations create organizational reality.
Either because of this dismissive attitude or simply not knowing how to intervene and participate in the conversations, they miss out on this entire dimension of the organization.
As one goes higher, your ability to create and bend reality with conversations becomes a critical part of your job. The meaning of bend here is not that of manipulation but of participating in a process and thus influencing the outcome.
The assumption that the work should speak for itself
Often it does not. This is a craftsman’s point of view and it is true when looked at purely from the point of view of execution in the It domain. The It domain is built on execution and deliverables.
Unfortunately your expertise needs to be seen as having value too. The beauty is as much in the eyes of the beholder and if no one sees value in your masterpiece it will not go anywhere.
Managers and execs in new technical domains
One less typical one is situations when managers and execs find themselves in an unfamiliar technical domain. Either when taking over existing business units or as a result of rapid promotions, the manager might be in a situation where they are entirely reliant upon one or two key individuals.
This can end up being their achilles heel. They need to have at least some understanding of the basis of technical decisions being made. While the typical advice is to build your team to eliminate your weaknesses, a leader cannot be completely ignorant. [2]
Problem-solution mindset
The primary orientation in any technical field is that of problem solving. And problem solving is what made us successful. Unfortunately problem solving also means a habit of thinking which can get in the way in social domains. [7] [8]
In a social domain, not everything is well defined and there might not be an obvious problem to solve. This can be disorienting for people used to looking for problems and solving them.
Problem finding and problem framing/defining is often more important than solving. A willingness to stay with the question longer than we are comfortable is also important.
Anything that does not follow the problem solving format can get misconstrued as a waste of time.
Balancing the I with the We
Individual success vs team success vs organizational success- organizations and management are full of paradoxes and this is just one of them.
Not only do you have to succeed yourself, but you also have to make sure your teams succeeds alongwith the organization. Often these are at odds with each other and you cannot have it all.
Trying to use I and It in the We domain
Relationships have their own dynamic and trying to build a relationship on the strength of the other two domains is when relationships feel shallow and lacking connection. That's when the other person does not feel “seen” in the relationship or as being “used” for the other’s purpose. It's also how a transactional relationship develops between a superior and subordinate without any basis in relationship.[2]
Confusing the domains in play/lack of differentiation
Engineered systems (It) are replete with fixed definitions and no grey areas for the most part.
They tend to have one good answer. Folks steeped in the It domain sometimes have a hard time dealing with the ambiguity of social systems not realizing that it is not a moral or normative issue, but rather the nature of the system itself.
In social systems (We), like management and organizations, things are more nuanced and open to interpretation.
This is why no two people see the same problem in the same way in a social system. Each of them comes to the table with their own interpretations and filters and hence sees the problem differently with different solutions.
In the We domain you get things done through people and hence understanding them is a key part of one’s success .
Clearly identifying the domain and its dynamics is critical to success. Confusion usually follows when we do not know what domain our particular problem is in.
As a solo contributor your actions and behavior played a much smaller role compared to the deliverables you produced. This relationship gets flipped as you rise higher.
Your actions and behavior start playing a much larger role until you get to the point where you are not producing anything yourself. The production is through people, through conversations, and through a network.
You are now completely in the social domain where actions and behavior play a much larger and important role.
Not being comfortable with ambiguity and lack of information
Leaders who have progressed through the ranks based on their technical know-how and specialized skillset, can struggle when operating in the realm of human performance. There is more nuance, complexity, and ambiguity to deal with, when this might not have been the case before.
What made them good was their ability to deal with the technical aspects, which by definition tend to be more deterministic in nature- you are aware of the variables that affect the outcome, and you can directly change or manipulate those variables.
The need to stay in control
As you go higher up, the need to get things done through others increases exponentially. You do not necessarily have direct access or influence into the results. And we struggle with this.
The paradox of leadership is that while on an org chart it might look like the higher up you go you have more control, the reality is that higher up you go, the more you need to get things done through others.
Leaders with technical backgrounds tend to struggle with the superficiality and open-ended nature of leading and managing. You don’t get to “crank out widgets” as someone on the shop floor might get to do.
There is a psychic benefit to cranking out widgets and checking out mentally everyday. Often there are no clear markers of starting and finishing something in the social domain. [10]
Collapsing the domains
A classic mistake is that of collapsing or mixing up of the domains. On one hand, the optimist and idealist in us assumes that great strength in one of the domains will carry us in the other two. On the other hand, the pessimist in us assumes that weakness in one domain automatically excludes us from opportunities requiring more of the other. [11]
We have to resist collapsing the domains and objectively look at our competence in each of them.
Definitions vs Distinctions
Definitions tend to dominate technical/engineering systems whereas distinctions tend to rule social systems. Definitions tell you what something is and something is not. The boundaries are more clearly defined. [9]
On the other hand distinctions are never complete on their own and the boundaries are nuanced. They help you interpret something in a different way or see something what was previously indistinct.
Hopefully, this list highlighted some of the reasons why you or someone on your team has struggled in a transition or promotion situation. It’s worth the effort to sit down with the list and ask yourself where there might be a disparity between reality and your interpretation of it.
Some useful questions:
- Which domain do I typically operate out of?
- Which one am I comfortable with?
- Which one am I not comfortable with?
- In which domain do most of my conflicts and weaknesses lie?
- In what domain does the current challenge I am facing lie?
- Am I playing by the rules of that domain or the one that I am comfortable with?
Related reading
Another area where technical specialists tend to struggle and that differentiates effective leaders is mastery of context and avoiding constantly delving in content.
Being effective at the building block of conversations is another differentiator. I explore this notion in Effective Leadership as Effective Conversations and Deliberate Practice and Leadership Effectiveness.
Sources
- Stanley Deetz in The New Handbook of Organizational Communication.
- Coaching by James Flaherty.
- Leadership Coaching for Results by Sunny Stout-Rostron.
- Managing Oneself by Peter Drucker.
- Now, Discover your Strengths by Marcus Buckingham.
- Management’s New Paradigms by Peter Drucker in Forbes.
- Path of least resistance – Robert Fritz. This book dives into the details of the creative orientation.
- Leading Geeks by Paul Glen
- From Debate to Dialogue by Bruce Hyde & Jeffery Bineham.
- The widget philosophy is from Getting Things Done by David Allen.
- Language & the Pursuit of Happiness by Chalmers Brothers.