> They are piloting it on internal HR software which I think says a lot.
There's a tendency for people to think that HR software and other internal tools are less important than public products, but if the company is allocating employees properly, that doesn't really make sense.
The engineers working on this HR software all passed the same technical interviews that everybody else did. Amazon could have easily allocated them to some flashy consumer product, but management decided that it's important to have a team working on HR software. So either somebody made a horrible miscalculation when they decided to build the HR software, or this work is equally valuable to all the other work happening.
If you're working on an internal product, your work is not standing up to, or shaped by, market pressures. At least not to the level of that of your peers who are working on public-facing projects. I've seen a tendency for internal projects to develop in a way that is more academic and less practical, for exactly this reason.
> The engineers working on this HR software all passed the same technical interviews that everybody else did.
No, they didn't. They likely were interviewed by the hiring manager. Which, a hiring manager of an internal tools team, does not face the public scrutiny of engineering detail required by a front facing mass consumer product. Therefore internal tools teams do not require as rigid software engineering rules as mass consumer products.
> Amazon could have easily allocated them to some flashy consumer product, but management decided that it's important to have a team working on HR software.
No, they couldn't. Internal HR tools usually means CRUD applications. Why would you put a SQL developer on a deep learning optimization team?
Don't try to defend Amazon here. They have messed up with the way they treat employees. 30 hour weeks doesn't change that.
I see that as a good thing. If you're going to experiment on your employees and try to change your workplace culture, low-profile projects that--while important--often aren't 100% mission critical are a good place to do so.
A major problem in HR or payroll software or something similar might cause some massive headaches for your employees, but it won't be as noticeable outside the company as a major outage or problem affecting customer data.
Amazon experiments. It's not about bold PR moves to make waves and attract attention. It's about trying everything, even ideas that might sound bad, and seeing if they actually work. This? This is the same idea. Try it out on something less important (HR software, sure, why not) and see what happens.
In the worst case, a bit of internal software is late. That's a low-cost risk to see if you can find a way to reduce developer costs efficiently.
It may be part of the same philosophy of "trying everything," but it would be naive to say that there are no motivations of improving the negative reputation Amazon has built upon itself through its intensive work ethic.
I've never understood why people paint companies making changes after negative publicity as such a scummy thing. Not all good changes can be thought of in advance. Making a change should not be viewed as scummy after negative feedback. In fact, not listening and adjusting is the worse move.
To me this seems like a purely PR driven move after the lambasting their culture has taken lately.