[tedjdziuba]

> It's typically difficult, if not impossible, to scale up and down your engineering team in the way you can spawn up new cloud servers. We're trying to change that by having a reliable source of contract engineers who can help us grow non-essential components of our codebase.

Sounds like an awful place to work. Treating your most valuable asset as a commodity? Let me know how that works out for you.

[amirmc]

> ... non-essential components of our codebase ... to build lower priority features that our core team doesn't have time to get to." [emphasis added]

Sounds like they've already got their most valuable assets, the employees, where they need them the most (presumably on core product). Using contractors to fill the lower priority gaps doesn't seem so bad in that context.

However, I could see it becoming an issue if something that was previously considered non-core suddenly turned out to be critical (e.g after changing direction based on customer/market feedback)

[quanticle]

I disagree. How many features are there that are 1) not high priority enough for a full time employee and 2) high priority enough to justify bringing aboard another person, train them in the code base, have them code the feature and let them go after coding is complete?

I think Jessica Mah is misunderstanding the purpose of contractors to her and her business' detriment. Hiring contractors because the team isn't able to accomplish its tasks in a timely fashion is disastrous in the long run. What happens is that the contractors will write code in the most expedient fashion possible, without care for the long term harm to the code base. The team then sees an inexorable decline in its ability to iterate, which causes the business side to think that even more contractors are required. This self-reinforcing cycle inevitably leads to a codebase that's almost impossible to change or improve in any way; it leads to a place where moving a logo is a three week project (don't laugh, I've been there).

There is another way of approaching contracting that is more valuable for both the team and the contractor. Instead of thinking of the contractor as a hired gun whose sole responsibility is to finish a feature or fix a defect, the founder should think of the contractor as a teacher or a coach. Hire contractors when your team needs to learn a new skill or improve some aspect of their development cycle. Approaching contracting with this mindset ensures that each successive contractor hired improves, rather than degrades the team's skills. Otherwise, your team becomes trapped in a maze to which they don't know the exit, and you wonder why every new version seems to have fewer improvements and worse performance than the last.

EDIT: After further reflection, there is another way that contracting can improve the business in a sustainable fashion. I know of a few companies that practice "contract-to-hire". In other words, you're brought on as a contractor for a period of 6 months or so. During that 6 month period, you and the company have a chance to evaluate each other. At the end of that period, the company makes an offer to you if you've managed to prove yourself as a good fit for the company.

[myprasanna]

Agree with Ted. I've heard so many horror stories from people who thought this way in the beginning. Yishan Wong, would give you good stories about, how zuck tried the contracting route when Accel funded them and very soon pressed the hard revert button.

Jessica - I'm a YC founder too, and most people have strong opinions on this. (http://bit.ly/9uDFfe); Maybe, you should ask pg, what he thinks.

[btucker]

Not to mention the issue that in many US states the enforcement of misclassification laws are on the rise and the penalties are stiff. So unless you can make a good case why a contractor should not be an employee--the main allowed reason being they're performing a task outside of your business's competency--don't outsource to a contractor based in your own state.

[lsc]

Yeah, this has worried me, too. I'd be interested in the best way to hire "contractor like" positions on a W2... e.g. I pay you as an employee but we're both clear on the expectation that you are not permanent.

I mean, I am small enough to dodge the 'wrongful termination' bullet, but I still have to pay unemployment insurance, and really, I think it's just fair to be up front and clear with people about where they stand. I mean, that part can be done verbally, but it would be good to hear what the 'correct' way to do it would be.

[trevelyan]

Her approach seems to be saving money by outsourcing less critical stuff and spending the savings on team-building trips and a more experimental culture driven by a smaller and more competent core team. That really isn't a bad idea at all.

[mchusma]

I think that if you hit a situation where you want to create something, but lackthe expertise or time in house, it is perfectly reasonable to outsource. Sometimes "good enough" is the best way to go for a startup. I think you should have the expectation that at some point you will have to completely redo it (although that is a risk with any development). The cost of repeated work is often worth the value of iteration and speed.

[johnrob]

Is the assumption that any company that wants to increase head count rapidly will treat their employees poorly?

[suking]

Agreed - but this is what happens when a 20 yr old is the CEO. Could MSFT have been started by contractors? I don't think so. Also, quickbooks online is 10X better, get those contractors working!

[paulbaumgart]

Bill Gates was 19 when he and Paul Allen incorporated Microsoft.

[lurker19]

How old was he when he hired a contractor labor force or a large number of employees?

[suking]

He's 1 in a billion.

[suking]

Lol, all her friends must be downvoting me. Truth is hard to swallow sometimes.