Information Overload! Isnt that the common theme in our hectic lives? The partition between work and personal lives are blurry, at best. Do I only work from 9AM-6PM? No. Do I keep away from work activities from 6PM-9AM? No. As I mentioned in an earlier Blog, I believe that it is going to be the trend. We have to get better at efficiently using our times in spurts of high-output time-slots, as opposed to predictable continuous hours on a particular activity. (Of course, a “red flag” or “high priority” item supercedes such rules, I think.)

A typical project involves the following as a day-to-day activity list:

– Individual Work (E.g. Designing, Verification, Testing etc., where there is an invidivual working on his/her activity)

– Team Meetings

– One-on-One (or multi-member, but not the whole team) Meetings or Activities

– Emails (!!!)

– Document Sharing

– Team Lunches and Get-Togethers

Etc. How do we ensure that Information is being propogated through the team efficiently? Let me illustrate with some examples of wastage (in my opinion, of course):

– Scheduling meetings where one or more of the invited members’ input or output is not required or needed

– “Too many cooks” Syndrome: I.e. There is a point where “increasing the number of engineers” is not the solution to the problem at hand.

– Multiple versions of Specifications floating around …

– Conducting a detailed back-and-forth discussion via Email. I have had occasions where a person sitting 5-ft from me discusses with me via Email! Dont get me wrong. Email has its advantages: Written minutes of discussion, Allowing the target person to respond at his convenience, Good way to consolidate an itemized list etc. But wont it be more efficient to tackle follow-up questions/doubts on the spot and terminate a question/issue on the spot rather than giving more workload to my Company’s products or giving a good workout to your computer’s keyboards (or your fingers)?

Some suggestions:

(a) Use Specifications as the hand-off tool between Team Members: It would be a good idea to insist on this. A lot of engineers like to get things done, and documentation is considered a boring chore. It would be best for that mentality to be altered. Any feature change or bug fix or programming guide, should be communicated through the official document, I.e. Specifications. Such a structure allows for a lone source of Information (for that part of the Product/Project) for all members of the Team. (Use Version Control).

(b) Feature Overload: As a part of Information Overload, it is best to keep the Feature Requests to manageable levels. Given a choice, who wouldnt like to cram every single feature into the Chip/ASIC/SoC? But we got to be realistic as well, right? Last minute Feature Changes are the killers!

(c) Team Meetings: Publish agenda beforehand. If there are documents that are needed as reference for the meeting, publish them beforehand. Maintain a list of the items you would like addressed during the meeting and at the end of the meeting, make sure you are on track to addressing each of them. Maintain the pace of the meeting. Some people love to talk. Consider yourself to be a Air Traffic Controller or Traffic Light System 🙂 Maintain meeting minutes and encourage Team Members to sift through the discussions and extract every single useful/related information for their part of the Project/Product.

(d) Be a good “Router”/”Switch”. (Hat tip to the Company I work for!). As important as knowing what to say, is knowing what NOT to say. Please keep in mind that not all information is meant to be “democratic”.

Adios …