Ex-AWS engineer on burnout, team dynamics, and shipping at scale

A former Amazon Web Services engineer has published a candid reflection on their four years building cloud infrastructure, describing how team alignment, relentless prioritization, and technical rigor shaped their ability to ship — and how misalignment eventually led to burnout [Adventures in OSS].

The engineer joined AWS excited by the scale of its systems but quickly encountered bottlenecks not in code, but in coordination. High-visibility projects often lacked clear ownership, and shifting priorities diluted focus. One project stalled for months after leadership reorgs scattered key stakeholders across new teams. Success, they write, depended less on raw technical skill than on a team’s ability to maintain shared context amid constant change.

They credit their most productive stretch to a tightly aligned team that shipped a distributed data pipeline used internally at scale. That win came from enforced prioritization: saying no to feature requests, delegating undifferentiated work, and documenting trade-offs early. In contrast, teams that tried to do everything shipped little.

Technically, the engineer worked across AWS’s golang-heavy stack, debugging latency spikes in services with hundreds of dependencies. They note that while AWS provides robust tooling, tracing failures across service boundaries remained a recurring time sink — especially when documentation was outdated or ownership unclear.

The post doesn’t romanticize the hyperscaler grind. The engineer left after four years, citing emotional exhaustion from repeated cycles of overcommitment and reorgs. They now advocate for smaller teams with bounded scope, where shipping doesn’t require navigating a maze of approvals.

One lesson stands out: at scale, organizational debt kills velocity faster than technical debt.