1. All problems eventually end up with the most competent engineer. "The curse of competence."  Regardless of type of problem (hardware, firmware, software)  it will eventually be placed in the hands of the most competent engineer on the team to fix.  If that engineer does hardware then the company will expect a fix in hardware, if that engineer does firmware then the fix will be a firmware fix, etc.  Note this also means this person will be blamed for all failures, even if it is just because they did not prevent other engineers from making mistakes.

2. The person who knows the most about an embedded project will always be the firmware engineer.  The firmware engineer is responsible for debugging all hardware problems, as hardware engineers can not debug without firmware, and unless the hardware engineer is the most competent engineer, he will blame any bug on the firmware guy especially if he is more competent(see #1).   The firmware guy has to know how every detail of the product works from the hardware to the customer requirements.  So again he will always be the one people ask how something works, regardless of who did the work, or who was manager/project lead/lead engineer. 

3.  Everyone forgets the initial design requirements after a few months.  That is requirements like short development time, or low costs get lost after a year.  That is after the decisions made to meet the initial design requirements have long passed then people forget them and wonder why better design and decisions were not done.  As a friend tells me "Make it work first and then cost reduced, if it meets the cost target and does not work then you have nothing."

4. If you do a little bit more than expected each day, then each day they expect a little bit more.  As soon as you add in a 'nice to have' feature or extra features to make development easier they quickly become cascading requirements.   Add in error logging then it will be required for customers to send log files and download.  Add in error checking then more and more requests for error checking will be requested, until firmware should detect bad solder joints (yes this happens).   Add in hardware protection, then why did you not do it everywhere.   No one ever says "Lets remove this feature because it is not valuable, and causes more testing and problems."  Instead it is always increasing.   At best people forget about requirements, but never remove them. 

5. Only the competent engineers go back and review the project.  No one else goes back to original documents for the project and asks what could we have done better?   Or how did we get where we are? 

6. The code is a mirror of the organizational structure.   If code is dysfunctional then the organization that created it was too.  For example code to test buggy hardware will be left in the product just in case it happens again (and often does).  Then requirement becomes for firmware to determine if hardware is buggy (#4). 

7. In a dysfunctional organization doing a good job is making sure that your part of the project is never the first to fail. Second is when someone else's failure causes a project to die make sure that you tell everyone how your part worked perfectly and how bad it is for the organization that other team was not as good.