JP Ventura left an intriguing comment on The Sage that I’d like to explore:

Considering each coin has two sides, what would be the dark side (i.e., opposite) of the Sage?

What I find interesting about this question is the fact that I had not given much thought to the “dark side” of the 12 highly effective developers. The Sage, in particular, can have several dark manifestations as ostensibly, they are supposed to be a benevolent master whose primary interest is helping the members of their team grow. If we look at someone who is pretending to act in a way that could be confused with The Sage but is, in fact, the opposite, we get something like this:

• Someone who is pretending to be a master, but is not.
• Someone who is pretending to help their team grow, but is not.

I have worked with people like this, and the thing that jumps out to me the most is that – at the time – I had no idea that they were not what they pretended to be. It would take many more years of experience before I would be able to realize their lie. 

“Mastery” is elusive and resists being pinned down to one concrete set of attributes. Furthermore, if someone is a “Master” or not is entirely subjective to who is making the assessment. A typical way a “pretend master” would come to exist is a group of novices who perceive someone highly proficient as a master. High proficiency, however, is not mastery. In my article “How to Learn Upskilling,” I give my breakdown of what I think constitutes a master (loosely based on the Dreyfus Model of Skill Acquisition), which amounts to being the person experts look to for instruction. This description cuts through the problem of “relative mastery,” as at least novices are not confused that they are experts…usually.

I do have sympathy for the master-only-because-they-are-surrounded-by-novices, however. When you have a team of a dozen developers treating you like a master, it is easy to get confused so long as you judge yourself solely in that limited context. The antidote for this is to break outside of our statistically insignificant bubble by comparing yourself to known masters. Determining who the masters are, unfortunately, becomes very difficult in the software industry, as unlike older disciplines with well-known masters, we have to guess at who our masters are. With no one to compare themselves to, the pretend master becomes understandable. 

There is, of course, a litmus test to mastery that the “Dark Sage” should know if they were indeed a master, and this is where they become unforgivable. The Dunning-Kruger effect predicts that a true master doesn’t think they are a master, as true masters are acutely aware of what they do not know, and therefore think they know nothing. Consequently, I believe someone pretended to be a master knows they are not, yet they suppress this feeling because they enjoy the privilege that comes with mastery. They are dishonest, and they know they are aware of their dishonesty. 

So far, this “fake master” phenomenon has not yet become a problem. Sadly, it often leads to arrogance and condescension triggered by having their mastery challenged. The self-defense mechanism of the fake master, when challenged, is to counter-attack the challenger. The true master instead uses the challenge as a point of self-reflection: “Perhaps I am wrong?” Indeed, true masters are never defensive when challenged because they are not conscious of their mastery, and see the challenge as reinforcing their belief that they know nothing. The Dark Sage, therefore, not only provides weak guidance due to the lack of mastery but is arrogant and condescending due to their instinctive defensive reaction of, “Who are you to question me?” 

Perhaps the Dark Sage, even at this point, is not necessarily a problem. Perhaps they internally believe themselves to be a master, but keep that belief to themselves. The danger comes when they inject themselves into an otherwise healthy debate between two competent or proficient developers and tells them what they should do. Had they not intervened, the developers might have reached an optimal conclusion, but when the Dark Sage says, “It is best to do what I tell you to do,” the process of solution discovery is terminated. Over time, the consequences are dire: the project suffers from bad advice, and the development team fails to grow due to mistraining while also not being allowed to make their own decisions. In the absence of a Sage, a development team can still be highly successful by making mistakes, learning from them, and getting better over time. The Dark Sage shuts down the process of team self-improvement, and instead of giving wisdom, they give misguidance.

Now that I have thought this through, I wonder if the three items in the Identification Checklist for “The Sage” are sufficient. However, without some way to confirm that “The Sage” is a true master, perhaps these three items are the best I can do with any hope of keeping the list concise. If there is a suggestion for other criteria, I would certainly consider adding them. The maximum criteria I have used is five, and The Sage currently has only three, so the list can grow slightly without diverging from established standards.