What is wrong with American engineering and how to fix it

What happened to American engineering over the last 20 years?  It used to be such a great profession.  It used to be a secure profession where an engineer could spend his or her entire career at one company.  They were valued as the brain trust of the company where all the inside knowledge resides. 

There were pensions and profit-sharing and many incentives to keep the engineer working at the company.  If an engineer wanted to leave a company, the company would make some effort to convince them to stay.

The engineers used to be in control of how they accomplished their job.  But most important, engineers used to "own" the project.  This is the most important change to the way engineering is developed today. 

Most engineers have 4 to 5 managers, each responsible for a different aspect of the project, but not one who is responsible for the whole project.  Gone are the days of the determined old ex-engineer manager pounding on the desk saying, "this is my project and it WILL get done on time!".

Ownership - The engineering solution

There is only one way to properly engineer a product and everyone knows it, "ownership".  Let's take software engineering as an example, but this is true with any kind of engineering.  When an engineer owns a piece of software, their pride will give them the enthusiasm to make sure it is "bulletproof".  "Bulletproof" is a software engineering expression that means it will work regardless of what happens.  In other words, there are no bugs that can be exploited.  When there is only one engineer working on the entire software, the chances are that it will be virtually bug-free.

The attack of the conglomerates

In the original days of software engineering, the Project Lead was completely responsible for the entire project.  That person took pride in the product and personally ensured that all malfunctions were considered.  These engineers, who worked hard for over ten years, would eventually get promoted to management.  They became the old manager banging on the desk.

Sometime in the 1980's and 1990's major conglomerates began buying up smaller engineering firms.  Long time engineers were no longer promoted to management.  Managers graduating from business school were placed in charge of engineering projects to streamline costs.

A "matrix management" system was created that removed ownership of any single project from any single person and spread it out among various departments.  This created an effective communism within the corporation.

Now, no one engineer is responsible for the entire product.  Since there was no longer a go-to guy to solve problems, corporations adopted formal engineering processes and methodologies.

There are many such formal methods in all forms of engineering.  Let's take the field of software engineering as an example.  SEI/CMM, ISO, Six Sigma, DO-178B and others are examples of processes and methodologies used.  They are basically detailed steps for engineers to follow that most engineers have been doing implicitly for years.

They all basically break down the development process into stages such as:

      Specification
      Development
      Debugging
      Verification
      Validation 
      Testing
      Quality Assurance

Then software tools were installed to make sure that engineers would follow each step.  These tools required the engineer to describe everything that was done and why.

For example, if a software change is made, a PR (Problem Report) would typically be created by an engineer.   This often took more time to write up than than it took to fix the bug.  Then another engineer would fix the bug.  Then another engineer would have to approve it and send it back to the original engineer, with comments which were often about spelling or grammatical errors.  Then the original engineer would have to redocument what was done and the second engineer would have to re-approve it.

What ends up happening is an engineer would fix a bug that took an hour to fix and then several engineers would spend another 20 to 40 hours of paperwork explaining what was done.  Since most managers were not engineers, nobody seemed to have noticed this inefficiency.

Any secretary could have managed this process and saved engineers hundreds of hours of paperwork.  The secretary would not even need to understand the engineering details, only the engineering process.

Managers almost seem afraid to allow any one engineer to accumulate complete knowledge of any one software product.  Managers loved these tools partly because they could fire any engineer they wanted.  Theoretically, another engineer could read through the thousands of pages of documentation and continue the work.

So today it takes about 10 software engineers to do the work of one engineer.  This is one of the problems with engineering today.

Another engineering expression is "skunking".  This means that when engineers are not busy on a project, they will create a tool or a product that they know the company will eventually need even though management has not asked for it yet.  These engineers became the brain trust of the company.

Now when a new project is started, the company must start all engineering from scratch.  Today engineers spend about half of their time doing paperwork and the other half performing actual engineering work.

Engineers need secretaries

