[kator]

Good question. I have an associate of mine who is building a fairly large web based system with oDesk developers. He told me the other day he spent $100k "figuring it out" and has burned through some 100+ people. He now has a core of about 12 that contribute and a small core of about 4 people who are daily parts of his team.

His insight is that you want a process to bring people in and shoot them quickly if they don't work out. It's sort of sink-or-swim but with a rubber ducky that has a leak in it. If they figure out the system from documentation and start contributing good stuff the core team will start working more with them. If they're slow to respond, don't submit stuff that looks useful they just whack them and move on.

He has some pretty amazing people on his team, that said he's dealing with the typical timezone and remote worker synchronization problem that all these teams have. Recent conversations have turned towards building a core team that is "in an office together" somewhere to get core work moving quickly and smoothly with stuff at the edges being worked on oDesk team members.

I personally haven't done any oDesk projects yet but I imagine "Hire carefully fire quickly" is going to be the best advice I can give.

[mattmanser]

To be frank, if he spent $100k figuring it out and still hasn't got it right, I hope you are ignoring everything he said.

That he's wasted so much money and now suddenly thinks everyone should be in the same office is a sign he's probably a terrible project manager. Probably.

[kator]

No he has a great working product that would have cost him 10x to build but certainly much of the $100k was used learning how to get the right team assembled and work with them to get them productive.

He is looking to get a really small core team in a small face-to-face space to accelerate their work. It's about speeding up iteration cycles and anyone who has worked on distributed teams know the challenges of not being in the same room with each other. That said I've had success with distributed teams but I've yet to see one loop through cycles as quickly as one that is in the same physical space on a regular basis. I'm not saying it can't be done, just in my time and experiences I've not seen a distributed team out pace a team that is in physical locality to each other on a regular basis.

[MicroBerto]

It's basically this.

1. Post smallish fixed price jobs and say more is at stake if they do well.

2. Hire several people for the jobs, if there are good candidates.

3. Stick to your typical screening methods. For me, I like checking out their stackoverflow and github.

4. Communicate well, ask for their honest feedback, and don't tolerate BS. If their work in a small fixed price job is good but not great, it will likely only get worse.

5. It's better to have a go-to team of specialists for many things. Ie Don't have a general PHP hacker help design your database. Foundational and architectural stuff is worth paying more for a specialist.

End of day... Small fixed price jobs limit your losses and failures in a major way.

Once you like someone, get a contract going. Rinse and repeat if you're growing and profiting.

[sergiotapia]

> Post smallish fixed price jobs and say more is at stake if they do well.

This is a giant red flag for me as a freelancer. It immediately puts me off as a sign of this guy is being defensive for some reason.

"I know we're paying you lower than your usual rate, but if you do this right, there's another project down the line."

No thank you.

[liquidcool]

Why are they paying below your normal rate? It is a fixed price contract, you are taking on all the risk, so if anything the rate should be higher. I've hired on Elance this way (i.e., audition project) and based on the hours worked, I paid 4X their posted rate. Happy to do it, because I found someone who worked very fast!

Don't forget that the client might not know what the budget should be, and on most sites, you can simply bid above their max and explain in the proposal why their budget was too low. Likely you will stand out if you brought up something they forgot to include or didn't consider.

Question: what if they said there will be an audition project at your specified rate? Not fixed bid, but you would be expected to provide an estimate. That is how I am doing it for my next project and would love to hear feedback.

[josephlord]

I don't think MicroBerto was saying pay a low rate just small fixed price blocks of work. If I was doing it I would probably slightly overpay to keep quality interested but not so high the appropriate rate for the main projects is offensively lower.

[GVIrish]

I think what Microberto is suggesting is to post a smaller unit of work and evaluate the results before committing to a freelancer for the long term. So maybe you put out a 15-30 hour job for $500-1000 to see if that person will work out. If it works out well, move on to the longer engagement. If it goes poorly then you're only out of $1000 and a week of time.

[sergiotapia]

I know that's what he's saying - that's what I find kind of off putting.

[MicroBerto]

FALSE.

Besides, ODesk uses a BIDDING system. They tell you the average bid price. Bid whatever rate you want.

If you are above the average bid rate (which sounds likely) and can sell the client on why they should pay you more, then put it in your cover letter. It's the exact thing that happened with my last devs.

You've seen the bad code out there. We have to be defensive if we want to keep our money around long enough to see the project to fruition. But I never said to underpay. I said to not commit to bigger things until you know what you're getting.

[MicroBerto]

And at what point in my post did I ever say to underpay the developer? I didn't.

Don't put words in my post/mouth. This is garbage.

[JamesSwift]

Absolutely agree. This is one of the instant alarm-bell triggers for me when reading a posting.