The prestige of the engineering profession (or lack thereof) has been a source of discussion from the first week, if not the first day, that I walked into an engineering office as a summer intern. The lower compensation relative to the other "professions" is a factor in these discussions. Some years back I bought and read the book "The Existential Pleasures of Engineering" by S. Florman (ISBN-13: 9780312141042). He tried to make the point that the process of engineering in itself provided zen-like satisfaction. I found the book completely unsatisfying, including the examples he provided of artful, elegant designs and their impact on society. (The author was a Civil Engineer and spent most of his time managing engineers, not doing engineering.)
So, what motivates engineers? The majority of the engineers I have known love their work and would not pursue a different career. Also, while I have known some that have left the profession for other opportunities, I know many others that have come into it fairly late in life via night school and work-study programs. In addition, I am amazed at the extent that a majority of the engineers I know pursue related activities in their personal lives. An engineering office is bound to be populated by photography buffs, motor heads, computer builders, home machinists and obsessive home improvers. Have a car problem, or plumbing issue? Just ask around the office for the proper expert.
All this leads me to the conclusion that most engineers seem to like independently fixing, improving and problem solving. I myself fondly remember many "ah-ha" moments where a solution or implementation formed in my mind proved to be successful. However, I also have many fond memories of expressed appreciation from plant operators, technicians and others who have been helped by the improvements and expressed respect and/or thanks for what I did.
What I think engineers seem to resent is the lack of recognition of those times when their work has made a real difference. What I try to do in the office is talk up the successful contributions of others. I have also used the "Employee of the Quarter" program to nominate engineers I work with. I also always try to involve users and craft staff in my projects as much as possible. This way I can provide solutions that are most beneficial to those who would most appreciate it and are likely to express thanks.
I was probably a pain in the ass to the older engineers I worked with. Why use the same old standard control circuits when there were microprocessors and programmable controllers to learn about? I can distinctly remember thumbing through a copy of Byte magazine while an older engineer (real nice guy from the Midwest) was telling about a servo control system he designed for the Navy. (It was from the days of vacuum tubes and magnetic servo amplifiers). I remember he explained why they used special alloy ring/pinion gears for low friction/backlash so they could tune the servos for required response. I really wasn't paying attention because of the out of date technology employed. (A missed opportunity to learn something...)
What I realize now is that technology is always changing. I was not a better engineer because I was somewhat more fluent in newer technology. Newer implementations were not always better than older controls - especially if they are implemented by engineers without the experience to avoid the common pitfalls. What makes a good engineer is a solid grounding in the basic principles and the willingness to constantly improve ones skills and learn about newer technology.
Which brings me to the 10 year rule...
I had forgotten about that rude behavior on my first full time job until I found myself on a trip down memory lane with a co-worker my own age. It was during a brainstorming session with a group of engineers. We were (or thought we were) regaling the younger guys with stories about the DEC VMS operating system. (VMS means Very Macho Software - it never goes down.) While we were talking about what great software it was, the image of my midwestern co-worker talking about about circa-1960 servo controls came back to me.
What I decided on, and have gotten my fellow old-timers to agree with, is "The Ten Year Rule". We have agreed to tell no more stories about technology more than 10 years old. When somebody starts on a glory days story we interrupt with a "Ten year rule!" to cut the story short. I think this helps us focus on current projects and technologies.
Well there is always the laziness factor. A lot of software documentation doesn't get done because it is just work that programmers and developers can get away with not doing. However, after the latest round of squawking that accompanied change management controls required by NERC CIP, I have come to the realization that compliance just runs against the grain for most engineers. An automated web based change management system was developed to meet the CIP requirements with a minimum of participants effort. Site engineers are even given the ability to propose, implement, and test changes all by themselves with only final ticket closure requiring management intervention. It is hard to imagine that day to day changes require more than just logging in at the beginning of the work day for a few minutes to enter or update tasks. The way staff complained you would think that they were each being shackled with a ball and chain.
I have come to believe that the values of many engineers just run counter to the idea of a workflow that requires step-by-step pre-approvals (even if they can enter and approve items themselves) for each phase of the work. Where workers value independence, learning and personal responsibility, a system that requires reviews and approvals for each step of a task is sure to meet with resistance. (I have observed instances in the Nuclear Plant environment where excessive reviews and approval processes not only slows work to a crawl but doesn't improve quality because responsibility for jobs becomes so diffuse.)
Rather than put in a system forcing everybody to document every step of what they do, it is better to make individuals responsible for individual systems, including each system's compliance documentation. This way person X is responsible for A,B and C systems and any work that is performed on those systems has to go through and be documented to him. He would be the person responsible for providing compliance documentation during audits. This methodology I believe would meet with a lot less resistance while at the same time get the required compliance documentation generated.