Why Office Gurus Are Bad (And The Buses Who Hit Them)
Filed Under Human Factors
Out of necessity, it is common for software teams to have its members silo themselves into specializations. One person maybe, the “reports” guy, while another maybe the “database” guru. Allowing members to specialize can be dangerous for a number of reasons.
1. Presents the “Hit By Bus” Test
If you haven’t heard of the bus test it’s pretty easy:
If person X was hit by a bus today how well would your team survive?
I have seen teams fail this simple test time and time again. As a need for survival, either individuals choose (or are assigned) to work in very niche partitions of a project or in a legacy code base. The result leads to a knowledge bottleneck which can present dangerous situations to a business.
No lie – I met a person who self-obfuscated all of his variable names to undecipherable “a1”, “b2”, and “zzz”. He kept a secret print-out map such that only he knew the real variable names. He said it was for “job protection”. He left the company on his own freewill, taking the cheat sheet with him, rendering the code base worthless and costing the company hundreds of thousands of dollars to replace.
2. Creates Tunnel Vision
When people specialize they tend to get tunnel visioned into their niche. No longer does the generality of development interest them, but only their one specific technology. As the saying goes,
If all you have is a hammer, everything looks like a nail. – Bernard Baruch
Wanna hear about another guy I have met? Of course you do…
Once upon a time, I knew this other guy who only knew Lotus Notes and XML. He spent all his time and energy learning every single aspect of both technologies, but not an ounce of energy towards different solutions such as Java, .NET, or Python. The result? Every single project he was given resulted in leveraging Notes and XML. Guess what happened next? Yep, he left his company too…thankfully he took his code with him…
3. Yields Lack of Community
Developers by nature tend to stay in their shells, and if given a reason will do so even more. As a result, having office gurus does not lend itself to a sense of community or team. Since each is an individual with no technical peers a dog-eat-dog environment starts to build.
So what is the antidote to the office guru? A healthy blend of:
- Knowledge Sharing
- Open Minds
- Code Reviews
Recognize office gurus for what they are – liabilities. Take advantage of the situation and learn from their craft as well, not only will you extinguish any knowledge bottlenecks, but you will also become more valuable to the company than the office guru.
9 Responses to “Why Office Gurus Are Bad (And The Buses Who Hit Them)”
That’s so true, and very common in the SMB sector.
If I were to get hit by a bus today, I honestly cannot imagine how my company would survive. I try to be relatively rigorous about documentation, backups, source control, etc. However, any attempt to explain these things to management is always met with glazed-over eyeballs.
So, in the event they’re needed, it would probably take weeks or months for someone to come in and figure out what’s what anyway. Very frustrating.
I don’t think you can eliminate the local wizard phenomenon entirely, but one technique I have used to force people out of their is bring in a consultant or contractor to work the guru. The third party reports back to me and I get a leg up on areas of mystery that can be cleared up.
My advise is that if you have someone who is actively working to obfuscate code is to hold a review, fire questions off at the guy, give him a chance to fix it, then fire him if he doesn’t. The pain of putting up with someone who is essentially blackmailing you is not worth it. A clash in the long run will be inevitable and you might as well take it on in your own terms when you are prepped.
It’s sad that people work so hard to work against each other, but life is short so gather those around you who won’t knife you in the back.
[…] Why Office Gurus Are Bad (and the Buses Who Hit Them) (Max Pool) […]
@Sensei –
It *is* sad that people work so hard to work against each other, but in the end it is one of the many ways we gain a false sense of security.
Like anything else there needs to be a grey area. While I don’t want a sole Reports guy and a sole Database guy, I also don’t want them to be an exact copy of each other’s knowledge. Too much time would be wasted making sure they both know everything compared to the very small risk of one of them being hit buy a bus, leaving the project with very short notice, etc.
Max, that was a really memorable post. You broke it down well.
As to the first guy, I think the co. should have sued him for the cheat sheet. In a situation where a company pays someone to code, the resulting work is their intellectual property, no? (And no, that’s not legal advice/a legal opinion.)
@Gab –
To be honest, I don’t know what ever happened, it was kind of a friend-of-a-friend relationship, but if I am not mistaken there was a lot of conversation with him shortly after he left…
Having been in the position of ‘office guru’, I have to say it all depends on how the guru in question deals with his position.
I for one have gone through great lengths to share my knowledge, educate juniors and documenting virtually everything I did, and most of all, encouraging them to have a go at it themselves. I rarely made any decisions without talking them through with coworkers, mostly just to keep them involved (plus talking to yourself gets old real fast…).
Unless the person in question is a sociopath or severely autistic, most office gurus will consider sharing the knowledge part of their mission (or even better: the best part). What usually gets in the way is an excessive workload, giving a team very little time to share stuff, not the attitude problems of the specialist.
In other words: I don’t think the office guru is the liability, but the manager that creates an unhealthy team dynamic that allows/forces specialists to isolate themselves.
Stop Refactorbating or You’ll Go Blind!
Stop Refactorbating or You’ll Go Blind!