The insidious danger of the lone wolf control freak sysadmin Often within teams there is a certain shared camaraderie and level of trust between team members. They chew the fat, have a moan or playful poke at other staff during a day’s work. They cover for each other and stuff usually gets done. At the end of the day, they spend more time with each other than family. Occasionally, …
To be fair to the person, it wasn't their fault, the department was massively under resourced, running several projects and he was given a tight deadline. Fast forward a few months, the person leaves the company, and nobody knows how the bloody system worked.
I'm still sorting the mess out - Its been a very expensive mistake for the company, but the main thing is lessons are learnt, we're bringing in several new people, I'd says its a bonus as in the long run, our jobs should be easier!
On a different note, we need a new News section, called Copy'n'Paste, for blog posts!
I lost count of the number of asshat companies or project managers who complained (sometimes officially!) about me "wasting time" doing things like writing documentation or correctly filing change requests (which would also involve amending the documentation).
If you're prepared to tell people, or provide them with so few resources as to make it impossible, that documentation and all the rest of it isn't needed then a) more of your knowledgeable employees will leave and b) you'll deserve the shit you have to pick up when something inevitably goes wrong.
"but SME's rarely have the budget to do everything as "best practise". I mean, Change Management?"
The real issue is that "change management" is really all about: thinking about what you are going to do before you jump in!
Many SME's (and their suppliers) think they don't have time and budget for "change management", but fail to see the time lost due to both themselves and their suppliers simply jumping in and fighting fires set by their cavalier approach...
Change what now? The last place I worked at didn't even have a test server/site until it was insisted on because the it department had doubled in strength and kept treading on each others projects (and by double in strength I mean there was two of us). Every single improvement to anything had to be fought over tooth and claw (because it was always done that way.. Including using a foxpro database for the accounts package. 1gb limit constantly hit n all that) in the end got tired of it all and went for a new job.
Now I get to pick and choose what goes in, make improvements and on a better pay packet.
And when I left the old place I gave them documentation on pretty much everything. Still haven't seen any work on anything I left them with though.
Yet again.
No experienced IT manager would let a sysadmin get away with "Tim's" behaviour. Comprehensive and usable documentation of all configurations, procedures, problems and resolutions, etc is just about the most important part of the role. Letting someone get away with not doing these tasks, because "they work hard, know everything and get things fixed quickly" is a sign of lazy and/or inexperienced managers who should not be managing sysadmins. As any company who tolerates this kind of behaviour will find out when their genius-in-residence moves on to repeat the same disaster somewhere else.
I have seen this happen in several places myself, and it also applies to self-described whizzkid software developers who refuse to document anything or share knowledge with others, leaving a huge incomprehensible mess behind when they leave.
This post has been deleted by its author
Ironically, you usually find that the, "whizzkid", wasn't as clever as he thought, and that the configuration was underperforming anyway.
Yep. I work with one. Lets call him Dave. Dave loves to tinker with faddy toys and to try refactoring other peoples code to "make it better". The only problem is that most of what he brings are indeed passing fads, that now have to be redesigned out of the system in favour of the products which should always have been there, and that he isn't half the coder he could be and already thinks he is.
With regards to the Tim in the original article... I used to work for a company with a Tim who had been there decades. Literally nobody else could change so much as a router configuration, making him utterly irreplaceable without serious disruption. The company continued losing staff over it, and the Tim continued demanding ever higher pay. I've no clue how that ended, having pulled the rip-cord and floated off before impact. I dare say it won't have ended well. Poor management, and lack of professionalism on Tim's part, were not a good mix.
Yes, I've seen this as well. My experience of this was in a hell-hole of a now happily-defunct ISP that was an offshoot of a now also happily-defunct PC box-shifter. The management in this ISP was dire, bullying and utterly incompetent. Planning was a dirty word.
I was appointed in the second wave of techies recruited, the first wave including a number of genuine wizards, and some extremely bright but only half smart ones. One of the latter we shall call "Johnny Random", a soubriquet earned by his habit of randomly altering system-critical stuff last thing on a Friday afternoon.
Johnny Random was a brilliant Perl coder, self-taught with a background in Assembler coding. He had to be brilliant to be able to work with the god-awful Perl bodges he created by way of scripts; hideous layout, no code indenting, no usable commenting, and every variable being world-viewable and very frequently re-used throughout the code for different things.
I got given the task of sorting out one of his hideous botch jobs, and it took me days to separate out the worthwhile bits from the dross, apply a decent code style and re-write it to take account of the many optimisations built into Perl for memory management and so on. My end product ran faster, worked more cleanly and was infinitely more maintainable than the original dross. It didn't get me a raise, however; it wasn't that sort of company. I left soon afterwards, vowing never again to work for such utter arseholes.
There seems to be two kinds of manager: the one who is on to this sort of guy and keeps him in his box, or gets him out, and the other who says 'hey, as long as the work is done.'
I see many commentards sharing their personal stories and I resonate to their frequency. I always thought these Colleagues from Hell were only to be found on the Dailt WTF until I worked along side one of them. After a weekend cleaning up his sh*t he'd done at 3am one morning, high on something (perhaps his own wondrousness), I decided that, since he wasn't going anywhere, I would be. Our manager was too busy looking like he ran a taut ship actually to do it. So I packed by coffee mug and left. And, oddly, I found I stopped grinding my teeth in my sleep.
everywhere
The 'star' player who refuses to write up documentation , then snoozles upto the management with ideas hes 'had'(in other words , pilfered off the rest of us) and finally can be seen working 12-14 hr days to prove to the management how valuable he is.
And the management pay him as such.
And nobody in the manglement ever thinks as they send just him out for training on new technology "What happens if this guy DOES get hit by a bus?"...........
Need a bus icon
Not just guys, either.
Last place I worked had a female sys-admin who wouldn't let anyone touch anything, came in early/worked late/weekends just to prove how "valuable" she was.
Management just hoovered this up and couldn't see the danger inherent in this. As far as I'm aware, nothing ever did happen to her, but if she fell under a bus etc then the shit would have hit the fan...
I am also guilty of this, though. Back when I was the lone sys-admin at another place (and by this, I mean there *was* no-one else) I was working late to make changes. Decided I'd had enough so left to come in early before anyone else the follow day, but got knocked off the bike on the way into work. Not seriously injured, but it meant people were locked out of the system until I limped in after lunch to finish the job. Any sympathy I had in being knocked off the bike was lost in being chewed out for leaving the system in that state to start with...
> Back when I was the lone sys-admin at another place (and by this, I mean there *was* no-one else) ...
I know that feeling - it's a "difficult" life.
Manglement never seemed worried, but I was - for one thing it meant never being able to switch off as there wasn't anyone else to leave things to while on holiday (or even at home trying to have a normal home life & sleep !)
But I did try and document stuff as best I could - I had a live database of all the patch cords and ports in the rack, and I had a nice diagram with ALL the LAN and WAN details on it. AFAIK neither of those were maintained after I left.
But where I work now is in some ways worse - I'm no longer the lone techie since it's a tech business - but while we have systems, the very worst offenders for completely ignoring them are the manglement who (wrote and) imposed them. I can guarantee that if I'm working on jobs managed by certain people (like the MD) there won't even be a job in the system to book my time against. As for another of the directors, he thinks he's gods give to coding - but devs that have come, got p***ed off with him, and left, have pointed out that "his code is not that great". He flames people like me for having small gaps in documentation - while building systems that as far as I know have no documentation whatsoever, and not updating any systems we do have.
It was sooooo satisfying when he barked at me for not having documented something to be able to point out "but I have, it's right here in our Sharepoint system ..." Didn't get even as much as an OK then, let alone an apology.
Anon for obvious reasons ...
"...came in early/worked late/weekends just to prove how "valuable" she was."
Disclaimers: I don't work in IT but I do have to think about people's motivation a lot. This comment is not genered especially, applies to Tims and Tabithas
What drives this overwork and inability to share/work with other people? Is it a cynical strategy to increase wages? Is it insecurity/bad attack of imposter syndrome? Or is it simply never having learned how to work with other people? Or all/any of these depending on the specific Tim/Tabitha?
Consequent on a diagnosis, has anyone devised strategies for managing the issues short of waiting for the Tim/Tabitha to disappear or jumping ship themselves?
Just wondering...
Coat: mine's the one with the herbal tea and essential oils in the pocket.
Pour petrol on it.
Exactly. If the team in the story was gifted with any ingenuity, they could have made Tim's life hell.
Take the example of not committing router config to NVRAM: it shouldn't be hard to make sure Tim gets to reconfigure one router an hour throughout the day and night.
"What happens if this guy DOES get hit by a bus?"...........
We have a little, informal, ceremony where we burn conspicuous clothes in honour of the departed, light cigars and all have a cognac to dull the terrible, terrible feeling of loss. After that, we collect our cellphones from the desk drawers and get back to work.
We have a little, informal, ceremony where we burn conspicuous clothes in honour of the departed, light cigars and all have a cognac to dull the terrible, terrible feeling of loss. After that, we collect our cellphones from the desk drawers and get back to work.
Isn't there also a ritual redistribution of stationery items such as staplers involved, and a general shifting of chairs in case the recently freed one proves to be a better fit for someone's rear? Or is that left until the end of the day to give the chair the chance to cool down first?
:)
The 'star' player who refuses to write up documentation , then snoozles upto the management with ideas hes 'had'(in other words , pilfered off the rest of us) and finally can be seen working 12-14 hr days to prove to the management how valuable he is.
And the management pay him as such.
I highly recommend to people who hire people to read this book. You wouldn't believe the "oh wait.. *facepalm*" response when you read it and realise you've come across the issues described before and suddenly you realise what is actually going on.
I've read it front to back a bunch of times and I can tell you that what you're describing could easily be one of the case studies in that book.
"If you don’t have a Wiki-style document repository where people can add designs, hints, tips and known issues, you really are missing a trick."
Maybe it's just the places I've worked, but I've never seen a decent internal Wiki. In my experience documents get strewn across multiple locations: network drives, source control, Readme.txt files buried alongside source code, Sharepoint documents, Sharepoint Wikis, other Wikis, etc. The idea of having one Wiki to unify them all reminds me of https://xkcd.com/927/ - just replace "standards" with "document repositories".
Yes, internal wikis can very definitely live up to expectations. But the first thing to emphasise is that sharepoint ≠ wiki.
Particularly with managed service or on-call, a good way to build up your wiki is to put your new engineers into the oncall rota early on, but with an experienced engineer to also be on call if the newbie gets stuck. First port of call is the wiki. Then, if still not sure how to deal with the alert, call the experienced engineer. Nothing like that for giving the experienced engineer an incentive to update the wiki!
Get your new engineers to document anything that they have had to ask about. Makes it easier for next time.
Employ engineers in their 40's - need to wiki everything as you want to remember the next time you have to deal with an alert at 3am, and the memory is not what it was!
Move people between teams - again an incentive for making the wiki better while you try and get up to speed.
Make the wiki easily searchable - if it is easier to search than ask, people use the resource. The more useful it is, the more people are likely to update the wiki.
Change the culture to one of expectation that it will be on the wiki. As a sysadmin, get fed up of answering the same question, and wiki it - then point people to the wiki.
Ideally you make it into a resource that people use in the same way they do Google. Why not use it?
> In my experience documents get strewn across multiple locations: network drives, source control, Readme.txt files buried alongside source code, Sharepoint documents, Sharepoint Wikis, other Wikis, etc.
Have an upvote from me.
We use Sharepoint - but even then there is stuff that can be put in something like 6 different places. It's documentation for a customer's system - does it go in the support folder for that customer, or the folder of network diagrams, or the folder of procedures, or the folder of access lists, or ...
ANd when I;ve drawn detailed network diagrams (with IP addresses and stuff like that), it gets converted into a meaningless "pretty picture" with no useful information whatsoever (OK, I can guess that they have a network with a server and some workstations, so what ?) because the useful information is considered to be "clutter". SO WTF is a network diagram for then ?
And for good measure, whenever we point out any issues, the result is usually to add another system - not fix what we have.
> We use Sharepoint
Colloquially known as "Wherepoint?" in our firm. Lots of documentation gets "added" in there (if by added you mean "I pasted this into a word doc and sent it to a sharepoint page somewhere") by project managers with no metadata, hierarchy or indeed a half-functioning search system. Navigating it basically requires you to keep your own hierarchy of bookmarks.
We're encouraged to use it by the bods upstairs though because our actual functional fully-indexed CMS/wiki/document store/integrated change management tool is an in-house bespoke application that isn't buzzword compliant, hardly ever needs any maintenance and doesn't require 64GB of RAM to get you as far as Hello World.
Personally, I don't believe that a Wiki can ever be an alternative to a properly structured document management system.
The problem with Wikis is that they're almost impossible to impose any structure to. Whilst they become a good place to drop hints, tips and the various miscellanea of wisdom, using one to be the primary document repository leads to you never being able to find anything without using the search function. And using search is fine until you get to a certain critical point where reading through the myriad of hits for common terms, especially if more than one team are using the wiki, becomes a burden in it's own right.
I suppose it is possible to impose a structure by convention, but such systems are easy to get wrong.
I prefer a system where the storage method imposes structure on the documents, at least for the formal documentation. So, you define a documentation template that includes all of the sections you're ever likely to need. Requirements, Design decisions, implementation details. Implementation plans, Operational procedures, Support procedures, Disaster Recovery etc. etc.
The idea is to try to cover all the bases, so define more sections than you're ever likely to need, and just miss out sections that are not needed for certain projects.
If you store this in some hierarchical storage structure (I actually like just using a tree-structured file system) with change control at every level, finding particular documentats becomes easy. And writing the documentation becomes easier too, as you can populate a new branch for a project from a pre-defined template, and all of the boring dross of getting the look-and-feel correct is done for you. You can immediately tell if a particular section of the documentation has been written or not.
And with regular section numbering and naming conventions, you can 'slice' the tree horizontally to get the first cut of a set of operational procedures for many systems to generate a new document for, say, your operators quickly.
I first saw this done for a UNIX system in the late 1980's, using the directory structure to organise the files, shell scripts to populate and customise a new branch from a template, files containing the sections written in troff/memorendum macros/pic/tbl/eqn/grap in each directory, and SCCS as the change control in each directory.
IMHO, it worked so well that I've adopted something similar whenever I've needed to write something in an organisation without it's own documentation standards.
I know that there are a whole slew of tools that will allow you to do something similar (even with MS Word documents in all their binary obtuseness), but I think this fits in with the UNIX way of doing things. And for search, well, you've got find and grep, and everything is text! And you can always create a permuted index with ptx if you're using troff.
Wiki is just a tool. How you implement it is totally up to you.
I have implemented enterprise grade wiki (Atlassian Confluence) in two different companies where I worked and it was great success. We had clear hierarchy, templates, and naming conventions. The thing worked as a charm to replace mess of the random files scattered all over the place.
At the same time I worked with free Twiki and it was an absolute pain. You get what you pay for I guess.
This post has been deleted by its author
IT dep't in new firm completely out of touch with business.
Grafting really hard to meet client demands, no else else seems fussed so users are approaching me direct.
Too many hours in the office, lager really helps me unwind......
Burn out.
================================
Sounds like terrible management though.
Anyone who thinks this is a new problem that came about post-server-farm IT needs to see the seminal video course by Ollie White on Materials Requirements Planning, made about 45 years ago.
You are looking for the bit where he discusses those people in the (non-IT) departments who have a solid reputation for knowing what the factory is doing before the computer does.
Seeing that lesson at an early stage in what I laughingly call my career saved me a lot of head-against-wall banging over the years.
got one in our group. He gets the job done, but doesn't follow protocol for updating drawings etc. That's only cosmetic... so he says, until there is an emergency and we all scramble to find the needed configs or drawings. I'm glad I've played the C-Y-A game before and know what I am responsible for maintaining. "It's not my responsibility, but I'll have a look" is my motto. I get lots of milage out of it, and people understand who was responsible. Tim?
WTF because it fits!
A couple of times I've seen a parade without a leader about to walk over a cliff and I've said, 'I'll rescue it, but you guys have to know this is NOT how to do it. The price of me not acting now will be worse than me acting, so I'll do it and I'll leave documentation." As it happened, nobody gave a toss, as long as it was fixed NOW, so I left the documentation in the logical place and wished them luck. The correct response, once the crisis (which never should have happened) was averted, was to have addressed the problem properly. But as far as management were concerned: case closed.
I do firmware, not IT (well... some IT but not much), but most of these principles translate. My own motivation is that I don't want the next guy calling me up all hours asking questions. And in 6 months I don't want to be reverse engineering my own work!
Usually, the keys get tossed on your desk. I'm the one IT person in a branch office of 500. I'm supposed to be 2nd and 3rd level support but I get my share of walk-ins and drive-bys. I've tried documenting things but no one really gives a damn... until I'm on vacation/holiday and something hits the fan. Even when you tell them where the docs are, they get irritated that you don't have all this knowledge in your brain, at the ready for their beck and call.
In some ways, it's great. Management and the main offices with a large IT staff is 300 miles away and leaves me alone. But the downside is, there's no support. The conversation "over the wall" about issues and fixes isn't heard. Once a year, management gets huffy and wants all the documentation you have, you get it to them and they promptly lose it or file it away never to be seen by human eyes again.
I also know that when I'm gone, the staff in this facility will be screwed as no one will know where anything is, even though there's a map on my office wall detailing where files for various things are kept. For example, I have file in SharePoint detailing what's in the server room, connections, those little nagging details like why the green cable isn't plugged into Router X but hangs next to the port. A hard copy hangs on the wall next to the door (inside the room). None of the server/network types ever reads it. They come to me.
Yeah, there is an incentive to this. They won't ever fire me unless I screw up royally. If they do fire me or I quit, the docs are there for whoever replaces me. But chances are, he'll never get a chance to read it since policy here is to seize all files (printed/electronic) and archive them far away. So he'll get the keys and have to learn things on his own with minimal help from anyone else. Meh.....
If you are the only one who holds the keys then good luck when your weekend/vacation is ruined because of some outage in the office.
One thing about my current job I absolutely love is that there is a Jr admin that can take over if I'm unavailable.
just because the CFO's niece got her MBA does not make her Sys Admin materiel.
Or interned at Google last summer. Skills need to be demonstrated and proven when everything is on the line.
And if you build an organization where a single individual is "to blame" for failures whether his/her decision or explicitly ordered by Management, you cannot expect that individual to risk sharing with the new kids who will be protected from any fallout of their mistakes or sabotage.
It's always easy to toss the Sysadmin under the bus. Just label him a "lone wolf" when he doesn't buy into the latest trade show hype and everyone who's been caught with unlicensed software and/or is frustrated about social media blocking policy will happily jump on the bandwagon.
You don't hire a sysadmin for their expertise then refuse to utilize it.
This is where the problem lies - poor management of rogue employees. A lone wolf control freak admin is a nightmare to both the IT team, and the wider organisation.
They usually suffer from 'delusions of competence' (the Dunning-Kruger effect) but also work hard on maintaining a good persona to those higher up in the organisation as a protective shield against recriminations.
If you ever see this behaviour, and you are their manager then treat them like a cancer and get them removed! If you see this behaviour from others within the team, but don't see it being addressed by management, then leave, because it's never going to get better.
... on a few occasions.
When management decided to cut funding for an IT system to the bone, I was the only person left who really knew how it worked. So I carried on as the chief cook and bottle washer. It was I who brought up the issue of getting run over by a bus when seeking an assistant as backup.
Finally, they relented and brought in a guy who was (supposedly) fluent in Perl. A lot of our system's glue code consisted of Perl. So, on his first day on the job, I sat him down with my documentation notebook and a read-only account on the server to show him the bits and pieces. I figured I'd let him walk through one function, looking at my notes and the code and get him used to how things were put together. After a few minutes, he asks, "What language is this?" With the following first line staring him right in the face:
#! /usr/bin/perl
Hopeless. But then that was the idea (I found out later). The CIO was actively strangling all in-house IT projects to force management to outsource them to a few firms he had interests in. So I waited until the next round of layoffs and stepped out. A few months later, thanks to my name being plastered throughout all the code comment sections, I was contacted by one of these firms to bring them up to speed on the system with a very lucrative contract. Good times.
Sometimes 'Tims' are created by incompetent or corrupt management.
Lone Wolf..
I understand where they were trying to go with the article, but what was missing IMO, was the other side of the coin.
Were the co-workers competent? Could they not keep up?
A lot of the time, the new Tim, Randy, or Jane was hired due to in-house not being able to handle the issues. If inhouse was paying attention, this should not happen. Sure he should not be the only guy, but then again, if your his co-worker, why are you not the 'guy' or 'gal' as well?
Every network, programmer, exchange guy thinks they are a god. Its complicated stuff, so hire people who can handle it.
- Jo
1. By the law of averages, at least some of the team will be either already competent or teachable.
2. So it is fair to say that the "toxic lone wolf" is one who hoards information and doesn't share it within the team, and actively works to prevent the others from getting anything done.
After all, if one really is the most competent person around, what harm is there in sharing information?
And the reality in a team is that people tend to be different, and each one has their own area of competence (or in the case of junior members, potential to become really good in one area or another).
Personally I've tried to stick it out in this kind of situation, hoping that the person in question would change, but it wore me down and in the end for my own sanity I had to quit.
"Personally I've tried to stick it out in this kind of situation, hoping that the person in question would change, but it wore me down and in the end for my own sanity I had to quit."
You're missing the point.
They see no reason to change.
This system works just fine for them.
It matters not if the co-workers are less competent. What matters most is that the 'competent' new employee works within the team as a team player. That means that if they feel the others are not pulling their weight they let them know and give valid reasons. This may lead to some friction but it has to be put across to the team that it's for the benefit of all. It's not a selfish thing to want to do well. But being a lone wolf is harmful to all and a selfish act.
The flip side? I am the guy people hire when there is a mess they don't know how to clean up and my method of operation is to fix the problem, make the solution as idiot proof as possible(sanity check inputs, informative errors, auto generate configs when possible, leave multiple very obvious warnings about gotchas in places where the next admin will see them etc). then train as many people as possible on how to deal with my solution.
In my experience, the guy who walks in and thinks he is so above everyone else that nothing can be explained is either not as good as he thinks he is or he is posturing to overcome his own shortcomings.
I'm cleaning up after such a guy now. Aversion to package managers, shell scripts where web config would have been better, duplicate information in SQL tables, firewalled off several countries to compensate for the fragile state of his security etc.. If I change anything it often has unexpected consequences.
In my experience, the guy who walks in and thinks he is so above everyone else that nothing can be explained is either not as good as he thinks he is or he is posturing to overcome his own shortcomings.
I roughly have the same opinion, I just express it differently insofar that I require people to teach others. In my (not exactly short) experience, there is no better way to sharpen your skills then to try passing them on, because you will discover that things you thought you knew have less solid underpinnings than you were aware of, forcing you to revisit it.
The mark of an expert is IMHO not in the ability to use incomprehensible jargon or create convoluted solutions (the "write only" model), it is in the ability to teach others who do NOT have deep expertise, and in clarity of delivery.
In my experience, the guy who walks in and thinks he is so above everyone else that nothing can be explained is either not as good as he thinks he is or he is posturing to overcome his own shortcomings.To paraphrase Feynman, "If you can't explain it to a complete newbie, you don't understand it."
A guy with a bit of drive and enthusiasm plus that cutting edge needed to survive was introduced into a team of lazy fucks who weren't prepared to put in the graft. He sounds very efficient and I wish my own team had that kind of resolve.
You don't get a job to make friends.
Le troll.
I have nothing against people trying to get ahead within a company. I have everything against people who do it at the expense of everybody else. Including the well being of said company.
Hard workers are a boon. But they are - usually - only working so hard for one person. Themselves.
"He sounds very efficient"
Did you read the article?
Whilst Tim did engage with the business, something that may have been lacking, however, Tim was working all the hours to deliver what he promised, which would indicate that Tim didn't know how to say 'No' and also didn't know how to plan his time. I suspect also Tim had a very poor concept of his true worth and ability to negotiate renumeration accordingly, hence why he was prepared to work such long hours without bringing it to management's attention.
Now if Tim only worked 10am to 4pm, drove a high-end company car, had regular expensive holidays (with girlfriend/family) and spent the rest of his time playing golf then I would agree he would be efficient. The only efficient people I know who work all the hours are highly skilled IT consultants, who get paid to dig clients out of shit...
I worked for a company whereby much of their data entry was made on software designed by someone who had retired years ago. They had a consultant working for them as their IT guy but he was not permanent staff. He only knew bits and pieces about the systems. I got the job as permanent IT admin through him and he showed me the ropes. It became quite clear that I was in over my head. Although I struggled through I ended up leaving after a year due to health reasons (the stress was crazy). They had a backup system that was untested (I tested it and found it did not work after a RAID drive died and I spent an entire evening trying to fix it with no overtime. More fool me!). The entire company was balanced on a knife edge and just before I left I sat in with their head honchos and rather generously told all of this. After that they were left to their own devices. I did a few years later look up the company to see if they were still in business. They were not (at least not under their previous name).
I've had the displeasure of working for a corp who's IT director was exactly that kind of individual. I was supposed to be in charge of IT for the whole office, including equipment and network. Yet any request for documentation was met with "stop asking for this and do your job" kind of responses.
It was as if anything I asked was treading on the IT director's turf.
Funny part? I got fired, 3 months in, for not following procedures I had asked for several times and never got. I never imagined I'd be happy to get fired from somewhere before then.
Most of the one sentence posts (if not ALL) in this forum are like a f*rt in the wind. This is a VERY GOOD and VERY TRUE article.
If I want to express my opinion, I will take some time and try to express my thoughts and will not just try to vomit a two second feeling before i click on the next post.
I am not a native speaker - and those of you who dislike Germans will now have one more reason if you belong to those who cannot express themselves.
If you DO work in the IT industry you should know that this article is some sort of historical documentation showing how our systems (politics and economy) are working today.
I am just afraid, that things will be worse in the future.
And to repeat what I wanted to say (yes I am repeating myself) - nobody is impressed by posts that are shorter than a twitter message.
And it is a PLEASURE for me to read posts from people who REALLY have something to say. I want to thank all of you who tried to let us know your point of view.
The rest is just f*rts in the wind.
A good sysadmin shouldn't normally need documentation as mentioned in the article. You should be able to determine what to do and how in a reasonable time using various troubleshooting skills as well as research. This can be done in a timely manner, even when something breaks and haste is required.
In my experience most job situations have poorly written documentation at best and you're left figuring it out yourself, team members, if present and knowledgeable in that field, will only know that much and aren't always willing to share much either.
"...all the documentation you have, you get it to them and they promptly lose it or file it away never to be seen by human eyes again."
This is the problem I ran into. I was doing IT work for a company (freelancing), and tried to NOT be the Tim there. I made sure the couple managers had information on the backup and remote desktop systems, network hardware, a network map, and so on, as well as the passwords. Several times -- when it came time they wanted to check on something, they NEVER seemed to be able to track this info down! Eventually I printed it out and stick it in this folder where they had some info on the old phone system and so on they have there, I figured they were less likely to lose that than to delete the electronic copies or whatever they were doing to them.
The flip side of this all was, I started having to repeatedly fix things -- I'd fix, say, port forwarding for their security camera DVR, and a few weeks later it'd quit. I'd come in, and find out that some piece of network hardware or other had been replaced, and not set up per documentation! (Basically, plugged in "out of the box" then called me when things didn't quite work)! I found out eventually, they had me working on some things, a person at the company that did some IT stuff "on the side", and a *second* group of two IT people doing *other* work, all without coordination with each other. Hopefully they didn't have a *second* set of docs *I* was ignoring, but maybe they did. No wonder there were problems 8-)
"A good sysadmin shouldn't normally need documentation as mentioned in the article. You should be able to determine what to do and how in a reasonable time using various troubleshooting skills as well as research. This can be done in a timely manner, even when something breaks and haste is required."
With all due respect, if a site has a cable or DSL modem (or 4G broadband or whatever), and some switches or access points in standard configuration, I agree. You plug the stuff together and it works. It breaks, you replace the unit and are done, no documentation needed.
However.... if your DSL modem, cable modem, or switches, routers, gateways, access points, go dead, and there's anything specialized... how do you expect to ordain what ports have been forwarded (if there's port forwarding), what VLANs are being used... if there are VPNs, what IP addresses, usernames, and passwords are being used for these -- are the even outgoing, or are remote sites connecting *IN* to form the VPN? If you get down there, find a port light out, switch that cable to an open port and determine it's actually a bad cable... how do you tell (until someone complains their service is dead) WHERE that cable is going, without some docs (perhaps docs just being a label on the cable itself?)
Don't get me wrong, it's possible... I had to do just that at the site I posted about a few above, read existing configs out of some routers and stuff to see what was what. But, it's a hell of a lot easier to have a document that says something like "This cable modem is left in bridge mode; this DSL modem is set in bridge mode, VCI/VPI are 0/31. These use bridge mode because they flake out under traffic load in normal mode. These feed into this device to do two-connection failover. On this device, the cable connection is set for DHCP. The DSL is set for PPPoE, with this username and password. Port xxxx is forwarded to address a.b.c.d to allow access to the foobar device from the internet. Traffic shaping is set up just so"... That's a lot easier than (best case) read out a config from the existing hardware and hope you didn't miss something important... or (worst case, your hardware is cooked) calling the DSL provider to get the username and password, not know the devices may not handle the traffic and wonder why there are connection problems (pretty sure the NAT tables would almost immediately overflow due to the high trafic levels), not know about the port forward and have to fix that later, and then have the 100 people on public wifi complain about speed problems and have to re-figure out what kind of traffic shaping helps with that.
This post has been deleted by its author
With more and more stuff going offshore this problem will only get worse,
especially with some of the Job titles some Jnr Staff abroad seem to get.
Director of technology? After two years on the Job? Totally inflated egos.
Working as a team gets harder and harder, eventually everybody becomes a lone
wolf as there is no team.
Also with the offshoring you no longer get the Jnr Staff you can train up locally teach them
those tips and tricks and useful shortcuts.
Personally sharing information means I get to be able to say "no" when workload gets too high but in the full knowledge that somebody else in the team can pick up the work.
Years ago I worked in a small IT department with separate projects and support teams. One of the projects guys implemented a new Citrix MetaFrame 1.8 farm when it was new out and looked to be struggling to support it by himself. When we asked him to show us the basics so he could concentrate on the higher level stuff, his response was something along the lines of "You don't have the skills..." and the head of IT supported him in his arrogance...
Within six weeks I was in a new job with a nice 30% pay rise, supporting a Citrix farm 20x the size (among other stuff) and last I heard he was in prison for ordering new laptops through the company and selling them to his mates.... The company itself went bust a couple of years later, although that was probably unrelated.
We had a guy at a UK bank like this. Fortunately he was spotted and not allowed to make the move into architecture. Fast forward a few years, I'm working somewhere else, and who should turn up as the 'Head of Architecture and Strategy' at another UK bank?! This guy thinks scribbling on a notepad (and I mean scribbling in the 3-year-old sense of the word - it's completely illegible) constitutes a technical diagram.
I'm stuck in the situation where this is being forced upon me. No budget for someone else to share load/knowledege and constant pressure from management to move onto the next job without finishing the last, minimising time to foolproof/document solutions. Dev team are supposed to cover the skills but without the familiarity of dealing with these systems everyday they soon get lost if I'm away and don't know how the info pieces together even when it is available. Management expect docs to handhold anyone through a task but a) that is impossible to foresee every eventuality b) I don't have remotely enough time to write that much detail c) its not my job to teach software, its my job to include the settings required for a power user of that software.
Sucks because I get called up whenever I'm on holiday, have 3 times more work than usual backlogged when I come back. Repeatedly tried to convince management of their overreliance and their suggestion is to ask a project manager to help me manage my time more efficiently!
Will be leaving soon as that seems the only option left, maybe they will realise their mistake when I'm gone. No doubt whoever replaces me will curse nonstandard ways of doing things, but at the time under the contraints on budget these were the only way to make it work at all.
Overall the article seems a bit of a management cop out looking to pin blame on someone rather than take responsibility or learn from their own doing :(
If kept under control by an experienced manager their energy can be usefully channelled but if management cannot see the problem these people are their worst nightmare.
Narcissists are truly horrifying people to work with, but give them the power of a sysadmin and they become monsters. They slowly suck everything into their empire while systematically preventing others from getting their own jobs done. The objective is self glory at the cost of everybody; back stabbing and self promotion are the tools of the trade.
The insidious danger is that the manager provides the narcissistic supply and as such is subject to the incredible charm these people can muster. The resulting codependent relationship completely blinds the manager to the destruction.
I have watched this dance play out several times, each time the manager's inability to see and act meant his own job failed. The post-mortum interviews of other staff revealed why the department began to perform so poorly. Each time the wolf was eventually fired but it took years to clean up the technical and staffing problems created while he ran wild.
If you are working with one, you know exactly how painful your job has become. I would strongly suggest you start looking for another job, it will get much much worse before it gets better.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
