IT contracting 101: Get it in writing

A tech who gets laid off during recessionary cutbacks is asked to come back to finish an app dev project, only to get burned again

Before the recent recession, I worked at a startup as a software engineer and developer. As the recession hit, we saw companies fall left and right. Our CEO assured us that our company was solid. But soon after one of these assurances, the ax fell and more than half of our company was let go.

It felt pretty bad to be one of those chopped, especially because, despite some frustrations about the company, I enjoyed what I was doing.

[ Want to earn a $50 American Express gift cheque if we publish your tech experiences? Send your IT story of a lesson learned, of dealing with frustrating coworkers or end-users, or a story that illustrates a relevant takeaway to today's IT profession to offtherecord@infoworld.com. | Get a new tech tale delivered to your inbox every week in InfoWorld's Off the Record newsletter. ]

The CEO even said that I was doing good work when he called me into his office to give me the news. "You're doing an amazing job, just absolutely hitting it out of the park," he began. Then he laid me off.

Off the Record submissions

For the next six months, I hit the job search hard, but didn't find employment. Then one day the CEO of the startup called me.

My role at the company had been to define a product, specify the functionality, implement it, and support the application in production.

One of the apps that I had been working on had been a few weeks away from completion when the ax fell. Since there was no one left to pick it up, the project languished. The CEO wanted to see if I was interested in freelance work to complete the app.

My first thought was, "Yes!" And my next thought was, "No!"

You see, one of the company's really big problems was getting new stuff through QA and into the field. It wasn't the fault of the QA engineers at all -- the problem was due to a process bottleneck. Only a select few employees had access to the production servers. Upper management, who created the workflow policies, stated that the reason was security, but there was an obvious element of paranoid control as well. There was a pervasive attitude of distrust, ugly turf wars, and embarrassingly childish egos within the small organization.

The Web applications we built had lots of components. Since upper management was afraid we would break the site, the development team couldn't access the production hardware (we could architect, design, implement, test, and debug the apps but not touch the production servers). QA had to be the go-between in order to get the details of problems before we could fix them. The process was just plain slow. While I was there, deliveries were rarely even remotely on time, and everyone was continually frustrated with the huge test backlog and the slow rate of progress.

I was quite rightly worried that I would do all this work and the app would never get deployed. I wouldn't have really cared except that the CEO offered me payment upon release into production. I spent many hours on the phone with a good friend -- someone I felt I could trust -- in the executive team going over my concerns. We agreed that, after feature complete, the application would be tested and released within a "reasonable" timeframe: three to six weeks. My buddy promised, his word of honor, that I would get paid fully.

I did insist on getting incremental payments for my work, which they agreed to. At that point, having been out of steady employment for so many months and thinking that I'd covered the bases, I went with my buddy's assurances, thinking they and the email trail was enough.

We got started. I did the work, then there were a few more features they wanted, so I whipped those up, and we got the application installed on their staging system. I did receive incremental payments as different stages were completed. My good buddy did a full two weeks of user acceptance testing and pronounced it feature complete.

Then the app sat. And sat. And sat. I checked in regularly, but my application "hadn't yet been given a slot in QA." Six months later, the CEO contacted me: They wanted back the laptop they had loaned me to do the work. "Sure," I responded, "just as soon as I get the rest of my payment."

Then the pissing war started. They said that the final payment would be made when the application was released into production. I maintained that the agreement was that I'd be paid in full after a "reasonable" test and release cycle that was framed as being three to six weeks. Now that we were six months out, we were beyond "reasonable," and I was entitled to the rest of my fee for the work I had done (especially since the application was still not scheduled to go into QA). They threatened to report the laptop stolen. I threatened with a legal suit.

However, there was nothing concretely written that required them to pay the full fee even if they never managed to get the application into production. My bad -- I had gone on my friend's promise that I would get paid in full for my work. I returned the laptop (the more mature thing to do), I haven't gotten full payment, and the friendship is shot.

I promise you, the amount of that final payment meant much more to me and my family than it could possibly have to the "well-funded" startup.

My takeaway is that a nice, gentlemanly, clearly written contract would have eliminated all this ugly back and forth, and it would have likely saved a friendship. I'm now steadily employed elsewhere and working with really great people, but I pay even closer attention to the details and the fine print.

This story "IT contracting 101: Get it in writing," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies