Also this works for products with "few" teams? Typically in big co products I have seen (working in cloud Saas offerings) development is broken into a dozen t

Also this works for products with "few" teams? Typically in big co products I have seen (working in cloud Saas offerings) development is broken into a dozen teams (observability, ux, service A, service B etc). It gets worse with higher revenue products (org building is norm). Customer support rotations though infrequent need you to understand a lot of things fully across the stack. While the odd eng enjoys the breadth most folks I've seen get burnt out as they are wading through a gazillion playbooks only to have tickets cross over to the "next" support rotations:(