An interesting idea and a funny way to describe an ivory tower architect. I've also been a lead architect for a team of senior developers who acted as a board of approval for all big architectural decisions, but that was only one of the blockers we had in our development process. I've since moved on from that job having learned a ton from the mistakes I made and success I had. Back then I also wanted to implement to ADRs so we had a log of made decisions to stop people going back on their decisions without any good reason.

I've also read Marquet's book. I like how you implemented his thoughts on empowerement in your development process. I can see many benefits in this, and the clear one is every developer will begin to think of the design and will start to think like architects, being ones for their own solutions. This will no doubt increase their skillset.

However, the problem I see here is that submarine operations and software development is quite different. The book mostly described situations that had binary solutions ie. "I intend to raise the submarine to periscope depth" and the answer is either yes or no. In that moment the intended action gets executed immediately.

We developers have more than a dozen ways of doing things with consequences that most likely outlast any submarine tour. Architectural decicsions are the ones that are hard to change. I'm interested in hearing that do you ever spend time going back and forth with the developer's intentions? If they have a difference in opinion and don't want to bend, do you have to override that? In my mind that would be a scenario where you could be spending way more time than a single entity controlling those big decisions. You can gain that wasted time back since you're also teaching developers more by utilizing this way of work, but at that time they may have already moved on to other things.