Live data from Hacker News

What’s wrong with billable hours

daedtech.com

111–120 of 137 posts

Re: What’s wrong with billable hours

#111
post #22
post #11

Billing hourly is bad, but you don't have to give up time & materials billing altogether. Just charge a day rate, or a weekly rate.

I'm genuinely curious: what is the difference between hourly and daily/weekly rates?

>> I'm genuinely curious: what is the difference between hourly and daily/weekly rates?

Clients start haggling on a hour by hour basis sometimes. Some want to review tasks and how long each took and whether the hours add up. Sometimes, it takes so long to figure out the conclusion of the haggling, that you've already lost 2 or 3 hours of non-billable time on the haggling itself.

With weekly billing, the haggling is reduced.

Re: What’s wrong with billable hours

#112

Earlier quoted context omitted.

I've never had to fix bid for work, always had hourly gigs in the wings. I hold the philosophy that sw dev is a product development, iterative exercise, not a construction metaphor that is predictable. Yeah, I expect you would be able to do the same if you billed hourly. If a client insisted I bill daily, I'd probably have no issue with it either. It's just so rare to bill daily in my circles that I've never consider…

When you bill hourly you are literally demanding that your clients account for your time on an hour-by-hour basis. So, no, it's not the same. If you're subcontracting in order to make ends meet, then you don't have any control over your project structure; you're a subcontractor. My advice is to plot a course to not subcontracting anymore as soon as you can. I doubt that the driver developer who kicked this thread off…

I've been in full control of the architecture, team makeup, feature design, most of the technology choice, and often the feature priority. I put my foot down on clients that dictate how a feature is to be built and give them the 'why' talk. I've had enough control over all the projects I've ever worked on these last fifteen years I've worked hourly.

I get your ideas about subcontracting, but I've always been treated higher than an employee and typically like a partner. The trick to this is to charge a ridiculously high rate. That instantly establishes the dynamic and relationship I want.

Re: What’s wrong with billable hours

#113

Earlier quoted context omitted.

When you bill hourly you are literally demanding that your clients account for your time on an hour-by-hour basis. So, no, it's not the same. If you're subcontracting in order to make ends meet, then you don't have any control over your project structure; you're a subcontractor. My advice is to plot a course to not subcontracting anymore as soon as you can. I doubt that the driver developer who kicked this thread off…

I've been in full control of the architecture, team makeup, feature design, most of the technology choice, and often the feature priority. I put my foot down on clients that dictate how a feature is to be built and give them the 'why' talk. I've had enough control over all the projects I've ever worked on these last fifteen years I've worked hourly. I get your ideas about subcontracting, but I've always been treated…

But you don't have a direct relationship with the actual buyers of your work, so you don't control your project structure, and the middleman business reselling your work presumably needs to be taking a cut. It's no wonder they treat you well, right?

Re: What’s wrong with billable hours

#114
post #60

Earlier quoted context omitted.

The longer the unit of time, the less pressure there is for either side to micromanage the work, or to avoid time-saving optimizations, or to invoice random conversations that could lead to new business, or to cram multiple clients into a single day when that's not what you want to be doing. I've written a lot about this on Hacker News over the years; like, a lot a lot. Here's a starting point: https://news.ycombinat…

This makes sense but I've never been taken to task for hours and many of my clients charge me out to their end clients for hours I submit. The other advantage is that hourly tracking gives me data to predict better what new features of similar complexity will cost. Certainly not an amateur capability.

You're free to do your own internal projections about the number of hours your features will take. Simply round them up to the nearest whole number of days, and present that to your customer.

Re: What’s wrong with billable hours

#115

Earlier quoted context omitted.

I've been in full control of the architecture, team makeup, feature design, most of the technology choice, and often the feature priority. I put my foot down on clients that dictate how a feature is to be built and give them the 'why' talk. I've had enough control over all the projects I've ever worked on these last fifteen years I've worked hourly. I get your ideas about subcontracting, but I've always been treated…

But you don't have a direct relationship with the actual buyers of your work, so you don't control your project structure, and the middleman business reselling your work presumably needs to be taking a cut. It's no wonder they treat you well, right?

Well for the case right now, I'm building a multi tenant system. Some tenants want features that no others want and they pay for my hours on those. I still have enough control in these cases.

I come up with better lower costing solutions when the stakeholders express WHY the feature is needed, what problem it solves. Then we and I can creatively explore HOW to solve the problem. There's usually several ways to solve anything, many that vary by orders of magnitude in terms of cost or architectural complexity.

If I am dictated always on the HOW, handed fully solutioned work to implement like a monkey I rebel and have a long talk about how this won't work. I never have had to quit over this stance but I would if it wasn't reconciled.

So when I say control, that's really what I specifically mean by that word. The ability to negotiate and explore the HOW with the why being firmly in mind.

Re: What’s wrong with billable hours

#116
Interesting read. My freelance work has never been by the hour, and for reasons that align with those mentioned in the article.

Clients don't care about hours I spend, my hours bring no value to them. They desire a certain result, and they know how much that result is worth to them.

For my freelance tasks, I've put forth a rather steep one-time price for the solution of the specific problem at hand. The condition: The price is paid when the problem is solved, if not, the service was not delivered, they don't pay.

