# How Hourly Rate Is Calculated

Source: https://www.yegor256.com/2014/04/20/how-hourly-rate-is-calculated.html

{% badge https://www.xdsd.org/images/logo.svg M https://www.xdsd.org %}

In [XDSD](https://www.xdsd.org), everyone---including project managers,  analysts, programmers,
and product owners---receives payments based on deliverables with agreed
upon budgets. In the first section of the article,
[How XDSD Is Different]({% pst 2014/apr/2014-04-17-how-xdsd-is-different %}) I explain
exactly how this concept works. I don't explain in the article, though,
how we decide which hourly rate is acceptable for each project participant.

When new people come to us, usually they have some numbers in mind. They know
how much they expect to make per week, per month or per day. We rarely negotiate
the payment rates, but rather just accept reasonable offers
(see [How Much Do You Cost?]({% pst 2014/oct/2014-10-29-how-much-do-you-cost %})). Nonetheless, every
few months, we review payments rates and change them accordingly (increasing or
decreasing them as appropriate).

Further along in the article, is a list of factors that influence our decision
making process regarding payment rates. However, before we get to the factors
that influence our rate-setting decisions, it is important to mention that---unlike most other companies or software teams---we don't pay attention to the
following:

 * Your geographic location;
 * Skills and experience listed in your CV;
 * Amount of time already spent on our projects;
 * Age, sex, nationality, religious beliefs, etc.


The factors listed below, though, are indeed very important to us. They affect
your "overall score" significantly and play a major part in decisions to
decrease or increase a payment rate. After changing a payment rate, we don't
negotiate it with the project member.

Keep in mind that besides decreasing your hourly rate, a low overall score may
affect the number of tasks you receive from us.

The best developers receive most of the new tasks. So, continue reading, follow
our principles and learn how to earn and enjoy higher rates.

## Fast Delivery

The faster you deliver on a task, the better. We track all your completed tasks
and can calculate easily how many days it takes you, on average, to close tasks.
To increase this metric, you should try to close all tasks as soon as possible
to reduce your overall completion-time average.

If you see that a specific task is not suitable for you, don't hold on to it.
Instead, inform your
[project manager]({% pst 2016/may/2016-05-24-who-is-project-manager %})
as soon as possible that you do not want to
work on the task. After you inform the project manager, he will try find you
something else more suitable.

By the way, the best developers usually close their tasks in five calendar days
(or less) on average.

## Past Due Tasks

Though we encourage everyone to reject tasks they don't like, we are
strongly against overdue tasks. Once you have started to work on a task, we
expect you to finish it on time.

Our
[No Obligation Principle]({% pst 2014/apr/2014-04-13-no-obligations-principle %})
gives our [project managers]({% pst 2016/feb/2016-02-18-holacracy-autocracy %}) freedom
to take any task away from you if don't complete it in a
reasonable amount of time (ten days).

Removal of tasks by project managers affects your overall score negatively.
Nevertheless, even the best developers sometimes have overdue tasks, and we
understand that it happens from time to time. However, our best developers they
keep their number of overdue tasks to a minimum. A good rule of thumb for
acceptable numbers in this area is about one overdue task per twenty completed
successfully and on time.

## Complexity

Every [XDSD](https://www.xdsd.org) task has a project role assigned to it. The article,
[Puzzle Driven Development by Roles]({% pst 2014/apr/2014-04-12-puzzle-driven-development-by-roles %}),
lists the key roles we use in [XDSD](https://www.xdsd.org) projects.
Generally speaking, the higher the role, the higher the
complexity of tasks assigned to it.
Therefore, closing a task in an "architect"
role is much more important than closing one as an "implementer" (or "developer.")

The more tasks you close in your current role, the faster you will receive
promotions and receive pay-rate increases. Very often, our developers work in a
few roles at the same time.

## Lengthy Discussions

We discourage long conversations on one task. The longer the discussions about a
task, the longer it takes to complete---which lowers your quality as a
developer. Ideally, developers should receive a task, deliver the result and
inform the task author after it's done. Afterwards, the task author closes the
task and payment is made.

We track the number of messages you post and receive in your tasks
automatically. Consequently, too many messages may affect your overall score in
a negative way.

To avoid long conversations in tasks, submit new tickets with questions or bug
reports. Again, the
[Puzzle Driven Development by Roles]({% pst 2014/apr/2014-04-12-puzzle-driven-development-by-roles %})
article explains the
whole idea of helping us "to break the project" by submitting new
[bugs]({% pst 2018/apr/2018-04-24-right-way-to-report-bugs %}). Follow
this concept and you'll be fine.

## Contribution via Bugs

In [XDSD](https://www.xdsd.org) [Bugs Are Welcome]({% pst 2014/apr/2014-04-13-bugs-are-welcome %}). You
are supposed to report bugs along the normal development activities. Besides
receiving extra money for reporting bugs, you can also increase your overall
rating.

The best developers submit one bug for every 2 to 3 tasks they complete.