There's a joke in the US: "A camel is a horse that was designed by committee."
Of course, camels are pretty cool. If you read Pratchett, they are the world's greatest mathematicians.
But they ain't horses.
There's a lot to be said for a single, focused, experienced, architectural "czar."
As to how much leeway the team is to be given, I think the jury is still out, and I'll bet it depends on corporate, or local societal, culture.
Team overhead is a big deal. The more leeway and autonomy that is given to the team, the more overhead is required to maintain the product focus and lifecycle.
But it can well be worth it, if the team is comprised of experienced craftspeople. Less so, if it is mostly junior-level folks, who need to "stay in their lanes."
I am not a fan of "One Law to Rule Them All, and In the Darkness Bind Them" rules. Every team, and even every project, will have many factors that will inform the structure, overhead, deliverables, quality, future maintenance, etc.
I think rather than a single person, you want exactly two people who have to agree on something to make a decision; and if you can't get to a decision, it's probably a sign you need to solve other problems first.
That way, there's someone who can challenge your opinion and you have to convince them to agree with it or find an alternative. Often during the convincing part you identify issues that you wouldn't have thought of by yourself, and since you don't have ultimate authority by yourself, you're less likely to unintentionally shut up someone who wants to disagree but defers to authority.
Of course, camels are pretty cool. If you read Pratchett, they are the world's greatest mathematicians.
But they ain't horses.
There's a lot to be said for a single, focused, experienced, architectural "czar."
As to how much leeway the team is to be given, I think the jury is still out, and I'll bet it depends on corporate, or local societal, culture.
Team overhead is a big deal. The more leeway and autonomy that is given to the team, the more overhead is required to maintain the product focus and lifecycle.
But it can well be worth it, if the team is comprised of experienced craftspeople. Less so, if it is mostly junior-level folks, who need to "stay in their lanes."
I am not a fan of "One Law to Rule Them All, and In the Darkness Bind Them" rules. Every team, and even every project, will have many factors that will inform the structure, overhead, deliverables, quality, future maintenance, etc.