Why Companies Turn Me Down For Contracts

My current contract is lovely. I'm having a lot of fun and the environment is awesome. However, it's a short contract. I took it, in part, because it was a problem space I wanted to do more work in. Because it's a short contract I'm already working on negotiating my next contract (a perpetual hobby for freelancers), but I thought I'd experiment with a different approach: asking you to reach out to me. If you think I can help your company and you're not in a position to hire me directly, go to those who are and talk to them. If you want to hire me or one of the talented developers who works with me, drop me a line (I can't guarantee that I'm available, but you never know). If this approach works, I can do more work on open source or Veure instead of spending all of my "between" time negotiating contracts.

That being said, I don't always get contracts I negotiate for and sometimes I turn them down. However, if you're an individual considering freelancing, I thought it worth discussing some of the obstacles I've faced.

The single biggest obstacle has been "we don't hire remote workers" (though I can, and do, work on site as the situation requires). I lost out on one contract when the company hired someone they weren't sure could do the job but could be sitting in a chair five days a week. Despite appearances, this isn't entirely insane. Alistair Cockburn, when he talks about what makes projects succeed, identifies three major components of project success:

  • Frequent releases (ensures rapid feedback)
  • Ready access to the customer (ensures rapid feedback)
  • A co-located team (easier to lean over and ask for input)

The last point is the killer. There is nothing as powerful as face-to-face communication when trying to figure out a thorny problem. We know this. However, it's too simplistic. For example, being able to talk to people to discuss issues means you're often interrupting the work of people you're asking for advice from. Your productivity is increased by decreasing their productivity. If you're Ward Cunningham and they're a no-name teenage hacker, that's probably a profitable trade off.1 The other way around is not. Still, most people don't understand why programmer flow is important and, until they do, they won't respect it. Being in the zone is something that is difficult to describe to someone who's not used to it.

More importantly, would you rather have remote advice from a top-notch expert or from your average "I can hack CGI scripts" developer? The experience of the developer matters more, in my opinion, than their physical location, but it's hard to convince someone of that when they have no understanding of what you do. It's the same reason many developers think writing voting software is easy: they don't understand the problem space and underestimate the complexity.2

Another objection I've received was interesting: "if we allow you to be remote, we have to allow that for everyone." That's actually a compelling argument and and it's hard to dismiss. If you don't know how to manage a remote team or you've hired people who don't work well remotely, a remote worker can seem complicated and unneeded complications are invariably something that companies try to avoid.

Interestingly, some companies require everyone to be remote from time to time as an emergency response mechanism: if public transportation is on strike or there's a medical quarantine, do you really want your business to shut down? Of course not. Thus, everyone learns to work from home. Still, many companies are extremely uncomfortable with not seeing their employees typing away industriously at keyboards, regardless of productivity. Thus, they won't make exceptions, regardless of how compelling the argument.

On the flip side, one company willing to hire remote workers has reached out to me four times (including by senior management), asking me to work with them. Four times. You would think that repeatedly asking me to help in areas that I'm a well-known expert in would be compelling, but every time I've been rejected by HR because I'm not in the US. It's not that this company has any legal obstacles to hiring workers outside the US: they simply don't accept non-US located workers.3 I like what they do and would love to work with some of their people, but their HR has rules and they won't bend.

I've also had companies turn me down because I'm on contract instead of willing to be hired directly. "Contract workers are too expensive." Really? You don't have to pay unemployment or medical insurance for me (US customers). You don't have to pay my vacation time. You don't have to pay extra taxes for me (my company handles that). And for most European companies: you can let me go at the drop of a hat compared to your regular employees. Hiring permanent workers is often more expensive than hiring contractors. Thus, I can only conclude that many hiring managers simply haven't been made aware of the extra costs involved in hiring a full-time employee.

I've also had two companies reject me immediately by saying "we think you're too expensive", even though they never asked me my rates! Truth be told, I do charge more than your average freelancer. In exchange, I will deliver faster and I will deliver quality, documented, and tested code. One company refused my daily rate and offered me a fixed rate for two weeks of work. I finished in three days.

The strangest objection, though, is a comment I've heard more than once: "we're afraid our code is beneath you." Seriously! I wonder how many companies have failed to contact me because they're afraid I'm some sort of prima donna who won't touch legacy code. I've seriously considered marketing myself as specializing in legacy code because there's so much of it. I'm there to solve problems, not judge them. I'm a hired gun; I don't care if my clients are pretty.

For many freelancers, the "beneath you" objection is less likely to happen because companies are less likely to have a preconceived notion about those freelancers. The other objections, however, will remain for a long time and they're hard to overcome.

So far I've been blessed. My company has been handling training contracts, recruiting contracts and consulting contracts. Our diversity has given us a layer of financial stability that many younger companies lack. That being said, while I'm fortunate to be able to attract consulting contracts given my name, even if there are many companies who turn me down for the reasons cited above.

At the end of the day, though, companies who only hire full-time, on site employees have some advantages:

  • They can interrupt them any time they want
  • They are less worried about the employee leaving
  • It's a comfortable, well-known way of working

I won't begrudge companies who choose these benefits because it's not my place to judge. But at the end of the day, here's what I often hear when I'm doing recruiting for a company:

We need to hire someone and we can't find any locals

Will you consider training them?

We don't have the budget

Will you consider remote workers?

No, they must be on site

Would you consider importing workers from another country?

No, we refuse to sponsor foreign workers.

Would you at least be willing to relocate workers in your current country?

We don't have the budget for that

