Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Technology

Rise of the Corporate Skeleton Crew? 49

Big Stick asks: "Recently I have noticed a trend in several prominent companies in my area of laying off entire technology departments. Just this week in my own company--a division of a well known, mid-sized corporation--the software engineering department was let go en masse, rather than just a reduction in head count. The rationale for the move being that it would be easier to evaluate the potential cost of developing a new product if groups of contractors were hired, instead of the numbers getting lost in the 'free' work of the full time developers. The overall impression this leaves is that many major companies are re-prioritizing the need to innovate new technologies for the presentation of their business, relying on skeleton crews of DBAs/SAs to maintain rather than enhance. The main question this raises is, are we heading towards an era where full time software development is more likely to be housed in technology specific firms? Something along the lines of the construction industry where projects are bid on, constructed, and the involvement of the creators with the finished product is minimal?" If others of you are noticing this trend in the industry, please share your thoughts. Do you think this is a move forward or backwards?
This discussion has been archived. No new comments can be posted.

Rise of the Corporate Skeleton Crew?

Comments Filter:
  • by ObviousGuy ( 578567 ) <ObviousGuy@hotmail.com> on Sunday May 19, 2002 @09:56PM (#3547696) Homepage Journal
    The simple answer to your question is Yes. It is cheaper to hire contractors because the benefits normally paid to full-time employees are not present. A full-time employee who makes $50K a year typically costs twice that when taking the cost of benefits into consideration. It makes much more sense to hire a contractor to write a piece of software in 2 or 3 months at $50/hr and let him go at the end of the stint. It's the same amount, but without the strings attached (like termination bonuses, etc).

    As for the GPL, which the title alludes to, it is the biggest proponent of contract-based employment there is. Since the GPL encourages sharing, companies will not develop in-house applications on their own dime and then license the software under the GPL. Therefore GPL programmers will not find full-time positions in companies developing software.

    This leaves only businesses that need a one-off program to do some sort of processing. This is where the GPL comes in, and is where the GPL really shines. Programmers who have at their disposal the full set of GPL code can use their knowledge in filling these one-off programming contracts. But it is doubtful that they would ever get hired on writing GPL'd code full-time.

    In essence, the GPL is killing the concept of the programmer-career path. It is making it easy for companies to cut costs and build their systems upon free software. This means a dramatic drop in full-time headcount, as you have seen in your own experience.
    • >A full-time employee who makes $50K a year typically costs twice that when taking the cost of benefits into consideration

      Not really. That "cost" above the salary is referred to as the "fringe rate". The company that I work for has the fringe rate set at 25%, which is a little low. An average fringe rate is generally 35-40%, not 100%

      When you hire someone through a temp agency or contracting agency that fringe rate is built into that. If as a contractor you're being paid 25/hr, the agency is billing you out for at least 35/hr, probably more.

      And yes - I do work for a HR Department.
    • I remember being at a social gathering where a project manager went on and on about the benefits of contracting out programmers - 10 years ago.

      The arguments then were exactly the same as the ones mentioned in this article. The practical reality hasn't changed much either.

      Some companies can contract out one-off programming work either locally or abroad to India/SE Asia. For lots of other companies, it will always be highly desirable to directly employ key talent in order to retain investment in product experience, improve security, improve the viability of long term software maintenance, and gain better overall negotiation power.

      The way I see it is the only way the industry will switch to mostly contractors is if programmers chose to do it for their own benefit, like doctors. Don't count on this happening in the absense of a strong guild structure.
  • by wackybrit ( 321117 ) on Sunday May 19, 2002 @10:07PM (#3547760) Homepage Journal
    This reminds me of the Dilbert strip where the staff were fired and immediately rehired as contractors for more money ;-)

    But, really, this is absolutely great news. Okay, maybe not for the people who were fired, or for people who are full time employees in technology divisions.. but for those of us who are contractors and freelancers, this is wonderful.

    It makes more sense for those companies too. They save a heap on labor costs, and only pay for what actually gets done. It's illegal to constantly hire and fire staff according to workload, but it's not illegal to put work out to freelancers. This is the sort of business we live off of.

    This sort of downsizing was all the rage in the early 90's and it led to the start of a massive boom for freelancers and contractors. Maybe this is the sign of the next boom. So, hey, perhaps the lull really is picking up folks. Let's hope.
    • An interesting sidenote is that one of the companies alluded to here has had extremely bad luck with hordes of contractors who have failed to deliver on several highly visible projects. As a full-time developer I've watched them come and go, and some even return after having left.

      I would think that in many cases hiring a grab bag of developers (possible from various contracting companies) for a project might present certain disadvantages. First, I think it's hard to ignore the sense of teamwork that can be fostered from working day in/day out with the same people. Granted, familiarity can lead to many negative things as well but a good "manager" should be able to smooth this over. Also, I think there is something to be gained by your developers knowing about the core business, what the customers expect, etc. Some businesses can have rather steep learning curve in this regard.

    • But you will lose the business knowledge that's in your employee's heads. Knowing the apps like the back of their hand and how things work/don't work in the organization is pretty valuable to the company too.

      My guess is that they decided to outsource all the development to an off-shore company because it looked like it would be cheaper on paper. Only time will tell if that's really the case.

      • Not good. (Score:5, Insightful)

        by Kris_J ( 10111 ) on Sunday May 19, 2002 @11:46PM (#3548142) Homepage Journal
        My guess is that they decided to outsource all the development to an off-shore company because it looked like it would be cheaper on paper. Only time will tell if that's really the case.
        Time has told. Rough figures: Contractors do half as good a job, taking twice the amount of time (though they only get called in for half as much stuff). Overall, IT contractors cost about 25% more up front and the level of computer support falls so low that it adversly affects the rest of the staff to the point where the real costs of external consultants is anywhere from 50% to 100% on an in-house IT department.

        Not all consultants are the spawn of evil, but the ability to walk away from something that goes wrong and have plenty of other companies still interested in your services does result in the failure of many a high profile project. In a big economy, a small IT consulting firm just isn't accountable. Mind you, failure often isn't strickly their fault -- if there are no IT people inside a company then there's no one who can really talk to and understand IT consultants. Frequently the two parties will think they've agreed to totally different things.

        Unfortunately, the first full-time IT person to walk into a company after an outsourcing balls-up isn't much better off than the consultants, with no-one in the company able to help them define their job and understand the installed systems, so the turnover for the first few permanent staff is also a bit high, leading to problems that look very similar to those caused by outsourcing.

        But I mean, what do you do when no-one in upper management understands how the company's IT infrastructure works? And how do we ever get to a point where upper managment at least has a few people who do understand IT when they're mostly so damn horrible to anyone that knows how a computer works?

        • Care to quote a source for these numbers?
  • Economic Recession (Score:4, Interesting)

    by jo42 ( 227475 ) on Sunday May 19, 2002 @10:08PM (#3547762) Homepage
    What you are seeing is the result of the economic meltdown that started with the dot-com bust. Despite what you see on TV and read in the papers, the economic meltdown continues - the media is masking the severity of this downturn. If you want to see for yourself how bad things really are, take a trip through the US and note the closures of many businesses, the 'downsizing', and actually talk to people. Things are much worse than they are made out to be. Conspiracy? Possibly. However, if the media told how bad things really are, economic conditions would be even worse due to reaction to these news.

    How does this fit into the topic of this discussion? Companies are going into holding patterns, reducing costs and hoping that things will turn around soon. I predict a second wave of large reductions over the next few months. I point to an article that IBM is looking to let go up to 20,000 more staff by the end of the year. By letting whole departments go, costs are being reduced significantly. It also allows the company, if it survives, the ability to restructure, either by contracting work out or rebuilding.

    Bottom line, keep the hatches battened down for further stormy weather. Bookmark this. Late in the year we will see if I am right or not.

    • Despite what you see on TV and read in the papers, the economic meltdown continues - the media is masking the severity of this downturn. If you want to see for yourself how bad things really are, take a trip through the US and note the closures of many businesses, the 'downsizing', and actually talk to people.

      That's not a good way to get a clear picture of the economy. Employment is a lagging factor in economic recessions: things are bad for months before layoffs begin, and things are good for months before layoffs stop and hiring begins.

      So if you go around looking at downsizing and talking to people who have lost their jobs, you'll get a picture of what the economy was like several months earlier.

      It's also worth noting that unemployment in the US is currently at 6%. Not nearly as good as it was 2 years ago, but worth remembering that until then unemployment hadn't been below 5% since 1970 and the Fed was worried that an unemployment rate below 6% would spark inflation similar to that seen in the early 70s, decimating the economy. The current "horrible unemployment rate" was thought of just 7 years ago as "unsustainably high levels of employment that risk pushing the economy into a depression"--obviously alarmist, but the point is that the job situation is still better than it was in 1995, or in the economic boom of the 1980s.

      Sure, I know a lot of people who lost their jobs--myself included. The company (a dot-com) I worked at went from 450 to 50 employees. But I don't know anyone who lost their job and didn't find another one at equal or higher pay within 3 months--and that's in the (comparitively) hard-hit software industry. Indeed, without 2 quarters of economic contraction or substantial unemployment, many people don't think we're in a recession at all. It's certainly a much milder one than we've had in my lifetime.

      Sumner
  • Certainly this isn't new in tech markets. Y oucan outsource nearly anything you want, including development of your core product. There are plenty of development shops overseas that you can contract on the cheap to develop your code end to end.

    The ongoing issue will be at what point is it more advantageous to get rid of internal full-time developers.

    While you may think they will always be essential, in industries like automobiles, companies like GM let companies like Dana pretty much manufacture a large part of the finished vehicle already, and the trend is to move more and more of the work to suppliers.

    In the end, the cheapest way to satisfy customers will win.

    • What you implied, but left unsaid, is that outsourcing leads almost directly to cheaper goods for the consumer. Dana (assuming you mean the drivetrain company) specializes in drivetrains. Why not let them build and design the best drivetrain? Makes sense to me. Why try to build/design a car stereo when there are dozens of manufacturers out there.

      The slashdot libertarians should be quite happy about things like this.

      The real trick is that (to take the GM example again), does the 'assembling company' (GM) know how to assemble parts from disparate companies, or do they only know how to do the complete package?

      BTW, not sure how any of this applies to software. I'm in the medical industry, and you let someone else deal with the government goons.

  • stability (Score:2, Insightful)

    sure, fire the employees, hire contractors. Lets look at the definition of a contract: basically hired to do a specific job for a specific amount of time. Implying that the contractor will move on. I have always thought that hiring full time employees is better, Full time employees, if they stick around, know the company, the technology, and their jobs. So contractors may be 'cheaper', but there are all of those intangable costs and benefits. Even if the full time employees are over-worked sometimes and bored stiff sometimes, they still will be more loyal then contracters will. and loyalty=stability. Stability= more venture capital, etc, etc, etc.
    • Full time employees, if they stick around, know the company, the technology, and their jobs.
      Contractors who are captive by temp firms, and who see themselves as simply another kind of employee, don't develop that relationship with the company, that's true. Contractors who are truly self-employed had BETTER develop that in-depth knowledge of the company (client), technology, etc. because the profit is in repeat engagements. It's a lot harder to sell the first contract into a company than it is to sell follow-on work. Put another way: the cost to acquire a new client is huge, the cost to retain them much lower. Same pay with less marketing cost = higher profit on return engagements.

      Contractors who don't do everything they can to establish those ongoing relationships shoot themselves in the foot.
  • I'm a hardware design engineer, and I see the same trend in the large corporation that I work for. In our case, the work goes not to individual contract employees on site, but rather to outsource companies in Asia that bid on the job, who in turn hire direct employees at very low wages.

    A skeleton crew of direct employees (including myself) remiains to oversee the work.

    The model is not working very well. There seems to be a huge gap between the former direct employees and the contractors in many areas, including knowledge of the company, products, and market, in technical and language skills, and commitment to quality and results.

    Our highly centralized upper management is in deep denial that there is anything wrong with the model. After all, we now have more "engineer months" assigned to the project, so it will obviously work out just fine!

    I'll be looking for a new job soon.

  • by Anonymous Coward
    This recently happened to me. I worked for a startup. We built a killer-app that a big company paid lots of money for. Oddly, they put some pretty inept managers in charge of us, and before long we no longer had the market leadership that we did when acquired.

    The point is, one morning a few months ago, we were all laid off.

    The decision to acquire us was a smart one. We were ahead in the marketplace, we needed to grow, etc. etc. Ironically so was the decision to let us go. We were 45 miles away from the main office, had come to be a source of embarrassment for the company, etc.

    The stupid decisions were in how the product development was mismanaged. Once that had been done, it made sense for the big company to cut its losses and look the other way.

  • I recently interned with a southeastern utility company. The majority of their software is created in-house. The main purposes are customer tracking, inventory tracking, workflow, and in house tech support. All of these applications are handled well with a database and a front end, so that's what the IT department was creating. The infrastructure in this company became highly specialized in delivering these custom made applications (read: insecure bloatware), and frequently, downtime was a result. After the Y2K 'crisis' passed without a hitch, that preperation team was restasked to evaluate and deal with the rising IT v. Infrastructre problem. The main thing that came out of this committee was a slogan: "We're a Public Utility, not a Software Company." Management agreed and the decision was made to phase out in-house software developement. The goal was to grab ready-made, off-the-shelf, tested and proven solutions, modify them only as necessary and deploy them company wide. I feel that this is the best solution, afterall why re-invent the wheel? It was getting to a point where 1/2 of the employees were tasked to various IT departments.

    That's what I've seen, just fyi: I was in a non-IT position(it's kinda fun telling the in-house tech support how to do their job and getting an "oh yea, now I remeber" response).

    • I think the general point is a good one: Outsource things that are not your core business. If you suggested to a hospital that they print their own letterhead, they'd look at you like you had rocks in your head; suggest that their run their own IT department, and they'll take you seriously. (The analogy is not perfect, of course, since letterhead's a pure commodity, and an IT infrastructure is not.)

      HOWEVER... There are a lot of counter-examples. A lot of companies (and divisions thereof) don't seem to understand exactly what their core business is. I worked at the Circle-M Ranch (no, not the real Circle-M Ranch, the batwing M place), and while about 60% of the systems group was (long-term) contractors, the cafeteria staff was all employees!

      That's a crude example, but my current employer is another one. We're the internet arm of a publishing firm, with our own programmers, content writers, DBAs, QA, and sysadmins. So when we needed to create custom code and content for our app server, what did we do? Outsourced, despite the fact that we had enough expertise in-house and we were more answerable to management than outsiders were.

      That brings me to another point about outsourcing: they aren't very answerable to you long-term. Sure, you can have a contract with explicit standards...but if the contractor doesn't live up to the standards, chances are they get paid anyway, partly because in a large IT project it's very easy to conceal blame by confusing issues. The contractor may also try to ensure that you hire them again by ensuring that nobody but them understands your infrastructure after they're done with it. And if you don't hire them again - hey, the way a lot of companies are these days, there was a good chance they wouldn't get hired again anyway.

    • The main thing that came out of this committee was a slogan: "We're a Public Utility, not a Software Company." Management agreed and the decision was made to phase out in-house software developement. The goal was to grab ready-made, off-the-shelf, tested and proven solutions, modify them only as necessary and deploy them company wide.
      I worked (note past tense) for a large midwestern utility that tried the same thing. After they fired all the 40-year DP veterans, they found that (a) there is no substitute for 40 years of business-specific knowledge (b) really smart 22 year-olds who hop from job to job at the drop of a dime are not a good substitute for reasonably smart 46 year-olds with stable lives (c) consultants who have no loyalty to the organization are interested in one thing only: grabbing as much loot as possible, then moving on to the next victim.

      This company's outsourced customer service system was 3 years late, and when it was turned on it failed to bill half the customers for at least 9 months. Cost them $3 billion in lost revenue. Good move.

      "We are not a software company" - yeah - makes some sense. "We are a customer service company and solid, well-understood tools that are under are control are required to serve customers" - well - that makes some sense, too!

      sPh

    • "We're not a Software Company" can also be read as:


      We don't know how to manage software projects.

      We don't want to waste management's attention on software.

      Standard solutions are more reliable, because they are not dependant on one or two key people.
      Or even:

      If we admitted at the outset what a big job we have in front of us nobody would approve it.

      An almost religious belief that at least the first three of these truisms are always true seems to drive infrastructure projects here at the very large, supposedly very technically sophisticated, company where I work.We start out buying a "turn-key solution", find out that it is not quite so turn-key, hire consultants and contractors to customize it, then finally after a year or two of work we end up with a system that is at least as custom as we would have developed in house, with the main difference being that the key people are contractors instead of employees.


      Of course, the managers here would disagree strongly - they are sure that their careful adherence to these well known truths has saved us from certain disaster.


  • by texchanchan ( 471739 ) <ccrowley@@@gmail...com> on Monday May 20, 2002 @12:01AM (#3548184)
    Zero-inventory = getting the supplies only when you need them, saving overhead in storage and so on. Hiring contractors instead of maintaining employees is analogous. Get workers only when you need them.

    However, a worker is not like a part off the shelf that can be popped into place. For projects of any complexity, there is going to be a learning period.
    a) About the project
    b) About each other. There are always human dynamics to consider, even among focused technical personnel.

    I see this as successful only in an environment of standardized work projects--more like an assembly line than anything else. And if it's that standardized, it'll probably find its way to the second or third world pretty soon.

    It is easy to imagine management trying to treat a project, any project, as if it could be handled with plug-in workers. It's equally easy to imagine this leading to tremendous delays and failures.

    I've been both contractor and employee. Always preferred the freedom of contracting. But I have a high tolerance for being broke.

    • The other way to get around learning curves a and b (above) is, if the contractors are a small enough community so that they know in general what's going on in the geographical area or the technical field. Also, so that they know each other. This could only occur in an atmosphere of specialization much more marked than we have now. Possibly also would lead to trades & crafts-like certification requirements, keeping the pool of contractors small and controllable (by the contractors themselves).

      Zero-sum thinking is the big danger here as many other places.
    • Zero-inventory = getting the supplies only when you need them, saving overhead in storage and so on. Hiring contractors instead of maintaining employees is analogous. Get workers only when you need them.

      However, a worker is not like a part off the shelf that can be popped into place.

      The large telecom equipment company that I work for has made it plain that upper management thinks we're all interchangeable cogs.
    • Zero-inventory = getting the supplies only when you need them, saving overhead in storage and so on. Hiring contractors instead of maintaining employees is analogous. Get workers only when you need them.
      JIT worked really well for Toyota. For a while, in Japan, anyway. It worked for Toyota and a few others in North America, for a while anyway.

      The UPS strike of a couple years ago, and the events of September/October 2001, have put a real dent in the JIT theory. It doesn't do much good to be able to track your critical inventory to 1 cm with GPS+RF tags when you find the inventory stuck in a customs queue at the Canadian border.

      I would have to think the same sort of problems would apply to "JIT employees".

      sPh

  • yes and no (Score:4, Insightful)

    by josepha48 ( 13953 ) on Monday May 20, 2002 @01:23AM (#3548385) Journal
    There are companies that do this, well sort of. AMS is one. They cone in build your software package then leave. Of course they offer you a support contract. My company does this to an extent, but some firm will need software engineers to build the product and a 'custom' built system takes 3 years.

    Then there are bugs. Building a bridge or house you better not have bugs (other than roaches and ants) that cause the house to collapse. How can the software industry make bug free software that works? THEY CANT. Linux has bugs, BSD has bugs, Windows has bugs, Sun has bugs, HP and AIX and MAC ALL have bugs. Palm has bugs as well. THER eis no way you can design a bug free OS and there certain is no way you can design software needed by a corporation to use that does not have bugs.

    My company let go of 1/2 of our dev team this week. We need to rewrite or go under. I'd like to take the source, rewrite it and then sell it back to the company as an improved product that they can resell. Ah heck I'm going to get into a different software development market.

  • by Anonymous Coward
    Back in the early-mid 90s I worked for a corporation that probably had a 2:1 Contract-to-Employee ratio. The rational was that it was easier to allocate staff, get rid of people, and made Wall Street happy with the headcount numbers.

    The other side was that some 'full time temp' folks there were getting ridiculous money -- $75/hr for accounting employees that could have been hired for maybe $60-80K at the time.

    A few years later, there were real jobs everywhere, retention was a major issue, and salaries were shooting through the roof. (This is the Bay Area.) I consulted at that place for a couple days and they said that they were 98% employee.

    My guess is that companies quite rationally think that in this job market, they can hire the talent they need for exactly the time they need, and there's no need to keep expensive folks standing around the water cooler. Of course this tends to backfire, so if you can get on the gravy train of big hourly rates for regular style work someplace, by all means do it.
  • by ninjaz ( 1202 ) on Monday May 20, 2002 @08:37AM (#3549513)
    I suspect in a large part, this is a housecleaning measure. Corporate environments tend to foster byzantine empires driven more by politics than by productivity. Each department manager fighting to get his budget as high as possible, each manager having his own team of sycophants operating at 5% efficiency while using politics to put a strangehold on other teams.

    The contracting houses aren't enmeshed in the corporate political structure, and offer project-based propositions rather than the typical corporate song and dance. Of course, an economic downturn is the perfect time to do this. When things are going well, "if it ain't broke, don't fix it". So, I'd consider this essentially as a corporate maintenance window. Soon, the limitations of outsourcing will rear their ugly heads eg., "oh, you want additional services beyond the contract? 5x the original cost!" which will spur the cycle onward.

    Regarding technology-specific firms, I think that's another topic entirely.
    In point of the construction analogy, I think the analogue would be software libraries. But the creators of those need skilled people to keep those in order (think movie & image format display stuff)

    If you mean in the fabless CPU company sense where a company gives a spec to an engineering company, I think that may end up as a net gain. That way, you get software design expertise concentrated with companies who know how to do that. Think: less hopelessly clueless managers calling shots on software projects, making every mistake in the book and dooming everything to failure through gross incompetence.

    Of course, the same companies which would be doing the "design" would need to know a good deal about software to begin with, which brings us full circle to how things were previously: software companies writing commodity software and vertical applications. Internal teams doing specialized work because open-ended/emerging technology is typically not handled well by contracting.

    I've never personally seen an IT outsourcing scenario that ended up well for the company doing the outsourcing. Typically this is because of changing business needs conflicting with the locked in contract with the services vendor.
  • A Brazilian company I consult for had 5 developers in house, but couldn't keep up with the payrolls.
    Their solution was quite creative: one of the company's partner opened another company with de laid off developers and started working as a contractor, and not only for the former company but also to others.
    I'd say that getting together and helping each other may be a very good solution. Of course, if you are going to build a whole new enterprise and have only one client, it would be ruined fast, but if you can find a good manager and (possibly) a good salesperson, you all can end up earning more than before.
  • One substantial issue with consultants is they will completely milk a large contract for all it is worth regardless whether the project is a success. I remember one consultant on a project who was always 80% finished. "Oh, I finished this, but that will take another two weeks..." His work wasn't all that great, but it worked just well enough to keep him going and going. However, it never worked well enough that the end product was worth the investment.

    Another substantial issue with consultants is that there are so many firms that choosing one almost seems arbitrary. Knowing that there are dozens of firms in a city and that many of them are incompetent or sleazy, how does a person dig through the crap without getting burned first?
  • I agree with the general sentiment of this discussion, that hiring temporary workers is cutting costs for the big companies -- and my dumb company is doing it backwards!!

    We're currently going through layoffs, and today's announcement was to freeze all consultants. Adding even more to the mystery, our IT dept. is infamous among my group (we're somewhat auxillary to both the IT and marketing depts.) for their internal billing -- regularly quoting higher dollars than it would cost for a consultant to do the same job. Add benefits cost to that, and it just begs the question: wtf?

    Is anybody else working for a laughably backwards company like this? I'm splitting my time between working on my resume and laughing my head off.
  • We let go of all the other Unix/NT/Cisco guys.

    Now it is just me doing Solaris/Linux/BSD/Windows 2000 and acting as backup Cisco guy....

    I have been watching the job boards for a while and have seen TONS of postings for Unix admins with MCSE's and Cisco certs????

    OR Developers who are also Oracle DBA's with SA experience.

    A couple of recruiters have confirmed this and told me that the companies are asking for everything from tech workers now.
    Its really silly of companies to do that. No one can be an expert at everything. Something has got to give.
    When it does the company is gonna pay heavily for it.

  • I worked in an agency (Hi, Brian & Jen & Tanya!) where a guy was hired _because_ he had experience doing this kind of chop-shop work. Eventually it failed, he got booted, no one was surprised. This was tried because the guys at the top were cheap-skates and they got sold a bill of goods about how this was a "smart" way to manage resources. (They also laid off the tech support department en masse one day.)
    The theory was that there'd be a couple of in-house staff near the top of each project (though not actually the leads) with everyone else on contract. Unfortunately, with no work coming in, the guy spun his wheels for a few months and eventually got the axe. In the mean time, the sole interactive CD-ROM project [yes, it was 1996] that we tried to do this way bogged down further and further, to the point that I don't think it ever actually shipped.
  • You need to ask your self what profit do these people add to the business? I do not mean that as a troll. IS departments are overhead. They often grow all out of proportion to their real need in a business. Most IS bosses are empire builders and TRY to grow their empires. As a cost center IS deptments should be telling the rest of the company how to get teh job done for less, not write a new database program everytime a user asks for a new field.

    If you work in an IS department that is moe than 2% of your company's head count expect to see pink slips. Look how those armies of well paid middle managers have been sacked and replaced by a few admins if you doubt the bean counters will not catch on.

    Different rules apply to departments that make products that are sold and MAKE money for the firm.

    • That is exactly the rotten thinking that is what is wrong with so many businesses in America.

      I'll illustrate by describing my experience at Dell.

      I worked tech support. We didn't generate revenue directly. Therefore policies were put in place that "saved money" by alienating customers and eroding Dell's reputation for having first-class tech support.

      On the other hand, the policies in the sales department "made money" by allowing (and in fact encouraging) salesmen to do things that would cause a customer to almost certainly never buy from Dell again, and probably return the system they just bought in the first place.

      I suggest that a better metric than "You need to ask your self what profit do these people add to the business?" is "How do these people affect the business' overall profitability?"

      The other major problem that this brings to light (but is off-topic) is the way that departments are set at odds with each other. Time and time again I saw situations where doing something one way would cost our department x dollars, and another with cost some other department 4x dollars, so we did it the other way without regard for the fact that it cost the company four times as much.

      A company that is able to sell PCs for premium prices because they offer stellar support mortgages their future when they "enhance" today's profit by eroding that reputation for service, using the theory that "these people don't make us money."
  • Here's a fun situation - firm outsources infrastructure IT (ops/network/telecomm/servers) then after a change in CIO 18 months later, insources 80% of them who are left. Original head count was about 130, coming back about 75-80.

    Let's face it, firms don't want to be in the IT business, but those firms that do not have an effective IT function will invite another firm to do it for them. If your company is growing quickly and changing rapidly, fight for the creation of a ninja IT team that will act as an IT strike force. Your firm will have the benefit of dedicated professionals that will (hopefully) share in the bennies as you grow.

    If your firm is stable, then look at outsourcing. Your IT people will have new vistas open up for them, and your company will now have to justify all of those weird requests since they have to pay dearly for them.

    Just a thought...
  • The part of this whole situation that is sad to me is that businesses have gotten so incredibly far away from their roots. The original concept of a "business" were groups of people working together to do or produce something in return for something. The point was not to become wealthy, move up the corporate ladder, or take over the world.

    The thing I most wish that businesses today would remember is that the people (read employees) used to be the important part - the business existed to help the people, not the other way around.
  • Ronald Coase wrote what should be a famous paper on why corporations exist. Some respondants here understand why; some do not. Basically, a corporation exists to reduce the transaction cost of negotiating every bit of work that needs to be done. If that cost is low, then corporations have no reason to exist.
    -russ

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Working...