In a recent post, I described a situation where one “brilliant” person is actually reducing the overall productivity of a software team. He’s writing lots of code, but no one else can figure it out. He claims that his teammates are just too stupid, and he’s got his manager convinced he’s an order of magnitude more intelligent than the rest.
Here are the three ways I usually see this play out once a manager decides to call the hostage crisis.
Some times the person hasn’t learned yet that elegant complexity is not the goal when writing code that other people will work with–and that writing comprehensible and as-simple-as-possible code is actually more challenging than writing a tangled mess that (sort of) works, as long as no one touches it. Mentoring and coaching on design and technical skills can help. It’s a matter of maturing in the craft.
Other times the person doesn’t realize the impact of his or her behavior. Many of us in the software field value “smart” over anything else…to our detriment when we actually have to work with others to produce results. Feedback (describing the behavior and the impact of the behavior) and coaching (building collaboration skills) can help here, too.
And then there are the people who are actively withholding information and/or making it difficult for other people to succeed. They are convinced of their own brilliance and believe that exempts them from the irritations of normal commerce.
When a person like this isn’t willing to change, terminating employment generally is the most effective counter measure.
If this seems harsh, step through the consequences of allowing the situation to continue. Or think about what happens when the indispensable person decides to take a hike (or gets hit by a bus). Sure, it takes some time for the other people to get up to speed, but the resulting situation is almost always more satisfying for the team and healthier for the company (in terms of risk and cost).
