Live data from Hacker News

What’s wrong with billable hours

daedtech.com

101–110 of 137 posts

Re: What’s wrong with billable hours

#101
post #83

Earlier quoted context omitted.

Don't set that expectation. Don't work with clients that expect you to track hours when you bill days. The threshold for productivity and exclusivity I've had has been "if I billed you for a day, I'm not going to bill work for anybody else in that day"; that's as far as I go. In 15 years of doing this kind of work ('05-'20) I never had a problem --- but we did bail on RFPs where clients made it clear they'd be lookin…

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 is subcontracting.

Re: What’s wrong with billable hours

#102
Heh, it seems like this article could easy be called "hourly billing considered harmful" and I would basically have the same critiques of it as most " consider harmful" posts.

I won't pretend I have years of experience in the freelancing world... I am fairly new to it myself. But I do know as engineer who also has done some stints in product, sales, and business side, that, just like in software, there is no one "right way" and that one of the most consistent challenges business face is choosing the best of many reasonable options, especially when one of those choices is viewed as a "best practice" but the team lacks the direct experience to answer the question of "best practice for who and when?"

I fully agree with the author that there are some real market forces that can make hourly work not the ideal for many situations... but I also think it massively over simplifies the different types of work that are done as "freelancing".

Whole new products, new features in existing products, taking over projects, rescuing projects, consulting with less experienced teams, embedding in teams, integrations of external tools, is probably only 25% of the type of engagements a single consultant may come across and probably only 1% of the type of engagements that exist. Combine that with the huge range of attitudes of companies and very quickly we are in a space where no single solution exists.

It seems like the author's true point is in the conclusion, that you should focus on driving value and results for your customer and you should structure work to align with that, which is absolutely true. The general take of "hey engineer guy who isn't as business savvy, that value might not be best delivered via hourly billing!" is not bad advice. If you do hourly billing because it is the most straight forward, you should probably think about it... but you also shouldn't move to project based billing because of some people calling it a best practice either.

My advice to any engineer looking to freelance (but really to almost anyone everywhere in this industry) is to not take the easy way out when facing decisions outside your domain. I think so often work seen outside of code is seen as "lesser value", and because of that, shortcuts are made by just taking the easiest or "best practice" answer to a problem and running with it, and not gaining any understanding of the problem space. No one can be an expert in everything, but when you can't make this decision someone else's job, like when a business doesn't have some expertise (which in freelance is always the case) then you can't afford to not put in the time to learn enough to at least be informed. If you then do decide to do the easiest / best-practice thing, at least you know why you choose that option and can later evaluate how it is working for you.

In summary, there is no simple answer, be thoughtful and keep trying new things. What works for one gig may not work for another.

Re: What’s wrong with billable hours

#103

Earlier quoted context omitted.

> This year I'm on track to bill out between $360k and $400k > To anyone reading this [post] and thinking they are offering you helpful advice, consider their motive Honestly I'd be happy to sign up to your newsletter and be upsold into a private $20/mo high-end consulting community forum if I were to learn how to earn those kind of numbers and I was disappointed you didn't.

I started "programming" in 1982 on a VIC-20, I taught myself C++ in 1991 and programmed as a hobby until I switched majors in University. Then I moved from Job to Job once I stopped learning/progressing. Along the way I made many contacts at a diverse group of companies. I started at a medical device company reverse engineering MRI/CAT scan data for a 3D device used in brain surgery. Then I worked for a company that…

You've had some really interesting engagements, and it makes sense to see where you are specializing at those rates.

I'm about 10yrs behind you, taught myself everything. I've been consulting for 15 years but I just don't understand how one would find these clients. I'm not sure if I'm the issue, or where I live (South Africa), or the niche I've ended up in (financial markets regulations) - hence the desire for the newsletter!

Re: What’s wrong with billable hours

#104
post #79

Earlier quoted context omitted.

"The biggest issue with hourly billing is that neither of us knows how much the contract is worth until afterwards." You still don't with daily billing.

I know with daily billing because they can only book me for a set of days in advance. It's not ongoing. We agree ahead of time on the specific days I will be there/available.

I would guess we do different types of work. Most of my engagements are at least a year long. I've been billing at my current company for four years this December.

Re: What’s wrong with billable hours

#105
post #6

