Yes, yes, yes.

The remainder of the post after "The answer is" provides no answers to someone wondering how to change this about their team. At best, it's a collection of mnemonics that remind someone who already knows what to do that they should do it. At worst, it's a collection of buzzwords that could mean any number of different things to different people, with described outcomes that are so vaguely positive that they amount to "just make the team right, you know?"

I once worked on a team that attempted to solve this exact problem by requiring all devs on the team to work in pairs all day, every day.

We would have a standup meeting together every day, then we would pick tasks to pair up on. Code was written TDD style, with the devs "ping-ponging" between writing tests and the code to satisfy the requirements of the tests.

The team consisted of two senior devs, one mid dev, and three junior devs.

Pros:

- Everyone on the team had at least a shallow knowledge of the entire codebase when it was all said and done.

- The code was fairly well tested (except for certain parts that interacted with third party services and were almost impossible to test).

- Some of the junior and mid devs improved their skills fairly significantly over the course of the year.

Cons:

- Development was ploddingly slow due to the insistence on pairing and TDD, with multiple deadlines being missed along the way. The project took more than a year to complete, when I know it could have been completed in a tiny fraction of the time if different development practices had been followed.

- Pairing for hours on end with other devs is stressful and often brings out the worst in people. Heated arguments were very common.

- Lack of individual recognition for excellence. There were quite a few times when I (as a senior dev) was put into situations where it felt like I was doing all the work, but wasn't getting the appropriate level of credit for it. The code would have my name on it, but every commit was also signed by the other people in the pair at the time (even if they were just watching). This normally wasn't an issue, but there were a couple of times where I built some really unique and clever/patentable solutions to problems, and the credit/recognition was essentially given to other people. It was especially demoralizing when it was time for raises and all the juniors got massive raises for doing so well (even though I was the one who did the bulk of the actual work while they watched). Meanwhile, I got a barely noticeable raise just to keep up with inflation.

I agree the post is great (which is why I submitted it) but I also found the last couple of paragraphs kind of a let down, after nodding along enthusiastically for the rest of the article.

The article links to this other post on a similar topic https://www.sicpers.info/2021/03/one-person-per-task/. The advice there boils down to "hey, remember agile? Not just the 'use Jira' but, but the rest of it. That was a good idea!"