This works out beautifully for the client, they run no risk (except the delay in waiting for me to fail so they can try someone else), and they know exactly what they pay.

It works out nice for me, since I have a reasonable idea whether I can solve the problem or not.

Hourly rates for those tasks have been close to $1000, including failed tasks where I spent some days not solving the problem.

In the end, it's also very fair to both parties.. It's reasonable to expect the agreed-upon result when paying someone to do something.

It's also unreasonable to expect to get paid for not doing what was agreed upon.

A concrete example I can talk about was a client whose database had started "acting up a lot" and they had no idea what was wrong, they were very friendly and told me they had contacted another company too who had quoted an hourly price around $200 but were unwilling to estimate how much time they would need, since they didn't know what the problem was. So I said, "I'll try and fix it, if I succeed it'll be $4000", that's a fair amount of money, sure, but it was pretty good value to them to get their inventory database back up. It turned out to be an unhandled edge-case that only showed up years after when they introduced a new kind of item into the database. I had to learn a little bit of VBA(!) to fix it, but in the end, it took about 2 hours, and you might argue that price is too much for those two hours, but they didn't pay me to spend 2 hours, they paid me to get their database working again.

Re: What’s wrong with billable hours

#117
This is nonsense. If you bill fixed, then you're doing it wrong if you estimate so lean that you put yourself at risk. And it's a disservice to the client if you are really conservative and they pay a lot more than T&M would have been. And if you are spot on with your fixed estimate, then that's the same outcome as T&M lol.

If you are an honest person and do business the right way, T&M is the way to go. If you want a higher effective hourly, then you would pad fixed. That doesn't make you professional though; it makes you dishonest if you purposely inflate.

If the company needs it to be fixed to compare apples to apples or their finance dept requires it, then submit your fixed scopes and run your business. It's professional to be flexible. And to not fight client processes and procedures.

You will not win a lot of great business if you have only 1 way to run your projects. Some larger companies will take a vendor that costs way more but offers better terms like net 45 or net 90.

I'm a professional. I run a business with employees that's grown every year. We do both, but it's better T&M. All time is logged with descriptions of what was done. We bill based on seniority.

We still do time estimates on items that are T&M so my team is accountable, thinks about their approach and time, and so the client can have an idea of what they are committing to. They don't care if it goes over, it just can't get out of control. And they need this information to triage and approve requests.

T&M with time estimates is a professional way to go. Some of your estimates will be off, some will be under. Just make sure clients understand that and traffic your wins and losses. And if you find out your 24 hr task is going to take 60 hours, notify the client as soon as you discover that to avoid surprises.

I'm experimenting with a more traditional contingency budget which is explicit in the estimate. In that manner, a fixed bid would be done but the client would be aware that there could be unknowns that result in tapping the contingency budget. And if it's not tapped - they don't pay it. So rather than try to bake the unknowns into the fixed which the client would pay regardless, I can have the contingency reserved if needed but be more palatable against a competing bid that wraps it into their fixed.

So say, 100k fixed bid, separate 20% contingency for unknowns for my bid. Versus another company's 120k fixed bid, no contingency. Both possible 120k spend. One may not use contingency and thus be 20k cheaper. The other - 120k is paid no matter what.

Anyone do that on their larger projects? How is that received?

Re: What’s wrong with billable hours

#118
Most legal firms do something in between, you pay a retainer or a minimum package, and then they bill you hourly

They get the money upfront, before they do any work

So, from the get go they know the minimum they are going to make, and they never get stiffed (also because most people don’t want to get into legal issues with a lawyer)

Re: What’s wrong with billable hours

#119

Earlier quoted context omitted.

This makes sense but I've never been taken to task for hours and many of my clients charge me out to their end clients for hours I submit. The other advantage is that hourly tracking gives me data to predict better what new features of similar complexity will cost. Certainly not an amateur capability.

You're free to do your own internal projections about the number of hours your features will take. Simply round them up to the nearest whole number of days, and present that to your customer.

Hourly estimating takes too much time and it never gives useful numbers even with various padding schemes when estimating innovative sw development. Cookie cutter web sites or repetitive work that you've done for multiple clients is easy to fix bid but I don't do that sort of work.

I just say this has a complexity of 1,3,5,8 or 'too big to say'. Each feature is a 1-15 minute conversation to get this number. Then they ask well how much time is that? I then answer "We have three months of velocity data, x points per developer per week accepted into production over the last ten weeks so those five new points for that feature will take one developer 4.1 days to complete with a variance of plus or minus 1.8 days. If you need better precision, we can take a day or two to really break down the work and get the uncertainty to at best a ten percent variance.

Re: What’s wrong with billable hours

#120

Earlier quoted context omitted.

You're free to do your own internal projections about the number of hours your features will take. Simply round them up to the nearest whole number of days, and present that to your customer.

Hourly estimating takes too much time and it never gives useful numbers even with various padding schemes when estimating innovative sw development. Cookie cutter web sites or repetitive work that you've done for multiple clients is easy to fix bid but I don't do that sort of work. I just say this has a complexity of 1,3,5,8 or 'too big to say'. Each feature is a 1-15 minute conversation to get this number. Then they…

I don't know what we're arguing about. I don't like hourly estimating either, I'm just saying daily billing doesn't keep you from doing it.
Post reply on HN