Well, I found this article insightful, even if I've no plans of going freelancer (though of course... "life, uh, finds a way", so who knows). I think my most immediate objection is one that is raised in the comments from TFA: customers don't know what they want. For a flat rate to apply, you have to work to an initial set of requirements set in stone, and we know these requirements are almost always wrong (except for…

> customers don't know what they want. It's not always like this. I've used contractors to take on extra work that we were familiar with, but didn't have time for. We knew exactly what we want because we'd done it multiple times before and had already written a clear spec. The eye-opening thing was that this actually scared a lot of fixed-bid contractors away. As soon as they realized that we knew the task and had th…

Yeah fixed bid for most sw projects just seems dishonest and not a satisfying way to work with people. And yes, I could easily make a business out of overcharging for cookie cutter type work. Speaking in generalities, there's always exceptions.

Re: What’s wrong with billable hours

#106
post #91

Earlier quoted context omitted.

Then you finally do all the research and they reject your quote. The most valuable part of my job is typically the engineering or architecting not writing the code. Depending on the client we do T&M or quotes but we never do free research. Well do a short proposal to quote you a big proposal

>Well do a short proposal to quote you a big proposal Did that for a pretty large client project once. Basically brainstormed/did some research to pick out some technology areas they might be interested in and why. Then did a bigger project to dive deeper into areas, conduct interviews, etc. that resonated with them.

It works well. And if they don't want to use us as the programmers, no problem, we deliver a document at the end of the first with recommend designs etc they can tak else where. T

Re: What’s wrong with billable hours

#107
When you bill by the hour, what you’re really saying is “I have no idea if what I’m doing will have any value, and I honestly don’t care — all that matters is that I am not exposed to risk for even a single minute of my time working for you. I get paid for every minute.”

Yes, that's the point. As a software freelancer you have no responsibility to take on risk for a client company that you have no ownership in. You'd be a fool to do otherwise.

Every hourly billable contract I've signed has included a detailed scope. Contracts that very clearly delineate responsibilities and compensation. Both parties are agreeing to the value the freelancer is providing. You'd be a fool to hire a freelancer without understanding the value they provide. And as a freelancer you'd be a fool to sign a contract without clearly defined responsibilities.

The author seems to believe the method of compensation determines the value provided. But these things are orthogonal. I've worked with multi-million dollar agencies that bill by the hour. They provided a lot of value, they knew precisely the outcomes they were responsible for, and delivered those outcomes.

Blog posts like this come along every so often, usually when a freelancer discovers that there are circumstances where they can make more money on a fixed cost contract. For instance "This project will take me 40 hours. If I charge $100/hr I'll gross $4000 total. Or I could quote a fixed cost of $5000 total, and net an additional $1000".

The downside is estimating software is hard, mostly because the end product is almost always a moving target. Generally speaking, clients have a good idea of what they want. But "what they want" almost always changes as a project progresses.

The upside for the freelancer is that if the scope can be nailed down, and a client is predictable, a fixed cost model allows the freelancer to capture any additional value/profit from their productivity.

Which is why savvy businesses are fine with paying hourly rates. They want to fully capture the value of the freelancer's productivity.

In my experience, from a freelance point of view, it tends to be a wash. There are many fixed cost projects where you will come out ahead. But there are always projects with tons of scope creep, and cost increases are almost always more difficult to negotiate on fixed cost contracts. But YMMV, and there's no single correct answer.

Re: What’s wrong with billable hours

#108

It's incredibly important to have a clearly defined scope prior to entertaining fixed pricing. If expectations are not established with the client, they will make assumptions and they won't be in your favor.

Also have pre-established policy for revisions. Like 2 minor revisions included in the cost but then have further revisions priced by how complex they are.

Then your interacting with your client in a rigid contractual way instead of a collaborative creative nature. Not nearly as fun and you spend a lot of time being very careful with your written words and your sign offs.

Re: What’s wrong with billable hours

#109
post #37

Earlier quoted context omitted.

Which is why you have clear boxes on that fixed-rate, and stepping over those bounds means you're back into T&M billable. The legalese on these contracts needs to be quite tight, but it's a one-time expense to set that up, and it's best done properly (and updated as new edge cases show up).

Yeah I'm honestly amazed at how many software people don't get that the optimal strategy is cheap fixed price and incredibly high margin change requests. That being said you need a good spec to do this, and that definitely isn't normally the case in software.

There is so much work out there that is cut & dried. It's not what you'd call software engineering stuff - more the bread & butter of consultants. But you really need to know the domain space to ensure you have those cutoffs (some of which might sound very limiting). About 3-4 times after you've deployed a specific solution for a specific vertical, you should be able to productize it (on 2nd and 3rd times through you're essentially spending extra effort to determine and test those boundaries for future implementations).

Often the goal of a cheap fixed price is to show how limiting that is so they know why you can't productize a fully customized solution.

Re: What’s wrong with billable hours

#110
post #60
post #56

Earlier quoted context omitted.

Yes, I understand that. What I mean is, how does it address the problems highlighted in the article? It seems to me there's no fundamental difference for the context of this article ; it's still flat rate vs unit-of-time based work, isn't it?

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.

Post reply on HN