3 ms·

That reminds me of my time at IBM under Palmisano a decade ago. His goal was to increase the share price by x%. It was no secret one of the strategies was to c

That reminds me of my time at IBM under Palmisano a decade ago. His goal was to increase the share price by x%. It was no secret one of the strategies was to cut jobs in high cost regions (US) and hire in low cost regions. You'd actually hear this in all hands meetings. It was shockingly shameless.

rufus_foreman 6y ago
>> It was no secret one of the strategies was to cut jobs in high cost regions (US) and hire in low cost regions What exactly is wrong with that strategy? You would prefer to own stock in the company that employed people in a high cost region when they could hire someone with the same skill set in a low cost region?
- V_Terranova_Jr 6y ago
  People are not interchangeable parts. If you have high-output staff in a high cost-of-living area, the strategy that recognizes this does what it can to "keep the band together" and keep them doing good for the company, not just saying, "Oh, they're an Engineer 3, why am I paying for a Boston Engineer 3 when I can hire a <insert low COL area here> Engineer 3 for less?" That kind of false equivalence thinking is part of what inspires anti-MBA rants. It's not just about the "same skill set" or title.
  - rufus_foreman 6y ago
    I think that is a short term issue. Yes you need to spin up the high-output staff in the low cost-of-living area before you fire the high-output staff in the high cost-of-living area, and yes you need to do knowledge transfer, the devil is in the details. This has happened to me before, the location I worked in shut down and the jobs were moved to a lower cost location. Many years later, they seem to be doing fine. If it was up to me, they would have kept the people in the high cost location but not hired replacements when people left while adding people in the low cost location, but they didn't see it that way. Also, the longer I work in software development, the more I disagree with "People are not interchangeable parts", at least with respect to developing software. People come work on a code base for a while, they leave, other people get hired on, the code base lives on. If a code base can't be handed off from one group of developers to another group of developers without much trouble, something is wrong. And yes, I know that is an unpopular opinion and the role of a good development manager is to pretend like it isn't true, but there it is. In a well run software shop, you should ensure the people are interchangeable parts.
    - adriancr 6y ago
      The thing about treating people like interchangeable parts and optimizing for low wages is you also get low skilled people / compromise. (low CoL but why stop there, why not look for cheaper people) Low skilled people will slow things down, will destroy any quality and advantages you have in your code and then leave as they get better (or stay if they're really crappy) It's worse if they stay as they have a tendency to multiply and get promoted to middle management and crap even more on things... This will only be noticed via the occasional question "why does it take so long when competitors already did this" after a few years. Also, by not keeping talent you lose their knowledge. All for what?, I doubt their wages factor too much in any product. Alternative is to keep good people and pay them well, nurture a culture of excellency and kick out occasional bad hires. That way you get great products and usually good costs as you tend to need fewer people to get things done (even if they cost more) Note: I've seen both types of companies and some in between.

rufus_foreman 6y ago

>> It was no secret one of the strategies was to cut jobs in high cost regions (US) and hire in low cost regions What exactly is wrong with that strategy? You would prefer to own stock in the company that employed people in a high cost region when they could hire someone with the same skill set in a low cost region?

V_Terranova_Jr 6y ago
People are not interchangeable parts. If you have high-output staff in a high cost-of-living area, the strategy that recognizes this does what it can to "keep the band together" and keep them doing good for the company, not just saying, "Oh, they're an Engineer 3, why am I paying for a Boston Engineer 3 when I can hire a <insert low COL area here> Engineer 3 for less?" That kind of false equivalence thinking is part of what inspires anti-MBA rants. It's not just about the "same skill set" or title.
- rufus_foreman 6y ago
  I think that is a short term issue. Yes you need to spin up the high-output staff in the low cost-of-living area before you fire the high-output staff in the high cost-of-living area, and yes you need to do knowledge transfer, the devil is in the details. This has happened to me before, the location I worked in shut down and the jobs were moved to a lower cost location. Many years later, they seem to be doing fine. If it was up to me, they would have kept the people in the high cost location but not hired replacements when people left while adding people in the low cost location, but they didn't see it that way. Also, the longer I work in software development, the more I disagree with "People are not interchangeable parts", at least with respect to developing software. People come work on a code base for a while, they leave, other people get hired on, the code base lives on. If a code base can't be handed off from one group of developers to another group of developers without much trouble, something is wrong. And yes, I know that is an unpopular opinion and the role of a good development manager is to pretend like it isn't true, but there it is. In a well run software shop, you should ensure the people are interchangeable parts.
  - adriancr 6y ago
    The thing about treating people like interchangeable parts and optimizing for low wages is you also get low skilled people / compromise. (low CoL but why stop there, why not look for cheaper people) Low skilled people will slow things down, will destroy any quality and advantages you have in your code and then leave as they get better (or stay if they're really crappy) It's worse if they stay as they have a tendency to multiply and get promoted to middle management and crap even more on things... This will only be noticed via the occasional question "why does it take so long when competitors already did this" after a few years. Also, by not keeping talent you lose their knowledge. All for what?, I doubt their wages factor too much in any product. Alternative is to keep good people and pay them well, nurture a culture of excellency and kick out occasional bad hires. That way you get great products and usually good costs as you tend to need fewer people to get things done (even if they cost more) Note: I've seen both types of companies and some in between.