In one of the chapters for my forthcoming best practices book, I discuss the importance of informal collaboration between hardware and firmware engineers. When an engineer on one team has a problem, there should be very little, if any, organizational barriers to prevent going directly to a member of the other team to discuss it. One of my reviewers, Vasile Surducan, had this to say:

Maybe somewhere you will explain how the “collaborate on design” principle could work in a company where the information follows vertical with horizontal flow only on top, at the company departments’ leaders. This method of collaboration is a mess because it is modifying the initial content of the information. If you try to speak directly with the firmware technician (assuming you are the hardware guy) and your boss (or his boss) finds out, you’ll be pointed as a bad guy.

As Vasile points out, information gets changed and lost if it has to pass through many people to get to its destination. Imagine this actual conversation (paraphrased) between a hardware engineer and me if we had been required to go up and down the management chain.

Me: “I put the block in reverse mode and I can’t get it to work. This is how it is supposed to work, right?” (Accompanied by a lot of hand-waving in the air.)
Him: “No, it doesn’t work like that, it works like this.” (More hand-waving in the air.)
Me: “How can it work like that? It is missing some information.”
Him: “There is a register with that information.”
Me: “What register?”
Him: “The line size register.”
Me: “Oh, that one? I didn’t know it was being used in this case.”

This type of dialog is very interactive. It cannot be done by writing an email with all the questions because the next question depends on the answer of the previous question. In this case it was an easy firmware fix once I understood that undocumented detail. When difficult problems exist, it is critical to pull together all pertinent engineers to solve them quickly.

The above example illustrates the benefits of informal collaboration. But at times, like Vasile, I have had to deal with more formal organizational structures. Sometimes I was able to reduce the barriers a lot, sometimes just a little. Here are a few techniques, in no particular order, gathered from my own experience as well as others, that you could try, depending on your situation:

• Use email and include all appropriate managers on both teams. If necessary, ask your manager to send your email to the manager of the other team, with copies to the appropriate engineers.
• Visit each manager up and down the chain, explaining the situation and ask for permission to visit with the next one. Explain how critical direct contact is necessary for the success of the project.
• Appoint a well-respected but capable senior engineer to be the liaison, a single point-of-contact for the other team.
• Accompany the managers as they go up and over. Let the managers talk and provide clarification and backup details as necessary. Visits may be in person or via a phone or video conference.
• Get permission to meet directly and then follow up by writing up the results and sending them up the chain as desired.
• If possible, visit the remote site with managers and get acquainted with the counterparts. Ask for some time in the schedule to allow engineers to discuss important issues.
• Write up in detail your concerns, problems, solutions, proposals, etc. in a well-written paper. (Not too big, maybe 2-6 pages.) Email the paper as far as you are allowed and ask the recipients to forward all or parts as they deem necessary.

These are just some ideas for lowering or eliminating organization barriers. You will come up with other ideas as you look for examples within your own situation where more collaboration would have helped solve problems quicker.

• Best Practice: Build bridges between teams to promote informal collaboration between hardware and firmware engineers.

Until the next organizational barrier…