We hear it enough for it to be a pretty unoriginal thought:
IT is rubbish.
I’ve been thinking about this a lot recently. I went to present at Sage Publishing a couple of weeks ago and had a fascinating time re-calibrating my own personal perspective on “where we all are with IT”. I’d made some assumptions about how much certain technologies had penetrated the “real world” and came away with the realisation that I’m not normal. I understand, use, appreciate SaaS (for example): most users don’t. In the real world, most users haven’t even heard of the idea of editing documents online, let alone actually done it.
There was a second and much more profound moment when I said something about how internal systems don’t often work with each other. Simultaneously, the entire room laughed, nodded, grimaced. This was a moment of understanding, a convergence of a shared experience.
What’s sad is that it is so rare that this shared experience is positive when it comes to IT. IT – as I said in the post – is usually considered a blocker and not an enabler.
I’m so very sure that you’re nodding too that I’m not going to back this up with too much evidence, but just ask yourself when you’ve heard (or said) these:
- “I can’t talk to the people on the service desk because they don’t use a language I understand”
- “I set up a blog to get my content out there because I can’t use the institutional CMS”
- “I would love to collaborate but no one can tell me the best way of doing it”
- “We asked for user-centric but got something hugely complicated”
- “We’ve been waiting for months for a new X system but the procurement process is just sooo slow”
- “Why do I only have 200Mb of email storage at work when my Gmail account has over 6Gb?”
- “How come I have to re-key that information X times?”
- “Why is webmail blocked at work?”
- “We only use 5% of the systems’ capabilities – the rest is just noise”
I want to hear from you if these are unfamiliar. I guarantee my inbox will be empty.
So the question I ask in the title is why?
Lets try and boil this down to a few key principles:
Reason One: IT people don’t think like normal people
IT people – and by this I mean web developers, support staff, academics, systems engineers – are almost always enthusiasts. They often (as per the cliche) live the technology – it’s a way of life and not just a job. These are – really – the people who have optimised PC’s at home that they built themselves. They have their own website running off a home-built CMS. They are asked to “fix my computer” by friends and relatives. They read Stuff and Wired for fun. They relish the moment that the Dabs catalogue comes through the door. They like reading the manual.
This is great – really – after all, this is me, too – but what is important is the realisation that you (Mr IT person) aren’t most people. If you’re an IT person then to think like most people requires extraordinary additional effort.
Reason Two: There is no Problem Between Chair And Computer
We IT types need to learn to accept this dictum: “the majority are right”. The fact that 95% of your users don’t see the “click here” link even though it’s blindingly obvious to you does not mean they are stupid. It means you are wrong. In geek speek, there is no PEBCAC.
Reason Three: Functionality is nothing. Simplicity is everything.
User requirements can usually be boiled down to this single word: Simplicity. We geeks are the only people who are excited about the way in which system X integrates with system Y and delivers XML via a SQL call to database Z. Our users wants to run a search or change their website as quickly, painlessly and simply as possible. It’s a shame (hey, I like a groovy API as much as the next person). Get over it.
Reason Four: IT departments are – historically – there to block
I once heard a (very) senior manager say this: “The IT department isn’t there to allow. Its job is to prevent”. Now, argue the IT team, that’s because it’s a dangerous world out there. We can’t have viruses coming in via webmail (so block webmail). We can’t allow wifi networks (so block those). We can’t have people accessing Facebook (block that). We can’t open port 25 (block it). We can’t allow Firefox (block). Etc.
Here’s the reality: If someone in your organisation wants to bring in a file, they will do. End of. Short of gumming up all CD, USB, IR drives and glueing the network cables to the ethernet port, it’s gonna happen. In a similar way, if your users have 6Gb of file space at home (for free), they simply aren’t going to accept 200 Mb at work (“because it’s expensive to provide storage”).
It’s time for IT departments to realise that they should be providing a service – they should strive to understand their users and their content; they should be reactive, rapid, innovative. In short, they need to work with the people they are there to help.
Reason Five: What We Do Is Complicated. Please Don’t Ask Us To Explain.
We hide behind this one, big-time. IT does not make sense. Even if you’re the most clued up, intelligent, well trained, experienced IT bod in the universe, you simply do not know it all. And that’s because it (sometimes) really is complicated. But we still use this as an excuse to cover up the fact that simple answers are almost always what is required. The user interface (and by this I mean “the interface with the user”) is everything, not just a minor part of the equation. IT departments should be hugely proactive in communicating what they are doing and why. We need to learn to interface with people and not just with the tech.
Where from here?
The more time I spend in this environment, the more I realise that the issues here are often “soft” issues. They aren’t – actually – about the systems themselves. They are about the ways that people interact with each other, the understanding that is given by (and to) IT staff, the communication of what we all do. I’ve been exposed to both sides of the fence: on the one hand being treated as “just a geek” and on the other seeing non-IT staff treated as “that bloody user”. The skills gap is almost entirely about a lack of understanding, on both sides.
If we could only talk a bit more, we’d probably find we got on…
5 thoughts on “How did IT end up like this?”
Interesting, although I don’t think of IT to be that bad. I mean, you got everywhere those who are against the big changes. And many system/network/whatever IT changes are huge and potential job-killers. Obviously, the extremes are most likely not to be wanted by the majority.
But in general you’re right we like new things, interesting changes, new solutions to play with – but everybody does. That’s our nature.
One negative.. big organisations need ages to change. That’s awful and bores every time!
Anyway, kind regards,
Michael Stephens spotted my use of “Computer Says No” catch phrase from Little Britain – http://tametheweb.com/2006/02/computers_say_no_it_says_no.html
I stopped using this when I tried it at a conference in Holland, and nobody got the gag.
But I still sometimes use the line “Rather than the binary view of IT folk Yes/No, we need to engage with the Hegalina dialectic so conceisely articled oin the Pollardian phrase ; Yeh, but no, but yer, like'”.
lol – yes…
As you’ll know I’m not a fan of spending too long on the shades of grey, rather preferring to go for the black or white in the hope that it’ll raise profile and promote debate.
Of course there is fine Pollardian discourse to be had, but I do truly believe that there is a major issue at the heart of IT which “we IT types” mostly fail to understand. Andy Powell just claimed that I only blog this stuff to get traffic – “how very dare you” I say…
I have to agree with reason #2, it’s amazing how IT people treat people who can’t use their system as inferior, with somehow lower IQ. How many times have you approached a developer for a change request to make something more usable/understandable by the end user and you get an arrogant reply on how dumb the customer is, while, in fact, as you said in #1, normal people do not think like IT (and vice versa). When developing a project, it’s always good to have someone with no IT skills whatsoever to test the functionality.