[This reprint of one of my linked in blog posts while I am on vacation]
For 8 years, between 2005 and 2013, I had the privilege of hosting the MathWorks Automotive Advisory Board (MAAB). In that role I helped to shape of version 2.0, 3.0 and 3.1 of the document. Over the course of those 8 years I enjoyed many conversations with engineers from GM, Ford, John Deere, Toyota, CAT to name but a few. Working with them helped to sharpen my listening and understanding skills; a benefit that I carry forward in all of my work.
Who were those masked people?
The average member of the MAAB Style Guide working group had a PhD, 20+ years of industry experience, and were the Model-Based Design subject matter expert within their company. Most importantly of all they were passionate about developing the field of Model-Based Design (a majority of the board members donated their time outside of their normal work duties.)
Bright, passionate used to being listened to…
When I took over the position the former host likened it to “herding cats.” So how to get them to work together?
1.) Understand your own bias: It is an extremely rare to take part in a conversation where you have no opinion. Be aware of your own thoughts and how they influence what you are hearing. Use that knowledge to be open to new understandings
2.) Actively listen to them: The first step in reaching consensus is understanding all points under discussion. As the “outside” person it is easier to hear all points of view
3.) Find the common ground: In most cases two (or more) parties will share common ground in their base line objectives.
Define the common ground referencing what you learned through active listening, and reach a consensus from the group for this baseline information.
4.) Explore the reasons behind the differences:
In my experience 80% of the time the differences in approach stemmed from a real world problem that the other person had yet to encounter.(1) Once the rationale behind the difference was understood then an informed response can be made
5.) Accept compromise: For the 20% of cases where there is no agreed upon position can be found (2) there is an appeal to necessity. Most experienced engineers understand project deadlines and if they have been listened to (3) are willing to accept a compromise on the work product.
We are all those masked people
In 20+ years of direct customer interactions, both technical and business focused, I have come to realize that everyone can be a ‘brilliant person.’ What you get out of an conversation is directly proportional to what you put into conversation.
Notes:
1.) The objective of the MAAB Style Guidelines are to provided recommendations to ensure error free models with a consistent style to aid in understanding.
2.) With the MAAB Style Guidelines there were cases where consensus could not be reach and both parties had valid points. This is where you see the “follow either option 1 or option 2” in the guidelines.
3.) Please note, I write, “have been listened to” not “feel like they have been listened to”. People can tell if you have actively listened and understood them.
a defensive question. There is, understandably, a reluctance to change existing processes if they are working. Because of this, the answer addresses the common problem that existing traditional hand coding environments, errors introduced at the handoffs points between researchers to developers to test engineers to system engineers to… As discussed in earlier blog posts, one of the fundamental aspects of Model-Based Design is the use of a model as the single development environment throughout the full development process.
significant investment in existing infrastructure. Therefore, it is a high priority task to figure out how existing software objects. First, as talked 
architecture following a traditional design practice.
However, one side effect is the observation “we find so many bugs when following an MBD process.
requirements and testing coverage through automated tools
an integration model that is created at the start of the development cycle. Individual developers check their models against that integration model to ensure that there are no conflicts. Hence in an ideal flow, the integration time should be near zero.
Combined they define how people will develop the model through interfaces and 
erity of bugs is necessary for prioritizing the correction of the bugs. There are two common metrics for determining severity. Frequency, how often does the bug occur. Impact, when the bug occurs what happens to the program. The following lists provide examples of how frequency and impact could be defined
