How much slack to give a programming contractor

Question

I have a contractor programmer doing some work for me and I'm wondering if I'm micro-managing or even being too strict with what I'm asking.

A few times in the past I have asked him to do stuff in a particular way, or follow a particular process and I have had to repeat myself because of his failure to do it. Lately I asked him to ensure his latest code project was checked in to our svn repository. I have had to ask this again after this not occuring (after about 4 days).

This will probably happen at some point but I'm a bit irked that a simple matter like was not followed through when initially asked and I had to follow it up. Is it acceptable to send another email outlying this. This is just a minor thing but it sort of has underlying themes in other work he does and we do together. I can't do anything about him (firing wise etc) as he was hired by my colleague and so we need him at the moment.

So my questions I guess are:

• How much slack does contractors get in regards to ensuring they do what you ask? Or do they get more as it's as long as the job gets done in the end?
• Should you treat contractors the same as employees?
• Am I being too OTT

Answer 1

This is a difficult question, and there's no simple answer. I think there are two important points to keep in mind.

• You hired a professional, and you trusted them enough to hire them. That means you should not normally interfere with their day-to-day work, nor try to micro-manage them.
• On the other hand, if you have specific needs or wishes, the contractor should take them into account, or explain why not.

So to answer your question: Whether something is a legitimate request or micro-management will depend on many factors (the role of the contractor, the external constraints for the work, the contractor's experties, your experties etc.).

However, one thing is a must: If you ask something of the contractor, you can expect a proper response from the contractor.

The response may be that he/she believes that their solution is superior, or even that you are interfering with things you do not know well, and that can be OK - but ignoring requests, or even accepting them and then not following through is unprofessional.

So I believe you really have a communication problem. Talk to the contractor, if possible in person or at least via phone/video chat or similar. Outline your concerns, specifically where you feel your requests fell by the wayside. Try not to accuse him, but explain that you expect your requests to be taken seriously (which includes a polite refusal, if needs be).

I hope you can get along this way :-).

Answer 2

First, it's important to understand that contractors are not employees, and the reason that many people go into business for themselves as freelancers or contractors is to escape the normal bounds of an 8-5 job.

As a general rule, contractors use their own equipment, pay their own health insurance, handle their own tax filing and reporting, and often set their own hours.

My experience comes from being a contractor in the United States, but I found information from the New Zealand Department of Labour Knowledge Base on the Difference Between a Self-Employed Contractor and an Employee:

The things to look at include:

• Was the intention to be a self-employed contractor or an employee?
• Is there any written agreement or correspondence that shows your intention?
• Who makes the tax payments to the Inland Revenue Department?
• Who provides the equipment?
• Who controls how and when the work is done?
• Who has the power to hire other people to do the work?

Additionally, here is some New Zealand case law which provides information on how the New Zealand courts determine the difference between an employee and a contractor.

In this case, the contractor was actually found to be an employee because the company provided equipment, regular pay, a set schedule, and even tax withholding. In this case, the area of concern for you is in terms of tools and controlling how the work is done.

With the criteria for being a contractor established, I'll tell you that I've been on the other side of this business relationship, as a contractor. It's up to me to use my own tools, my own computer, my own Internet connection, my own tax advisors, and of course, my own version control system.

In my case, where U.S. Copyright laws grant me full rights to any code I write, those rights are not transferred to the client until payment is made. Thus, in my past contract relationships, no code was transferred until that time period when payment was received.

In your case, you need to ask yourself what the contract says? What does New Zealand law say about who has the copyright to code written by a contractor. If the contract doesn't specifically cover this topic, you need to ask yourself if the law allows you to demand something that has yet to be paid for.

Since you're dealing with a contractor, you cannot make up arbitrary rules, unless of course this is covered in the contract itself. Furthermore, as in the case law example, Mr Bryson was deemed by the courts to be an employee, based on the answers to the questions of the difference between employees/contractors; thus, there is a danger that you could be liable for taxes and benefits should you ever have a dispute after continuing to treat the contractor like an employee.

In my case, I did eventually start using the client's version control, but that was once there was a level of trust built upon a series of on-time, prompt payments for work completed previously. However, I was under no obligation to do so as per our agreement, and I was fully within my rights to refuse to do this.

So what can you do?

First, ask yourself why you need this code committed. Are you directly working or contributing to the code too, or is there some other reason? If the reason is not important, then you might consider just letting this go.

If you do really need this code committed, your best course of action is to first look at your contract and find out what you agreed. If your organization and the contractor agreed to use the organization's version control, then you could remind the contractor of this written agreement and discuss a commit frequency that's mutually acceptable.

