What You Need To Know About Managing Engineers
A guide for non-engineers
Engineering is unique among professions in that it is very common for engineers to be managed by non-engineers. In other words, while an engineer’s first level manager was likely an engineer at some point, the engineer’s second level manager will just as likely have had a background in an area like business development, marketing, or sales. If you compare that to the other professions like law, medicine, accounting, or consulting, you will see that those organizations are lead by people who began their careers as the very lawyers, doctors, accountants, or consultants they now manage.
This creates a lot of tension for both the engineers and their managers due to the fact that these managers may not understand how engineering works. Much of this stress comes from the fact that engineering work is very different from work in areas like business development, marketing, or sales. Many of the traits, personalities, and even the way the work is done in good engineering would be viewed as undesirable or bad in business or sales.
I would also like to point out that what is said in this article is a generalization. It does not apply to everyone in all scenarios as there are exceptions to every rule. I am also not advocating that all managers need to be engineers, but that at least people who directly interface with engineers need to have some idea of how engineers think and work.
Introvert versus Extrovert
I think this is the most obvious and initial source of conflict. Many people that tend to be drawn to business, marketing, or sales tend to be extroverts. An extrovert is energized by being around other people. They tend to be talkative and enjoy meetings. Introverts are the opposite. They get drained by being around people, and get energized by being alone. Introverts are not shy — they just need some time to themselves.
This creates an obvious area of conflict if introverted engineers are managed by extroverted sales or business people. For example, an extroverted manager will burst into an introverted engineers cube and start hammering away with questions on something that just popped into their mind. The engineer will just sit their quietly looking at him. Both are getting mad at each other — the extrovert does not understand why the engineer is not hammering back at him, and the engineer does not understand why the manager will not be quiet for a minute so he can compose his thoughts and answer. Two people are getting upset with each other when both are acting normally.
Another problem (horror?) that extroverts can impose on introverts is the open office environment. In some ways this is the extroverts dream. There are no walls — you can just talk to anyone you want. Great collaboration! Meet anytime! It is so energizing. While this may work in creative areas like marketing filled with extroverts, it does not work well within engineering. Introverts need a place they can get away to be alone. Open office environments will drain them. They will find it exhausting to be around so many people, and will stifle their ability to think clearly and innovate. Thus, the open office will likely have the opposite effect on innovation than what was intended, and ultimately will have a negative impact on the bottom line.
So how do you encourage engineering collaboration? By combining alone time with chance encounters in one-on-one environments. A great example of a company that used to do this well was HP. They used to have donuts and coffee every day around 10AM. Engineers could spend time working by themselves, and then get coffee and chat with their fellow employees in a calm one-on-one environment. This is the kind of collaboration that works for introverts.
For more information on introverts, please refer to the work of Susan Cain. She has done amazing work describing both how introverts think and their value. See her TED talk here or her book.
Following a schedule in design is difficult
One of the most difficult things for engineering to work towards is the schedule, particularly in product design. There are 3 main reasons why design engineering schedules are difficult to hit.
Unforeseen problems or obstacles
This is best understood with an example. Management wants to launch a new phone where you replace the buttons with a large touchscreen — except nobody on the engineering team has ever worked on a touchscreen. Engineering (regardless of what they say) has no idea how long it will take. Even if they do a lot of upfront work talking with suppliers, looking at past new product developments, and looking at reference designs, any aggressive schedule will be wrong. The reason is not because they did a poor job on the schedule, but because in any large scale project there are always things you did not think of. Many problems are identified only after work has begun when the engineer is digging into the finer details of the design. It would have been impossible to see these issues in the planning stage when looking at the big picture. The only possible way you could have understood the problem was by working on it.
This is problem that almost any engineer can speak to. What started out as a simple project with the goal of “improve parameter X by 10% in 6 months” spiraled into a nightmare. How does this happen? In general an engineer will go into the project with a plan to improve X by 10%. They know the theory, the steps, may even have some promising early test data. Therefore, they are very confident about finishing the project in 6 months.
What happened? Improving X by 10% caused parameters Y and Z to degrade by 10%. This was totally unexpected. Every time they tried to fix Y and Z, parameter X now goes bad. So now their whole schedule was involved around fixing X, but now they need to figure out why Y and Z are affected. They need to stop and develop a theory about what is going on. Sometimes those theories can take forever because…
How do you plan for a “flash of genius”?
“Flash of genius” is a term used to describe how an inventor comes about finding something innovative. It can come at work, at home, at the bar, or anywhere. Something they think of, hear, read, or God knows what triggers their mind to be able to solve a problem they are having.
Some projects actually require a leap in technology beyond where any of the theories or resources currently explain. It requires truly innovative work. Sometimes going into a project people either do not realize how much of a leap the project requires, and believe it can be solved by iterative means. When these leaps in technology are required, it means that the project is indefinitely delayed until the engineer can come up with the theory that explains how to approach the problem. When does that occur? Well…
More time at work does not always mean more work is getting done
I know that in areas like law, sales, accounting, and finance, more time in the office generally means more work is getting done. Many managers that have risen through the ranks and are now managing engineers are used to this mentality of time in the office. Engineering does not always work this way. There are times when an engineer needs to be spending 60+ hours a week on something (such as paperwork, testing, or reports). However, there are times when more time in the office will not help if there is a technical problem that he or she does not know how to solve.
As mentioned before, some projects require a flash of genius to continue. These flashes occur if the engineer is in the office or not. They are more likely to occur if the engineer is not stressed. As a manager you need to try to get a feel for what is delaying the project. Is the engineer not getting basic stuff done like writing specifications, performing testing, etc? Or is the delay in the project due to him not understanding how to fix it? If he is just not getting basic stuff done, that is something you can directly deal with. If he does not understand what is going on (and most engineers will not readily admit this so you need to read between the lines), you need to alleviate the stress on him to get him to think better.
The other common misunderstanding about engineering schedules is the dreaded physical prototype. The quickest you can ever get prototypes in from an outside source is about 1 week. Realistically most orders tend to take 4 weeks or more. There is nothing an engineer can do to speed this up. At best, they can completely prepare for the arrival of the part. Once prepared, if this is the critical path, nothing can help. You are at the mercy of the supplier. Working OT for these 4 weeks just makes the engineer frustrated.
So how do I manage engineers?
Give them space
Engineers, on average, are introverts. Make sure they have time to spend by themselves to think. If you have a question about something, understand that they may need time to think about what you asked before giving an answer.
Hire the person, not the skills
If you need someone to design antennas, most corporations may only look for people with an antenna background. What you can end up with is a rude and unmotivated person that has had great experience. In doing so, you passed by a person with a decent background in electromagnetics that is smart, motivated, and a great team player. While the first person may hit the ground running better, the second person will be a much better investment in the long term.
Remember, much of what I am advocating in this article is that your engineers will run into problems that throw all the schedules and promises off. You need to have smart and motivated people that you trust. You need people that when they see a problem they come up with a plan to fix it and stay on schedule. The real key to managing engineers through problems is that…
Obstacles happen, watch how they react
This is the key to identifying who your best engineers are. On any project engineers will hit obstacles that can throw the schedule off. The trick to watch how they react to the problem. Two common reactions are:
- They have a problem and throw up their hands in defeat. They may hide it from you for a while. In general they will say the project schedule is going to be shot.
- They have a problem and propose solutions. The engineer clearly understands the deadline, and works to get back on schedule. They come to you and tell you about the problem as soon as they see it.
The trick with engineering is sometimes you have a great engineer up against a hard problem and a bad engineer solving all sorts of easy problems. When writing performance reviews, make sure you realize that good engineers will overcome obstacles and find solutions. Bad engineers come up with excuses.
Treat them as people, not resources
A dangerous trend I have seen at some organizations is that they try to manage engineering like production. They track all hours worked, move them around the organization without their input, and have office initiatives that sometimes come off as condescending. Remember — engineers are intelligent people that may have had more schooling than many of their managers. They are going to be able to see through any simple ploys and micromanagement for what they really are. If you try to manage engineers and treat them as children, some may start acting that way. Treat them as the intelligent and motivated individuals they are. Better to trust and gain two coins that to distrust and save yourself from losing one.
I know most college students starting their career do not even fully understand what they are getting into, so as a first time manager with little background in engineering you will have difficulty as well. I hope this article helped you to better understand the way engineering is done and can be managed.