We all know someone like this. That person who everyone else asks for help. The one the boss relies on to pitch in on every project that is floundering, even while spearheading other work. The friend who seems able to think about your problems and their problems, while you perhaps feel weighed totally with simply your own issues.
Some of us are the one receiving help, some of us are the ones providing assistance. At different times in our lives most of will wear both hats – but for some there is a pattern of taking on an extra burden. Within the workplace there is often one type of person who gets tapped to fill that role, the hyper competent.
At first this seems to that individual like an acknowledgement of their ability. A wished for recognition that they are talented in a way that others really need. This is not wrong. This is with out a doubt a primary factor in becoming the one who is relied on. This person is highly capable, engenders trust and often delivers on expectation. However this can cause an issue both for the employee and the company.
The burnout this can cause, or the lack of productivity due to being spread so thin, are well worn paths. I wish to examine the other side of the equation – the risk run by the organization.
Organizations or groups that have hyper competent individuals come to rely on them by nature. If it becomes too common, if there is an underlying issue that might be masked by the borrowed competence of this individual. How important does it become to understand the reason this person is getting so much work? We should all be aware that relying on a small subset of the company is risky. If it is simply the blinding talent of one person,that may not be an issue. But if this bandage is covering up the festering incompetence of their peers it becomes imperative to keep an eye on the situation. Where there is implanted competence, we must be wary of infection in the potential gaps that competence covers up.
Sometimes the question is not “how do we solve this problem?” but “what is the actual problem?” Some six sigma minded types would tell you that the first step to solving any problem is diagnosing it properly. They are not wrong, but that way of phrasing can be a bit misleading. I am not talking about problems that need a little fishbone diagramming and some root cause analysis. What I am talking about is the situation we find when ambiguity surrounds an issue – when you are not even sure what direction the solution should lie in.
It may be easier to think through an example. Imagine looking at a changing industry (perhaps insurance, banking or even long haul trucking) and being tasked with answering the question “what do we do next with product A”. Now mix in a little bit of “by the way, product A will not be profitable in 3 years and may not even exist in 5 years” and some “it is part our core business.”
How do you begin approaching this problem? Maybe some data analysis? Maybe some expert consultants? Hold some innovation tournaments?
I think before those questions there is actually a more urgent and arguably more important issue that needs to be addressed – who do we want doing this work? When ambiguity arises, who leads us through the fog? I would propose the leaders needed in these situations are comfortable setting strategic direction without need to build an edifice of system. What the leader needs is an agile mind and the ability to act on an informed opinion. Or as I have titled this, a quick wit and a strong point of view.
Have you ever been on a project where it feels as though someone is unwittingly playing defense against a successful outcome. Either they are doing things that actively run counter to the group or are doing things poorly that require others to pick up their slack. I do not mean those who are trying to tank a project, I mean those whose incompetence on the project produces a result indistinguishable from sabotage. What do you do with this member if you are not responsible for assembling the team?
Generally in this situation there are a few basic options:
- Advocate for that person to be removed from the team.
Now there there are different ways to go about this. I don’t recommend advocating to the whole group in the middle of a meeting in the presence of this individual. This may produce results, but it also produces the undeniable perception that you are a total douche. Instead I recommend speaking with whoever was responsible for staffing the project. Approach them one on one and be fair but straight forward in your words. Above all make sure it does not come off like you simply don’t like the incompetent individual, even if that happens to be true.
- Assign them work of the lowest importance.
If the above option is unavailable for whatever reason, or if you would rather not pursue it, you can always change the kind of work assigned. Perhaps this person can schedule and build agendas for meetings. They can take notes and follow up with people. Perhaps there are work streams that are “nice to haves” rather than “must haves”. This requires a bit of the benign deception and people skills that make many managers great, the ability to decrease someone’s importance to a project without them feeling slighted enough to blow up.
- Mentor them to bring up their performance.
I personally feel this is the ideal state, but because of that it of course is the most difficult to bring to fruition. It would be excellent if you could bring someone from dead weight to contributor while they are on your project. In order for that to happen three things must be true: the participant must be willing, the mentor must have at least a little skill in teaching others, and there must be enough time. This is the calculus that you must perform if you want to pursue this option. Is this person willing and do we have anyone able to bring them along in time for the value to be recognized in this project? That is a tricky and situational decision, but the rewards offered if successful should make this a consideration each time.
- Stop assigning them work.
I personally find this to be a bit passive aggressive, but some may see it as the only possibility in their circumstance. This is pretty self explanatory, you simply stop assigning work to them, or have someone always paired with them who is actually responsible for the work. This has a high risk of turning the incompetent member of your team into a disgruntled member of your team. That can cause friction in the working environment that may spill over, so caution is required if you decide to go with this approach.
Obviously this is not some panacea, but by weighing out the options available you can drive the result that provides the best outcome for a given situation. Always consider the risks that accompany each solution and take mitigating action at the same time you start to implement your solution.
A few weeks ago I overheard a common complaint while in a meeting with technology experts.
“They don’t know what an MVP is. Our business partners just aren’t thinking as well as we are about these things.” The promulgator of this complaint was looking around the room ready to soak in the approval of their peers, who certainly would agree that “those other people” did not understand. Indeed most of those centered around this table nodded and smiled knowingly. While this situation of “us vs them” is common, the issue that arose in my mind from this comment was actually their use of MVP.
An MVP, for those who have more exciting lives than mine, is a Minimum Viable Product. It is a phrase that became popular in the software sector around 7 years ago. A basic definition would be “a product with just enough features to gather validated learning about the product and its continued development.” This definition is vague for a reason. While I am not going to get into too deep of a discussion about what qualifies as an MVP, it is important to know that there is no formula for an MVP. The MVP in any situation will change based on what is attempting to be delivered.
Going back to the comment I heard, I felt a disconnect around what was being defined as an MVP. The picture above, taken from here, is a general metaphor for what the goal of an MVP is. The technology being delivered worked, but did not provide what the business needed to give to the customer. In the diagram you can see that the MVP asked for was a skateboard. This is because what the business needed was something that moved the customer. In this situation, the individual was complaining about the business partner who was asking for software. What they were getting from the technology partner was an excellent wheel, whose code ran smoothly and would be a critical component of the car to come. But you cannot give your customer a wheel and ask them how well it moves them. My complaining colleague was assigning blame, but not accepting that it was the technology group that had misunderstood the meaning of an MVP.
Thus far we have noticed that there is a disconnect between to business partners and the technology group. Next we will look at what may cause this disconnect, and finally we will look at ways to overcome this disconnect.
In business, efficiency is often placed on a pedestal and revered as a demigod. Six sigma could serve as its Franciscan order. Agile was born of the pursuit of efficiency. There exists, however, a vast amount of work that lives in the qualitative and communication based setting known as a meeting. It is here that the rudder event occurs.
A rudder is small, yet controls the whole course of the vessel. In the same way there are often small actions, questions, or comments that control the whole course of a conversation. Learning to control these events, and guide conversations without having to dominate them is an important form of efficiency. The length of a conversation is not proportional to the value of its content (I would like to coin this as the McClain Axiom) and nothing exemplifies this more than rudder events.
Imagine if you will a conversation about implementing a new workflow. Because this will only be of interest to a few in the room, the conversation can definitely list from its destination without much effort. How can this be prevented? By keeping a steady hand on the wheel, with timely and direct comments and questions that keep conversations focused. This does require someone to be monitoring the conversation more than providing content, but in almost every meeting there are those who are there for the purpose of providing direction. An expert application of rudder events saves time in every meeting, and keeps people engaged. Saved time equates to efficiency.
The window view is of traffic and a park a little further off. This tenth floor window peers out of a modest conference room where a group of successful men and women are mulling ideas of progress and transformation. The group of a dozen or so has segmented into two groups, one on each side. Both sides have circled up to throw around their dreams and weigh them on the scales of opinion. Collaboration on a superfluous level comes easy but true collaboration is fleeting. With success comes a well won ego.
The ego is Homeric in flavor, as the Greeks believed that the strong deserved to be the proud. That an ego wasn’t hubris as long as it was supported by a record of success or a true ability. Now these managers lack the pantheon of gods telling them it is fine to continue as they are, but they seem to have overcome this issue by the monetary rewards or professional titles they have received. The observer however may have difficulty with this. How do people know that these egos are just?
The world proposes a simple test. Listen to the ideas, listen to the words. No epics or ballads exist to tell of heroes, men are left to search for themselves. In a conference room, on the tenth floor of a simple office complex this test was in motion. Testing their thoughts against each other these men and women were writing their own modern day epics. Epics written in strategies and progress. Having an idea accepted and acted on would cement one’s right to an ego. This ego justly won would be attested to by the future they had set in motion with their own words and ideas.
Years ago I had a seminar on “Greek Mathematical Thought and the Origins of Algebra“. While that topic may not fan the cockles of the average heart, I found it to be a fascinating study in how ontology (theory about the nature of being or the kinds of things that have existence) can shape our scientific tools.
To cut right to where I am going with this, consider the case of a child growing up right now. Whereas technology used to be the domain of wealthy adults, now it has become much more available to children and the middle class. Consider children growing up with a digital device such as an iPhone, tablet, books on the computer or digital learning games. It will be fascinating to see how their minds are shaped by these experiences approaching the problems of tomorrow. Issues such as virtual reality, digital privacy, and access to internet as a right rather than a privilege, are all potential situations where generations may have a different way to conceptualize truth simply due to the way their minds were exposed to technology while growing up. I am fascinated as to whether an ontological shift will occur over the coming centuries as the digital and physical continue to track towards each other in the future. I am not nearly informed enough as to whether we will see a collision between the two or if they will act as an asymptote drawing ever closer but forever distinct.
I would never declare any of what I have said unassailable truth, but I am continually ruminating on the idea that how we conceive of our world will allow us different glimpses of the truth that may underpin human understanding. Its an exciting and sobering idea that there may be ideas of which I could not conceive because the understanding of the world formed in me from my youth could be completely different from someone a mere twenty years younger than me.