I wonder if the group that does this will be viewed as lesser, e.g. work on less interesting projects, be less likely to be promoted, than the "40" hour employees.
> 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.
The pilot is a team-wide thing. You won't have a 30-hour employee on a 40-hour team. 30-hour employees will work with 30-hour employees under a 30-hour manager. I think that will help offset some of this, but it does put a limit on what projects you could work on. For the pilot, anyway. I'm interested to see how this pans out.
I recognize that 'You won't have a 30-hour employee on a 40-hour team'... my point is that, unless they segregate them in another building, probably another company, the pilot teams will interact with the non-pilot teams... and, at some point in the hierarchy, will be managed by 40-hour people.
As jaded as I sound, I do think there's a place for workplace flexibility. What would really tell me the executives are committed to it: Calculate their actual FTE's - average work week hours divided by 40 - and make sure there are at least that many physical FTE's.
There's no reason why you cannot do that. Our contractors get fixed hour allocations, and often will strictly work to the hours they are paid for (we won't pay overtime without approval).
A few of my folks were angry about this and claimed to be working 50-60 hour weeks. My response was "there's a easy solution to this problem". They cut out the excessive OT, which was mostly unneeded, and not too much changed.
This might be a team wide thing at Amazon but I have seen mixing the two in a single team. Its called reduced hours and can be very helpful for people coming back from maternity leave (as well as others).
Let's be honest - most working professionals (especially in Software) earn more money than they need. I think it's much better to have more time - time with you family, time to be outdoors, time to be healthy - than it is to have more money
I wonder if the group that does this will be viewed as lesser, e.g. work on less interesting projects, be less likely to be promoted, than the "40" hour employees.