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.
I am a director of a small consulting company and we generally find that we get the best people by taking contractors. It also means that we aren't paying them when we haven't got work for them to do.
The downside is that sometimes they find work through other people and they aren't there when we need them later. This has proved to be less of a problem than it might, but we have very loyal contractors because we treat them very well, pay them very well and involve them in the company as much as we can.
We also take on some permanent staff, and permanent staff is what some excellent people want to be. Bear in mind that after the designers have done their design, you need to implement it and that sometimes the 'best' people are wasted on scut work but it still needs to be done. Sometimes people are after the security of a permanent position, and they aren't in the business for fun or anything, but they can be damn good backing on the project nonetheless. Mums returning to the work force can be fantastic in this sort of role, especially if you're willing to cope with them working their own hours and so on.
My sister was a Senior Systems Analyst with a big banking group before she quit to have kids, and when they got a bit older she couldn't find anything but the lowest paying of jobs in the industry, even though all of her analysis and management skills were still completely applicable. She's now the being offered a slice of the organisation she joined simply because she's proved (again) that she can do all that, and because she's the longest serving employee - after only five years.
So: it takes all kinds to make a world...
-- Andrew
Andrew.
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.
1- Generally employees should be hired for critical tasks.
I love the people I work for, and what I do - but if someone offered my twice the salary, I'd leave. Simple as that. I have about 4 major projects that would be left hanging, and they would have a very difficult time replacing me. We've had difficulty just hiring some to "assist" on our team, never mind being "senior". Mind you, I'd likely wrap up my projects cleanly, or at least give them a chance to salary-match. (Otherwise, it's just not professional)
That said, if you're really happy with a contractor, and you can give them a competitive salary, offer to make them an employee... it strengthens the loyalty somewhat. Because...,
2- Contractors generally know more.
Like I said, less managment and admin, almost all the major work is done by contractors. Government employees, despite the constant (free) training, just don't keep up. They took a gov't job for the stability - not to spend hours a week just to keep up to date. Contractors are in it for the money and the tech, both of which require keeping ahead of the game.
3- Listen to them, even if you don't think they have a vested interest.
Nobody want's to be associated with a failed project, and they all want to be part of success stories, so if they are really telling you something is stupid, don't ignore it completely. (The same can't be said for contracted companies though... there's less personal reputation at stake)
4- Always have them onsite.
Offsite contractors are just difficult to manage, and communications break down. Simple as that.
5- Make them feel part of the team.
They helped too, and everyone likes a pat on the back for a job well done. Don't overlook them just because you assume they know their contribution. If everyone else in the team got a token, but not them, they'd feel pretty bad. I know it sounds like a small, silly thing (Dilbert-related), but it helps.
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.
This brings up an interesting question: how is code handled inside Microsoft?
:)
Altho this isn't really on-topic I'll relate this little story because you brought this up.
When I was in university and taking a program design class, I had a TA who had previously worked for both NASA and Microsoft (not at the same time).
The TA session was on specifications, and he trotted out some of the specs for the space shuttle software. It included huge amounts of detail, as you might expect for something like the shuttle.
After the class, a few of us accosted him about specs. I asked him what kind of specs they used at Microsoft. He said that he was worked on a word processor (presumably Word), and he said that the design/coding went like this:
[0] Microsoft "designer" draws a picture of what the gui should look like.
[1] "designer" goes to coders office and hands him/her the drawing.
[2] "designer" says to coder, "make it look like this"
[3] "designer" leaves office.
Assuming this is true, it might explain a few things
You can find either. The decision of what to go for depends on what your plans for the future are. It may be that you want have a lot of developers for one project. You hire staff, then they will complete the project, and you now have a lot of unused developers. Now you either have to find another project for them, or fire them. Firing them is bad karma, if they are permanent. If they are contract, then the contract ends and they walk away. Everyone knew that was the deal at the start and they are happy.
Moving staff to another project is harder, especially if you are a small firm. Big firms (IBM, AA etc ) can always find somewhere else. The smaller firms may have a problem.
Work out which is right for you.
Remember that contractors are human too. If you treat them like peons, then they will act like that, and you won't get the best out of them. Its very common to have contractors who turn up on their first day, to be given the old 386, the dodgy 14 inch screen, and the keyboard missing the space bar. The permanent staff have PIIIs, 21 inchs screens, and get to go to the project meetings.
Once there, they wonder why the contractor that they treat like a second class citizen doesn't give a shit.
Treat them right, and they will work as well as permanent staff for you. And be loyal.