[dextorious]

You want to keep the expertise on your product IN-THE-COMPANY, not outside.

You want to be able to build a company engineering culture, to be able to adapt.

You want people which have a stake in the actual outcome of the company.

You don't want your programmers only be a contract away from working for your competitor.

Also: you don't want all the contracting engineering, communicating and legal overhead.

[mgkimsal]

Replied earlier but it was eaten...

----------------- You want to keep the expertise on your product IN-THE-COMPANY, not outside. ----------------- Much of the 'expertise' I run in to is another word for undocumented knowledge. When someone leaves - employee or contractor - stuff leaves with them.

----------------- You want to be able to build a company engineering culture, to be able to adapt. ----------------- Having written documented processes will help all people be able to get up to speed much faster - employees and contractors - and 'adapt' more easily to changing needs.

----------------- You want people which have a stake in the actual outcome of the company. ----------------- Give me some written profit-sharing agreements, open books, and the ability to veto bone-headed decisions by people above me and/or in other departments. Outside of that, what "stake" do you really have in your company?

----------------- You don't want your programmers only be a contract away from working for your competitor. ----------------- Non-competes. Not valid in all areas, but possibly more enforceable against contractors or small shops than employees. IANAL, of course, but full-time employees are also just a phone-call away from working for your competitors too.

----------------- Also: you don't want all the contracting engineering, communicating and legal overhead. ----------------- Yeah the 'overhead' of communication with people is too much. Better to just have FTEs and leave them in the dark. ???

Lastly, none of what I'd initially written was posited as an "either/or". Digg's problem was they made too many hires, then were overstaffed when the nature of their problems changed. Strategic hires and contract relationships would have been much smarter, and this is something I say certainly in hindsight with Digg, but had they asked in 2007, I'd have said the same thing.

[dextorious]

"""Replied earlier but it was eaten..."""

I think it was better off eaten.

"""--- You want to keep the expertise on your product IN-THE-COMPANY, not outside. --- Much of the 'expertise' I run in to is another word for undocumented knowledge. When someone leaves - employee or contractor - stuff leaves with them."""

Then you're not doing a good job managing the company's engineering dept. Is this supposed to be an excuse for moving the experience even FURTHER away?

"""--- You want to be able to build a company engineering culture, to be able to adapt. --- Having written documented processes will help all people be able to get up to speed much faster - employees and contractors - and 'adapt' more easily to changing needs."""

You can have both written documented processes AND employees that know them by experience, instead of just some "documents" left by some contractor that some new contractor needs to decipher.

"""--- You want people which have a stake in the actual outcome of the company. --- Give me some written profit-sharing agreements, open books, and the ability to veto bone-headed decisions by people above me and/or in other departments. Outside of that, what "stake" do you really have in your company?

Early engineers in a startup like Digg was have a lot of stake in their companies. Ever heard of stock options?

"""--- You don't want your programmers only be a contract away from working for your competitor. --- Non-competes. Not valid in all areas, but possibly more enforceable against contractors or small shops than employees. IANAL, of course, but full-time employees are also just a phone-call away from working for your competitors too."""

There is much more friction involved if have some stake in the company, and also if they feel the "belong" in its culture. Heck, people even choose to work for companies offering less money that what competitors offer because they like their culture.

"""--- Also: you don't want all the contracting engineering, communicating and legal overhead. --- Yeah the 'overhead' of communication with people is too much. Better to just have FTEs and leave them in the dark. ???"""

No, the overhead of communicating with contractors is too much, the overhead of communicating with people in your company is much less. (And I can't even begin to think where you got that bizarro impression from what I wrote).

[slindstr]

I agree with all of your points, but I'm wondering about the case where it's a solo technical founder that has to do EVERYTHING - marketing, development, customer relations, billing, etc. In that case do you think it makes sense to outsource non-core functionality just so he/she can accelerate development in order to get a more complete product out there (beyond MVP)?

[garethsprice]

With a tech startup, code is core functionality.

Building an MVP and iterating requires building to a (changing) vision. Contractors have an incentive to stick rigidly to a narrow, fixed specification. If you can build that spec and task it out then you may get good results, but just telling a contract developer your vision and sending them off to build it has a strong chance of ending in (expensive) tears.

I am a contract developer. I work with clients to elicit their requirements and have seen this first-hand - the projects that turn out best are the ones where I'm working with someone in-house who has development knowledge, even if it's just to manage and review.

[viscanti]

There's different stages of a company. In the beginning, when flexibility is more important, contractors might make sense. Even then, I think you're better off finding flexible developers to work with long-term, but if a contractor is the best you can do at that stage, it's probably not a deal breaker.

MVP+ stage requires a lot of iterative development. Ideally, you'd want to keep the people who are helping with that, because they'd know WHY things are done the way they are. They'll be aware of the failed experiments and previous iterations. You don't want future employees making the same mistakes. The goal of the MVP+ stage is to learn as much as possible about your market and product. Letting that product learning walk out because they were contractors is probably a mistake.