Employee vs. contractor

Tom Mochal's post got me to thinking about the differences between the employee and contractor relationship.

As a consultant, I always work on contract.  That isn't strictly necessary, though.  "Consult" is what I do (i.e., provide expertise in my field of specialization); "contracting" merely describes the terms of my engagement.  It just so happens that most consultants are also contractors, whereas most (but far from all, increasingly) programmers are also employees.  Why is that so?  What differences in these two forms of engagement make one more appropriate than the other for a given role?

  1. Exclusivity.  Whether or not it's desirable, an employee is to some degree "owned" by their employer.  They usually have an agreement that includes not working for competitors (often even covering some period after termination).  Even taking on a second, unrelated job may be frowned upon.  Essentially, they've parked their career on the company's lot for the duration of their employment.  To be fair, an employer buys this exclusivity at the cost of FICA, worker's comp, health benefits (not so much anymore), and other employee perks; while contractors pay for their freedom by bearing all those costs themselves.
  2. Duration.  Employees are expected to work a set minimum schedule of hours as determined by their employer, and they're often expected to work overtime with no additional compensation.  On the other hand, they can usually count on holding onto their job until either they or the company screw up majorly.  This arrangement gets the most hours and most predictable production from people whose output is often measured (perhaps erroneously) in terms of daily or weekly goals.  A consultant, on the other hand, may only be required for brief, intermittent periods to ensure that the company is making the right choices at the right times.
  3. Direction.  Most companies have some form of management hierarchy that sets goals and measures performance for employees.  Contractors are generally expected to be more self-directed, since the company is their customer rather than their employer.  Focusing on customer satisfaction (rather than on the next performance review) means that contractors should think beyond their assigned duties, beyond the questions asked by the customer, to try to solve the real problems at hand instead of the ubiquitous imagined ones.

As I intimated in my comment on Tom's post, the sense of responsibility for the company as a customer should ideally be forefront in the minds of employees, too.  Anything that gets in the way of that will turn potentially creative people into less than they might be.  Unfortunately, the image of the (sometimes not so) benevolent, parental employer often leads employees to act more like adolescents: covering their tracks and focusing on perceptions rather than results.

That's a gross generalization on my part.  Some companies get this right.  But way too many still get it wrong.

So in light of the above, perhaps the worst case scenario (for the company) is the contractor who is expected to produce like an employee, but doesn't report to anyone in the company, and furthermore isn't dedicated to the company as a customer because they are employed by a consulting firm instead.  Their incentive is to make their employer think that they're being productive — a perception that is only weakly linked to solving any actual problems for the company.  For the consulting firm to be really successful, they need to tightly couple their employees' evaluation to their customers' overall satisfaction, so they'll take ownership of the company's problems.  Or just find a hot niche market where they can charge big bucks for garbage work because there's plenty of it.


Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

Editor's Picks