All people are red shirts at amazon

Don't know about Amazon-specific details but since I have setup a similar mechanism with my team and our "partner teams" within a big company to solve similar scaling challenges I will make a few observations.

Per that wikipedia article, Brook's law is more about trying to use more people to make a late projects faster, than projects in general starting from scratch. Knowledge transfer (KT) mid-project, and knowledge transfer as the project inevitably evolves in design/implementation is the challenge due to the need for N people to communicate which can lead to n-squared communication paths which fails to scale.

Brook's law also doesn't really apply if you have some segmentation so the "Away" team and "Home" team have semi-clear boundaries of responsibility allowing them to work independently. The architecture of whatever you are working on has to have some internal boundaries where the "Away" team works on something that generally doesn't require change (or awareness of changes) from the "Home" team and vice-versa. It is presumed in this Home/Away scenario that the "Home" platform/system is fairly stable for the most part and the "Away" team is just plugging in features/new-capabilities and there is some degree of organization and pattern in the core system already.

Ability to scale with multiple Away teams is based on 1) the degree of that segmentation, and also 2) any reduction you can make in amount of upfront KT needed and judgement-based decisions that otherwise require interaction along the way and during the later review stages.

The KT and communications along the way and review process will still cause some Amdahl's-law like situations in overall scalability but you can avoid the "n-squared" Brooks phenomena.

In my experience, the problem with the "Home"/"Away" approach I've seen so far (from a manager/architect perspective more than IC) is that Away teams tend to be project based, so you spend a lot of time KT'ing between Home and Away, and when the project end, that KT goes to waste and is lost. If you have a steady stream of incremental work done by away teams, management should arrange to create a partner permanent team divided along some architectural boundary ideally (make the org match the architecture) or if needed, along some different mission statement. This is analogous to what happens when you have employee turnover on your team.