With the obvious reward for contractors being money, it shouldn't come as a surprise that the new breed of IT workers will be highly mercenary. That isn't really a bad thing if you view them in the same light as plumbers, lawyers, and surgeons. Each of those professions is predicated on the correct assumption that people will always have somewhat random, but predictable problems that must be solved by highly skilled individuals. If you have a flooded basement, you call the plumber who comes and resolves your issue for a premium price. The same thing holds true for lawyers and surgeons. When you need them, they are available to help you. But at the same time you pay handsomely for the services they offer. Both sides are happy with this type of exchange because it is limited in time and scope. Neither the plumber, lawyer, or surgeon tends to stick around after the problem is solved.
For IT contractors, the ability to work in this stark of manner is still somewhat of an evolving process. I saw this with a caveat that it probably pertains more to contractors above the age of 30 than below. Unlike the other professions that have been operating in the contracting mode for decades, IT is still in the process of transition. And this transition is leading to a certain type of dysfunction that I want to talk about.
Being the head of an IT organization I have the opportunity to view contractors coming and going all of the time. What I have observed in many cases is the following. The longer a contractor stays with the company, especially when they are performing the same type of work, the more they begin to identify with the company in the same manner as an employee. Here are a couple of qualifiers to further define these individuals:
- As mentioned above, they tend to be older than 30 and in many cases are closer to 40 years old and higher. The contractors at 30 years old and below don't want to stick around after the scoped work is done.
- They are usually more likely to be 1099 or corp-to-corp contractors. In other words, they are freelancers that don't have a larger organization out looking for their next gig.
- They are not new to IT. In fact, they probably began their careers as employees, unlike their younger counterparts who were never "part of the system".
- They are ambitious and typically work hard to develop relationships with senior leadership outside of the IT organization.
Because the nature of contracting is that, by definition it is temporary, the end result comes in one of two forms. The first is that the contractor is hired on as an employee. No need for worry after that because the "entrenchment" behaviors led to permanent employment. But, the other result is that the work comes to an end and the contractor is let go. I can't tell you how many times I have seen contractors leave "kicking and screaming". They can't believe after all their hard work and "loyalty" that the company would send them packing.
Ironic, isn't it? Have you seen that reaction from a contractor in your organization when it was time for them to go?
So there are two takeaways from this post - one for contractors and one for the managers who employ them.
For Contractors -- Your whole job function is to solve problems for an organization that cannot do so for itself. Charge a premium price for your work. After all, you would not be required if the company could handle the problem on its own. Embrace the fact that you are a hired gun and enjoy the fact that you can make a great deal of money while not having to engage in the political or interpersonal struggles that exist within the organization. Then, when you are finished get out. There is nothing to say that you cannot go back at a future point. By leaving you perpetuate the belief that you are in demand, which you almost surely are anyway. Revel in your ability to go where you want, work for who you want, and get paid between 2x and 5x as much as your FTE counterparts.
For Managers -- Realize before you ever hire them that contractors are problem solvers whose work should always have a beginning, middle, and end. Do NOT view them as a crutch or a way to ameliorate design flaws within your organizational structure. You will be paying them a premium (if they are capable) so put a lot of thought into exactly what you want them to do and then make sure that remains their focus. When the problem is solved, move them out. For all the reasons above, when the work is done it is time for them to move on. To do anything less risks the health, growth, and morale of your team.