3 ms·

> 40 hours of work a week The concept of hours per week is shaped by it's origin in production manufacturing. Most people who are in a position to discuss 4 d

> 40 hours of work a week The concept of hours per week is shaped by it's origin in production manufacturing. Most people who are in a position to discuss 4 day weeks are in the Service Sector or otherwise 'creative roles'. This is analogue to the argument of why do we not pay developers by lines of code. Both time and LOCs are not necessarily linear with productivity and delivery of function. Arguing for pay to be linked to time is in my view an artefact of the production & manufacturing origins of modern work. So to come back to your point. Previously both parties agreed that 40 hour week was worth this much money. Now both parties agree that this link with time is a bad metric and that pay is provided for the realization of certain function or deliverable.

robertlagrant 4y ago
It's not a bad metric. It's just not a perfect metric. And, more importantly, paying for time isn't a metric at all. It's just one of the legal ways to employ people. Paying for deliverables, which you describe, is another legal way to employ people. Here are some downsides to paying for deliverables: Any job that requires talking to other people will suffer, as they won't work at the same time. Some jobs this is okay (e.g. open source development is very asynchronous) but many are not. If you move to deliverables, what happens if you don't deliver on time? Do you not get paid? Who sets the deliverables? How are they paid, if they are the ones creating a nice deliverable structure for others to get paid for delivering bits of? How do we measure the value of each deliverable, to pay accordingly? How do we measure if you really delivered? If the company decides the deliverable is no longer valuable and stops it halfway, do you not get paid? Do you get paid based on the estimated value (at the time the work was agreed) of the bits you did do? Do you have to negotiate that? If you go on leave, should you not get paid? If you deliver twice as fast, do you get paid faster? How does "realisation of a function" work except based on time? If I'm at a service desk, should I be paid nothing if no tickets come in? Or should I be paid for... my time? What I'm driving at is you've invented something that already exists: the fixed-price contract. Scope is agreed, lawyers get involved to approve it, and finance for its budget, you do the work, the scope slips in a way that the customer believes was implied all along, you bring in lawyers to fight, and you get paid at the end, or not, and the work at the end probably suffers quality-wise because you had a fixed-price deliverable, and the faster you do it the more money you get. I don't think many people are up for that; nor are many companies going to go through that pain per-employee.

robertlagrant 4y ago

It's not a bad metric. It's just not a perfect metric. And, more importantly, paying for time isn't a metric at all. It's just one of the legal ways to employ people. Paying for deliverables, which you describe, is another legal way to employ people. Here are some downsides to paying for deliverables: Any job that requires talking to other people will suffer, as they won't work at the same time. Some jobs this is okay (e.g. open source development is very asynchronous) but many are not. If you move to deliverables, what happens if you don't deliver on time? Do you not get paid? Who sets the deliverables? How are they paid, if they are the ones creating a nice deliverable structure for others to get paid for delivering bits of? How do we measure the value of each deliverable, to pay accordingly? How do we measure if you really delivered? If the company decides the deliverable is no longer valuable and stops it halfway, do you not get paid? Do you get paid based on the estimated value (at the time the work was agreed) of the bits you did do? Do you have to negotiate that? If you go on leave, should you not get paid? If you deliver twice as fast, do you get paid faster? How does "realisation of a function" work except based on time? If I'm at a service desk, should I be paid nothing if no tickets come in? Or should I be paid for... my time? What I'm driving at is you've invented something that already exists: the fixed-price contract. Scope is agreed, lawyers get involved to approve it, and finance for its budget, you do the work, the scope slips in a way that the customer believes was implied all along, you bring in lawyers to fight, and you get paid at the end, or not, and the work at the end probably suffers quality-wise because you had a fixed-price deliverable, and the faster you do it the more money you get. I don't think many people are up for that; nor are many companies going to go through that pain per-employee.