To fix this problem, either corporations must return power and control of projects to engineers or they must provide assistance for all of the paperwork.  It is unlikely that companies will return control of the projects back to the chief engineers. 

Their current solution is to throw more engineers at a project, often these are contractors or consultants who are hired for a short period of time.  Then when the work slows down, you get massive layoffs.

If managers truly want to fix this problem without revamping the system, they could provide engineers with some assistants.  Engineers should have available to them technical writers, database assistants, and secretaries to help them with all their paperwork duties.  In this way, engineers could once again focus on the hard work of engineering, instead of performing mindless paperwork.

Here are a few examples:

Disney listens to their engineers

In one case, When Disney Imagineering and Disney Scientific systems found themselves falling behind in a large software project, they asked the engineers what they needed.  Some engineers suggesting hiring a technical writer to help them document the software, so they could focus on perfecting their software. 

Disney managers reacted immediately and hired a great technical writer.  Software engineers wrote notes in email, text or Word documents and sent them to the technical writer.  The engineers either hand-drew diagrams or worked with the technical writer while she skillfully created them.  Sometimes they would even make drawings on napkins during lunch and handed it to her.

She was an expert with MS Word, Visio and other documentation tools.  Within minutes, she would type up the documents, adding diagrams and cross-links and would then hand it to the engineers.

All the engineers had to do was to correct the mistakes and give her additional direction and she would be back within minutes with a perfect document.  Of course, the engineers had to make sure that the document was correct, but they did not have to waste time checking their grammar or struggling with Visio images.

She was a great success.  The engineers were able to focus on the software and all the documentation was done perfectly and on time.

It should also be noted that the engineers also asked for docking stations so they can take their work home with them and ergonomic chairs so they can spend more time at their desks.  Disney responded to all of their requests and the engineers worked with extreme enthusiasm, dedication and efficiency.

It is also worth noting that most Disney engineers stay with the company for their entire careers.

In memory of Hal

In another case, a forward-thinking manager hired an engineer to do nothing else but integrate the software and communicate between the engineers.  The manager became terminally ill and the team continued without a leader for several months.  When a new manager was assigned, he noticed that engineers were coming in at 11AM and leaving at midnight and appeared to be undisciplined.

The new manager called an 8AM meeting but only the integration engineer showed up.  He told the new manager what everyone was up to and not to worry because everyone knows what they need to do.  He told the new manager that the original manager assigned ownership of each module to one engineer.

The new manager went to a staff meeting expecting the worse, only to find out that his team was way ahead of all the other teams.  After that, there were no more 8AM meetings and the manager only needed to ask the integration engineer what was going on.  He would show the manager their status by running the software on the system and demonstrating what is working and what is in progress.

The new manager wisely filled out all the paperwork himself for his engineers and continued to receive kudos from his managers.

The DOORS guy

In another case, engineers were writing test cases but also had to use a database tool called DOORS to document the test cases, linking them to the requirements.  They were having difficulty linking system requirements to software requirements to test cases and other things using DOORS.

When the managers asked if there is anything they can do to speed up work, the engineers suggested hiring a DOORS expert that can help them with this tool.  The on-site DOORS expert trained everyone as they requested it and also did much of their time-consuming work himself.  All they needed to do was to focus on the test cases and verify that the links were correct.

Again this was a great success.

These stories are rare.  In most cases when engineers request assistants, it is met with sarcastic laughter.

Managers who were never engineers simply cannot comprehend that software engineers must have all their focus on the code and should not be distracted with paperwork. 

Today managers assign small portions of the software to various engineers but do not provide any inter-communication or guidance.  It is like trying to build a building with a bunch of bricks but without any mortar.

So if you are a manager and having trouble meeting your schedule, try asking your engineers what will help them work more efficiently.  It may be an integration engineer, a pool secretary, a technical writer, a tool expert, multiple monitors, or an ergonomic chair.

But do not laugh at their requests.  Remember it is their brain that is creating your product.

It is in everyone's interest to help engineers focus on engineering and not on paperwork.

This blog is dedicated to the memory of Hal