Zerocracy: Most Typical Concerns

I decided to publish this blog post in order to summarize the most popular concerns potential clients of Zerocracy express, when they start thinking about moving from a traditional management to microtasking. The blog post will be get new content regularly, and will be used as a reference tutorial for our sales front.

Who will do a very expensive and time-consuming work of breaking larger tasks to microtasks?

We don’t have a dedicated role for that. Programmers decompose larger tasks into smaller pieces by themselves, using our own patent-pending methodology, known as Puzzle Driven Development, explained in M28.

It seems that your management model relies on the architect a lot. What happens if he/she makes serious mistakes? Will the project have fatal consequences?

Indeed, the architect is a technical dictator in Zerocracy. However, his/her decisions are always documented and the documentation passes regular reviews, as M2 explains.

It seems that in order to hire Zerocrat to manage my projects I have to change my programmers, because my current team is used to work in a traditional pay-by-hour model. Is it true?

Yes, most likely the majority of your programmers won’t be able to adopt and you will have to let them go, if you quickly jump into the pay-by-result and microtasking. And Zerocracy won’t work, unless you pay everybody by result only, as M3 explains. However, you may save some of your best developers, if you transition slowly, as M62 and M35 suggest.

How Zerocrat knows who has to work with a particular microtask? It seems that this decision can only be made a human, not AI.

Zerocrat has its own multi-factor mechanism of election, which decides which programmers are most suitable for a particular task. The decision is based on their previous performance and current workload both in the project and in the entire pool of projects. On top of that, since each project and each GitHub repository we manage is mono-tech as suggested in M6, it is safely to distribute tasks among programmers even randomly.

It seems that freelancers in your microtasking mode are only interested in short-term gains through micro-payments, but don’t care about the future of the project and have no commitment to stay with it for longer than a few days. Isn’t it a risk?

Indeed, freelancers care only about their individual results within the borders of their personal microtasks. Indeed, they may refuse any task or even leave your project any moment, because they lose interest or for any other reason. However, we believe that this very freedom makes your project only stronger, because right from the start you are prepared for a high turnover and the management system knows how to handle this.

It seems that your approach may work well for a small project, where risks are low and people may come and go without any serious damage to the project. However, larger projects need more stable teams and better commitment from participants.

First, as M15 explains, large projects must be broken down to smaller sub-projects, to be manageable. Second, neither full-time hiring nor outsourcing can guarantee as high manageability as microtasking can do in Zerocracy, see M22.

How can you predict the amount of microtasks when the project just starts? Who and how estimates the project duration and budget?

Even though we don’t quote projects and usually don’t estimate them upfront, as explained in M60, microtasking enables better accuracy and higher precision of estimates, as M27 explains. Starting from the beginning of the project, every week we ask one of project participants to re-estimate the scope of work. Then, we put together the collected estimates and our statistics in order to predict the future of the project, in terms of time and cost.

It seems that microtasking may only work when the scope of work is very well defined and programmers know exactly what to do. In our projects it’s usually not the case. We simply can’t determine our scope to the level of microtasks.

It is the responsibility of each programmer to make sure those microtasks are correctly described and their scope is clear. M37 explains how programmers deal with uncertainty.

It seems that freelancers may easily lose focus of work and do things, which are not important for the current stage of the project. How do you make sure they are focused enough?

It is the responsibility of an architect and the client to make sure the team is focused on specific areas of the product scope. M59 explains what to do in order to keep the team under control and focused.

It seems that microtasking only works for junior programmers, who have no problem of dealing with primitive pieces of work. Senior programmers will not like that and won’t stay in the project.

This is absolutely not true. According to our experience, only senior developers are capable of working with microtasks, since they are mature enough to manage their own time, deal with scope uncertainty, resolve dependency conflicts, etc.; watch M21 for more details.

Why Google, Facebook, and other giants don’t work with freelancers, don’t allow programmers to work remotely, and don’t use microtasking? Instead, they build campuses to keep people together. Do you think they are stupid?

Yes, I do. Watch M68.