4 ms·

This is what I've been trying to tell people for awhile. In "knowledge work" areas I suspect most people work around 5-6 hours a day and the rest is spent doing

by selykg 5y ago

This is what I've been trying to tell people for awhile. In "knowledge work" areas I suspect most people work around 5-6 hours a day and the rest is spent doing whatever other stuff they do. My current job I only work 35 hours a week and it's great. They pay us for an hour lunch basically and I just take it at the end of my day, thus shortening my day to 7 hours.

Miner49er 5y ago
One study found it's only about 3 hours for the average office worker: https://www.vouchercloud.com/resources/office-worker-productivity https://www.vouchercloud.com/resources/office-worker-product...
- BitwiseFool 5y ago
  Sounds about right. At my employer, DevOps expects that we fill in our time sheets completely in order to represent the whole eight hour workday. So we do. Things like taking breaks, talking to coworkers, waiting around for answers from other teams, meetings, etc., all of that goes towards active project work. However, the projects are estimated using effort hours and they do not include inflated 'we need to look productive the whole day' tasks. If an individual goes under the full eight hours, it reflects poorly on them during evaluations. If the division goes overtime on project hours, nothing bad happens. So naturally each developer is incentivized to jot down extra time and disincentivized from tracking time truthfully. And yet management wonders why we go overtime on so many buckets! And everyone knows the numbers aren't real, yet the song and dance must go on. I really wish we had a term for this in English. I suppose 'Potemkin' sort of applies?
jimbob45 5y ago
Maybe for menial knowledge work. During crunch time, nights and weekends get completely filled with work.
- handrous 5y ago
  Did you intend to use the word menial? I'd say it applies much better to tech workers who are subject to "crunch time" with any kind of regularity, or who lack the ability to say "no" to weekend or evening work, than to the rest.
- selykg 5y ago
  Crunch time is something I would absolutely switch jobs to avoid. It would be fine if it were emergency only situations and they happened once or twice a year for a couple nights. But if it's such a regular thing that it has a name "crunch time" I'd be out. I work to live my life, not live my life to work.
derefr 5y ago
It feels like there’s no sensible reason that employers/contractors should be allowed to establish contracts where “knowledge work” is being compensated for time worked (i.e. to set an hourly wage, and an expected number of working hours.) No matter who thinks they benefits by such a contract, it seems to almost always turn out for the worse for both parties. It seems like instead, almost all “knowledge work” is really fundamentally salaried work, where the employer/client should be paying for output, perhaps with contractual milestone deadlines that determine a boundary that the employee/contractor schedule their work to happen within — but with no contractual constraints on how or when the work happen within each milestone/sprint should happen, as long as the milestone deadline is satisfied. This is already the universal expectation for “knowledge work” where the knowledge-worker is generally respected for their talent and is seen as hard to replace — e.g. in the working contracts between fiction authors and their publishers. Nobody gets paid a wage to write books. (We even distinguish this particular type of knowledge-worker, calling them a “creative”, as if that meant anything more than “a knowledge-worker, but, y’know, a respectable one.”)
- mason55 5y ago
  The problem is that this model loses most of the benefits of the Firm (economies of scale of labor). Let's say you have some money and want to make something happen. You find a developer and an infrastructure person. Now you have to negotiate a price with each of them for some defined output (and unless you're technical you probably need to first negotiate with the dev to get her to produce an infrastructure plan, then find the infra person and negotiate with him, and then negotiate with the dev to get the work done). Ok, you've spent a bunch of time negotiating individually and defining exact output specs that withstand contractual scrutiny. Then you get partway through development and learn something new about your market. You decide that you need to change your product a bit, so now pause development and negotiate a change order with your dev. You come to an agreement but the change requires infra changes. So you go negotiate with the infra person but you can't come to an agreement on the changes required. Now you're paying the infra person to finish something you don't want any more, the dev can't do the additional work she's willing to do because the infra won't be there, and you're stuck building something that you don't even need. This doesn't even take into account that this model forces every single person to be both a negotiator and marketer of their own skills, in addition to whatever technical skills they have (comparative advantage shows that they should each just do what they do best). The obvious next step is for groups of people with complimentary skills to get together and negotiate projects together and from there it's a very clear path to ending up with salaried workers again. The advantages of the Firm are just so great that even with a ton of waste it's still better than everyone individually negotiating their output. Look at the consulting companies for an example, even though they negotiate at the project level they still pay people salary. They know exactly how much bench time each person has and they still use that model over hiring for each project based on the project's output.

