zerocracyI just got an email from one of our customers this morning. They are complaining that the project is not moving forward as fast as they would expect. Here is what they are literally saying: “Despite the fact that about 20 developers have been invited to the project, work is going very slowly and, worse, unpredictable. On average, the developer closes 3 tasks per week. It seems that all of the DEVs have a main job, and in Zerocracy they work on a residual basis. There are cases when a task (which should take 30 minutes for the developer) is not solved within 10-15 days. Moreover, we cannot do anything about it, because according to the policy, developer has 10 days to complete the task. Also, we do not have tools for additional motivation of developers. The reputation system doesn’t seem to work, because reputation does not affect anything and punishments are very small.” It’s a fair complaint, let’s see what we can do about it.
First of all, we have to understand that the very idea of Zerocracy is freelancing and microtasking, which mean no obligations from all contributors. Simply put, they work when they feel up to it. Our job, if we want them to contribute more actively, is to give them enough motivation for that, and to punish them strongly enough, if they don’t. So, it’s our fault if a project doesn’t move forward as fast and as predictable as expected. By “our” I mean us together: Zerocracy and the customer. So, what can we do to fix things?
There are basically five instruments in your hands:
First, it’s the amount of developers in the project. The more of them you have, the faster the project moves forward. Twenty is not a big number at all when we are speaking about freelancers working in a microtasking mode. Having one developer closing three tasks per week is a normal situation. That’s how most of them will work. To close more tasks per week we just need more people. I’ve had a project with about 50 developers, a few years ago, and it was developing a rather small Java application. Fifty! For someone who used to work in a co-located team of full-timers this number may sound too huge, but for a team of freelancers it’s still a pretty small team. You definitely need more than twenty! Ask your architect to be more active in the area of team building and recruit more developers, promote the project more actively on the board and in our Telegram chat, etc.
Second, it’s the rates you pay. It’s simple: the higher the rates, the more motivated are the programmers. Even if (and it’s almost always the case) they work somewhere else as full-timers and dedicate just an hour per day to your project, a good financial motivation will make them contribute more actively. Remember, that the only main thing that motivate freelancers is money. The more you pay, the faster they deliver and the more interested they are. Just play with the numbers and you will see some results.
Third, you can use our “boost” feature at some tasks, which are more important. I’ve seen it working quite well. Just 2x or 3x the task microbudget when the task is important and you will see how its developer becomes more engaged. Don’t overplay this feature, though. Make sure you boost only those tasks that really are important. The architect can also use this feature, just make sure you all agree about the intensity of boosting.
Fourth, it’s the 10-days window per task. It is pretty large for a project that wants to move forward really fast. You need to make it shorter, in order to eject slow developers from their tasks. This is the punishment part. Ask your architect to modify that parameter in our project configuration and things will improve. You may lose some programmers, who are not ready to work faster than they used to, but that’s the price you will pay for the speed of development you want to get.
Fifth, don’t hesitate to eject slow producers. In the world of freelancing and microtasking, there is no place for sentiments. Don’t worry about their feelings. They have no obligations for you, you also don’t have any for them. You want them to produce and do it fast! If they don’t, or you don’t like the quality of work, or you have any doubts, just reject the person you don’t like. There is a pool of others waiting to join your project. Reward those who stay and contribute (by increasing their rates) and discharge those who are too slow. The same applies to the architect. If you don’t like how effective that person is, replace him/her.
Hope this helps.
If I missed something, don’t hesitate to comment below.
PS. You may also like this video that explains how to make sure your programmers are focused on what matters most of all.
