Slashdot Mirror
Rise of the Corporate Skeleton Crew?
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?
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.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
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.
Sig (appended to the end of comments you post, 120 chars)
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.
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?
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).
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.
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.
Only 'flamers' flame!
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.