Wow. Taking it section at a time.
If you have strong strategic thinking and leadership skills, then the programmers and the artists do not need to know anything about the game concept and design.
No. You don't wait until the contract is signed before telling "Oh yeah, this really isn't a FPS, it is a kind of turn based/RTS hybrid."
You need buy-in and feedback from everybody. You might write your pie-in-the-sky GDD thinking it will take three months for five developers to build, only to hear back from your development team that you are looking at 15 people for 12 months. If you design in the dark you will probably be surprised what you see when daylight shines on it.
You cannot lead effectively without knowledge, and you get knowledge by active communication and constant feedback.
What proportion of skills and roles are used by the team members is partly a matter of necessity but mostly a matter of your preference.
Only partially so. If you write an art-heavy design you will need more artists. If you right a code-heavy design you will need more programmers.
You have some ability to guide it through your decisions, but if you make up an art-heavy design and then hire insufficient artists, the results will be unsatisfying.
It is ideal to have all team members working independently of one another but dependent on YOUR guidance. This way none of them are waiting on one another but only waiting on leadership upon completing elements of the game.
Yes you need to remove the blocks. That is part of the job of a producer and the project manager.
Removing the blocks does not mean "working independently but dependent on YOUR guidance". That is called "micromanagement", and it is a bad thing. It means the manager is blocking everything.
Over the years my experience is that interdependence is far better than independence. When studios follow the (absolute garbage) advice that chain of command must be followed, it goes like this: Artist asks the art lead. Art lead asks the project manager to cross divisions. Project manager asks the programming lead. Programming lead asks the programmer. Programmer provides an answer to programming lead. Programming lead relays it to the project manager, who passes it to the art lead. Art lead tells artists. The process takes three days...
... by which time the artist hunted down the programmer, they had a five-minute discussion and the pair found an even better solution than either would have found on their own.
Your goal as a producer or project manager are to enable people to do their jobs. Finding good ways to manage means removing barriers, not micromanaging their tasks.
This is BY FAR the most cost effective way of running a game development company.
Citation needed.
Imagine at the other extreme if all of your team members are depending on one another for everything and spend many hours discussing things among themselves instead of making things. Does that sound profitable to you?
I have seen too many counterexamples to even know which one to cite.
For every game object before starting work we involve the designer, the programmer who will own the feature, the modeler who will own it, the animator who will own it, the sound engineer who will own it, and the QA lead and at least one tester. For important objects we also include the feature's producer(s) and potentially additional developers. The designer discusses the design with every one of them before the final design is approved, often with each group getting clarification or more information back to help build a solid design. Then we have a meeting where all the disciples get together, read the design, and either accept it along with its schedule or suggest significant refinements and send it back to the drawing board.
Often these are scheduled in 4-hour blocks as a chunk of the project moves forward.
Some of those objects are simple and can be reviewed and accepted in a matter of minutes. Some of those objects are complex, requiring an hour or more for everyone to agree. It is usually obvious how long the design will take, but sometimes there are surprises where a seemingly simple object makes everyone object to unexpected complexity, or a seemingly complex object can be reduced into very simple parts by the individual disciplines.
That kind of open communication allows bad to become good and good to become better.
We can be halfway through the meeting and suddenly the QA lead asks "Have you thought about such-and-such? If they activate A and B at the same time, will this break the game?." And suddenly everybody stops and realizes there is a fatal flaw.
Or the audio tech speaks up "I might have counted that wrong, but when I multiply those together it looks like you are asking for about 300 unique voice events. Is that correct?" And suddenly the designer realizes the requirement needs to be removed.
The programmer might realize "What if we tied this in to such-and-such system? We could gain these features and also reduce the cost, but it needs more art", followed by the artist "I can probably reuse the existing such-and-such asset if we did that, we can reuse the rig and probably half of the animations", etc. A short conversation follows with some very minor design adjustments. The end result is a 50% reduction in development cost and an even better game object.
You want to avoid a situation like Congress, with 535 competing ideas, but it would be foolish not to get input and buy-in from every discipline before starting. These people are your team and your most valuable resource, they are not your enemies.
Quality Control is YOUR responsibility. You are the leader.
It is everyone's responsibility. Done well everybody is accountable for their own work, and diffusion of responsibility does not apply.
Does that sound profitable to you? 