If your contract doesn't mention version control, then consider approaching the contractor to discuss this. It's important to understand the contractors concerns, and you may need to ask some probing questions -- in a non-accusatory manner -- in order to ascertain the perceived challenges. Also, ask if what you're asking for is acceptable. If not, try to find suitable alternatives that you both can agree to. If the concern is about money, consider discussing a more frequent payout. If that's not possible, consider using an escrow account to hold funds, which will be payable on delivery.

If you cannot come to an acceptable agreement, and the cost using this contractor's services exceeds the benefits you gain, then look at your contract to see if there is a way to terminate it. Keep in mind that in many cases, either party can terminate the contract. In other words, the contractor can fire you as well and go find work elsewhere, so it pays to be a good client. :)

In summary, if you want your contractor to actually be a contractor, it's wise to approach this situation as if you're meeting with an equal and not someone who you can control. Good luck!

Answer 3

I was at the opposite end of this question, it was my responsibility to commit code to an SVN instance my client had set up. Neither I nor the other contractor on the project could ever get SVN to work properly. It got to the point where we were zipping the code and emailing the project to the customer, and leaving it up to them to sort it out.

Contractor Independence

My 'workday' is about 3 to 3.5 hours. This is how much time I spend at the computer coding, and it's how many hours I bill. Since I work out of my house, I spend some time doing laundry, making tea, running around getting lunch or haircuts or cars fixed, etc. And, of course, perusing questions on boards, including SE and LinkedIn.

At various times I have mentored people, often quizzing them over dinner on matters related to programming, business, science, etc. As I did this I got better and better at explaining things. I remember dozens of times when I was trying to explain something I would come to a realization on the spot, something tangential to the explanation but nevertheless a useful insight. Often these were of critical importance later. Among the things I got from this is learning how to communicate with non-technical people, and how to be patient with people that are doing their best under the circumstances, but are in over their head.

Your contractor may simply be doing things however (s)he thinks they should be done: they've been micromanaged before and pretty much tune it out. They could either spend time explaining to you why they do it the way that they do it, or they could just get it done. They've been told it has to be done by a particular date, they probably knew at the start it wasn't going to happen, so they're producing at the natural rate of code development. I was told on one project that I had to be done by a legislative deadline six months hence; 18 months later I was finished. If you fire them and hire someone else with the same deadline, you'll get the same results if the problem simply can't be solved in the timeframe you're demanding.

In short, when people are contracting out of choice, it's usually so that they can 'make their own rules'. They have generally discovered that they can do their best work by freeing themselves from what would be routine concerns as employees: 'drop ins' from users or co-workers, detailed procedures by managers, 'all-hands' meetings, baked-Alaska cubicles, etc.

Some contractors can explain this if their customers are listening, others aren't so good at it. There is nothing wrong with asking for the code, but if SVN is creating problems just have them send you an archive and you can split it out to a duplicate project folder. I never have a problem showing my work; however there are some people that get highly defensive when a manager asks for routine progress updates. In that case the contractor is probably not doing their job at all.

Treating Contractors the same as Employees

A lot of contractors would like to be employees - they consider the 'arms length' relationship to be unfortunate. Usually this is true when they are seeking benefits like vacation and health care, don't mind the 8:00 to 5:00 routine, and would like to believe the employer will keep them around for years. These people tend to work on site, make their desks look like full timers, and get weird when managers don't keep them up to date on renewal status. When you find these, treat them like employees, and when possible, make them so.

When the contractor prefers to work at home, seems to have little patience with bureaucracy, and has fingers in multiple pies, they aren't wannabe employees. They're only one step away from starting their own company and hawking their own product. These are best treated as highly independent consultants.

'Over The Top'

The particular point you brought up wouldn't bother me, it is a reasonable request. However, being asked to do little things all the time is bothersome, particularly when it breaks up concentration. I'm used to spending chunks of time focused on a problem, which in some cases is days. I've been in work situations, both as a contractor and as an employee, where the working environment was so full of interruptions I couldn't make forward progress.

Signs Nothing Is Being Done At All

From time to time, employers run into people that don't have a snowball's chance of working out.

One example was a civil service employee responsible for administering some servers. This individual was both silent and reclusive, to the point of being a hikikomori. The base was set to close, and this individual succeeded in finding work with a major private employer in town. He handed over his passwords on his way out the door on the last day of his employment. We discovered nearly immediately is that he had done nothing during the entire term of his employment.

In short, in software and systems administration, silence is not golden. Real programmers tend to be noisy, they insist the programming language they use is the greatest, they'll argue over databases and processor architectures and browsers and whatever. In a group of like minded people, they tend to complain about bosses, users, working associates, vendors, and help sites. Note what percentage of users on this board are IT related.

