In XDSD, everyone—including project managers, analysts, programmers, and product owners—receives payments based on deliverables with agreed upon budgets. In the fhe first section of the article, 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?). 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 :)
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 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.
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.
Every XDSD task has a project role assigned to it. The article, Puzzle Driven Development by Roles, lists the key roles we use in XDSD 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.
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 article explains the whole idea of helping us "to break the project" by submitting new bugs. Follow this concept and you'll be fine.
Contribution via Bugs
The best developers submit one bug for every 2 to 3 tasks they complete.