Freeform Dynamics An interesting finding emerged from a recent Reg reader study. It concerns a cause and effect that is pretty obvious once it is highlighted. Put simply, IT departments operate much more smoothly and efficiently if IT staff are adequately trained. The data, which is derived from over 1,100 responses to an …
Some don't seem to have completed potty training, never mind anything even vaguely related to computers.
Since joining the company a mere 22 jears ago, I have been on one training course: First Aid at Work from the Red Cross. All other "training" has been a case of "There's the manual. We know it's c**p, but that's all there is" ... and that ends up splattered on my official training record. Not bad for one of the first UK software houses to get BS 5750 certified, and now ISO 9001(?) certified. (More worrying is the fact that we still work on projects for the nuclear, chemical, food, pharmaceutical, oil & gas industries)
From the Department of the Bleedin' Obvious....
"...IT departments operate much more smoothly and efficiently if IT staff are adequately trained."
Couldn't this be spread across the wider community using this basic template?
**XXXXX operate much more smoothly and efficiently if XXXXX are adequately trained**
Microsoft... ... scratch that one, never going to run smoothly.
If you train people properly, they are more effective......wow, I'd never have thought of that!
This report brought to you by The Society of Stating the Bleeding Obvious.
If it's so bleedin' obvious
Then why aren't more companies doing it?
You can't really have a pop at the article, as so many firms seem to need the bleedin' obvious spelled out to them in large letters.
RE: Andy Worth
.... but so needs explaining to a large section of beancounting UK management. Far too many have absolutley no idea of what knowledge is required to fill certain roles in IT and fall back on paper qualifications. "If Mr/Ms X is accredited in System Y then that must mean they can do the job", when in reality, all they did was study up to pass the exam and actually have zero practical experience.
And don't get me started on the number of times I've seen experienced colleagues replaced by "qualified" but clueless graduates, just because the grad has the right bits of paper when it is blatently obvious to anyone with an ounce of technical savvy that they haven't a clue. There is a tendency in UK companies to try and recruit fully-trained staff rather than develop what they have, and it is this which leads to the hiring of paper specialists with no experience, usually at over-inflated wages, rather than paying for the existing staff to be trained up.
Nothing to do with training
I beg to differ with a few of the earlier comments, the training part is not so bleeding obvious. Training is not the be all and end all, you can't take any idiot off the street, put him through a training course, especially the sort detailed below, and get a competent support monkey or whatever at the end of it.
I have a regular argument with my wife about schools, she goes on about how the best schools produce the better qualified students. In my neck of the woods schools are selective and no amount of pointing out that the best schools only take in the best students so it's no wonder they getter better ratings will work.
Similarly, with this in mind, we need to know what was the competency of the respondents before they went into training. Effectiveness of training should be a measure of the delta between pre and post training. In my opinion there is no substitute for experience and I doubt very much that any training course can make a difference to worker productivity.
I have limited experience of courses but the few I have been on involved being given a manual and the presenter then reading the manual with various scribblings on a whiteboard. From colleagues who have been on other courses I gather that this is normal. I would like to hear if anybody has been on a course that didn't follow this format.
Re: From the Department of the Bleedin' Obvious....
It may seem obvious to you, but you'd be surprised how many people think they saved teh big bucks if they save 10% on the wages... and end up needing 2-3 times as many man-hours.
Heck, in the 90's it was even a common doctrine that quickly retraining ex-burger-flippers off the street as programmers and admins is the way of the future. You know, don't worry about all manufacturing jobs going to China, we're going to retrain them all as programmers and admins instead!
That said, I also suspect that, as always when something seems like a bloody stupid solution, they're not actually honest about what problem they're actually solving. Humans tend to be that way. They're actually surprisingly good at finding a solution. They only seem stupid when they can't tell you the real problem, and have to invent a bogus one to fit that solution.
In this case, you also have to factor in, that hiring enough people without drawing suspicion, also almost automatically grants a manager a promotion in most corporations. If you do your job quickly and efficiently with 3 top-notch people, you're at most a team leader. That is, if you don't find your team merged with another one, because noone pays a manager for 3 people. If, on the other hand, you managed to get 30 drooling retards under you to do the same job, well, that puts you on a higher level of the pyramid.
I've seen a couple of people who've earned their promotions that way.
Companies supplying contractors and consultants also don't help. They're more than happy to try to sell you 10 burger flippers, instead of 1 expert. Better yet, to sell you those 10 as experts.
Corollary do the managers really know what they are doing or are they like the boys and girls at SG in France basically a bunch clueless planks of wood useful for window dressing only ?
Re: Chris W
Mate, you're right, but methinks you misunderstand what "properly trained" means. Taking an idiot off the street and giving him a crash course, does not make him a properly trained professional.
And while I'll agree with you that experience is important, I'd also say that it's no substitute for knowledge. I can think of a lot of algorithms (since I'm a programmer) which I'd never have come up with on my own, just by banging on a keyboard.
Similarly, for an admin, just using a Linux shell doesn't mean you'll necessarily become more knowledgeable.
People set into a rut for normal day-to-day work, and just do again what worked before. You can work with Linux or Java or whatever for years and never discover anything new. If, for example, you always used Midnight Commander to do some file stuff, you'll keep doing that, and never learn how to pipe a grep in the command line.
But then comes something unexpected. You have to SSH into a machine which doesn't have MC, in the above example. Or whatever falls outside your usual rut. And then is when some training would have been useful. Even if you only vaguely remember what they told you there, you'll at least know what commands to read the man pages for or google for.
And then there's new stuff. For example, we have a DBA here who _still_ doesn't understand what the Oracle 10 autotuning does, and what he should do about it. He's struggling to apply outdated knowledge, and comes up with comically ridiculous solutions, like, literally, "Ok, I copied the statistics from the other program which runs faster. But those are for more records, so you'll need to fill your database with 1 million more bogus records. Is that ok?" No, seriously, I'm not kidding.
Or when _we_ told him what utility to run, he just sent us back the output, thinking it's some hint for us how to optimize our SQL statements. The idea that he just had to set that profile into the database, didn't even occur to him.
Because he has no bleedin' clue what he can do with those new Oracle 10 tools.
Maybe sending that guy to some Oracle 10 training wouldn't be too bad an idea, you know?
Re: Hans Mustermann
In the context of the article "properly trained" seems to imply sending employess on a few training course. I would disassociate this from a good education followed by ongoing learning through one's own inquisitiveness and knowledge gained from more experienced colleagues. I remember starting off and whenever I had difficulties would find someone who knew, sadly these sort of people are not valued nowadays.
>But then comes something unexpected.
I car pool with a chap who is constantly taking courses for one certificate or another and he gave this as an argument for taking some of the courses, mainly that he could learn something that he hasn't come across in his day to day tasks. He was unable to give an example in which a course had gone so far from the mainstream that he learned something that didn't already know. There are thousands of tricks that we pick up along the way but I doubt a single one is mentioned in any training course.
As for your Oracle10 bod, he could be sent on a course to point him in the right direction but it's his own tinkering that will get results, without that the course will have been a waste of time and money. As an example, way back when Delphi was affordable I got one of those Delphi in 24 hour books, the 24 hours being 24 chapters which should take about an hour each. Each chapter took me over a week because of trying this and let's see what happens if I do this, sure it could have taken the specified time but would I have learned anything?
As folk have already mentioned, it only seems obvious. It seems obvious to the IT staff, and very probably to their managers.
The real problem occurs when said manager goes to the Finance Director and says : "I need an additional 25k in my budget next year so we can send ten of our staff on three day courses."
And the FD replies with something along the lines of :"AAHAHAHAHAHHAHAHAHAAAA."
In big orgs with internal markets and cost centres and all that jazz, I've seen it even worse. In a multinational with USD 26 Billion turnover, developers were unable even to obtain technical books. They weren't authorised to spend anything, and nor were their team leaders. And even if they had been, they would have had to charge back to the 'client', because there was literally no budget (outside of headcount) for the dev team.
The departmental higher ups wouldn't order books either, because "If we do it once, we'll have to do it for everyone". Well Duh! At the same time, this org regularly fed it's visiting external clients a buffet that included caviar. Yes, you read that right. From the cube farm where the dev team sat, they could quite literally sit and watch through the glass wall as the directors and their high value clients stuffed their faces with caviar in the meeting rooms. But somehow these same people couldn''t pony up a few quid for a few decent manuals. Try, if you will, to imagine that as a motivator. * This may seem hard to credit, so I have to reiterate that they really did buy shed loads of caviar, which staff were able to verify because after these meetings were finished, the leavings would be placed in a staff common area for people to pick over. How thoughtful.
I blame the metrics personally, most places don't know how to measure what IT does.
There's no direct bottom line number for the bean counters to grasp. And that's about the only thing they care about. Lets say your dev team work unpaid overtime for two months and deliver a really good system that makes your sales team 50% more efficient. Where does that number go on the spreadsheet ? Under "Sales", obviously.
Bonuses all round for the sales droids, on top of their generous commission, and the IT team get bought a pint out of their managers pocket. w00t!
There is a solution to this, also sponsored by the DotBO, and also so "obvious" that no one ever actually bothers to do it, which is to measure user experience (quarterly, or oftener, survey which you will have to design very carefully) and follow this up with frequent, formalised contact with stakeholders from your user base.
Every time I've implemented this, the result is a steady increase in the overall figure for "user satisfaction" or whatever you want to call it. (Seriously, you'll score points just for asking). It hasn't, yet, resulted in what the IT people always fear when you suggest this to them, e.g a crowd of angry users wielding pitchforks and a huge backlash against the IT function. Yet. But let's face it, if your org is likely to go that way anyway, you really NEED to be doing this.
In addition, you get to go the FD and say things like "Deparment X is going to want to implement a [some kind of system] next year" (remember you know this because you've been talking to them about their future plans and likely requirements), "we don't currently have the skills in house to do that, so as part of the project budget there will be a requirement for training in [some system]"
And this works, because you have also communicated this need to whoever goes into bat for Dept X, and who is now your best buddy, and will therefore push for the budget to be allocated because it's now her pet project, and she doesn't want her critical path being b0rked.
Of course it's not always quite as easy as I'm making out, but at least it gives you a metric that actually means something, and a stack of numbers which you can make pretty charts and powerpoints from, these are always helpful when dealing with bean counter types. You also build meaningful relationships and channels of communication with the people who matter most. Your users.
As an extra bonus, you get to write the process up using all the buzzwords that pointy hairs like, "empowerment", "ownership", "buy in" and all that bollocks. You can probably even get away with using "leveraging" and "synergies", possibly even in the same sentence.
While I'm busy pontificating, a handy hint for IT management types is that most decent IT folk (not the paper tigers, I suspect) are actually quite good at educating themselves. But you need to give them time to do it. Fridays are good for this, especially Friday afternoons when everyone would otherwise be slacking off and posting lengthy flames to El Reg in any case. Make every friday, or every other friday or whatever you can spare (rotate people if you have to) a Skills Development and R&D day, and watch your team's productivity go sky high.
Getting this past your next layer of pointy hairs will be the single most politically difficult task you will ever face, though. You may well have to settle for less, or something a little more flexible. That's OK.
* In case you're wondering, every single developer in that department applied for voluntary redundancy in oh, about the second round of "rightsizing". None of them were granted it. All their jobs were subsequently offshored to an Indian contractor. Nice.
Mate, I don't know much about admin stuff, but I don't even need to try to hard to come up with examples when it comes to programming. Half the CS stuff I learned in university, I never would have come up with on my own.
There's a whole framework, including maths, which you need for some of that stuff. So, yeah, you _could_ spend a lifetime reinventing it all on your own, or you could spend a semester learning it from someone who already knows it. I'll take the latter, thanks.
E.g., just by banging code you'll never come up with, say, Heap Sort. And that's a simple one. You could be programming in Java and might have learned some mantra like "use the built in quicksort!" Well, try using that on a 100 GB file on the disk, and you might find it a tad less than optimal.
E.g., 1-2 times per year yet another retrained burger-flipper comes to me with, basically, "Auugh! Java's Hashtable is broken! I store a value in it, and it replaced the value for a completely different key that had the same hash code!" What really happened there? It added a new node to the front of the linked list for that bucket. But said burger flipper doesn't understand hash tables, nor linked lists, and having only dealt with Java he doesn't understand pointers either.
Worse yet, almost all of those first spent 1-2 weeks debugging a class that they shouldn't even be worrying about. And some teams even implemented comically absurd "workarounds" for that "problem." All the more comical since they invariably can be proven mathematically to be snake oil, and only masked the "problem" for the particular test case they were using.
Even worse, they often didn't just waste that time, but created a problem for maintenance later too.
That's the kind of thing I'm talking about. I'm not even talking newbies. I'm talking about people who've used a Hashtable or HashMap a thousand times before, over several years. But then something happens that's outside the usual rut. They debug something else and end up looking inside a Hashtable. And the lack of knowledge bit them in the arse hard.
Yes, you could argue that a determined individual could have learned all that on his own. Some do. Maybe you're one of those. I don't know. Most don't, until it bites them in the arse hard. And then they don't even know what to google for, and spend inordinate amount of time and work to rediscover something that a teacher could have told them in 20 minutes.
That said, though, I'd like to add the caveat that a heck of a lot of certifications _are_ snake oil. They ask trivia, but never check the fundamental concepts behind them. They're made "difficult" by asking such trivia as in what package is some obscure class, or for Unix certs, in what directory is some obscure utility found. (Never mind that there are tons of ways to find it, if you ever needed that, plus they miss such common occurences as it having been recently recompiled and residing in /usr/local/bin instead of /bin.) Briefly, they're not supposed to make you any smarter, they're just supposed to make money by also selling training and books about those trivia.
_If_ your mate was going to that kind of snake oil courses, well, I'm not going to argue with you that he probably didn't learn anything useful :P
Agree with you, training will be most useful on people who have a clue to start with. However, when that is the case and the training is the the right one, benefits are immediate.
I had excellent training when I was working at Reuters, on their own systems, as well as Sybase and Sun Solaris admin. It worked because it was good training delivered by excellent trainers who were specialists in their field to skilled staff who were able to apply it in their day to day job immediately. It wasn't cheap training but the amount of time subsequently saved by the company made it more than worth it.
I also found myself on the other side of the desk, as a trainer for another company. Then again, it worked because my day job was to do the same thing as the guys I was training so I had the experience of what they needed to know in order to do their job properly.
It's like everything else: providing good training to skilled people in invaluable, provinding bad training to clueless people is like giving them paid holidays. This is why management and beancounters are often dubious about its value.
I'd like to work with this bloke.
When I interview people, I go for IQ, Motivation, and General Experience.
The first two are mandatory. The third one depends on the level.
First Question, "You're on a lake in a boat, with a car battery. You throw the battery in the lake. What happens to the level of the water?"
Second Question "How do you increase the M25's resilience to flow problems due to accidents?"
Third Question "Think of something that Amazon/John Lewis/Yahoo doesn't yet do that it should."
Fourth Question "What's the difference between data model architecture, and domain model architecture and what is the limitation in the mindset of domain model adherents that makes them only realise their code is so slow a week before it's due for delivery?"
Fifth Question "Describe your favourite pub."
Sixth Question "Write an imaginary postcard from a weekend away, using words only beginning with S."
And so on...
50 IQ & Porsche 911 but no people skills = Commercial Director
50 IQ & No Porsche 911 and no people skills = Head of Operations
80 IQ = Cleaner
90 IQ = Chief Cook
100 IQ = Bottlewasher
120 IQ = Tester
130 IQ = Developer, Business Analyst.
140 IQ = Architect, Project Manager etc
150+ IQ = Troubleshooter
150+ IQ & Business Ability = Enterprise Architect, Business Development etc.
160 IQ = President, Einstein
200 IQ = John Stuart Mill
It's a pity that the recruitment industry disagrees and thinks a business analyst should be some kind of admin bod, instead of an ex programmer who is bored with it all.
- Xmas Round-up Ghosts of Christmas Past: Ten tech treats from yesteryear
- Analysis Microsoft's licence riddles give Linux and pals a free ride to virtual domination
- Review Hey Linux newbie: If you've never had a taste, try perfect Petra ... mmm, smells like Mint 16
- Special Report How Britain could have invented the iPhone: And how the Quangocracy cocked it up
- Massive! Yahoo! Mail! outage! going! on! FOURTH! straight! day!