IT Commandment: Thou shalt not fear change

IT Commandment: Thou shalt not fear change

Summary: Fear of change blocks many technology decisions and leads many technologists to fight against technology they probably shouldn't.

TOPICS: Outsourcing

it_command.gifI've been wracking my brain for a commandment which would fit with the theme this week, and I figured that the commandment "Thou Shalt Recognize the Inherent Superiority of Microsoft Software" might be a tad too partisan, particularly coming from guy who works for Microsoft in its IPTV division (queue maniacal laughter here).

"Thou shalt not fear change" might seem like a mild, and somewhat obvious, commandment, particularly in an industry typified by rapid change. Unfortunately, it isn't from a practical standpoint, something which is understandable given the investment every one of us puts into keeping our IT skills sharp. It is expensive both in terms of time and money to learn a new technology framework. Likewise, it's simply not an option to become an expert in all technologies. Granted, certain skills are very portable across technology domains. However, becoming a master in the intricacies of Java takes time, and leaves you less opportunity to become a master in the intricacies of Oracle database tuning, or Windows programming.

This economic reality can sometimes overpower the natural love of technology which made technologists choose their profession in the first place, engendering a conservatism which can block change. I've faced it more times than I can count, and applies to technologists favoring any platform. I've fought with Oracle technology experts who think that Oracle tools should be applied in all situations, Unix experts who treat the incursion of Windows into their environment like a body defending itself against infection, and Windows experts who view the growth of open source with fear normally reserved to attack by chainsaw wielding asylum escapees.

The fear of change isn't just confined to new technology. Many of us grew accustomed to the overheated job market of the 1990s, with its fast wage growth, job security, and headhunter queries filling our inbox. That market was driven by a telecommunications revolution set in motion by the creation of a global Internet, a side benefit of which was telecommunications links which enabled ever closer integration between IT centers around the world. That created competition from sectors that programmers in rich nations didn't expect, such as developing nations like India and China who charged far less than local programmers.

In the boom years when IT resouces were in short supply, nobody noticed. But when the boom turned to bust, fear set in, and former fans of free markets became closed-border, anti-market fanatics within months. Those foreign programmers were taking "our" jobs, and we have to stop them lest the American economy pop like an overinflated balloon.

As I've discussed before, however, foreign outsourcing isn't the jobs catastrophe people make it out to be. That seems less controversial today now that IT markets have picked up. A defense of international outsourcing would meet with less negative response today than at the start of 2004, simply because markets have digested the ramifications of outsourcing and realized that it's an addition to the IT resourcing toolkit, not a wholesale replacement. Outsourcing lowers costs for certain types of tasks, leaving more money for the new development tasks that local developers do best.

None of this is meant to imply that there isn't room for a principled defense of a position you think is right. Fans of Oracle tools, Unix or Windows are free to defend why they think their favored technology is best suited to the task. Local programmers are free to describe why outsourcing a particular new development project to India is a bad idea (as I've noted, new product development is a poor candidate for outsourcing).

It's important, however, to keep an open mind and embrace change when it's clear that that change is for the general good (even if it entails some work on your part). That may sound obvious, but then again, if you think about the sort of things that tend to find their way into historical lists of "commandments," they usually are obvious.

The trick is adhering to them.

Our IT Commandments:
  1. Thou shalt not outsource mission critical functions
  2. Thou shalt not pretend
  3. Thou shalt honor and empower thy (Unix) sysadmins
  4. Thou shalt leave the ideology to someone else
  5. Thou shalt not condemn departments doing their own IT
  6. Thou shalt put thy users first, above all else
  7. Thou shalt give something back to the community
  8. Thou shalt not use nonsecure protocols on thy network
  9. Thou shalt free thy content
  10. Thou shalt not ignore security risks when choosing platforms
  11. Thou shalt not fear change
  12. Thou shalt document all thy works
  13. Thou shalt loosely couple

Topic: Outsourcing

John Carroll

About John Carroll

