Slashdot Mirror
Ask Slashdot: Employees or Contractors?
gurn submits this item for discussion: "Here's my challenge, I currently managing the development section of a small Consulting Firm. All of the developement efforts are being handled by contract employees. They have announced that they are going to start expanding aggressively and as a result need to ramp up quickly - especially on the development side.. The president of the firm is uncomfortable with the developers being contractors, while I think it is the only way to get the best people. My thinking is that those that really know their worth and have high skill levels tend to be contractors. What do other companies do? What is your experience with contractors vs. employees? "
My experience has been this: if you need a task done that can be well defined, and has a short lifespan, say 0-3months, a contractor can be good. Examples might be writing tools that are "grunt work" or doing admin work for machines that are "hanging on" until your next project completes.
;)
In one position, I had a number of contractors work on development and deployment of a mail/web platform to support 25k customers. While they did reasonable work, what we defined and what they built didn't really jive in the end, mainly because they didn't come with the long term experience with our customers. Certain flawed systems, most notably NIS+ were used that later proved to be problematic, after many of the contractors were working elsewhere.
My advice is to find good people who share your vision and have the proper skill set who you can keep long term. This won't be easy, especially in an environment like the valley, but its better for you and your customers, and will almost certainly cost less. Don't forget that you can get an employee who has 75% of what you want, who will cost less than a contractor, and who can learn the other 25% as things progress. Employees can be put on-call... most contractors will balk at this.
As for all the good people being contractors.. I dispute that. Those contractors don't get good options in startups as a general rule. They may get more $/hour, but in the end the employees who stick it out tend to cash in way more.
-lynch
More importantly, I think, is that a significant number of in-house development positions have been given to contractors...and many of the contractors are former employees who quit, then returned as contractors. Certainly the company may come out ahead in that they don't have to pay such things as social security and other taxes, nor do they provide any benefits, but the IRS looks very closely at the use of contractors for more than just short-term jobs.
Also, I would question that you get the best and brightest of people. I think that you get individuals who are seeking a lot of money...but they are also giving up security, important benefits and entangling themselves in a potential tax nightmare. Unless you know that you are dealing with savvy business people, I would question the wisdom of your contractors. The pay that they command may be a lot of dollars in their pocket, but when all is said and done, chances are very good that they have forgone a substantial long-term financial gain for some short term money. And that doesn't sound like a smart move to me.
But it's true that to quickly ramp up a rapidly growing operation contractors can be a boon. Just make sure that you're using your resources wisely. You'd probably be well advised for your first contractor to be a human resources analyst.
=h=
In this business, even if you're an "employee" of a company, how long do you really expect to stay with that single company anyway? While working for one company, someone may decide to be labelled "employee" or "contractor" simply depending upon how they want to do their taxes, what kind of short term benefits may be provided, personal reasons, etc not because they are more or less skilled than the other guy. Some places are reporting over 25 percent turnover per year of their IT staff. I see no reason why being more or less skilled than others would make you choose one label or the other.
As an employee, I know that I'm going to be sticking around and probably MAINTAINING that code at some time in the future (even if I move to another project, I always find myself getting pulled back to patch up older projects to deal with unexpected contingencies), and thus I'm more likely to put the code together right in the first place. Take as an example the encryption code that I'm working on right now. I could have just taken any crappy old pseudo-random number generator and got good enough code that worked well enough for marketing purposes (albeit not cryptographically secure, but hey, it's a marketing checkbox). Instead, I took the time to put some DESIGN into it (if you look at sci.crypt you'll see part of the thought processes underlying that design). I wouldn't have done that if I was a contractor. I would have grabbed any old PRNG and rammed it in there, because the whole point of being a contractor is to go in, get the job done, and get out.
Anyhow: Contractors are hit'n'run, employees stick around. You need them both -- the project that I am working on could very much benefit from some contractors for a three-month time period, I have partitioned it off into a number of smaller projects that I can get a contractor working on in a jiffy. (Thank you Unix, "many small tools chained together" works!).
Think of it as the Microsoft approach ("good enough" code) vs. the ideal approach (code that is designed for expandability and maintainability, code that has some DESIGN behind it).
-E
Send mail here if you want to reach me.
It sounds like the code these developers are going to write is part of your company's core mission. If that is the case, then you really need these developers to be part of your company's core.
If the code is simply add-ons, doo-dads, and gee-gaws to what you actually do, then I back off. Frills and extentions can be done by contractors.
But if the code really matters, if you are judged by the application, then you need to have your developers' motivation aligned with the company's. That means making their financial success tied to the success of they company's. That means equity, not contract-by-month.
Building a good engineering team is not an easy thing. But it is absolutely necessary if you want to put out a good product.
I really disagree with the concept that "the good ones go into consulting." The good ones really care about what they do, and that means sticking around long enought to make it sure it works. Of course, you have to make it worth their while. Good people have "vision." They see their products almost as children, and care for them accordingly. Consultants see their products as rest stops on a highway. Nice for the moment, but nothing to invest any real time in.
Do you lose sleep at night worrying about work? I bet you do, and it is because you care about your job and how your company does. Good developers will be the same way. Contractors will worry for 3 months, and then just walk away.
Point being that it was corporate POLICY to hire kids for peanuts in full expectation that after putting a year of work, those kids would go elsewhere. They figured they got "good enough" work out of their cheap employees, and it saved them money. Their response to the IT shortage is illustrative -- they were one of the biggest enthusiasts for increasing the number of foreign IT specialists that could be imported on special visas. They figured that'd let them hold on to their kids for a few months longer, since there would be fewer higher-level jobs open to them (since the kids are woefully underqualified compared to the typical Indian programmer). That's how corporate snakes think, y'see.
Point: Employers who give a **** about their employees don't have those kinds of turnover problems. You can bet that employers who have those kinds of turnover problems typically have fascist environments that monitor everything, office politics rather than ability detirmines advancements, they require regular piss tests, have dress codes that are more conservative than Wall Street, and require two reams of paperwork to requisition a stapler. Sometimes these guys even pay well, but it just isn't worth the hassle of working there.
-E
Send mail here if you want to reach me.
I am a Project Manager in a Contracting Company, so probably I am biased in their favour.
Anyway, Contractors come in various shapes, just like the employees do. You can find contractors who will work 9-6 and you can find contractors who will more commitment to the company/work than a regular employee.
Advantages of Contracting:--
1. You do not need to hire and fire people just to get enough headcount for the peak development phase. Someone else handles the headache for you.
2. Although you are paying more than what you would pay to the regular employee, when you count the costs of Human Resources Management, Technical Training, 401, Vacation, Sabbatical, Stock Options etc., it does not end up being much more.
3. Many contractors do come with a better expertise of the functional area you are interested in.
Disadvantages (reasons/solutions):--
1. Loyalty. If you asking for a person to work with you for 3 months, you do not expect that person to be more loyal to you. And why should you??? However, I have seen contractors working for a single client for multiple years and being a strong part of the client team.
2. Employee Satisfaction. When an employee notices a contractor earning more than him/her, it is not bound to leave a good feeling. However, as long as they understand that the contractors are temporary and justified for a particular requirements, AND not a threat to their jobs, this risk can be mitigated to some extent.
3. Code quality. I put that in as a joke. Code quality is as good as the deadlines and/or the application design, irrespective of whether the coding is done by an employee or a contractor.
4. Loss of expertise once the project is over. Yes, once the contractor leaves, the expertise is gone. But should you not have some employees in the project?? Or some long term contractors?? At least one of these is essential.
Othe Perspectives:---
I come from a company which believes in offshore development. We do most of the work in India, while keeping about 10-30% of the manpower at the client side. Since the costs of doing work in India are about half the costs of doing work in US, the cost issue becomes moot. Also, part of the management headache is passed to the consulting company. And since we are commited to working with an offshore model, we put in much more effort to make the offshore work a success. This model is great for large project teams though may not be suitable for small projects.
Anyway, please do not treat this as a promotion for my company. I am a regular slashdot reader but this is the first time I though I would be able to contribute something to the discussion. You can write to harry_ruby@hotmail.com to discuss any other aspects of this issue. I would rather not get company email to get flamed.
PS: I have worked for 4 clients in my 8+ years in this industry and have been involved with the current client for more than 3.5 years. As a contractor.