4 ms·

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 "fig

by kator 12y ago

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 12y ago
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 12y ago
  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.
  - Chronic28 12y ago
    Avoid developers from India.
MicroBerto 12y ago
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 12y ago
  > 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.
  - josephlord 12y ago
    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 12y ago
    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.
    - 12y ago

by kator 12y ago

mattmanser 12y ago

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 12y ago
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.
- Chronic28 12y ago
  Avoid developers from India.

MicroBerto 12y ago

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 12y ago
> 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.
- josephlord 12y ago
  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 12y ago
  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.
  - 12y ago