In other words, many companies struggling to fill positions are insisting upon finding a local pool of experienced candidates who can hit the ground running, even when they're in a small town of 30,000 people, far from major population centers. We typically turn down recruitment contracts like that. It's not that we want to turn them down, but we're not going to take a contract that we can't fulfill (and we've also turned down more than one contract when they were paying below market rate).

And as an aside, I'll tell you one of the single biggest problems I have: I'm too honest. When I used to sell cars, I told people the truth about the cars they were buying, not just the good points. I was a decent salesperson, but I was never going to be great because I couldn't avoid telling people the complete truth. For one extremely well-paying contract, I'm reasonably certain I lost it because I pointed out a certain issue that was a problem that they later cited when they didn't hire me. Had I kept my mouth shut, I probably would have won the contract. As it stands now, it turns out that company is having issues with ... well, the issue that I raised. So that's one problem I have no idea how to work around: get work by not being forthright but risking my reputation or losing work because I'm honest. For me there's no question as to the right path, but it's a frustration nonetheless.

So I say contact me. I want to front-load my contract work so I can provide better financial stability for my family. I want to have more reassurance between contracts that I can keep improving the open source work that your company relies on. I'll develop software faster than most developers and make it cheaper to maintain. I'll save your company money and make it easier for them to maintain their bottom line. I won't go broke if you don't contact me, but I admit that's a luxury I have.

Have Perl, will travel.

1. The "Ward Cunningham" comment sounds ridiculous to some, but it's not. For even the best developers in the world, when something is unclear, asking someone else for their advice, no matter how unskilled they are, is often the key between "good" and "great" software. They might simply point out something you missed, or it may be the case that in explaining the problem, the solution becomes clear. Both of these issues have hit me more times than I care to admit.

2. I have discussed the voting software problem with one famous programmer (whose name I guarantee most of you know) who was seriously considering violating his NDA to let people know why it threatened the foundation of democracy and I agreed with his reasoning. This problem space is hard.

3. Just to be clear: I'm a US citizen and security clearance isn't an issue in their work.They'll take Iranians with US residency. In fact, I'm as close to them, in terms of timezone, as Honolulu, another area they'll accept workers from. Their HR simply says "US residents only."


As a counter-point, if you lean too heavily on contract labor, you lose out on growing institutional knowledge. That is a long-term cost that is generally greater than short term labor rates.

The in the USA one kills me. I am a US Citizen, with a US bank account and US permanent address and I still have run into this. They should just think of me as a US remote worker permanently traveling. As for "our code is beneath you", just send them my way, no code is beneath me - the uglier, the better. No docs? Original programmer gone and probably dead? No tests? Just jump in and figure out our app from 2002 that hasn't been touched in 12 years and we want modernized, docs, and tests -- I'm the man.

One way to avoid the discussion about hourly/daily rates is to work with fix-price contracts. Of course, there is the risk of getting your estimate wrong (in either direction). But in general for the customer this is a far easier concept as they only have to decide "am I willing/able to pay that for the expected benefit".

Although admittedly some customers seem to have problems to see that and want to have a contract with hourly rates AND "maximum costs". I always wonder what is suppossed to happen when the maximum is reached (and already paid) and the result isn't yet what they expected.

Everybodys own programm starts with "use strict; use prejudices;" So "use strict" is the reason for being kicked out of the US market :-)

That said: Your arguments are true, but most of them (except may be that you are a famous guy and I'm a no name) are a problem of most freelancers.

There are more things to mention: Here some people are fanatics about buzz words. For example in my last contract I heard a lot about Perl6 - for production code. My "inability" to do that requirement reduced the amount they would pay for the job. (which was a 3 weeks price earned in 10 days - yes, my Perl foo is far worse than Ovids).

"None" had a comment on inhouse-knowledge. I would agree to that argument if the company is stable but especially in a time of crises the more able employess leave their employers faster than the level-C-workers - which of course includes their knowledge. Especially in a flexible job market like the US...

OTOH that knowledge can be a reason for larger costs. For example I was working 2013 with Perl5 V10 with a few more... well, name it how you like it: No "use english;" (No, this is real!), no Moose, OO just in hand-made form, which automatically disallows something like DBIx::Class, no packages, not even inside-out objects plus some other demands which made the program look like Perl4. In-house-style...

"HR" departments would be better described as "Firing and Recruitment Prevention", since those are the two most important things they do.

I've heard horror stories from friends about former managers who wanted to re-hire them, but couldn't, because the resume hadn't come through HR.

Given all the obvious rationalisations and bogus assumptions one encounters, it's hard to have any sympathy for companies that whine about staff shortages. One wonders how important their projects actually are, given that they seem to prefer inifinite delays to hiring a near-fit.

At the end of the day, you are still selling some of your waking hours for money. That is to say that you are earning money rather than making money.

Whilst its important to build your career, remember that ultimately all you are doing is making your waking hours more valuable for someone else to buy - usually to build an automated system which makes them money 24/7.

A career only lasts till you retire, it can't be passed on to your children, friends or family when you die and it could end while you are driving home from work.

So if its financial stability you are after, then spend some of your earned income buying things that will provide passive income. Such things can be passed on to your children, friends and family - even when you are retired they will keep putting money in your pocket and if you have a terrible accident they will not be impacted.

That is to say, rather than just building systems that make money for someone else - become an owner of such a system. Have something (an asset) working for you 24/7 to make you money.

Obviously your company could become such an asset if built in the correct way. Property (land) is always a good asset that will provide passive income. Stocks or shares in private businesses can also be good assets.

Matthew Dillon (of DragonflyBSD) is able to work on his OS as he pleases because his assets provide sufficient passive income that he has the freedom to do so.

Money is a huge taboo subject. Break the ice and talk to your friends about it :)

Money is a huge taboo subject. Break the ice and talk to your friends about it :)

I am exceedingly curious what you meant by this last line. If the answer needs to be tailored and is not fit for public discussion - drop me a line at ribasushi@cpan.org

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/