4 ms·

Mine is when human beings working at the company start becoming referred to as “resources” instead of people.

necovek 4y ago
I am starting a new forum ResourceNews where resources can gather around and discuss anything that irks them in their workplace.
hk__2 4y ago
You can do both: "resources" and "people" are two different point of views of the same thing. I’m in a 5-person company and we refer to people as "resources" when we’re allocating times to each project. We refer to people as "people" outside of that.
- necovek 4y ago
  You can certainly do both, but you shouldn't. People are not resources: each one of them will do different work and different amount of work. They are never interchangeable, and they don't even behave the same over time. A frustrated or bored "resource" will do lesser work, but as long as you refer to them as a resource, you'll miss on that nuance. It's not that hard to consider them people, possibly even people by names in such a small company as yours.
  - thebadsleep 4y ago
  - dusted 4y ago
    > People are not resources: each one of them will do different work and different amount of work. Different people have different resources, when you allocate a resource, you're allocating something someone can do, not something they can't do.. When you put resources on a project, the people follow along, since they're the ones with the resource in demand. I've never understood the resource as referring to a person, but rather, to the work that is expected that the person can do. If you need a C++ resource, you pick a person that can do C++, they may also be able to do PHP and SQL, but in this case, that's not what you're selecting for.
    - necovek 4y ago
      Even then, your "C++ resource" will perform completely differently based on the person they are: eg. a junior C++ engineer will be slower than a mid/senior engineer, and an engineer providing a more maintainable solution might be slower too (and somebody un/familiar with the problem domain or API in use). I don't see how planning work for a "C++ resource" helps other than faking it over and over again.
      - hk__2 4y ago
        In my specific case we all have roughly the same experience with each technology so it’s fine to consider people as interchangeable. Of course that doesn’t mean we don’t take preferences into account; it’s just to have a rough idea of our roadmap and know if we need to recruit.
        dusted 4y ago
        I agree. Also, if people are so uniquely skilled that each and every task can only be made by a specific person (excuse me, "human being") then your bus-factor is 1 and a single person leaving, getting sick (or indeed, hit by a bus) means death for the project.. That's terrible. It's entirely reasonable to think of work and people using separate terms, I'd argue it's probably healthy too.. Now, that's not the same as ignoring personal preferences where they apply, for instance, when allocating resources to a task or project, of course, consideration should be taken when possible, "oh, person X hates doing this, but Y loves it, sure, X is slightly stronger at it, but we let Y do it, then they're happier and Y gets stronger too" I consider myself as being around a 1.3x javascript resource for backend, a 0.8x for frontend, and around a 0.5x resource for C++ (meaning I'll spend twice the amount of time doing the same task as someone I consider a 1x C++ resource).
        necovek 4y ago
        > uniquely skilled I was mostly referring to how we all have different levels of expertise in some narrower domains. Just like your example of you being 1.3x at JS and 0.5x for C++: you can do C++ on a project, but you can't allocate two weeks on the C++ part of the project without deciding if it's you or 1.5x person doing the work. IOW, your roadmap is "faked".
lrvick 4y ago
Once a CEO giving a tour of the engineering department to a potential investor and loudly described us as the monkeys that hammer out code for him. This was never forgotten and marked the beginning of a major engineering exodus.
- teknopaul 4y ago
  Oook. I consider myself to be a code monkey and divide the jobs I'm given in to one, two or three banana jobs. (indicating complexity)
2OEH8eoCRo0 4y ago
Human capital
muzani 4y ago
Counterpoint: I've seen this go okay when it's to make things impersonal. Rather than saying the engineering team is slow, we just say there's not enough resources in engineering. Rather than saying Diane is being stretched out across too many teams, we say we need more resources in design.

I am starting a new forum ResourceNews where resources can gather around and discuss anything that irks them in their workplace.

hk__2 4y ago

You can do both: "resources" and "people" are two different point of views of the same thing. I’m in a 5-person company and we refer to people as "resources" when we’re allocating times to each project. We refer to people as "people" outside of that.

necovek 4y ago
You can certainly do both, but you shouldn't. People are not resources: each one of them will do different work and different amount of work. They are never interchangeable, and they don't even behave the same over time. A frustrated or bored "resource" will do lesser work, but as long as you refer to them as a resource, you'll miss on that nuance. It's not that hard to consider them people, possibly even people by names in such a small company as yours.
- thebadsleep 4y ago
- dusted 4y ago
  > People are not resources: each one of them will do different work and different amount of work. Different people have different resources, when you allocate a resource, you're allocating something someone can do, not something they can't do.. When you put resources on a project, the people follow along, since they're the ones with the resource in demand. I've never understood the resource as referring to a person, but rather, to the work that is expected that the person can do. If you need a C++ resource, you pick a person that can do C++, they may also be able to do PHP and SQL, but in this case, that's not what you're selecting for.
  - necovek 4y ago
    Even then, your "C++ resource" will perform completely differently based on the person they are: eg. a junior C++ engineer will be slower than a mid/senior engineer, and an engineer providing a more maintainable solution might be slower too (and somebody un/familiar with the problem domain or API in use). I don't see how planning work for a "C++ resource" helps other than faking it over and over again.
    - hk__2 4y ago
      In my specific case we all have roughly the same experience with each technology so it’s fine to consider people as interchangeable. Of course that doesn’t mean we don’t take preferences into account; it’s just to have a rough idea of our roadmap and know if we need to recruit.
      - dusted 4y ago
        I agree. Also, if people are so uniquely skilled that each and every task can only be made by a specific person (excuse me, "human being") then your bus-factor is 1 and a single person leaving, getting sick (or indeed, hit by a bus) means death for the project.. That's terrible. It's entirely reasonable to think of work and people using separate terms, I'd argue it's probably healthy too.. Now, that's not the same as ignoring personal preferences where they apply, for instance, when allocating resources to a task or project, of course, consideration should be taken when possible, "oh, person X hates doing this, but Y loves it, sure, X is slightly stronger at it, but we let Y do it, then they're happier and Y gets stronger too" I consider myself as being around a 1.3x javascript resource for backend, a 0.8x for frontend, and around a 0.5x resource for C++ (meaning I'll spend twice the amount of time doing the same task as someone I consider a 1x C++ resource).
        necovek 4y ago
        > uniquely skilled I was mostly referring to how we all have different levels of expertise in some narrower domains. Just like your example of you being 1.3x at JS and 0.5x for C++: you can do C++ on a project, but you can't allocate two weeks on the C++ part of the project without deciding if it's you or 1.5x person doing the work. IOW, your roadmap is "faked".

lrvick 4y ago

Once a CEO giving a tour of the engineering department to a potential investor and loudly described us as the monkeys that hammer out code for him. This was never forgotten and marked the beginning of a major engineering exodus.

teknopaul 4y ago
Oook. I consider myself to be a code monkey and divide the jobs I'm given in to one, two or three banana jobs. (indicating complexity)

2OEH8eoCRo0 4y ago

Human capital

muzani 4y ago

Counterpoint: I've seen this go okay when it's to make things impersonal. Rather than saying the engineering team is slow, we just say there's not enough resources in engineering. Rather than saying Diane is being stretched out across too many teams, we say we need more resources in design.