by selykg 5y ago

Miner49er 5y ago

One study found it's only about 3 hours for the average office worker: https://www.vouchercloud.com/resources/office-worker-productivity https://www.vouchercloud.com/resources/office-worker-product...

BitwiseFool 5y ago
Sounds about right. At my employer, DevOps expects that we fill in our time sheets completely in order to represent the whole eight hour workday. So we do. Things like taking breaks, talking to coworkers, waiting around for answers from other teams, meetings, etc., all of that goes towards active project work. However, the projects are estimated using effort hours and they do not include inflated 'we need to look productive the whole day' tasks. If an individual goes under the full eight hours, it reflects poorly on them during evaluations. If the division goes overtime on project hours, nothing bad happens. So naturally each developer is incentivized to jot down extra time and disincentivized from tracking time truthfully. And yet management wonders why we go overtime on so many buckets! And everyone knows the numbers aren't real, yet the song and dance must go on. I really wish we had a term for this in English. I suppose 'Potemkin' sort of applies?

jimbob45 5y ago

Maybe for menial knowledge work. During crunch time, nights and weekends get completely filled with work.

handrous 5y ago
Did you intend to use the word menial? I'd say it applies much better to tech workers who are subject to "crunch time" with any kind of regularity, or who lack the ability to say "no" to weekend or evening work, than to the rest.
selykg 5y ago
Crunch time is something I would absolutely switch jobs to avoid. It would be fine if it were emergency only situations and they happened once or twice a year for a couple nights. But if it's such a regular thing that it has a name "crunch time" I'd be out. I work to live my life, not live my life to work.

derefr 5y ago

It feels like there’s no sensible reason that employers/contractors should be allowed to establish contracts where “knowledge work” is being compensated for time worked (i.e. to set an hourly wage, and an expected number of working hours.) No matter who thinks they benefits by such a contract, it seems to almost always turn out for the worse for both parties. It seems like instead, almost all “knowledge work” is really fundamentally salaried work, where the employer/client should be paying for output, perhaps with contractual milestone deadlines that determine a boundary that the employee/contractor schedule their work to happen within — but with no contractual constraints on how or when the work happen within each milestone/sprint should happen, as long as the milestone deadline is satisfied. This is already the universal expectation for “knowledge work” where the knowledge-worker is generally respected for their talent and is seen as hard to replace — e.g. in the working contracts between fiction authors and their publishers. Nobody gets paid a wage to write books. (We even distinguish this particular type of knowledge-worker, calling them a “creative”, as if that meant anything more than “a knowledge-worker, but, y’know, a respectable one.”)

mason55 5y ago
The problem is that this model loses most of the benefits of the Firm (economies of scale of labor). Let's say you have some money and want to make something happen. You find a developer and an infrastructure person. Now you have to negotiate a price with each of them for some defined output (and unless you're technical you probably need to first negotiate with the dev to get her to produce an infrastructure plan, then find the infra person and negotiate with him, and then negotiate with the dev to get the work done). Ok, you've spent a bunch of time negotiating individually and defining exact output specs that withstand contractual scrutiny. Then you get partway through development and learn something new about your market. You decide that you need to change your product a bit, so now pause development and negotiate a change order with your dev. You come to an agreement but the change requires infra changes. So you go negotiate with the infra person but you can't come to an agreement on the changes required. Now you're paying the infra person to finish something you don't want any more, the dev can't do the additional work she's willing to do because the infra won't be there, and you're stuck building something that you don't even need. This doesn't even take into account that this model forces every single person to be both a negotiator and marketer of their own skills, in addition to whatever technical skills they have (comparative advantage shows that they should each just do what they do best). The obvious next step is for groups of people with complimentary skills to get together and negotiate projects together and from there it's a very clear path to ending up with salaried workers again. The advantages of the Firm are just so great that even with a ton of waste it's still better than everyone individually negotiating their output. Look at the consulting companies for an example, even though they negotiate at the project level they still pay people salary. They know exactly how much bench time each person has and they still use that model over hiring for each project based on the project's output.