Less is more- My experiences of 'billable hours' at a consulting startup

Less is more- My experiences of 'billable hours' at a consulting startup

Thursday December 18, 2014,

6 min Read

less_is_more
image credit: Shutterstock

Billable hours per week is a term familiar to every consultant in the technology world. Simply put it is the number of hours of work; you get paid for in any week. Often freelance developers track their hours with time tracking tools like Harvest. Invoices are raised on a weekly or bi-weekly basis with detailed time reports. There is usually an agreement with the client on the number of hours the consultant is expected to work. Now let us see why is this ‘Billable hours’ interesting and what are some of the things we can do with it:

  1. Maximize billable hours - Spend as time as you can (your mileage may vary)
  2. Fixed billable hours - Apply moderation and work only a fixed number of hours irrespective of any other factors.
  3. Minimize billable hours - Actively try to spend as little time as possible on billable work. (Sounds silly?)

Maximize billable hours

This is how I started as a freelancer trying to bootstrap my product startup. It seemed like the most logical thing to do to make more money. Eight billable hours a day as the norm (40 hour week) is quite a lot if you accurately measure ‘actual work[1] with a timer . Even if you did this for four days a week you will be burnt out by Friday. 40 hours a week is possible only on rare occasions. Though this approach usually has very good short term returns, it generally affects productivity and efficiency in the long run, and at most times is not even in the best interest of your current piece of work.

Fixed billable hours

A year ago, I switched to consulting full time and joined MavenHive. All of us had done our fair share freelancing and consulting projects. We arrived at the conclusion that 32 billable hours a week is the maximum we can commit to our clients.

Having a cap allows for predictability and to an extent ensures that we are at our optimal best while working on projects.

Minimize hours

As we grew, company activities like sales, marketing, recruitment started eating into billable time and we were usually around the 27 hours per week mark. This seemed like it could create two problems:

  1. Clients may perceive lesser hours as slow progress.
  2. Possibility of not meeting our financial targets (paycheck).

However, surprisingly our clients did not complain since delivery was as per schedule. Working fewer hours made it easier for them to stop, reflect and change course.

Overall we were burning through the budget slower. This has very interesting and useful side effect of forcing us to constantly find better tool to reduce our effort.

The money inflow did take a hit, initially. But then our rates improved faster than we anticipated, which softened the hit. Clearly our clients were happy inspite of our utilization[2] being low. Dialing down on the billable work gave us space to attend to long terms concerns like growth and direction without compromising on personal lives.[3]

Being a happy bunch has always been the most important thing to us.

Pushing the limit

Things did not stop here. Another thing happened which further pushed our number of billable hours even further down, and this time it was less intentional. A few months back we were not in a good shape in terms of our sales pipeline. We had to spend more time pursuing sales leads.

At this point we started further reducing our billable time to extent that one of us was completely non billable.and this time it was not intentional.In other words, we did not have enough work. Of course, things turned around in a few months and we are now with a healthy pipeline of work and fresh clients.

This experience taught us some things which we may have never learnt otherwise.

I was working part time on one project and almost on retainer with another maintenance project. I hardly did 20 billable hours per week. Productivity wise it was probably my best time, since I was trying to actively chop of any work that did not add business value.

The clients once again did not ask why I was spending less than the committed number of hours. To them what mattered was the features delivered and the business value added on a week on week basis. Also the burn rate of the budget was much lower than predicted even with revised billing rates.

This has reinforced our belief in the idea that efficiency and productivity are more important that actual effort.These days we actively try to push back on features in an attempt to look at way to reduce the amount of effort involved. At the end it is just a question of being very clear about your ‘buy vs build’ choices and being good at effectively communicating this to the client.

The difficulty with these changes is that it is much harder to explain our high billing rates to clients who are not aware this approach of working. Luckily most of our clients have been referrals and have heard of first hand account of our success with delivery.

We still do not know what road block we might hit, other than the above one. But making it a habit to treat time as well defined limited resource and not reducing the quality of output while still hitting out deadlines has been very exciting. Maybe someday we could potentially reach ‘The Seven Day Weekend[4] state. Hopefully at that point we would have parallely developed our capability to be most optimal at delivery in terms of time/money spent.

The interesting thing at that point would be to understand what was the cause and which was the effect.

[1] Work distractions not counted - http://xkcd.com/862/

[2] Utilization is not the same as billable hours. - http://en.wikipedia.org/wiki/Utilization_rate

[3] Another blog by my colleague @pavanks about Startups being equated to burnout

[4] By the author Ricardo Semler of the popular book ‘Maverick

About the author:

Hari Krishnan is a Developer with over 9 years of experience in domains like banking, network security, telecommunications and retail. He has worked across multiple tech stacks on several complex projects. He is currently a Senior Associate with MavenHive where he is working on Consulting/Delivery projects.

(image credit: Shutterstock)