# Zerocracy: Sales Kit

Source: https://www.yegor256.com/2019/03/26/sales-kit.html

<!-- this most migrated here from zerocracy.com -->

I was talking to a few people recently, who wanted to join
our team and help us sell the [platform](https://www.zerocracy.com)
to potential customers---software companies.
They all asked me for a "sales kit" document
or a package of documents, which were supposed to answer their most
important questions and help address the pain points of those
potential customers. Anyway, instead of a fancy PDF document I decided
to write up this blog post. Here it is, feel free to use this information
when you sell [Zerocracy](https://www.zerocracy.com):


## Pain Points

Traditional software teams, no matter, whether they are co-located
or distributed, experience similar problems with the effectiveness of
their human resources, like programmers, testers, designers, etc., which are:

  * **Costs-vs-Results Misbalance**.
    Salaries are high, while the productivity of an average programmer
    is rather low. A lot of time is spent on learning, meetings, trainings,
    rework, vacations, and social activities, while code writing and
    features delivery is constantly behind schedule.

  * **High Turnover**.
    The demand for good programmers is very high on the market and that's
    why they have the luxury to choose who to work for. The best programmers
    quit, very often even without a notice, and the problems they leave behind
    are difficult or impossible to solve for newcomers. Junior programmers
    also leave, but later, after they get enough training.

  * **Low Maintainability**.
    The source code programmers create is as good as its authors. While the
    project is young and the team is motivated, the code seems to be good
    enough. However, after a few personnel rotations, it becomes very difficult
    of impossible to maintain what's left.

  * **Low Quality**.
    Any software has bugs, but most software teams don't know how to
    control quality and make sure customers don't see defects
    before we fix them. Customers complain about quality issues
    in the product and programmers complain about "spaghetti" code they have to
    deal with.

These four problems hurt the business and make it lose time and money.
An inexpensive, reliable, and predictable software development process
is the key success factor of any tech business. However, most companies
continue to suffer because they can't resolve these problems using
the solutions that exist on the market.

## Existing Solutions

In the exiting market, where the demand is twice as high as the supply
of good programmers, any tech business suffers in finding good software
developers, retaining them, motivating, and making sure they deliver
the quality the business needs. In a desperate attempt to put things
under control a business owner can do
[many things](https://www.yegor256.com/2016/12/06/how-to-pay-programmers-less.html):
above-the-market salaries, equity sharing, team building, etc.

However, none of them really help, until the key roadblock is removed.

## Pay by Result

According to our 20+ years experience of managing software projects
and working with over 400 different programmers in co-located and
distributed teams, the ultimate solution means changing the motivational
mode from pay-by-time (also known as monthly salary or
[hourly pay](https://www.yegor256.com/2015/07/21/hourly-pay-modern-slavery.html))
to pay-by-result.

Instead of paying programmers by the end of the month, no matter whether
they were working or doing nothing, and hoping that they will be very
productive and will care about the objectives of the business, we suggest
to pay them for the results they actually deliver, in
[microtasks](https://www.yegor256.com/2017/11/28/microtasking.html).

However, it is easier said than done. We've spent almost 10 years to research
and develop a management model and a set of instruments, which make it
possible to manage a team of programmers so that they get their compensation
only when they deliver what they are supposed to: a high-quality
working software code. We even created a
[chatbot](https://www.yegor256.com/2018/03/21/zerocracy-announcement.html) to let programmers
communicate with our software tools. [Zerocrat](https://www.zerocracy.com), our chatbot
is supposed to automate the majority of routine management operations, which
are inevitable when working with [microtasks](https://www.yegor256.com/2017/11/28/microtasking.html).

There is a number of benefits a business is getting when switching
to the pay-by-result management model.

## The Benefits

If the business manages to switch its software team to the pay-by-result,
a number of obvious advantages will be gained:

  * **Higher Efficiency**.
    The amount of code programmers deliver via microtasks
    is many times bigger than what they deliver in a traditionally
    managed setup. Even though their rates are higher, the ROI of
    each dollar spent is [5+ times bigger](https://www.yegor256.com/2014/04/11/cost-of-loc.html).

  * **Higher Motivation**.
    With an obvious and transparent motivational scheme good programmers
    feel more interest in contributing to the project, in delivering
    higher quality, and in staying in the team.

  * **Higher Maintainability**.
    The very idea of [microtasking](https://www.yegor256.com/2017/11/28/microtasking.html)
    is designed to handle high turnover
    and keep the quality of code at a high level, no matter how many people
    is working with it. Thanks to that, the readability of the source code is always high.

  * **Higher Quality**.
    Software defects and user-facing defects stay under tight control,
    thanks to the principles of our [Policy](https://www.zerocracy.com/how-it-works) of work. In the end,
    the quality is a few times higher than in traditional teams.

In order to start the transition a potential customer has
to fill out this online form
and one of our lead programmers will get in touch with them.
They will discuss the on-boarding procedure, the customer will
fund the project with a credit card and the journey will begin.

If there are any concerns left, [read this]({% pst 2019/mar/2019-03-29-concerns %}).

Good luck!
