Are your staff adequately trained?
Avoiding the false economy trap
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 online survey, is difficult to argue with. There is a clear relationship between the attention paid to IT staff training and the perceived level of burden experienced by IT. To put it another way, properly trained staff find it easier to cope with the demands placed on them in areas such as infrastructure optimisation and management to keep service levels up and costs down, effective maintenance of desktops to maintain user satisfaction and keep security risks under control, and provision of helpdesk support to meet user expectations maintain user satisfaction levels.
What’s more, the relationship between training and operational efficiency and effectiveness is a linear one. What does that mean? Well, it doesn’t really matter whether training requirements have been neglected, if the organisation already has its act together, or if it’s somewhere in between; indications are that that incremental training will always have a positive impact. To put this into perspective, another finding from the same report was that investment in other areas, such as systems management automation and integration, does not deliver benefits in the same linear fashion. Essentially, you need to get past a threshold of capability before significant improvements are generated.
There are some interesting lessons in here for all organisations, but particularly those that have a tendency to skimp on investment in skills development. If this study is anything to go by, such an approach is clearly false economy. In fact, if you have anything to do with running an IT department that is underperforming on IT service delivery and operational efficiency, then the first port of call when looking for improvements should probably be staff development. While upgrading your systems management tools and technology may also be a necessity, investment in this way will take time to pay back. Meanwhile, a bit of additional training at a fraction of the cost is likely to have a much more immediate impact.
Oh yeah, and study also quite clearly shows that training end users can have a similar impact, reducing the burden placed on IT in areas such as desktop management and help desk delivery. The basic principle here is that adequately trained users encounter (and create) fewer problems, and when problems do occur, users are much better placed to sort themselves out.
There’s a lot more to this research than the stuff we have been talking about above, so if you’d like to learn more, you can download a full copy of the findings from here. And if you’re interested in a companion report looking at the future of IT Service Management (ITSM) in general, you can download that from here.
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.
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.
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
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.
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?