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?

Games people play!

This is not about the politics but the real games people play in the office like Ping pong, video games (Wii, PC), board games etc. My general observation is that people who started playing a new game and started improvising on it rapidly, showed the same kind of approach towards coding. Apart from the improvisation part, games also provided a platform for people to get together in an informal setting which is not very easily available in the offices other than the coffee table or water cooler. The gaming zones are the breeding ground for people identify like minded ones and also develop camaraderie.

In the last few years I have worked with teams which plays a team game regularly (twice or thrice a week). I noticed many positives after people started playing team games.

  • People got more comfortable with each other and were quick to share feedback about something not going on fine, those feedbacks were also well received and often in a jovial way.
  • The teams were anxious to play almost every day which meant the work on the day had to be finished on time, this made the entire team focussed on becoming very efficient to save time for the evening.
  • The post game retrospectives were so great for some of the strategy games that people made use of that data to plan for next games, which is similar to having iteration retrospectives and planning for the next week. Though the same kind of passion was not evident in the workplace retrospective, I have seen some people referring to a game’s retrospective and set the tone for the team at work.
  • Overall, games reduced the stress levels for individuals who had been pre-occupied with work the entire day.

Apart from games I have observed music, code jams, craft and arts also help people in similar ways mentioned above. which means

All work and no play makes jack a dull boy. Play games at workplace!