John Carroll has delivered his opinion on ZDNet since the last millennium. Since May 2008, he is no longer a Microsoft employee. He is currently working at a unified messaging-related startup.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Party like it's 1999?

    I still see about as many headhunter e-mails and field about as many phone calls as I did in 1999. Most of them are a) projects related to Homeland Security, or b) projects that prepare in-house resources to be offshored. Do I take the contracts? Heck, yes. Am I roundly hated by the people who thought they had stable jobs? You bet. Then again, I also take customizing FOSS contracts, which were offshored from the Netherlands and Sweden, so I can also be roundly hated by their citizens too.

    Contractism: it's the newest reason to hate people as a group.
    John Le'Brecage
    • I've never had trouble getting a contract...

      ...and that applied even when I was in Europe. Of course, contracting is a different lifestyle, and fear of change for those accustomed to full-time employment in-house at a corporation can be acute.

      Different, however, doesn't imply difficult.
      John Carroll
  • Positive change won't be evident until years later

    Change is often good, but the way we humans do it can lead to disruptions that seem unjustified. My sense is the way a lot of companies have handled outsourcing is the wrong way: they outsource new development, and keep the legacy stuff in-house. According to yourself, and other IT experts I've listened to, this is ass-backwards. Eventually they learn this was a mistake, but it's disruptive in the meantime. IT workers get the impression that their jobs are at risk no matter what they do, because of these mistakes. They see people whose jobs shouldn't be outsourced, get outsourced. We have to learn from our mistakes to make change work.
    Mark Miller
    • Very true...

      ...and that's why it is useful to counter a change you don't agree with. However, there's a middle ground between fear of the unknown and blind acceptance of whatever hare-brained idea comes from upper management.

      People have already been burned with outsourcing, and they are starting to understand where it fits best. You are right, though...first attempts tended to be ill-considered, mostly because the ability to outsource was so new.
      John Carroll
  • How about

    [i]"Thou shalt not throw thy chair."[/i]
    D T Schmitz
    • Okay...

      ...I promise not to throw my chair at you.
      John Carroll
  • Suggested commandment: Wait.

    When driving on a limited access highway I prefer to be the second fastest car on the road. The police usually pay more attention to the fastest.

    Outsourcing, of which offshoring is a particulrly disruptive subset, is just the latest example of what happens when an idea is embraced and implemented before it's understood.
    If a company interested waits to see what works and what does not, and then waits again to develop plans with a chance to be effective, and then waits again to assure that the candidates for selection will be capable of meeting requirements... maybe the whole idea will be abandoned.

    And that applies to hyped fads like the ones that divert so many (other) people at ZDNet.

    Given the failure rate of substantial changes, being the first or even quick to change can make an organization an object lesson.

    Learning from others' mistakes has been a strong human trait since cave people decided to avoid caves from which the first to enter did not return.
    Anton Philidor
    • Good point...

      ...though one could say the same about the mad rush into Internet technology which occurred in the 1990s. Humans don't like to wait, and jumping on bandwagons seems programmed into our jeans.

      I guess the "don't fear" commandment is basically a call to be rational about these things. That applies to those who are forced to contend with people who aren't waiting.
      John Carroll
  • Re-cycled change

    My definition of a "re-cycled" change is thus - When a new technology is first brought in-house, there is a flurry of activity until things finally settle down. At this point, the technology goes into the maintenance phase and get replicated. What happens when you fail to recognize the importance of a feature - that you already have? This is good technology that was passed over when it wasn't understood, but is never re-visited by the "next-best-thing" guys looking at new tech.

    In my (*NIX) world, this product is the automounter. NOTHING like it exists outside of the *NIX world (I WAS able to have it work from a NFS mount from a Windoze box). It is a POWERFUL tool that allows things like file-system virtualization - a wonderful idea where "hard-coded" pathname problems go away. It allows you to get to your home directory from any machine, and allows for load-balanced, high-availability application serving. These are things that you <b>cannot do on M$ Windoze or any non-*nix OS</b>. Are they useful? You bet. What does it cost? Nothing - built-in. Why are we not using it? IBM has something called SAN File System that does the same thing at an exhorbanant price - so we are looking at that! ITS NEW!

    Getting what you ALREADY HAVE to work better - without introduction of new tech - is a "change" that no one seems interested in.
    Roger Ramjet
    • Speaking of tech . . .

      How come I space things nicely in paragraphs - and ZDnet squishes it all together? Any CHANGES being implemented here . . . ?
      Roger Ramjet
      • Suggestion.

        Put a line between paragraphs and two when you switch topics.

        Makes the post look longer, but less daunting.
        Anton Philidor