One perhaps relatively minor problem tends to occur with purchasing. Some years ago I was overruled by my then manager on a purchasing decision over a dozen PCs. He insisted on purchasing very cheap models, designed as home PCs (UK monks will probably know the manufacturer I mean). These machines simply were not up to the volume of use we put them to, and ended up being replaced much sooner than the lifecycle required. At one point in my time as a field engineer I took to pointing out the recommended duty cycles of printers to customers, as they had often been sold printers that were not up to the job of printing several hundred pages of month end reports, and I got called out to fix the damn things every time they jammed. The customer didn't know, after all, a dot matrix printer is a dot matrix printer - what difference is there between them?

Software purchasing is even worse. Given the choice between a product that stored its data in a standard DB backend (Oracle, SQLServer etc), and one that used a proprietary file backend, all other things being equal I would go for the DB based one. Why? Flexibility - the data can be accessed without using the suppliers app, for reporting, or if the supplier goes bust and support is no longer available. That sort of criterion tends not to be a factor in most purchasing decisions though.

There are day to day issues as well. Knowing what's possible can make an extraordinary difference to the service that an IT department offers to an organisation. A little work to write an app that feeds directory information into electronic or paper white pages (like this one) can save a lot of wasted time trying to find contact details, or manually retyping/cut-and-pasting to create the company phone book. There are countless other examples - document management systems, intranet web frontends to existing apps, etc, etc. Before these things can be done, someone has to know they're possible.

Other problems crop up in contract management, something a generic manager is expected to be good at. Even something as apparently straightforward as managing the relationship with a comms provider requires technical knowledge to get the best service. Without technical skills, how do you know whether you need QoS or not? Or even how much bandwidth you need? Is a managed service comms network going to give you the flexibility you need, or is it going to cause problematic delays in changes to network topology?

In all the cases I've cited so far, the generic manager can avoid the pitfalls of a lack of technical knowledge by talking to technical staff. All too often he/she doesn't, possibly out of misplaced pride, but the opportunity is there. Of course, that's made easier if the manager and the techy understand the same terminology to some degree. However, when it comes to outsourcing, all bets are off.

Theoretically, outsourcing development can make sense. The outsource provider has economies of scale, and since they specialise in development they're 'likely' to have good working practises (version control, testing procedures, documentation etc). I quoted the word likely, because that tends to be the perception. It's not always true.

Outsourcing normally involves making people redundant, or at least moving them to another employer. That means that the manager can't get technical advice from the technical people, because what he/she is doing seriously affects their jobs. It also usually plays merry hell with the morale of the people involved once they find out.

So post outsource, the generic manager instigates a new project. The chances are it's going to be done using the waterfall method, because there doesn't seem to be much awareness outside technical circles that the waterfall method doesn't work very well. First of all the requirements have got to be written. Since it's the (non technical) manager of the contract who has to sign off on the requirements, they can't be written in a rigorous form like the UML, they have to be written in natural language, possibly with some simple diagrams and (if you're very, very lucky) mocked up screenshots. Of course, that means that there will be a lot of wriggle room in the requirements. Since delivery is based on agreed requirements, once the requirements are met, the provider can and will consider the project completed. Any tweaks, changes and 'thats not really quite what we wanted' that used to be done as part of the process is now an additional requirement, leading to delays and additional unplanned costs. If the testing process is insufficiently rigorous (Quality standards, something else that should have been specified in precise terms at contract negotiation...) misunderstandings and vagueness in the spec can be catastrophic.

Most outsource contracts are for a fairly considerable duration - typically 5 years. Employment contract protection as part of the TUPE process in the UK is typically 2 years. So once you're two years into the contract, the outsource provider can get rid of those expensive experienced developers who understand your mission critical application, and replace them with inexperienced but much cheaper developers who don't.

In some cases, after 5 years, the customer is so locked in for technical reasons that moving to another provider or bringing the process back in house is prohibitively expensive, so there's no choice but to live with whatever standard of service the provider chooses to offer.

I could continue to rant about the innumerable pitfalls of outsourcing controlled by non-technical people, but I won't. Move on.

Why do so many of the IT manager jobs go to non-technical 'generic managers'? Why are the PHB and his BOFH equivalent such easily recognisable figures?:

• People are prone to employ candidates who are as much like them as possible.

When recruiting for e.g. a developer, there are certain criteria that must be met. Like the ability to write code. Recruiting for a manager is done by people further up the hierarchy who consider the key required skills to be management skills, and consider technical skills to be optional or unnecessary.

• People are prone to disparage any skillset not their own.

OK, possibly a little more controversial, but a proportion of developers sneer at 'management soft skills' (example) while a proportion of managers seem to consider technical work menial. A lot of people just seem to be like that. Both skillsets are required, and at the interface of the two, a combination enhances communication.

• Technical people, especially developers, are perceived to lack interpersonal skills.

While it is a stereotype, there does seem to be at least some reason for this commonly held belief. Perhaps a higher incidence of autistic spectrum disorders is behind it (I haven't been able to find any documented evidence of this, but that doesn't mean it isn't true - most developers seem to believe it). Even so, it's far from universal.

• Technical people are perceived to lack business awareness.

Again, sometimes it's true. A fascination with minutiae can be a useful characteristic in someone who writes code all day long, but it can mean a lack of awareness of 'the bigger picture'. Again, there are plenty of exceptions.

• Geeks don't want to be managers.

Again, true in some cases, not in others. I've heard plenty of technical people bemoaning the fact that once one is 'typecast' as a developer/engineer, management roles with their often higher salaries and greater opportunities seem to be forever closed.