I would disagree - I think you are reading something into “let engineers decide” that goes with the many micromanaging structures like scrum, which is to start

I would disagree - I think you are reading something into “let engineers decide” that goes with the many micromanaging structures like scrum, which is to start with a close to complete lack of trust in ICs. In a well managed organisation ICs don’t simply go off and do what they want. In a new organisation with a lack of any experienced engineers a failure in management could easily lead to that as management has failed to do its job and the ICs are not sufficiently experienced or informed to be able to compensate for such a failure. More experienced engineers can generally identify poor or incompetent management and can compensate (to an extent). But by and large “all the engineers went off and did random things” is absolutely a failure in management, not the ICs. If there are just a few ICs off in the weeds then that implies the ICs are the “problem”, and that may simply mean having some more hands on management - helping them understand prioritization, etc not micromanaging them - or possibly having them get some help from a more experienced IC, so that they can learn how another IC does their job. At no point have I said anything about peer programming, which should not ever just be a “this is how all dev shall happen” nonsense. Things like peer programming is a fairly occasional tool in my experience, something that has happened when I’ve been working on a particularly irksome problem with another person on a whiteboard, and it seems like the code might be gnarly, but that latter is very very rare; vs the simply working out the solution.