Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

IT Management, outsourcing & technical skills

by g0n (Priest)
on Dec 28, 2006 at 14:30 UTC ( #592050=perlmeditation: print w/ replies, xml ) Need Help??

Or: why the PHB needs to know an Etch-A-Sketch when he sees one.

this thread and particularly this reply led me to formulate something of a rant that's been bubbling over for some time:

There seems to have been an increasing tendency in the last few years for IT management jobs to go to 'generic managers', possibly derived from a growth in academic study of the 'theory of management'. I've been bemoaning this, and the catastrophes that it sometimes causes, for quite a while.

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.

Ultimately, many organisations stand to derive a great deal more benefit from their IT systems than they do at present. As long as they place control of the IT function in the hands of people who don't have the technical savvy to innovate, or enough technical background to understand the innovations being suggested to them by others, they won't.

Rant over. If anyone has bothered to read this far, thank you for listening.

--------------------------------------------------------------

"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".

Comment on IT Management, outsourcing & technical skills
Re: IT Management, outsourcing & technical skills
by alpha (Scribe) on Dec 28, 2006 at 17:35 UTC
    Technical people, especially developers, are perceived to lack interpersonal skills. Yes, this is very true in most cases.... This is imo the main answer to your question.
Re: IT Management, outsourcing & technical skills
by perrin (Chancellor) on Dec 29, 2006 at 03:00 UTC
    I feel your pain, but I wouldn't call a manager who doesn't ask his technical staff for guidance on technical purchasing decisions a "non-technical manager" -- I would call that person a "bad manager." A good manager knows that the maanger's job is not to know everything and decide everything but rather to focus and guide the team's skills to solve problems. A basic technology grounding is certainly helpful, but I've seen plenty of techies screw it up. I think that a set of skills more like those of a good sports coach (to borrow an XP analogy) are ultimately more important.
      I feel your pain, but I wouldn't call a manager who doesn't ask his technical staff for guidance on technical purchasing decisions a "non-technical manager" -- I would call that person a "bad manager."

      Agree completely. As I said before:

      Some of the very best managers I've worked with have been completely non-technical. Some of the very worst managers I've worked with have been ex-techies.

      In my experience the divide between good and bad management has very little to do with technical experience, and a lot to do with being able to trust people to do their job well and remove the things that stop them doing it.

        I want to know the skills that are neededby an IT Manager to manage the outsourcing of IT activities.
Re: IT Management, outsourcing & technical skills
by talexb (Canon) on Dec 29, 2006 at 04:12 UTC

    Interesting post, thanks.

    My idea of a good manager is someone who takes my technical recommendation and makes a decision using that information. Your manager made a different decision than the one that you recommended, perhaps based on budget information that you didn't have or need to know.

    That's the organization's fault -- save a little now, pay a lot more later. Yeah, that's stupid.

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

    Yup, quite true. That can be a good thing, or it can be a bad thing.

      People are prone to disparage any skillset not their own.

    Disagree. I'm actually glad someone else has the talent for doing Sales and Marketing. I suck at both those activities.

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

    I think 'lack' is too strong a word -- geeks get on quite well with other geeks; you should see how chatty some Perlmongers meetings or YAPC events are. Let's say that they are not as talented at communicating.

      Technical people are perceived to lack business awareness.

    That's a mis-perception -- sure, as a technical person I can get fascinated by technical minutiae, but I am also able to pull back and think about the big picture.

      Geeks don't want to be managers.

    This is the most difficult statement to wish away, and probably requires a Meditation all on its own.

    A manager usually doesn't get to 'do' any more -- he or she gets to direct others who do the doing. But there are two kinds of managers, people managers and technical managers; I sure don't want to be the first type of manager, but I'd love a chance to be the second kind of manager.

    Wrestling a tough technical issue to the ground is what challenges me. Dealing with a difficult employee situation gives me the willies.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: IT Management, outsourcing & technical skills
by Dervish (Friar) on Dec 29, 2006 at 06:05 UTC
    I think a lot of your statements are accurate, but most of them are /perceptions/. There will be many technical people who will be good at management, have decent interpersonal skills, have an awareness of business needs, and might even want to be managers. After having been placed in the position of team leader a few times, I find that I really don't want to do what the higher-level managers do (in fact, I find it hard to stay awake at a long meeting on a topic which /seems/ unrelated to work. This is a poor management practice. However, I did well enough at the job for more than one company giving me 'adequate' ratings in job reviews. I preferred the 'excellent' ratings I got when doing development). However, I've seen other technical people who were good at it -- when given the chance. To me, that seems to be the biggest stumbling block to technical people becoming managers. Most managers seem to me to be reluctant (for various reasons) to tell the technical people about the business issues that influence their decisions. In my experience, most technical people really appreciate being given that business information, and can be quite loyal to a manager who listens to them and describes why they might make any decisions. Our company has started sharing annual report information such as profits attributed to each department, financing decisions, and so on, with the R&D department (where I work), and although many of us grumble at being away from our work to hear that information, they also seem much happier to have it than they were when a more traditional method was used. Among other things, it makes us all very aware of how our decisions impact the company's bottom line. I've seen several people take more time about expense requests and dealings with vendors. All the kinds of things technical people usually get to avoid considering. --D
Re: IT Management, outsourcing & technical skills
by rodion (Chaplain) on Dec 29, 2006 at 06:20 UTC
    When you get together technical people who understand management goals, and management staff that appreciate technical evaluations and decisions, the result can be really satisfying. It's great work, if you can get it.

    More often, time is short, and so is the patientce to listen and understand. Competence comes up short too. We all have things we're not good at. Thus we work with what we've got. Things are often as your "rant" depicts them, and everyone loves reading dilbert because it strikes close to home all too often.

    We can lament that things are not better, or be thankful that things are not worse, but either way the satisfaction comes from making some piece of the process work a little better. At least that's what works for me.

    I enjoyed reading your thoughts. Thanks for sharing them.

Re: IT Management, outsourcing & technical skills
by rinceWind (Monsignor) on Dec 29, 2006 at 10:44 UTC

    Good post, g0n, albeit a self confessed rant.

    I'll see if I can pull together some of the ideas and points, and give my take.

    Choice of technology platform

    I'm using the word "platform" in a very general sense: like your database back ends, or this could apply to the choice of programming language used. This is clearly an area which requires technical expertise to understand the issues involved. However, I've often seen statements about technology platforms built into business requirements. Usually, this is wrong; such statements belong in the solution, not the requirements. The requirements should be pitched in business language, and free from the specific technical considerations of the solution.

    An exception to this might be where there are vested interests. For example, if Oracle are sponsoring the project, it's not unreasonable to have "Oracle database" in the requirements.

    Outsourcing

    Like you say, this can be good or bad. Personally, this may potentially give you the opportunity to move around and grow in the service organisation, without being tied to the one client, as you would be as a direct employee.

    The problem with outsourcing usually occurs at the boundary between the two organisations, usually because some detail has been omitted from the contract. This can also, as you said, be a failure of requirements analysis in the client.

    Technical managers

    You are more likely to find somebody doing both technical work and being a manager, in small firms. In large corporations, it seems that there is no opportunity for technical roles above a certain point in the management hierarchy.

    Put yourself in the shoes of somebody who has been promoted into a non-technical role (this happened to me once). You end up either knuckling down to the management job your employer is asking you to do, and losing your technical knowledge if you stay there. Or you fail and leave.

    I made my choice, and I no longer want to climb the management hierarchy ladder. Though this could change if I end up running my own business.

    Conclusions

    Large organisations move at the pace of prehistoric gastropods. Don't expect much innovation from your colleagues.

    Management ain't what it's cracked up to be.

    You stand a better career chance working with the large organisation as a client, you being a freelance contractor, employee of an outsource supplier, or an outside consultant.

    --

    Oh Lord, won’t you burn me a Knoppix CD ?
    My friends all rate Windows, I must disagree.
    Your powers of persuasion will set them all free,
    So oh Lord, won’t you burn me a Knoppix CD ?
    (Missquoting Janis Joplin)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://592050]
Approved by planetscape
Front-paged by Jenda
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (16)
As of 2014-07-25 15:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (172 votes), past polls