New Studies Show Bob is Not All That
They call him the fireman. Oh sure, he probably has a title like "system's administrator" or "lead technician" or even lead developer, but his real job is putting out fires. Let's call him Bob. There's "Networking Bob" and "SysAdmin Bob" and "Developer Bob" etc. When the server goes down, call Networking Bob. The server needs an upgrade - "SysAdmin Bob's the guy. If a backup needs restoring, code needs tweaking, some work-around needs to be worked around, some proprietary Application is failing.... there's a Bob that can handle it. He'll come in with fire hose blazing and takes care of business. If a vendor needs placating.... ok... so call Sally, Bob's abrasive - but he does get the job done. The CIO thinks he worth 3 regular employees. Shouldn't everybody have a Bob? Well...
Bob has a couple of problems that are troubling. Like most people, he enjoys the little boost he gets from people treating him like the Amazing Kreskin. He loves those oohs and ahs when he can solve a problem that everyone else finds puzzling. It's nice to be the "go to" guy. Sure, it means he gets called in whenever anything goes wrong, but aside from interrupting his 15 month long game of WOW in his Mom's Twinkie-wrapper laden basement, he prefers to be on the job anyway. Being the "go to" guy gives you a competitive advantage. It means you are indispensable. Bob goes on vacation and things go haywire because no one knows what Bob knows.
This means that Bob is not just the "go to" guy. He's also the "go-to-and-leave-it-with-him" guy. He can do it faster if he's left alone. When a crisis emerges Bob isn't the team leader of a group who are all working to solve the problem, he's the tragic lone figure at his post - well, not so much a post... maybe a rack. Anyway, he's the lone ranger charging in, changing code, re-writing config files, editing data directly, using repair utilities and generally playing the role of manic Genie with glasses and a pocket protector. And he likes to "go it alone". He's not much of a collaborator. Being collegial means the accolades are evenly distributed instead of belonging soley to him.
Bob fixes problems fast and does not document the fixes. There's no post fix review of what went wrong and how he repaired it. Bob provides enough of an explanation to satisfy the non-technical Boss who needs it. Beyond that, Bob's work is undocumented by design. Surprising eh? I bet you thought that a lack of documentation was a result of time management issues. Nope - not in this case. Nothing Bob does is written down - at least not in a way that can make it repeatable - and Bob likes it that way. Remember, he's the compendium of knowledge at your company. He want to be sure he stays the "go to" guy.
Bob also gets to set his own agenda - at least some of it. Because he is such a productive employee Bob can pick and choose the stuff that receives priority. In fact, people and departments become supplicants to Bob. They need him. They need not just his skills, but also his favor if they want things done. They know that Bob can even circumvent company policy with impunity to accomplish certain tasks. The boss knows in the back of his mind, that if he ever loses bob, it will take him 2 months to recover from the loss of knowledge.
So, you think Bob is a figment of my fertile imagination eh? In the past 2 years I have on 2 different occasions been hired to go into a small to medium size company (less than 20 servers) and "clean up" after Bob (not "the" Bob - but certainly "a" Bob). The task was simply to figure out all the stuff he did and try and document it or tell the company what to do about it.
Recently, a 3rd situation arose where a "developer Bob" built a proprietary application that became the basis for a companie's business "Developer Bob" would bring in the install files on a CD and install it in the company offices, then leave - with the CD in hand. The application has hard coded links and database calls to external systems and no one really knows how it works. When changes are needed they simply have to call "developer Bob" and live with whatever timeframe and cost he dictates. Because he's become increasingly difficult to work with they would like to leave "developer Bob" - but they are frightened that to do so would mean jumping out of the frying pan and into the fire.
My Advice? When you see a Bob developing in your company, work hard to make sure he documents everything. Don't let him be the lone ranger. If he insists or becomes intractable, fire his butt and replace him with 2 eager college kids at half his wages. It will be more difficult in the short run, but you'll thank me later.
6 Comments
-
What happens when Bob is a contractor getting paid $150 an hour for his services? It may take him 30 minutes to fix the problem, but he'll spend an hour or more documenting it. How do you convince a tight-wad company to spend twice as much money on documentation as they do on the actual service?
It sounds like a no-brainer (it would actually *save* money in the long-run), but there are plenty of companies who aren't thinking about the headaches in the future, they're worried about the bottom line today. I know because I work for one right now. -
It doesn't usually take 1 hour to document a 30 minute fix - but your point is well taken. And it is exactly because of such short-sightedness that the fireman has a job. In fact, I would add that the company should usually be asking - "why do so many things break down all the time". In my experience the shop that relys on the fireman is already run pretty loosely.
Perhaps it's a lesson that is only learned by experience. Or perhaps only the wise can see it :)
Being a high price consultant myself (ha), I can tell you that I bill for both the fix and the documentation and include both in my estimate. -
so errr, where's the study then?
Not sure I agree with you completely, as not every 'Bob' deeply want's to be a 'Bob' because of their complexes and insecurities, as you make out.
I'm currently about 5 'Bob's at once, and I hate it, so I'll be moving on soon to somewhere that gives me the time (or can afford to) to think about and document things properly. I'll be spending the last month documenting the past few years and trying to find another mug to replace me.
At the same time I've recently had to manage another 'Bob' who part built a massive OOP application for us then pretty much vanished, leaving behind not a shred of documentation (not even comments!) and no-one knowing what the hell most of it does or why. So yeah, your last line of advice I can agree with whole heartedly. :) -
Adam - yes, I do sort of paint with a broad brush. I'm trying to be a bit absurd (and funny) to make the point. And I admit that many Fireman types are not willingly so - there's a certain business culture that forces them into that role. I think it comes from not realizing when your "small" business has graduated to the next level of management and process. People who start their own businesses have an institutional aversion to bureaucracy as well - and they see process planning as an expensive layer that will add to the cost. But if I may paraphrase Jesus, "...they strain at a gnat and swallow a camel" :)
As for you OO project with no docs I sympathise with you. I hope you have the source code. -
there are good bob and bad bob.
When all around you, you got only undocumented junk code and what you are asked is only a quick fix to make it work, why would you go into the trouble of documenting/explaining something that DO NO interest the company and/or the original "developpers" of the junk ?
they don't care, they just want it to work,
and they just want bob to solve the problem for a very low price or in a very few time.
They call bob, when they are stuck with their own mistakes.
Put some good bob(s) at the start of a project and pay them decently and then you can have something well done.
It's a little bit too easy to put all the problems on only 1 guy shoulders, and personnaly the attitude of saying "fire his butt and replace him with 2 eager college kids at half his wages" is what gonna make "a" bob just do the necessary work he is paid for, no more.
This remind me of the excellent post from Eric Sink
http://software.ericsink.com/entries/No_Great_Hack...
As I think you will always need a good hacker at one time or another, I think also you will always need a good bob at one time or another, I don't know how to describe it fully but I see these kind of guys as the ones who knows how to add the little things which transform something normal in something great. -
Zwetan - the goal here is to goad the "bad bobs" into documenting. It is to help identify that individual who uses his knowledge as a source of personal gratification ... it's also to help the business owner or client to see the importance of documentation and knowledge sharing. Knowledge sharing is not an option anymore - even in a small company. You simply must spread it around or your business can fail miserably - especially if it depends on technology.
I didn't mean to "put it all on one guy". - and we've all been in the situation where "getting it done" was far more important than anything else. I'm saying that, in the long run, a few less talented people with smaller egos will have a more beneficial impact on the bottom line than one very greatly talented person who enjoys his job a bit too much. I DO believe that Information technology brings very bright and talented folks who are also quite insecure to the forefront. Perhaps you don't see it that way - but I have seen way too many power struggles over knowledge sharing to believe it is a mere coincidence.
Sites to Watch
Aggregators
RSS
