Advisors · Engineering management

How do you manage engineers?

ivan ner HR Manager at VR

September 20th, 2016

Engineers are a different breed.
They can not be managed the same way as you will hold accountable folks in the marketing or HR departments.
Do you all have any suggestions ?

Stephen Palmer Grand Master, Sovereign White Knights - 6 Peaceful Orders

September 21st, 2016

As an Engineer, Physician, and attorney, and as an inventor; you do not manage Engineers in any structural way that you would a business executive, it is a huge mistake to try; it will cause high turnover and could cost you your company and your credibility. You select a project, particularly in their primary field of engineering, select a project lead that can fill both shoes: Admin and Engineer, throw in a few chemists or materials engineers, and a few software engineers, then give the lead a project budget, that is an approximate; there will be cost over-runs if they have not been intimidated by competition, or management time-lines. Engineers do not normally work on budgets, or time constraints; do not over intimidate them by demanding progress reports, and cost statements, that is not what they are there for. If you have either a new or going concern, you want to budget at least 20% of your funding or gross-net profits to R&D, that is unless you do not plan to stay in business. Managing Engineers is like herding cats; it cannot in realistic terms be done successfully. Yes Engineers work with physics, mechanics and materials, but they are still creators of our new reality, thus, they are artists.

Rob G

September 21st, 2016

...i almost forgot: 
8. marketers and engineers will drive each other crazy so make sure you have a buffer in between.  Marketers are all about fluff and broad brushstrokes.  Engineers are all about details. Best to have a translator in the middle - usually called a 'product manager'.  The next time one of your marketers says "we deliver best of breed integrated technology solutions...." make sure they are wearing a helmet if there's an engineer in the room.... and please don't ever ask a marketer to write a spec. 

Stephen G. Barr

September 21st, 2016

In the old days you just put them in one big room with no windows and slid pizzas under the door a few times a day.

Mark Shaw CEO at NEOS HR

September 21st, 2016

Stephen well said!  Yes I agree AND I will provide a different point of view for the discussion.  Ivan, my first comment is it is silly to try and manager one group of employees in the same way and to the same standard as another group. If you disagree, I'll ask you to justify managing the receptionist and the CEO the same way and with the same standards:).

Now most engineers are not automatically practical business people - that I respect.  Whoops neither are HR or marketing folk for that matter.  The risk is anyone can kill a company by 'cost overruns' as quickly as save a company by 'that brilliant breakthrough'.  To me the answer; leaning how to manage risk; be it business risk, engineering risk, commercial risk or legal risk etc.  We need people to appreciate risk and ensure our contribution is adding value (perhaps with a degree of risk) without killing the business.  I also appreciate these ideas are not easy to implement.  Best wishes

Louis Infante Electric Vehicle & Sustainable Energy Systems Technical/Business Consultant

September 21st, 2016

I am not sure I understand the comment about accountability but my experience with managing engineers is to understand their motivations and manage to that. Engineers (the good ones) are motivated by having challenging work to do and are satisfied by providing technical excellence. Then they want to be compensated for that. They need support and proper tools to do their work and when provided and guided through projects they are usually very good participants in an enterprise. If someone tried to play dictator or to question every action, they usually become ineffective at getting work done and meeting deadlines. Regards, Louis Infante +1 248 761 2592

Gregory Scharfstein Oliwan meets SDS at Gmoney Productions

September 21st, 2016

Ivan. Excellent observation. I have been managing engineers for about eight years. I would even differentiate to another level: software engineers, mechanicals, electricals, chem e's ... With whom do they interact? [scientists, customers, sales reps, marketing reps - check all that apply] Then look at the management structure - matrix? project-based? What is the incentive structure? is money more valuable that credit for work accomplished? Inventory tools [computers, software. etc ...] and obtain a real understanding of the efficiency and effectiveness of each tool. Do you have CAD platform challenges? Is the PDM / PLM / ERP fast and useful? Is IT kickass? A map of the above will enable you to see how the teams and folks are being pushed / pulled and essentially what motivates folks to get stuff done. Engineers simply want to get stuff done and be proud of it [recognition from the community]. Things that enable this are good. This is all a good start - the next step is to train the engineering leadership to interact with their teams / folks to fill in the human reflection of the above. This takes time and patience. I have done this effectively by "hitting the floor." The goal is to get face to face with the teams and people and talk about whatever comes up. Then I make sure to ask if there is anything on which they are working that needs support. The key here is I shut up and listen. I write it down and I follow up on it [I walk around with pen and paper]. Most of the time the answer is no. The quality of the initial conversation is essential to solid responses on the back end. An important detail: The engineering leadership must have an effective feedback system to integrate this face to face data into the "Structure" model [i.e. the first set of statements/questions I presented]. Let me know if you have specific questions. Cheers, -- Engineering miracles daily ... Gregory Scharfstein | Senior Mechanical Engineer 410 961 2464 | Mobile

