Becoming a highly-paid Software Developer Pt 2: Top devs are compensated beyond their working hours.
In the previous part of this series, I emphasized that businesses don’t just pay software developers for coding, but for the solutions they provide. However, many Tanzanian developers believe that coding is their primary responsibility, leading to pricing errors when negotiating their pay. While the time taken to complete a project is an important factor in determining compensation, other factors are even more critical.
In today’s world, where there are many tools available to speed up work processes, and in the competitive business landscape where companies need to adapt quickly, telling a client that a project will take a year to complete does not necessarily mean a higher pay rate. It may give the impression that the developer is not competitive enough to deliver the work in the shortest possible time frame. This can give clients more reasons to pay less.
When negotiating compensation, most developers will position the time it takes to build the solution as the main factor influencing how much they deserve to be paid. They may even copy someone else’s hourly rate without considering the variables used to come up with the rate.
Software developer’s compensation should be based on many variables beyond just time and copied hourly rates. While the variables may differ, there are important variables that are common and carry most of the weight.
Many developers use the “time x expenses x margin” formula to calculate their rate, varying the weight of each variable depending on what makes more sense to them and the nature of their clients.
The weight ratio of the variables could be 40:30:30, 33.3:33.3,33.3, 30:30:40 or any other way.
While the formula works well for many, it has one flaw. It doesn’t factor in the client’s perceived value of the solution to be built or the potential market value of the solution. This is one of the key variables that differentiates the best developers from the average ones.
In most cases, the client is willing to pay from 10–25% (depending on the size of the business and the sensitivity of the sector/problem/solution space) of either the amount they are losing by not having the solution the developer should be building or the percentage of the perceived value of the potential solution to be developed or the market value of similar solutions.
For example, it may take 200 hours to build solution A, a million-dollar solution for which a client is willing to pay a percentage of the perceived value. In contrast, it may take 1000 hours to build solution B, an average solution that has little to no potential compared to solution A. Therefore, putting time as the main factor influencing how much a developer should be compensated can hinder them from being paid more to build solution A in less time. Many developers will find themselves spending a lot of time building Solution B with low perceived value and end up being paid less to work more, which leaves them frustrated and unsure why they are paid less.
The percentage of perceived value can be paid direct as part of one time fee or in form of a percentage share of future revenue brought by the product/solution or percentage of amount saved as a result of using the product/solution for a specified period of time.
The best developers factor in the perceived value of their work when negotiating their pay. This guides them in making decisions on what job to accept and vice versa.
In conclusion, it is important to know the value of the work you are going to do or that you are doing and factor it in negotiating what you should be paid because capitalism rewards smart workers more than hard workers. And those who can do both get extraordinary rewards.
“Work hard, and you will earn good rewards.
Work smart, and you will earn great rewards.
Work hard and work smart, and you will earn extraordinary rewards.”
― Matshona Dhliwayo
Watch out for the next part…
