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
Depending on how you structure the company, employees are certainly more loyal, especially if there's stock involved. They'll hang their asses on the line to get the job done, whereas contractors typically -- note "typically" -- have a laissez faire attitude towards projects. This is more a market problem for employers than anything else; contractors typically come from firms that can have a backlog of opportunities. If the contractor is faced with a difficult project, the contractor can usually bow out for an easier one. An employee can typically find jobs quickly in the market, certainly, but there's always the hassle of having to find the job (unless he/she wants to become a contractor).
I've found that a good working environment with employees is better than any group of contractors...
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.
There are a large number of top notch people out there that have absolutely no desire doing contract work. I'm one of them. I like to get to know the people I work with and that can be rather difficult if you are jumping from job to job a few times a year. I also can't stand looking for work, I've got better things to do with my time. Yeah, the money contracting is nice, but as they say, money isn't everything.
Also, not all contractors are created equal. I have worked with a number of execellent contractors and I have also worked with a few turkeys (the turkeys don't last long).
As a low-level manager in a tech support office, I have a large number of people I'm responsible for, and a recent hiring trend was to bring in almost exclusively contractors from [a prominent technical staffing company]. This has had two contradictory effects.
One, they know just slightly more than the untrained people who were brought on as company employees, but often had more relevant experience. This was both a boon and a burden. . . while they took to training slightly better, many had chips on their shoulders and were openly discussing their intentions of moving on after their 90-day period was up. Fine, that's up to them, but not so bright or good for morale.
Two, there is the issue of seniority should they choose to become employed by the company. This has caused no end of headaches.
This isn't an industry-wide sample, of course, but for what is basically entry-level technical staffing, contractors are not the best solution.
I agree with the individual who said that employees are better for long-term projects, since they will have more ultimately invested in the outcome.
Rafe
V^^^^V
Rafe
Opinions expressed by the author may not actually exist in the wild.
As a contractor I must say that, where I work, if the didn't use contractors things would take 10 times longer. There are two reasons for this:
:)
1. I work for the Australian government. The public service has a ridiculous class structure that means that new staff can't get employed at higher than the lowest level and getting increased pay for a particular level is hard. What this boils down is that that can't pay enough to get good software engineers on staff. If the don't have good software engineers there projects come in way over time and over budget. With good software engineers that come in only a bit over time and over budget
2. Software isn't core business. If the had to pay the required rates to keep good software engineers on staff that'd only be able to employ half the staff and the extra they are paying for SE's is wasted when the don't have work for them.
Admittedly there are a few problems with contractors. Most of these are to do with the fact that they don't have the same commitment to the company. What I've fund works well is if you have a few employees on the development team with the contractors. This means the contractors are invloved with the company. The employees don't have to be software developers they can be people who are there for requiremets and for ideas on what is required.One of the employees should also be a manager who is dealing with the admin side of management. This person should work closesly with the Technical Manager who should probably be a contractor. This approach will mean that the contractors work on your site all the time.
The company that I work for has established this method of contracting as our standard operating proceedure and when we bid for contracts we explain to the customer this is how we do it and we explain why. Most of the appreciate it and it helps us win the contract.
dabrig
"If ignorance is bliss, then wipe the smile off my face"
In the Boston area anyone with a couple of years experience in the right areas could get a contract through an agency for 50 bucks an hour within a day. If you have 5+ years experience you can get 100 an hour. On your own you can expect to add 50 percent to that. Why anyone would waste there time working for a dead-end company is beyond me.
Of course, if you have an equity stake, that's a different matter all together; but working 80 hours a week to get a coffee mug and a hearty slap on the back at the end of a death march is for chumps.
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.
While it's true that having 10 different groups of programmers for your 10 versions will waste time, as each group has to get re-acquainted with the source base, it still may be better in the long run to rotate people through the project. Why? If you're programming component Gizmo, and you know that somebody later on, other than yourself, is going to have to maintain Gizmo, you're going to think a little more about making Gizmo easy to understand/documented. However, if you believe that you are the only one that will ever be maintaining this Gizmo for a long time, why bother with documentation/understandable design -- you can get your new features implemented faster by skipping those steps. The nomadic consultant programmers will understand that they need to write better code such that the system can be maintained.
This brings up an interesting question: how is code handled inside Microsoft? Do programmers end up running their own modules for long periods of time without rotatation of programmers? If so, this may explain why Microsoft's programs started out being fairly good, with new features ahead of the competition, yet now, several years later, they are having horrible problems with stability and code bloat. One reason I think Linux is so stable is that the programmers expect and hope that others will view and improve their code, so they write it in an understandable fashion. Microsoft code is undoubtly terribly more ugly to look at than any open source project (just ask the folks who got University licenses to see the NT source).
Without long term, dedicated employees, your company cannot build a technical personality and its associated value.
I have been both a contractor and a full-timer. The work I did as a contractor was simple and task oriented. Whenever I wanted to innovate or improve the process I was ignored or rejected. Now, as an employee at the same company doing the full-time version of the same job I have latitude to do what I need to do to help the project and the company succeed.
Looking back on my contractor days and also at contractors now in my group, I can easily say that for positions that the group clearly needs creativity, dedication and innovation, it should choose a full-time employee - and reward them well. As a full-time I have taken on nearly the same task with a ton more energy and enthusiasm than I was even allowed to before and am therefore helping out even more!
If you need people on to help maintain a project for a definite period of time go with contractors. If you need intelligent people you want to add value to the entire company with, choose full-time employees.
Thanks for your time.
theSLEEP
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.
Of all the figures you quote, they can only get better by being selective of the company you take options from. Its similar to playing any game, you don't make move randomly, you think about them. I have worked for 4 startups now and had 2 go public (but I left the last one that went public just before it did).
Just remember to be selective like you would normally be and don't let the lure or options seduce you to work at a place that you don't see going anywhere.
-jason
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.
Just to provide some info for fellow consultants..
Yes I know this is off-topic..
If you are a 1099 contractor you dont have to
deal with the whole taxes and non group benefit thing. My last contract I just signed up for
a benefit company which deals with all the taxes,
group benefits..etc. It cost me 200 bucks a month
for their services and believe me.. its worth it.
An example would be Gotham or church hill benefit. www.churchillbenefit.com I have no direct
relationship to them.. just a happy customer.
Malice95
At least when I was contract on a 1099, I couldn't figure a way to expense my health insurance. Tax law treated it as a personal expense, not as a business expense, and personal expenses are not deductible.
-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.
Yes, there are a lot of bad contractors out there. Yes, There are bad consultants. Yes, too many are motivated by money alone.
But most consultants are {should} be different from the sort that most people seem to have experienced and are commenting on here.
I am a consultant. I work for myself, sub-contract out for additional help only when needed for a specific area. I tend to maintain my relationships with clients for years, even if they only have me do a few dozen billable hours of work for them per year, unless they are completely unreasonable or don't pay their bills.
The pay is nice (easily twice what I can make in my state [Maine] as a employee most places). But I don't consult because of the money. I am a consultant because I *hate* doing the same thing every day, and I want to be using and implimenting fairly new stuff on a regular basis.
As a consultant, I get to see and use a lot of new technology, and gain experience in a lot of different settings. I get to work with all kinds of people and different types of projects. I have even cut my rates to work on a project from time to time, because the project looked like fun or was interesting in some way.
People hire me because I get the job|project done and can resolve problems (or better yet, anticipate problems) that leave their own guys stumped, or at the mercy of their vendors. I usually work directly with the customer's IT staff, and am often given day-to-day management oversight of their staff for the duration of a project.
I believe the fact that I work on many different projects for many different people is a value add for my clients. I can't tell you how many times I have been able to tell someone "you want to watch out for X when you do Y" because of experience that I gained on another client's project.
I also hate office politics and the other BS that often goes on in organziations (ever have to chase paperwork for 3 hours to buy a $100 part?). As a consultant, I am an outsider.
I can tell the management or the CIO or whomever EXACTLY what is wrong with their methods or ideas or who isn't pulling their weight, and not have to really deal with the politics, if I don't want to. It is not that this gives me a license to be rude, but rather, an opportunity to be completely honest with them. Sometimes this doesn't go over very well, but often times, they are glad to hear it.
A good consultant should be able to save you time, money, or both on your project. They should be able to represent your best interests in all areas, especially when dealing with vendors and outside contractors. Consultants should be vendor neutral. A big pet peeve of mine are the so called "consultants" that are really just resellers for a set of product lines, and really only want to sell you their "solution package". Consultants should only sell their time and expertise, and nothing else. I very rarely ever let a vendor or contractor group so much as buy me a drink.
One of my own personal goals is to always bring enough value to a project (through cost savings or time savings) that it more than pays for my consulting fees.
In short, an outside consultant should be hired for the same sort of reasons that you might hire a good lawyer, accountant, or other professional: to help you with major planning or processes, to give you access to a depth of knowledge and experience you don't have in-house, and to kick some major butt when and where you need it.
There's a lot of good info in here, a lot of good advice, and very little that could possibly need to be moderated down, so, I almost feel odd skipping over page after page of commentary that probably contains the same sentiments I'm about to espouse.
I've seen contracting done well and contracting done poorly. I've worked in situations where i felt it was done poorly.
Yes, by and large, there is at least the myth that all contractors make more money. This isn't always true. I'd venture to say it's more often than not a myth these days.
I can't say i enjoyed my experience as a contractor. I love the company that i worked for, I just got tired of being citizen 2nd class.
Businesses can't survive without teamwork, and a team oriented perspective is aided by actually, well, being made a member of the team.
Loyalty is a two way street. If you see a long term need for your contractors, offer them a full time position. Offer them an equitable salary and job security. Let them know that they can take their pick, that you don't wish to force them to change the way they work for you, but you'd like to offer them job security because you value their work. See how many of them will bite. I suspect a fair number of them will, and a fair number won't. To each his own.
I think it's absurd to think you need to hire contractors to get the best people. You may find excellent people working as contractors, and better than what you'll drag in off the street generally, but by no means the best.
At some point in their life, most people find themselves in a situation where they realize their stress level, or the stress level of the people they love, would be greatly relieved if they were to aquire a position of security in a good company, and feel assured that they have no reason to believe they'll be looking for work in a few months or years.
That being said, I'm afraid there are too many companies hiring contractors on a "when we feel like it" basis. It's incredibly unfortunate that the lines between "technical contractor" and "temp" have become so blurred.
If you know you're only going to be using someone for a limited time, let them know how long that is. If you're filling for a 3 month project, give them a contract for three months with the option for you as the employer to extend the contract, and give them the option to negotiate to leave early if the project completes before the deadline and they are nolonger needed.
Give them a definate date, guarantee them work for an agreed-upon length of time, so they know when they will be available, and when they should start looking for other work. Leave yourself the option to forewarn them of possible contract extension if the project is going longer than expected. Leave them the option to negotiate to leave early if the project is ahead of schedule.
In short, give them a clear cut, sane, and equitable package.
And lastly, by all means, even if they are a pinch hitter, let them join the team. They've signed the nondisclosure agreement, so you can let them come to meetings that pertain to their work. Let them come to the company picnic, have them bring their family or a friend of they like. They feel uncomfortable getting involved, and may decline, but it's only polite to invite them. Let them know that for the duration of their contract, granted some obvious security risks that need to be looked out for, they are indeed one of the gang.
Otherwise, if you've shown them no great consideration for their person, you can expect them to show you a smiliar ammount of consideration for your project.
It's just food for thought. There were days when i was between "real" jobs when i felt like i wasn't doing all i could do for the company i was with, but couldn't totally convince myself that I wasn't more of a water boy than a pinch hitter.
I feel bad about that, but what i wanted was a secure position with like-minded, team oriented people, and i couldn't help feeling disappointed with the situation i was in.
Some people like contracting. Treat them well, they'll treat you well. When you need them again, they'll come back to you.
Some people are just looking for the right company, or are waiting for the right company but haven't fully visualized the need for it. If you need them, offer to take them into the fold, it's a better relationship for both of you. If you don't, give them as much stability as you can. They will appriciate it, and will do you the same favor in retun.
This is just like television, only you can see much further.
Here's an idea, you get what you settle for.
Everything that I might have said has already been said, and sometimes not too politely. Given that I am a contractor and that I prefer it that way, you can guess how well I like those snide remarks about contractors being ill bred parasites. However, to give it perspective, look up J. Campbell's analysis of the interaction between the nomads and the agritarians. Compare it to the Contractors and Emps. Funny how things work out that way.
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
Background: I have worked as a maintainer and developer for more than fifteen years. We work with projects, i.e. we work for customers with products that should be finished in from three to twelve months, with from two-three to many more developers.
It could well be that contractors are among the "best" people, and we do occasionaly hire some when we're short of people. The big problem with contractors is that they always come in on projects unprepared, because they haven't been there that long.. which means that the project is hit hard with Brook's law: Adding people to a project that is late makes the project even later. It doesn't matter how good they are. We can hire super-contractors but they're not much more useful than fresh students, because they don't know the background for the project (they are often expansions or new features in old projects), they don't know the customers and their site and other projects etc. We can make them useful if we have a long-term project
with good experienced employees leading the project where it makes sense to hire the contractors, and only if they can join from the very beginning. But we definitely prefer to populate the project with the old hardliners (our own employees). Conclusion: Contractors can be useful for completely self-contained, rather simple and short projects and jobs.
TA
In case you are curious, I do contract work for the U.S. government. We work side by side with the government employees. I have been at the site for 1 1/2 years, and there are others at the site who have been there much longer.
The workgroup I manage is a mixture of contractors and sub-contractors. We usually bring the sub-contractors in with 6 months right-to-hire. This arrangement has worked out well for ramping up quickly. (Even so, it is hard to find good web programmers these days!)
Word on the grapevine in that the legislation (IR35) is due to be either dropped completely, or significantly toned down. However, I haven't heard anything officially about this, and last time I looked, there was nothing on http://www.ir35update.co.uk about it. I guess time will tell.
I'll be less affected than most, as I pay myself a relatively high salary (to keep my pension contributions high), but it's still a worry. In particular, some of the proposed regulations will significantly drive down contract rates.
Anyway, in answer to the original question, I'd aim for about 75% permies and 25% contractors.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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.
Form a corporation (or trust) off-shore and become an agent of that trust (remember you CAN NOT be a beneficier or grantor!) If you investigate, you will find certain countries DO NOT tax foreign income! As an agent of the off-shore corporation you are free to contract and work in the united States (yes small 'u')
l t ml i x.htm
Remember to give your manager a W-8 form, as the number of the off-shore corporation CAN NOT be used as a TIN inside the U.S. (yes Capital 'u')
Here are some links that you will find interesting:
http://members.tripod.com/~fedinfo/tax_page.htm
http://www.civil-liberties.com/pages/cases.html
http://www.mind-trek.com/practicl/tl16d.htm
http://www.nyx.net/~imschira/frogfarm/fffaq16.h
http://www.mind-trek.com/treatise/ls-tbj/append
http://freedomabovefortune.com/
Email me at mpohores@sfu if you would like more information.
BUT, the PM should be aware of the added risks when using contractors. I've seen many projects running into serious problems because of insufficient/bad contractor management. If you think about it the risks involved are most of the time just common sense:
(i) Is he good enough? You normally have quite a good idea of your own employees' experience and strengths. A contractor may have a good reference etc. but some more background research may be needed to establish confidence that he will be up for the job.
(ii) Problem definition and design. Too often a badly defined contract causes a lot of delays downstream when you realise that what is delivered is not really what was requested, causing a lot of time for rework and integration. This is often made worse by a PM not willing to commit to the extra overhead and ensuring there is REGULAR feedback (e.g. staggered design reviews and deliverables) from the contractor and good communication between him and your own people who will be using his module.
I'm sure there are many more issues, but I'll stand with the above two. Do the effort for some background research on the possible contractors, don't take one because he's cheap and available NOW
something wicked this way comes...
Well, anyway, that's my $.02, hope it helps.
I noticed something today while I was at home after 8 hours of work. At about 9:00PM my boss calls me up. He's changing my schedule around to 12-9PM and scheduling me to work on weekends.
You ahve less than a month left. How much does this job really matter to you? What's stopping you from just saying no?
Companies ask ridiculous things of their employees because employees grudgingly go along with them.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Disconcerting, to say the least.
I think the tendency amongst the non-computer-types who manage IT nowdays is to view their entire staff as toy-happy ne'erdowells always looking for new ways to spend "their" money. If their staff says they need to upgrade their 10baseT network to a switched 100BT network because the current network is completely saturated, they have the same response as if the staff says that they need to buy top-of-the-line SGI workstations for all of the developers' desktops -- both requests are treated the same, as "frivolous techies just want new toys". After all, these IT managers came from finance or sales, they wouldn't know a network switch from a light socket.
An outside consultant, since he is not going to be the one playing with the "new toys", is viewed as more dispassionate by the PHB. Which, in turn, discourages employees, who then contribute to that turnover problem by going elsewhere or going contract...
-E
Send mail here if you want to reach me.
There's plenty of interesting things to do within my current employer's walls, and not enough hands to do them all. I don't have to go elsewhere to get variety.
-E
Send mail here if you want to reach me.
Many people here seem to be making some false assumptions:
1. There is only one kind of contracting/consulting work. Which is not true at all. I've known consultants that stayed with a company for 5 years. And there are also contracting teams that always work together, which lessens the social problems of contracting. Not to mention the fact that contractors often work with the same company on and off for many years as well. And there are also contractors that primarily teach employees. (Personal note: I think contractors write crappy code often because they are expected to and given deadlines to match. A craftsman is a craftsman whether contract or employee.)
2. Contracting is the same everywhere. That is also not true from what I've been reading. In different countries, heck, even different parts of this country the attitudes about contracting and employment are very different. If you are in Boston or the valley or Seattle, there are a lot more startups and the history of failed companies shafting employees is very long. Loyalty in such areas is very low. Even between big companies and small companies the comparisons and the contrasts are very different. (Personal Note: My opinion is either contract or work for a small company. Contract for the change of pace and the money. Small company for the chance to make something real, be a part of something big and get vested. But then again I don't really value complacency/stability that highly in todays market:) I think people have to take this stuff into account, like where this guy is coming from..
>The best developers are worth upwards of $150/hr, and if you want to keep them on your staff, PAY THE MONEY.
There's a problem with this. Management generally doesn't have the slightest clue who's performing and who's not. They sure as heck can't pay everyone $150/hour, and if they can't tell the difference between diamonds and coal there's a very real risk they'll be rewarding the wrong people. This will create even greater alienation among the good employees, and hasten their departure out the door. Maybe in the long term allowing poorly-managed companies to fail in this way would be a good thing, but in the short term I'm not sure the industry can tolerate such a high mortality rate.
Slashdot - News for Herds. Stuff that Splatters.
>Conflicts of interest often arise
Forget conflicts of interest, how about outright intellectual property theft? At one company I worked for, a contractor walked out with a tape of our source code, which as little as a month later started showing up in a direct competitor's product. I know because my next employer licensed the code from the recipient of stolen goods, and I recognized some of it as my own.
OTOH, I've seen regular employees carry code from one job to another and reuse it in their new projects without a twinge of conscience too. I think it's only the sheer turnover rate that makes this more of a problem with contractors.
Slashdot - News for Herds. Stuff that Splatters.