Richard Feynman illustrated a point about involvement and productivity in the book “Surely you are joking My Feynman”. There was a big team of physicists working with every possible resource available to create the atomic bomb. As part of the project they were supposed to do tons of calculations and hence hired the best mathematicians in the country and placed them along with expensive computers to churn the necessary calculations out. Since the project was top secret, the mathematicians just received the problems; in spite of their level of expertise, the performance was found to be too mediocre.
Feynman took the tough decision of disclosing the project secret to enhance their productivity and convinced his superiors to help him to do so. He got a buy in and went ahead in explaining about the nature of the project and why it is necessary for them to come up with the bomb before any other country comes up with their own. As expected by him he found the productivity to increase many folds when they knew the end goal and its importance. His idea of treating them not just as a facility for mathematics but involve them to be as part of the project has paid rich dividends. He has observed that the mathematicians became very inventive to make use of the limited availability of the computers and took extreme care to iron out inefficiencies.
This is a real life incident and I have also heard many times about “difference between laying the bricks and building the cathedral”. In the software building world, the bigger picture never gets painted to the entire team and often the talent is overrated than how the job can be taken to the finish line. Unless every one in the team has a strong sense of ownership towards the goal, the peak performance never occurs. Getting the whole picture can also give an illusion of a time consuming activity, but benefits out weigh the time spent on that activity.
What would happen if the captain of the football team need to yell to every one the field on what to do next, wont it be a terrible team to play with?
Novi's 
Hi,
I’d be careful about confusing the message of “sharing the big picture” with the message of “pressure to perform.” In the example of the physicists working on the calculations for the atomic bomb, the sharing of the big picture ALSO exposed them to the pressure of failing, which meant that many lives would die in their homelands and that the enemy would potentially win the war and take over the world. The pressure that came from the sharing of the bigger picture, in this case, has to be factored into the performance of the physicists, after the disclosure of purpose.
In reality, sharing the bigger picture doesn’t always help localized workers, like coders, to perform better. However, adding some element of real pressure might change that performance. Also, there are different levels of pressure that would have to be taken into consideration. The pressure of missing a date may not be as big as the pressure of losing your bonus or your job, or even remotely close to the pressure of someone dying because of your mistake.
While in the case of programming, I believe that sharing the bigger picture doesn’t hurt, I don’t know that I have experienced that it has always helped, either.
Here’s a question that looks at the same issue from a different perspective: Why can’t people just do their jobs well, all the time, even without knowing the bigger picture?
My Best,
Frank Guerino
Chairman
The International Foundation for Information Technology (IF4IT)