Spent 5 years there, I definitely know the experience varies wildly between teams and orgs so take all of this as just my personal opinion.
I was part of the Amazon Luna team and Devices org.
Yes oncall is super rough, yes people are very demanding. Internal documentation sucked.
But overall I had a really great experience, there was a strong sense of “ownership” on the stuff we built due to how teams are expected to be run. We owned all the infrastructure ourselves, costs, QA, deployments, technical decisions, you name it.
As long as you could justify the customer value managers and execs were pretty open to experimentation and trying out new approaches.
I also was lucky enough to have a very technical oriented manager, he had a great long term vision of where he thought we needed to go and the technical chops to guide us there.
The approach is definitely not for everybody nor the only one that can work in a company like Amazon but I think it did fit with my own values (if that makes any sense).
Some other random things I miss not in any particular order:
- Strong document oriented culture, it is expected of you to dive deep into certain areas while at the same time communicating them effectively
- smithy
- While CDK started out clunky pretty amazing high level constructs were available later.
- Full access to AWS, pretty easy for you to experiment and prototype.
- Both internal FF tooling and the AWS options were quite good.
> But overall I had a really great experience, there was a strong sense of “ownership” on the stuff we built due to how teams are expected to be run. We owned all the infrastructure ourselves, costs, QA, deployments, technical decisions, you name it.
This is one of those terms that drive me nuts, because actual ownership implies revenue/profit sharing, decision making, and property rights.
Sounds like you're getting all the responsibilities of ownership, but none of the tangible benefits.
Considering many shops are just "implement whatever the business people want" and have things silo'd out across many teams, the autonomy to make a thing you work on and support better is hugely valuable. You can get that lots of other places, but it's very hit and miss on the level of ownership you can actually achieve. Amazon does tend toward a very startup-like sense of technical ownership, even if there's little financial tie to the product.
I'd argue that most startups have little financial tie to the product too for all but the first couple of contributors due to all the complications that wind up going into startup funding. If you can only realize any value from your equity with 1:10000 odds, your expected ownership is 1/10000 of whatever you actually got in equity.
- AI comes fast, there is nothing you can do: Honestly, AI can already handle a lot of tasks faster, cheaper, and sometimes better. It’s not something you can avoid or outpace. So if you want to stick with software engineering, do it because you genuinely enjoy it, not because you think it’s safe. Otherwise, it might be worth considering fields where AI struggles or is just not compatible. (people will still want some sort of human element in certain areas).
- There is some sort of ceiling, gives you more time to act: There’s a chance AI hits some kind of wall that’s due to technical problems, ethical concerns, or society pushing back. If that happens, we’re all back on more even ground and you can take advantage of AI tools to improve yourself.
My overall advice; and it will probably be called out as cliche/simplistic just follow what you love, just the fact that you have an opportunity to pursue to study anything at all is something that many people don't have. We don't really have control in a lot of stuff that happens around us and that's okay.
I was part of the Amazon Luna team and Devices org.
Yes oncall is super rough, yes people are very demanding. Internal documentation sucked.
But overall I had a really great experience, there was a strong sense of “ownership” on the stuff we built due to how teams are expected to be run. We owned all the infrastructure ourselves, costs, QA, deployments, technical decisions, you name it.
As long as you could justify the customer value managers and execs were pretty open to experimentation and trying out new approaches.
I also was lucky enough to have a very technical oriented manager, he had a great long term vision of where he thought we needed to go and the technical chops to guide us there.
The approach is definitely not for everybody nor the only one that can work in a company like Amazon but I think it did fit with my own values (if that makes any sense).
Some other random things I miss not in any particular order:
- Strong document oriented culture, it is expected of you to dive deep into certain areas while at the same time communicating them effectively
- smithy
- While CDK started out clunky pretty amazing high level constructs were available later.
- Full access to AWS, pretty easy for you to experiment and prototype.
- Both internal FF tooling and the AWS options were quite good.