Cutting Supply to the Chain
I’ve recently come to the end of my first venture into contracting, a one year foray with the supply chain wing of a large international organization. It’s certainly been an adventure - one worthy of a blog entry.
It’s been a rocky road, venturing through various terrains, requiring copious levels of endurance.
Thoughts on Contracting.
Before the project I certainly had a naive perspective on contracting. The only experience I had with contractors was with recognized experts, brought into projects for a limited period of time to perform a very specialized task. For instance an Oracle DBA co-ordinating a massive data-load process, or a Rules Expert spreading knowledge to the team. However, the use of contractors in this environment was very different, contractors were brought in to provide general skills - developers, testers, analysts - essentially being plugged together in the hope of achieving the desired result with very little direction and direct management.
Indeed, I was initially shocked by the approach - or lack of it. Contractors bring with them their own ideals and practices - getting a co-ordinated approach out of individual approaches is a relatively difficult breakthrough at the best of times. Of course, being part of a full-time team in a software development or consulting environment is very different, usually these employees are educated towards a consistent approach - one methodology shared by all. Contractors moreso need to be educated on each project to get familiar with the approach and the organization. Unfortunately the project was somewhat challenged to the point where no approach had been decided, so trying to get contractors working in a unified manner was an impossible task.
Even worse was the attitude displayed by some of the contractors that obviously recognized the system (or lack of it) and took full advantage of it. Quality controls were at some stages in the project virtually non-existent, so it ultimately fell back to the values and morales of contractors to appropriately implement functionality. All this made me realize that some people in the industry are not concerned about acting in the best interest of their employers or colleagues. Some are interested in maximizing their importance and value ($) to the business. Others are looking to silently idle, blend-in with the furniture and try to pass as competent enough to earn an inflated salary. So it’s certainly been an experience that has jaded my perception of contractors. I’d encourage any organization to strongly screen contractors (after all they should justify there inflated salary) and to avoid employing more than a small percentage of contractors on a single project. They undoubtebly offer the best value when employed for a limited period of time as experts that educate or trouble-shoot and depart.
Dutch Employment Law.
It has alot to do with the contracting market here in The Netherlands. It is extremely difficult to fire any employee - a court must permit sacking any employee regardless of the circumstances. Consequently it is somewhat understandable that employers may prefer contractors over risking employing a full-timer that interviews well but can’t deliver. Still, employers shouldn’t use this as an excuse - evolve your interview process - invest in forming a process that exposes just how good candidates are at what their core responsibilities. If your process involves just answering questions - I’m sorry but answering questions is not the core responsibility of anyone in an IT organization. Get hands on, down and dirty.
Testing Beliefs.
Going solo (so to speak) was an acid test to my personal values and beliefs, in this case an opportunity for me to encourage the business to evolve processes - to interact with management in a very unconventional way from what I’m accustomed. This particularly involved moving from understanding and accepting XP from a developers perspective to trying to rationalize and justify it’s practices with management - an experience that served to fortify my belief in the process.
At various points in the project the technical challenge wasn’t there - now this has happened a few times in my career - so I started to find ways to fulfill my technical interests outside of the office. Long commuting times via public transport offered an ideal time to do that, experimenting with different technologies. All this proved to me I am a geek not interested in stagnating, and I see contracting as a particularly hazardous way of falling into this trap - it’s easy to focus on the bottom line, $’s in pocket - but you’ve gotta be forward thinking. In todays marketplace, especially the Java marketplace, the flavor of today may not taste so good in future months. If you do not learn and evolve you will limit your employment opportunities to large corporations unable to move with the times.
Censored Opinions.
Admittedly, there’s been a few times over the last year where I’ve had blog entries screened and retrospectively I’ve decided not to publish them. Occasionally I’ve found situations and attitudes simply unacceptable and had to vent. While I advocate brutal honestly there is a limit to my brutality. I’m confident I’ve been able to express most of their important points to my colleagues and the community at large in a more constructive fashion than in the original blogs. Perhaps one-day I’ll be as shameless as the BileBlog but I’m grateful that day hasn’t come.
Moving On.
My next role promises to be challenging with plenty of development work, involving the use of Swing and JDO and a couple of other technologies I’m not intimately familiar with at this point. To top it off I’ll be working on a Mac - I’m very interested to see how my perspective on Mac’s as a 9 to 5 tool evolves. As a past-time/hobby, sure it’s rather cool on a Mac - but can it survive the 9 to 5 acid test?
