Author’s name withheld by request
Several years ago, I was asked by my then-employer to work on an after-hours development project, modifying an existing application to work with a new database back end. Now, I’m no consultant, never claimed to be, and I’d never been a gun for hire before. I had heard horror stories from colleagues about things that had gone badly on their projects: undefined requirements, abrogated verbal agreements, and such. Yet I felt fairly confident that I had a handle on the situation and that I knew where those other folks had gone wrong. I was going to have a contract, written requirements, the whole nine yards. Besides, they were talking about a lot of money…
I’m going to tell you about all the things that did go wrong, despite my best-laid plans. Hopefully by doing so, I’ll convince you that after-hours work for money arrangements with your employer should be avoided: The terms “employee” and “consultant” should remain mutually exclusive. However, I’m cognizant of the fact that many of you may be unable, as I was, to turn down a large amount of money, despite advice to the contrary. Everyone has a price where greed takes over; it’s human nature. So while relaying this sad story to you, I’ll also be providing you with some tips to help you avoid my mistakes and to make your road easier should you choose to go against my warnings and take on such a project.
Clouds on the horizon
The first sign of trouble for me was when, after reaching a verbal agreement on a payment amount for the project, I was surprised by a request for a meeting with the company president, who had been present for all the haggling. She explained that there had been a mistake and that she had really only intended to offer about half of the amount we had agreed upon. Needless to say, this went over like a lead balloon, and accusations of faithless negotiating flew. A tense standoff ensued, lasting several days, but she eventually backed down, and the original agreement was written into a contract, although now with a stiff penalty for late completion, and signed.
At the time, I thought this was a cheap, used car salesman-like ploy, and I resented the treatment. However, it’s a widely used negotiation tactic, and after all, this was essentially a company attempting to get its best deal from a supplier. It just so happened that this supplier was also an employee.
Tip number one: The best way to avoid nasty negotiations is to accept alternative compensation, such as extra time off.
Partners and time management
I had a partner on the project, another developer employed by the company. At first, this seemed ideal; it’s always nice to have another person to bounce things off of and to divide the work with. Unfortunately, I had trouble with him right from the start. He seemed to be on a crusade, trying to “fix” all the application’s existing quirks and oddities and rework the user interface—basically going far beyond our project’s scope. We started to constantly butt heads as I tried to drag him back on task.
Here, we have another problem I hadn’t considered—supervising a coworker at night with whom I had no supervisory relationship during the day.
Tip number two: Don’t take on a partner unless you feel you can work well with the individual. If you do take on a partner, decide on a leader and agree on some kind of mediation strategy, before beginning the project.
My partner soon began having trouble finding time to work on our project because his daytime project was spilling over into the evenings, so we were falling behind schedule. Fortunately, I was in the opposite situation. My daytime project was going so well that I often had time to work on my night job during the day. We were so far behind schedule that I soon had little choice but to use my time this way. This naturally drew criticism from some of my coworkers.
Tip number three: Try to differentiate between your "real" work and your other project. Change locations, change languages, whatever it takes. Time management is difficult when your day task and night task are similar and performed at the same location.
In my case, we were on a different project but using the same language, tools, and methodologies as our regular, day jobs. Consequently, it was easy to blur the line between the two projects. The ideal situation would therefore seem to be a situation where you’re doing totally unrelated work as an ancillary project—for instance, COBOL during the day and Java at night. You then have built-in insulation between your two tasks.
Despite all the problems, we managed to finish the project on time. Unfortunately, however, the contract we had signed did not include any terms for payment. I think we had both assumed that we’d be receiving checks the day we handed over the code. Of course, it didn’t play out that way. Citing the company’s shaky financial situation, the powers-that-be managed to avoid paying us off for months. I treated this situation as though attempting to collect a late payment from a creditor, with persistent reminders. These reminders soon became harassment as my frustration grew. Of course, this landed me in hot water, since the person I was harassing was also the company president. I remember one particularly nasty exchange that occurred when payment was about four months late: I threatened to tank on a current project unless paid; she retaliated by threatening to fire me.
While trying to collect payment, I forgot one critical thing.
Tip number four: Remember that you have to come in and work there the next morning.
A certain degree of decorum is required when the individual you are attempting to collect a late bill from is also your superior in the company food chain. Of course, politeness often doesn’t make people eager to pay a debt. This quandary is yet another reason to pursue a nonmonetary reward.
Corollary to tip number four: Remember the taxman and have any taxes withheld.
In my case, I was finally paid, but there were no taxes withheld from the check. I intended to put away part of the payment to cover the tax liability, but of course, I didn’t. By the end of the year, I had spent the entire sum and had to write a large check out to Uncle Sam the following April.
Shortly after that fiasco’s resolution, I left the company for greener pastures. The experience had left me bitter and destroyed my confidence and faith in the organization’s management. It also ruined my working relationship with several coworkers. I’ve resolved never to allow myself to get into a similar situation again. The reason is simple: Consulting for an employer makes the line between employee and exploitable asset uncomfortably blurry. My advice to you is to keep your line sharply defined, or if tempted to blur it in this fashion, don’t make the same mistakes I made.
Have you ever had an experience similar to this? Do you agree or disagree with the author’s advice? Send the editors an e-mail or post a comment.