I picked up a client that was in desperate straights. Originally the two developers sat at a computer in the client's office and muddled through the design issues required to get a medical billing system to work. Eventually, however, they did progressively more of their 'work' in their rural compound and avoided any presence on site. They were charging a certain amount of money for 'support', what this consisted of was coming in once a month to re-index files. I was unable to locate the source code, which they had agreed in the contract to leave on-site. When they gave us their copy, it was on a different disk capacity from the ones in the client's office - we had to go through other people in town to get the files transferred. In short, they had simply moved from development to milking the client, and real issues remained unresolved, such as in particular changes in Medicare billing forms. It took me about six weeks to fix the critical issues - from there on out I was making other enhancements that kept me busy and made the doctor's office more productive.

The third story is a bit of hearsay - I had been hired to replace someone that had found other opportunities. The most senior manager on this project would have lunch with me from time to time, and after a few months of work he told me the circumstances under which the previous employee had left. Her job was basically to fix some FoxPro code that was out of date - the system had severe performance problems and some stuff was buggy. When I looked at the code it was a bit bewildering, the backend was SQL Server (6.5) using stored procedures. This was non-Y2K compliant, so we were under some pressure. At any rate, after she had been there a month the senior manager had dropped in on her to get a status update, she took offense at the question and said basically 'Why are you bothering me? I quit!'. With that she walked out the door.

It was my opinion, after working on the FoxPro stuff for a few days, that it was unmaintainable, and we should just write the new system in VB6 and be done with it. As it turned out, the real performance issues were with the server, which we replaced with a significant upgrade. Had she made the project manager aware of the difficulty of maintaining the code, and the constraint imposed by the server, it's unlikely she would have felt put on the spot a month later when the boss asked for status.

For someone to take this personally meant that she either had no idea what she was doing at all, or didn't feel like she could discuss refocusing development efforts to better effect. I tend to suspect the former, since the people in our group were just trying to find the best way to get the contract delivered.

Answer 4

If as the @dreza indicated this is a contract employee, working on tasks assigned by the company. In this type of contract the contractor should be following the policies and guidelines of the company that has hired him. Additionally the company owns all work generated as part of the contract.

So in this case it is reasonable to demand that they follow company policy and to commit their code to SVN. If they continue to refuse to do this, terminating the contract is quite reasonable.

I have worked in this type of contact scenario and I never had any other expectation that all the company policies applied to me as if I was an employee.

Answer 5

If the person is hired as a contractor, then you can't really treat them as an employee - if you treat him and he let's himself be treated as an employee, then he isn't a contractor, and there may be severe consequences (mostly tax wise).

As a contractor, you don't take orders. However, you keep the client happy, because contracts can be cancelled. As the client, you don't give orders. However, you can tell the contractor what would keep you happy, and if the contractor doesn't keep you happy, contracts can be cancelled.

If you are not happy with the contractor, don't order him to check things into SVN. Tell him that you would like to know what progress is being made, and that you are worried about the progress, and advise him that he needs to show progress. You can't give him orders. However, you can demand evidence that you are getting your money's worth. If he doesn't work out, there are other contractors out there, and there are plenty of good ones.

Answer 6

From one point of view, you can't treat contractors exactly as you treat employees - at least in the US, if you do, there is the chance they can claim employee benefits especially if your company has some kind of beneficial windfall. However, that is usually predicated around treating them like an employee personnel-wise and not about them following technical standards and processes.

You should set expectations up front. At my company we've hired contractors of the "you are a special snowflake off to the side doing something in isolation and we're paying you to deliver the end result" ilk, and also of the "you are staff augmentation, you'll be on a team following all the team's processes and using their tooling" sort of gig. Not all actual contracts are this specific about the technical part, so just make sure there's a common understanding. Many contracts will say things like "and perform other reasonable duties as requested by the client" unless it really is a one-shot "deliver thing X whole cloth" case. At least around here that tends to be the difference in terminology between a "consultant" (coming in to do their thing with us) and a "contractor" (coming in to do our thing with us).

At my firm, we have a bunch of contract programmers, QA, and Ops engineers and they are most certainly expected to check code into svn promptly, send their code for code review to employees, use our ticketing system to track their work, et al. We're not running a one-person piece shop, we have many people collaborating on one product, and failure to do that would mean the contractor would be out on the street fast. Obviously this is all subject to contract, but many contracts either don't cover minutiae (where to check your code in) or have more blanket clauses (can be terminated at the client's discretion).

So to sum up, no you're not being unreasonable, do check the contract, maybe you should have set expectations up front, but you are empowered to give direction to a contractor. Also, he should be the one saying "I prefer not to do that and my contract terms say I shouldn't have to" and not simply ducking/failing to do it. Reset expectations in accordance with the contract and your wishes, and then if he's not living up to that, there's more fish in the sea.