# Zerocracy: Most Typical Concerns Source: https://www.yegor256.com/2019/03/29/concerns.html 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. {:.question} Who will do a very expensive and time-consuming work of breaking larger tasks to [microtasks](https://www.yegor256.com/2017/11/28/microtasking.html)? {:.answer} We don't have a dedicated role for that. Programmers decompose larger tasks into smaller pieces by themselves, using our own [patent-pending](http://www.google.com/patents/US20120023476) methodology, known as [Puzzle Driven Development](https://www.yegor256.com/2010/03/04/pdd.html), explained in [M28](https://www.youtube.com/watch?v=LmSaC_OjIbQ). {:.question} 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? {:.answer} Indeed, the [architect](https://www.yegor256.com/2014/10/12/who-is-software-architect.html) is a [technical dictator](https://www.yegor256.com/2016/07/21/convince-me.html) in Zerocracy. However, his/her decisions are [always](https://www.yegor256.com/2019/01/15/what-if-architect-is-wrong.html) documented and the documentation passes [regular reviews](https://www.yegor256.com/2014/12/18/independent-technical-reviews.html), as [M2](https://www.youtube.com/watch?v=PYq05UAwzNk) explains. {:.question} It seems that in order to hire [Zerocrat](https://www.yegor256.com/2018/03/21/zerocracy-announcement.html) to manage my projects I have to change my programmers, because my current team is used to work in a traditional [pay-by-hour](https://www.yegor256.com/2015/07/21/hourly-pay-modern-slavery.html) model. Is it true? {:.answer} 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](https://www.yegor256.com/2017/11/28/microtasking.html). And Zerocracy won't work, unless you pay everybody by result only, as [M3](https://www.youtube.com/watch?v=CZ_Bhg4vW58) explains. However, you may save some of your best developers, if you transition slowly, as [M62](https://www.youtube.com/watch?v=0mOn9MvuMzU) and [M35](https://www.youtube.com/watch?v=dAgRUtR3LQg) suggest. {:.question} How Zerocrat knows who has to work with a particular microtask? It seems that this decision can only be made a human, not AI. {:.answer} Zerocrat has its own [multi-factor mechanism of election](https://www.zerocracy.com/how-it-works), 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](https://www.zerocracy.com/how-to-earn). On top of that, since each project and each GitHub repository we manage is [mono-tech](https://www.yegor256.com/2018/09/05/monolithic-repositories.html) as suggested in [M6](https://www.youtube.com/watch?v=zljJpADEf_E), it is safely to distribute tasks among programmers even randomly. {:.question} It seems that [freelancers](https://www.youtube.com/watch?v=1OFgf8XYI2A) in your [microtasking](https://www.yegor256.com/2017/11/28/microtasking.html) 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? {:.answer} Indeed, freelancers care [only](https://www.yegor256.com/2014/04/13/no-obligations-principle.html) about their individual results within the borders of their personal [microtasks](https://www.yegor256.com/2017/11/28/microtasking.html). Indeed, they may [refuse](https://www.zerocracy.com/how-it-works) any task or even [leave](https://www.zerocracy.com/how-it-works) your project any moment, because they lose interest or for any other reason. However, we believe that this very [freedom](https://www.youtube.com/watch?v=6CPOHvyyY2I) 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. {:.question} 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. {:.answer} First, as [M15](https://www.youtube.com/watch?v=IqnbG826Oyc) 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](https://www.youtube.com/watch?v=GozQCUH2D0I). {:.question} How can you predict the amount of microtasks when the project just starts? Who and how estimates the project duration and budget? {:.answer} Even though we [don't quote](https://www.yegor256.com/2015/06/02/how-to-estimate-software-cost.html) projects and usually don't estimate them upfront, as explained in [M60](https://www.youtube.com/watch?v=j5uXrY2gttA), microtasking enables better accuracy and higher precision of estimates, as [M27](https://www.youtube.com/watch?v=1rmZN3r5SWg) 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. {:.question} 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. {:.answer} It is the responsibility of each programmer to make sure those microtasks are correctly described and their scope is clear. [M37](https://www.youtube.com/watch?v=z59jkRAeBDg) explains how programmers deal with uncertainty. {:.question} 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? {:.answer} 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](https://www.youtube.com/watch?v=w3HwEtFU2wo) explains what to do in order to keep the team under control and focused. {:.question} 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. {:.answer} 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](https://www.youtube.com/watch?v=1pHUx-ISrS8) for more details. {:.question} Why Google, Facebook, and other giants don't work with freelancers, [don't allow](https://scottberkun.com/2014/famous-programmer-leaves-google-because-of-remote-work-ban/) programmers to work remotely, and don't use microtasking? Instead, they [build campuses](https://techcrunch.com/2018/12/17/google-new-york-campus/) to keep people together. Do you think they are stupid? {:.answer} Yes, I do. Watch [M68](https://www.youtube.com/watch?v=XQQoaBZEs38).