Amazon

Everyone I had the opportunity to work with was hardworking, smart, and in general kind. They were willing to support me through early mistakes and develop me into a much stronger engineer through my first years in the industry.

Internal tools and support are very strong. Access to internal documentation, source code, videos, message boards, and office hours for the dozens of systems I had to learn to interact with made life much easier. With such a large company, many people have experienced similar problems to you before, and it's easy to find answers to problems in the internal search tool.

Lots of opportunities to work on challenging projects and a relatively straightforward process for internal transfers if you find another team working on interesting projects.

I found that the amount of work put on you scales faster than your own productivity does. Early on, I felt mildly overwhelmed, mostly due to a lack of experience. But even as I learned and began to work much quicker, I was given more projects, required to learn new tools, languages, or software, more project management responsibility, and more responsibility to develop new hires (coming in frequently due to turnover) or organize tech talks or reading groups.

By the time I left, I had asked around, and only one person (a manager) was happy with their work-life balance. I worked here for a little under three years, and only two of maybe twenty original team members were still around by the end. This turnover is both a symptom and cause of burnout. As merely by sticking with a team for more than a year, you're likely to become the only person to know intricate details of a few systems, and so become responsible for most of its management on top of whatever other work you're assigned, which then leads to burnout, which leads to turnover. And suddenly, now some other poor person is in charge of the system.

On my team, tech debt piled up dramatically. Within two years, we went from owning just one system to more than ten. On-call rotations became so hectic that most of the time was spent putting out fires rather than working on addressing root causes. Frequent shifts in team structure and transitions of ownership of systems also meant constantly having to learn new systems on the fly and being responsible for decisions made by other teams. However, management rarely made time for more than one major project to address operational burden per year, instead prioritizing the development of new systems and features, which only further added to issues.

The belief that turnover is due mostly to headhunting is, in my experience, completely false.

Most people are leaving or transitioning because they're unhappy in their roles and feel overburdened.

Even if hiring is keeping the number of employees constant, ask yourselves whether the constant bleed of institutional knowledge and relentless accumulation of tech debt is a worthwhile consequence for fast-paced innovation.