3 ms·

I think that most clients in my current part of the world (Tokyo) have a set expectation of what a work day is -- normally ~8(+) hours. I have that in the agree

I think that most clients in my current part of the world (Tokyo) have a set expectation of what a work day is -- normally ~8(+) hours. I have that in the agreement to avoid this misconception if a certain client expects me to be available/reachable during all of their own working hours. Also, I do maintain flexibility in how I work the hours -- I don't say when those hours will be worked, just how many "days" are being billed per week. Sometimes I split it up over several days, and I almost always split it up into multiple chunks on a single day. This is the part I like most about the arrangement and my current lifestyle. Eventually you have to do some work, and the number of hours/day is the number I'm comfortable with working (it's less than 8). Now this completely goes out the window for project based pricing jobs -- If I am charging for project/milestone completion, then I do not mention "work days" because they're irrelevant, there's only the deadline and whatever scheduled checkups/sync meetings, doesn't matter if I completely ignore the project for a whole week. This comes back to my point before -- it seems to be the only real dichotomy is whether you charge for 1 unit of time (before/after the project deadline) or whether you charge for some derivative of hourly wages (due to the preconception of what a "workday" means in most people's heads). Assuming you understood my previous point, are you suggesting that I should just leave the definition of "work day" vague? and treat a weekly contract as a project based one? I guess this could work, but it feels more to me like project based pricing split up into milestones that happen to have weekly delivery dates -- not what everyone is saying to "charge by week". And the problem there is the same -- how do you avoid/deal with bad estimation?

allannienhuis 8y ago
> how do you deal with bad estimation? I think in part it depends on the type of client you're working with and the type of relationship you're building. Non-tech/software clients (ie a business paying for custom software they're going to use themselves) care a lot about the total cost of $features, and often try to manage risk of cost overrun by treating estimates as part of the contract with the developer (even if it wasn't a fixed bid contract), and will hold you accountable to the project milestones: eg they don't care why things are taking longer - 'you should have considered that risk in the estimate - it's your fault'. Tech customers (ie a software licensing or sass company) that use contractors to supplement their internal workforce usually understand the variability better, think of the contract more as buying the (expertise and) time of the developer, and they're managing more of the project and risk themselves. When things don't go to plan, they understand that many/most times this isn't the 'fault' of the developer, it's simply the inherent risks in the task being uncovered. It's much simpler to arrange weekly rate contracts with the second type of customer than the first.
- hardwaresofton 8y ago
  Just wanted to note that this is spot on -- I've found I've enjoyed working with customers in the tech sphere a lot more than non-tech/software clients. I end up just assuming that I just don't have the tooling/skillset just yet to handle the former set of clients well yet.
lmm 8y ago
> This comes back to my point before -- it seems to be the only real dichotomy is whether you charge for 1 unit of time (before/after the project deadline) or whether you charge for some derivative of hourly wages (due to the preconception of what a "workday" means in most people's heads). No. There is a huge difference between counting hours and counting weeks in terms of how much overhead it imposes on you, and how much opportunity it gives a client to nickel-and-dime. > Assuming you understood my previous point, are you suggesting that I should just leave the definition of "work day" vague? and treat a weekly contract as a project based one? No. I'm saying charge time-based, but by the week rather than the hour: that is, do not quibble about the difference between 39 hours and 41 hours, and do not work for clients who want to. We really do mean what we're saying. Charge by the week, not by the hour, really does mean charge by the week, not by the hour. No more and no less. It really does make a difference.
- hardwaresofton 8y ago
  > No. There is a huge difference between counting hours and counting weeks in terms of how much overhead it imposes on you, and how much opportunity it gives a client to nickel-and-dime. > No. I'm saying charge time-based, but by the week rather than the hour: that is, do not quibble about the difference between 39 hours and 41 hours, and do not work for clients who want to. Yeah but both of these things are what bad clients do, who we agree are weeded out (usually) with higher rates. Also "not quibbling" about the difference between 39 and 40 hours means that there is an expected amount of hours you're supposed to be working -- how does that get set? Is the answer to just not talk about it? Why wouldn't a good conscientious client ask how much time you're dedicating to the project per week, if they find your per-week scopes to be lower than what they think could be done in their idea of a work-week? To reiterate, I think the real kernel of advice here is "charge more to weed out bad clients", and the "charge by the week" to be a red herring. Charging more is doing the hard work here, weeding out clients that might attempt to micromanage, not changing to weekly billing. When businesses have enough headroom to not worry about whether they're maximally extracting value from you, that's when they don't care how long your work week is/what scope you set for a "week". The legal profession seems to have no problem charging by the hour, why should we?

allannienhuis 8y ago

> how do you deal with bad estimation? I think in part it depends on the type of client you're working with and the type of relationship you're building. Non-tech/software clients (ie a business paying for custom software they're going to use themselves) care a lot about the total cost of $features, and often try to manage risk of cost overrun by treating estimates as part of the contract with the developer (even if it wasn't a fixed bid contract), and will hold you accountable to the project milestones: eg they don't care why things are taking longer - 'you should have considered that risk in the estimate - it's your fault'. Tech customers (ie a software licensing or sass company) that use contractors to supplement their internal workforce usually understand the variability better, think of the contract more as buying the (expertise and) time of the developer, and they're managing more of the project and risk themselves. When things don't go to plan, they understand that many/most times this isn't the 'fault' of the developer, it's simply the inherent risks in the task being uncovered. It's much simpler to arrange weekly rate contracts with the second type of customer than the first.

hardwaresofton 8y ago
Just wanted to note that this is spot on -- I've found I've enjoyed working with customers in the tech sphere a lot more than non-tech/software clients. I end up just assuming that I just don't have the tooling/skillset just yet to handle the former set of clients well yet.

lmm 8y ago

> This comes back to my point before -- it seems to be the only real dichotomy is whether you charge for 1 unit of time (before/after the project deadline) or whether you charge for some derivative of hourly wages (due to the preconception of what a "workday" means in most people's heads). No. There is a huge difference between counting hours and counting weeks in terms of how much overhead it imposes on you, and how much opportunity it gives a client to nickel-and-dime. > Assuming you understood my previous point, are you suggesting that I should just leave the definition of "work day" vague? and treat a weekly contract as a project based one? No. I'm saying charge time-based, but by the week rather than the hour: that is, do not quibble about the difference between 39 hours and 41 hours, and do not work for clients who want to. We really do mean what we're saying. Charge by the week, not by the hour, really does mean charge by the week, not by the hour. No more and no less. It really does make a difference.

hardwaresofton 8y ago
> No. There is a huge difference between counting hours and counting weeks in terms of how much overhead it imposes on you, and how much opportunity it gives a client to nickel-and-dime. > No. I'm saying charge time-based, but by the week rather than the hour: that is, do not quibble about the difference between 39 hours and 41 hours, and do not work for clients who want to. Yeah but both of these things are what bad clients do, who we agree are weeded out (usually) with higher rates. Also "not quibbling" about the difference between 39 and 40 hours means that there is an expected amount of hours you're supposed to be working -- how does that get set? Is the answer to just not talk about it? Why wouldn't a good conscientious client ask how much time you're dedicating to the project per week, if they find your per-week scopes to be lower than what they think could be done in their idea of a work-week? To reiterate, I think the real kernel of advice here is "charge more to weed out bad clients", and the "charge by the week" to be a red herring. Charging more is doing the hard work here, weeding out clients that might attempt to micromanage, not changing to weekly billing. When businesses have enough headroom to not worry about whether they're maximally extracting value from you, that's when they don't care how long your work week is/what scope you set for a "week". The legal profession seems to have no problem charging by the hour, why should we?