I struggle with this question a lot: when does specialization make a team better, and when does it start to erode ownership?

When I first joined Amazon, my team had no dedicated QA, Product Manager, Technical Program Manager, or frontline support team. I had come from a startup where none of those roles existed either, so it felt normal. Engineers also carried the pager and dealt directly with the operational consequences of what they built.

Since then, I have worked with teams of very different sizes and levels of product complexity: internal and external products, Tier 1 services and much less critical systems. Some had every specialization—QA, PM, TPM, and a dedicated support organization.

On a few of those teams, I encountered a very different engineering culture. Product understanding was the PM’s job. Quality was QA’s job. Delivery coordination was the TPM’s job. Customer problems were support’s job. Collectively they had created enough distance that engineers no longer felt accountable for the whole outcome.

For me it is less about whether a team has QA, PM, TPM, or support line, and more about whether those roles increase the team’s capability or partition its accountability.

The litmus test I use is the 3 a.m. page: does the engineer have enough situational awareness to understand the customer impact, navigate the system, make a credible mitigation, and help drive the permanent fix? They do not need to be experts in every discipline, but they should understand the product and system well enough to own the outcome.

Specializations are necessary as systems, products, and organizations grow. But it has gone too far when engineers can no longer operate effectively without every specialist standing beside them.

I am also exposing my own bias here: I believe engineers should carry pagers. That is how I grew up professionally, and I think direct exposure to production consequences produces materially better engineers.