This article was written by Simon Stewart (@simonstewart) - a freelance developer and organiser of JSinSA (JavaScript in SA conference)
"What's your hourly rate?" This is one of the hells you have to deal with as a freelancer. All of the time you've spent over the years amassing a mountain of knowledge eventually boils down to a few numbers followed by a "/hr".
It is tempting to think about hourly rates by starting with an end salary in mind: take your ideal monthly salary, divide it by 160 hours (5 days x 8 hours x 4 weeks) and voila - there's your hourly rate. Such a calculation is too simplistic.
My aim with this article is to help contract developers by discussing
- the elements that impact your hourly rate,
- unobvious things to keep in mind when you take on a project,
- what I’ve learned from my engagements with clients and
- things you can do to build your public profile as a developer.
Disclaimer: I got 40% for Accounting Grade 9, so your mileage may vary :-) This should also not be seen as any form of tax or legal advice.
Elements that impact your hourly rate
Billable hours
First things first: To calculate your hourly rate, you need to have a nuanced understanding of how many billable hours you actually have.
Understanding how you spend your time
About a year ago, I started timesheeting everything I do - presales, marketing, attending conferences, preparing talks for user groups and, of course, actual consulting work.
Before this, the only metric I had were "billable hours". So, inadvertently, I was punishing myself for doing all the secondary work like marketing. By not tracking time spent outside of paid work for official clients, I ended up with a frustrating amount of blank spots in my billing without any information to explain it.
By tracking my time in detail, I now have a more realistic idea of my billable hours, how much self-learning I do, how many conferences I attend and how much time I spend on presales every month.
Being realistic about the number of workdays in a year
As a contractor, you need to be realistic about the number of workdays you actually have in a month and year.
In a full time job, it’s easy to think that your cost-to-company (CTC) salary is based on the assumption that you are at work for 8 hours every workday of the month. That assumption results in a simple but faulty formula for your hourly rate: CTC salary / work days per month / 8 hours = hourly rate.
I made this mistake when I started working for myself, but there is a major issue with this formula: You definitely don’t work 8 hours per day all year long.
Here are a couple of things that affect that perfect daily average:
- The variable number of work days per month (eg in SA, April 2017 only has 17 workdays. 2017 has an average of 20.67 workdays per month),
- sick, personal and annual leave and
- billable hours lost due to presales.
Leave is a big item to factor in. I use 1 day per month (Jan-Nov) plus 10 days over December. That means that 2017 only has 16.42 workdays per month, leaving a mere 131.36 billable hours with which to hit your monthly salary target. That's almost 30 hours per month less than the 160 you get with the simplistic calculation!
Expenses
The next thing to keep track of are expenses. They add up quickly, so keep an eye on what you're paying and make that a part of the internal equation when thinking about your hourly rate.
Not all expenses are monthly expenses, so I track mine in three different categories:
Monthly expenses include things like Github, Pingdom, Pluralsight, AWS, Audible or whatever other services you subscribe to. A quick hack to keep track of them is to only use your credit card to pay for these, and then to review what you spent your money on at the end of a month. This is just one of the reasons why having a separate bank account for your business is a good idea.
Yearly costs may include things like audit fees or an Apple dev subscription. Be sure to add the costs for a conference or two (including flights and accommodation) every year - if that's your thing.
Costs that span over multiple years are things like the new Macbook that you would need every three years, or expensive developer tools. This can be annualised so that you account for it per year.
A template for calculating your hourly rate
To bring all this together, I use a spreadsheet to keep track of the variables that impact my hourly rate. It contains three sheets: summary, monthly expenses and annual expenses.
The summary sheet contains several bits of data:
- A breakdown of work days per month for 2017,
- the number of workdays per month that get deducted from the realistic target (leave, presales),
- a cell (E:21) that you can modify to enter in your target salary, and the final hourly rate that is calculated (E:22),
- I also include a "safety net / month" and a "business profit / month" - both expressed as a percentage of salary. Feel free to zero these out if they aren't relevant. If you want to factor in a December bonus, then include this here.
The monthly expenses sheet contains a list of all monthly expenses.
The yearly expenses sheet contains all yearly expenses, and also a “lifespan” column that indicates over how many years that expense is annualised.
Unobvious things that impact projects
Here is cautionary note: Contracting work is not only about the rate and the hours you have available. There are a lot of other unobvious factors you should keep in mind when taking on a project.
Distance to the client:
Travel time kills. It's unlikely that the client will pay for your travel time as they probably aren't paying other consultants or employees to show up either. At minimum, you should be keeping a log of your commute for your own internal reporting.
Chances of the client shipping something soon:
I've worked on projects where it's taken a client's team six months to finish up a component that was needed for deployment. Having to wait six months to be able to add this to my "achievement log" (covered later) for that client was not fun. It can also cause complications with getting timesheets approved if the entire project isn't delivered, regardless of the reasons.
How remote-ready a client is:
Working "remotely" is in vogue lately, but many clients aren't on that wavelength yet. It can severely jeopardise your chances of succeeding with a project if you struggle to do the work remotely.
Bureaucracy and efficiency of finance departments:
Some clients pay quick, others not so much. If the income from a slow paying client is time-sensitive, it quickly becomes a major problem. Advice I've taken from a friend in the UK is to offer clients pricing options based on how they pay. If the invoice turnaround is >60 days, then you quote rate X. If they pay <30 days, then you quote a lesser rate. A client that pays on a reliable time schedule is gold!
A common mistake is to state your rate as a range and not as options. Saying that your rate is between R200 and R400 will confuse the client and they'll just hear "R200" anyway.
The trick is to have a set pricing strategy based on all the factors that are important to you, and put it into a format that allows you to simply copy and paste it to your client base.
Tips about engaging with clients
I’ve learned quite a few things about engaging with clients - be it about negotiating rates or the time that was spent on a project. Here’s what to look out for:
Negotiating your rate
Everyone strives to be professional in the way they conduct themselves, but there is a mistake people often make right up front, when negotiating a rate: making things personal. The number of kids you have, your personal budget or the length of your resumé have nothing to do with your client or the outward appearance of your business. Don't bring emotion into the pricing discussion. Your public profile should substantiate your rate (more on how to build a public profile below).
Keeping timesheets
Even if you're working fulltime for a client, having a weekly timesheet with "8-8-8-8-8" as your billed hours for the week isn't helpful. You really should be breaking down your work into smaller chunks - ideally with a reference to Jira tickets or specifics about what you were doing. This will keep your timesheet detailed enough should there ever be a query. Remember: The client is paying for your time.
The good news: There's really no need to reinvent the wheel here. Use tools like Freshbooks or Harvest - preferably something with decent reporting and a mobile app.
Your default should be to have full transparency with your client about what you're actually billing them for. An easy way to do this is to include your detailed timesheet with every invoice.
Here’s a sample timesheet:
Depending on what your timesheet system exports, you can probably leave out the “Client Name”, but the “Project Name” is really important. Although you may mostly work on one project per client, it’s really important to track your hours separately if you are on multiple projects, as they may have separate budgets for each.
Knowing how much time you’ve spent on each project also makes it easy to invoice separately for these. This limits problems if projects are delayed or payments are locked down due to any contractual issues.
Keeping an achievement log
Another way to keep track of your work is by way of an achievement log. This is not a git log or a timesheet export. The idea of an achievement log is to present the work you do in a different way, allowing you to communicate the value you’re adding to the client’s organisation. An example might look like this:
- increased performance of process X by 20%
- reduced hardware requirement by R20 000 per month
- speeded up deployment times from 1 human hour per build to 0 human hours per day
The examples above are hard facts, but keeping track of more abstract achievements might also be useful. For example:
- shared knowledge with the team
- smoothed out dev flow process
- improved quality of code to enable easier handoff to junior staff
- documented server config to enable business continuity should there be a hardware crash (no, not everyone has Docker'd all the things)
The best time to start collecting this data is when you start with a project. The second best time is now. Don't try and do it just before a self-review with your client.
A list of wins like this only has value if you’re sharing it with your client. I prefer sending this out once a month to keep the client up to date with some of the value we’ve brought to their projects. Use something consistent in your email subjects like “Project Wins” to help you find these later, when it’s time to sit down and discuss possible rate hikes.
Rate increases
If you're not increasing your rate every year, you're gradually losing money. You should be confident enough to have this discussion with a client. Keeping a log of your achievements in the way I suggested above will give you a good base for grounding that confidence.
There's also a hidden benefit in doing an annual increase with each client: it allows you to subtly test if they are still getting enough value from the engagement.
Anything <10% can safely be viewed as an inflation-based increase and shouldn’t be too unreasonable. Be wary of increasing > 10% year-on-year, though. This could indicate to the customer that you’ve changed your mind about the engagement.
In my experience, consultants push “unreasonable” rate changes for 4 reasons:
- The annual rates weren't periodically applied, leaving this client's rate far below others,
- the consultant’s skill levels have increased,
- the consultant is bored and ramps up the rate in an attempt to make the work more palatable, or organically push the client to another company, or
- the cost-of-living has changed.
None of these should be the client's concern. If you're charging by the hour, then you're selling an hour of your time to the client. What the client asks you to do during that hour shouldn't affect the rate you're charging. (Motivation, sure, but not rate.)
It’s useful to keep track of all the rates you’ve used or quoted over the years. I’ve got a text file with data going back to 2008. This allows you to view rates you’ve used for clients in the past and what rates certain clients have accepted or rejected.
Building your public profile as a developer
Essentially, your public profile as a developer is the best base for negotiating your hourly rate. Here are several ideas to create a valuable public profile:
Speaking at conferences or user groups
The quickest hack to being regarded as an “expert” is by speaking on the topic at a conference. It’s also the fastest hack to force yourself to learn a topic.
The two biggest excuses I hear from people are “I don’t like public speaking” and “I don’t know enough to give a talk”. These are not convincing reasons. Here’s why:
First of all, very few people (if any) are born with an innate desire to speak in front of dozens or hundreds of people. It’s also typically not something they teach you at school and that’s a pity because the ability to stand up and give a talk is such a vital skill in business. If you haven’t had time to hone this skill, it could damage your chances of success - so learn it.
Secondly, you don’t need to be an expert when you sign up to do a talk. I’d love to run a survey to compare a speaker’s knowledge of a topic two months before a talk to their knowledge of that topic on the morning of the talk. So what do you need? An interest in the topic? Sure. A great understanding of the general domain? Sure. But as much knowledge as the day of the talk, I doubt it.
If you’ve got the budget and appetite for international travel, take a look at PaperCall for conferences with an open “call for speakers”. SA also has many local conferences that are always looking for speakers, so start following them on Twitter (@devconfza, @scaleconf, @agileafricaconf, @phpsouthafrica, @javaafrica, @rubyfuza, @jsinsa) and keep an eye out for their call for speakers.
Networking at conferences or user groups
There are so many options to choose from in South Africa that it’s always disappointing when I hear programmers say they’ve never attended any special interest groups in their chosen field.
Even if you attend these passively, you’ll learn a huge amount just by listening to what people are talking about and how questions are being asked.
Website
Obvious as it may sound, services like LinkedIn or About.me are very useful as a single place where all your work-related info can sit.
Pet projects
I’m a big fan of pet projects and have given a few talks on the subject, but I don’t think most people give it enough attention.
A pet project serves a different purpose than a Github repo. It’s easy to dump some code on the internet and claim you’re now an “open source” developer. But what does it really mean? In my view, it shows you can create a Github profile, add a public repo and do a commit.
More often than not, it doesn’t show that you can ship something useful or create something within time and budget constraints or that it’s even usable in a practical setting.
What’s a pet project from a programmer’s perspective? It’s something you’ve created that demonstrates your interest in technology and your ability to ship something. It’s not you pitching an idea for a startup you’ve had for 10 years, but never done anything about. That won’t separate you from the pack - we’ve all got those!
Pet projects should make for a quick and easy demo that you can share with someone while standing in line at a conference: “I’ve made X, check it out …” By touching on interesting tech, you’ve potentially sparked an interest from someone involved in a similar space - like AR, geospatial, big data.
The perfect pet project allows you to use technology you may not be in a position to use day-to-day and put something into production. That last part is so important and is one of the reasons I’m not a fan of seeing a public Github account as proof of all that much.
Check out this related article on How to Be a Successful Freelance Programmer & Developer.