3 ms·
I argue a similar thing often -- we're all fundamentally driven by incentives, and hourly billing creates a direct financial incentive to work more slowly (and
by nlh 11y ago
I argue a similar thing often -- we're all fundamentally driven by incentives, and hourly billing creates a direct financial incentive to work more slowly (and a financial disincentive to work more quickly), no matter how honest/honorable we want to convince ourselves we are. Even if it's the teensiest, tiniest, most subtle ping, there's a little ping in the back of your head that will always say "if this takes me 2 hours, I earn $200. If it takes me 1 hours, I only earn $100."
I know per-project billing is fraught with its own issues, but I'm much more a fan of that vs. time-based billing. It may work out to cost the client more, but it removes that layer of distrust ("is my engineer taking longer to squeeze more money out of me?") and sets the incentive on the worker to get the job done as quickly as possible, since now taking longer becomes the disincentive.
I believe the only folks who should bill hourly are the ones who do jobs where performance of work duties is directly correlated to hours spent working -- i.e. where doing a job "faster" doesn't change the time required. Security guards, retail workers, etc.
I'm sure there are a ton of fallacies in the above arguments, so let's hear 'em...
- rm_-rf_slash 11y agoHaving done both, I can say that I prefer the per-project method for the reasons above, but the problem there is when workload exceeds cost and time estimates, and it's either ask the client for more or grind through a project you feel is undervaluing you. Not a solution, just two cents.
- mcavaliere 11y agoI think this is a very reasonable argument for per-project billing, for the reasons you mentioned. But the downside you mentioned is valid also - that some clients will be greedy with your time. I prefer time based billing, because I don't work 8 hour days like normal people. For this reason I also make sure I'm working on things that can be done in those timeslots, and I'm very, very conscious of the client's time. I think either method is fine as long as you're comfortable with it, and you're on the same page as the client.
- kohanz 11y agoI often hear the touting of project-based billing, but the reason I'm afraid to make the jump is that in my field (developing prototypes, often novel, for scientific applications), the requirements are just not well-defined enough to give an accurate estimate. If I went project-based, just to cover the risks involved, I might have to charge 2x or 3x what it might actually take me. This may work if your clients are big corporations for whom 10k is the same as 20k is the same as 30k, but not when you're working with startups, boot-strappers, etc. I know the next thing people will say is find better clients, but some people just have expertise in areas where the clients tend to be smaller and more cash-strapped. Thankfully the work is interesting. Right now I give estimates, but still provide hourly billing as a safety net. Once I'm confident that my estimates are consistently accurate, I might move to project based billing, but it also feels a bit sleazy because what I would do at that point is just take ESTIMATE x SOME MULTIPLIER. In other words, project-based billing sometimes sounds like a hand-wavy way to charge the customer more without them being able to tell.
- tptacek 11y agoI don't think project-based billing is necessarily the right way to go. Most of the projects I've done have been time & materials.
- eschutte2 11y agoI can't agree with this. I've never experienced the ping you're talking about, and I've billed many thousands of hours on an hourly basis. There's always far more demand on my time than I can fill.