Thomas Sutrina Inventor at Retired Pursue Personal interrests and family

September 21st, 2016

I am an engineer with about three dozen patents.  And have worked in situation where a result, an invention, was needed in a time frame.  I have succeeded most of the time.  But as an inventor I tell people that I will find the answer, but it could happen in the next half an hour or two years from now. At the start I can not tell give you a schedule of when the inspiration that is a patent will happen. 

An example, my first patent is the a Ziploc bag extrusion process.  The production goal was 4 times faster then the stability point of the existing process.  The previous engineer on the project lied so the foundation of the plant was poured and two $1 M custom machines ordered (see Dow Chemical law suit for selling the machine to Glad)  Schedule called for the plant to start in 9 months.  You know know as much as any human on earth about the process needed.  No experts could be hired.  Six months passed with zero progress but lots of failures.  I recalled a lecture that spent less then a few minutes on an obscure historical observation in aviation.  Put together scrap parts from previous failures.  What do I have to loose was going through my head.   I knew we had a process within ten minutes after turning on the machine.  

Now engineers do other things that requires following a process with known steps.  In those situation a schedule is possible.  Like anything else the unexpected will happen along the path.  So how many times an engineer has followed this path will determine how accurate the estimate will be.

Joanan Hernandez CEO & Founder at Mollejuo

September 21st, 2016

Hello Ivan,

It depends on what you're doing, weather it is R&D or deployment. In my case, as an engineer, I do have to respect budgets, I do have to comply with a dead-line and etc. etc. etc.

We engineers are blunt. People take that bluntness as being rude, that's not our intention. We are direct and to the point. As such, we expect communication towards us to be direct and to the point. I know, that's not the case for other professions, for whatever reasons.

For deployment work (tried and true methods), a job can have a deadline and a budget, people will need to comply in some sort of way. However, if doing R&D on some new stuff, then it is indeed more difficult to foresee the cost and delivery time, for obvious reasons. Those things need to be factored in any project.

One important factor that engineering doesn't take well is changing requirements. Changing requirement after something has begun has penalties in the rest of the work. You don't change your house position when the walls are already built, and then expect that change to be done on-time. Those are the levels and the magnitude of the changes -no matter how insignificant from the customer points of view-, imply.

In the end, as long as you have clear requirements, you communicate them well and you DON'T change the requirements during the deployment phase, working with an engineer is like working with anybody else :-)

Best of lucks!

Rob G

September 21st, 2016

grouping all engineers (regardless of specialty) into 1 group in an effort to define a management plan/style is like painting all women or frenchmen or athletes with the same brush - you will miss a lot.  That said, some broad, general brush-strokes that often apply to engineers are noted below. how you manage to that is up to you. 
1. motivated by challenges and conquering those challenges: hitting a project deadline or budget because some exec has drawn some arbitrary, uniformed line in the sand is not a challenge.  "our primary competitor's product does x,y and z and the speed = x.  Do you think you can build a product that does x, y, z and z' that will run 4x faster?  If it will cost more than $1M or take more than 12 months to build it's probably not worth it.  What do you think?"  That's  a challenge. Let them go chew on that and come back with an answer. 
2. Engineers often want everyone  to know they are the smartest in the room. leverage that intellect. seek their input. They like to build the best, fastest, xyz-est thingymabob the market has ever seen. Give them recognition. 
3. engineers are often single-threaded: let them focus on the task at hand.  Minimize distractions and randomizing activities. Sometimes that means shut the door and pull the blinds and sleep in the office until they've conquered the problem at hand ... then sleep for 2 days.  
 4.  engineers are often perfectionists... don't ask them to settle for "OK".   if what you've challenged them with is to build a widget that is 4x faster they will have built something 8x faster and are working on 16x faster.  If 16x has value then put that on the roadmap down the road and figure out a way to get them satisfied with a market-ready interim 4x product and try to find a market for the 16x product.  Don't tell them "4x is good enough" because they are going to build it 16x anyway whether you like it or not. 
5. they like cool tools: 
6. there's usually more than 1 way to get to the end goal. Set the end goal, but try not to restrict how they get there. 
7. like most of us, engineers don't like to be micromanaged.  You are paying them for their intellect, experience and creativity.  Set informed goals (ask for input before setting goals) and then get out of the way... and keep others out of their way. 

Thomas Sutrina Inventor at Retired Pursue Personal interrests and family

September 22nd, 2016

Good engineer and market people have no problem working together.  I have done it for years and at different companies also.  Market people that understand that it actually has to meet customers need to be a successful product, and engineers that know we have to make a profit work together fine.