The Engineer's Drive

Engineers are driven by the quest for the right answer. This can manifest itself in the ability to work long hours, sacrificing social life, hygiene and diet for this quest. Tech upstarts like Google, Facebook and Microsoft have been able to take advantage of this drive to change the world. But a forceful corporate culture can turn this drive ugly, into an Amazonian environment. Perhaps this is best for the company bottom line in the short term. But you'll have to get used to managing a constant stream of fresh meat for the grinder, instead of building relationships with your team.

Any good engineer with meaningful work will be self-motivated already. If you push them they will probably be able to work stupid hours in service of the quest. This is where you need to decide what kind of manager you want to be - do you relentlessly push for maximum productivity in the short term, or do you take a longer term view and keep your team together at a sustainable level. However, bear in mind that there is a point at which working more hours will mean less productivity.

The Engineer's Social Hierarchy

Most engineers have a subtly different view of the social hierarchy than other workers. This comes primarily from being the smart geeky kids at school. Engineers or your other tech guys will have their own internal hierarchy, which might not match your pay scales or titles. To engineers, technical competency is substantially more important than other items. Other items can be important too, but a Senior Design Engineering Manager making twice the money but who only knows management and struggles with the technical aspects is not going to be respected and so will struggle to manage them effectively. The marketing guys who have great people skills and are making the sales will be looked down upon. As an engineering manager, you need to be respected by your team, but you might not actually have the background. How can you do this?

1. Cultivate a technical background. This won't happen overnight, but if you are to manage these guys effectively, you need to know how they work. Once you've got the basics, feel free to lean on your team's expertise to build your knowledge, they'll respect that you are learning.
2. Become a subject expert in a specific area or two, where you can demonstrate your usefulness to them. A great option is the Codes and Standards which apply to your work, your engineers will need to interact with these all the time but you won't need to do the heavy maths and physics lifting. 
3. Show them the results of your management. This is going to be hard one, but if you can show your team that you are actively making life easier for them, then they may come to respect your non-technical abilities. 
4. Work to their hierarchy. Don't be afraid of asking the new guy your important questions, if the rest of the team looks to him for advice then you should too. 
5. Don't try and placate an engineer who is looking to leave with a promotion and a title. Titles mean very little to most engineers, because they already have the most important job in the world (to them). More money might be appreciated, but really if money was their prime focus they would have taken their maths skills into finance rather than engineering.  

There is also a bit of a technical hierarchy between STEM fields. This does vary by field and country, but should be some handy shorthand. This generally ties in with the engineer's respect for the person actually doing the technical work, rather than the facilitators. So if you are coming from another field high on the list then you'll get respect for that. Typically on this blog I've used engineer as shorthand for 'employee in a technical role in a STEM field', but here I mean actual degree qualified engineers.

1. Rocket Scientists
2. Physicists
3. Engineers (non Software)
4. Engineers (Software)
5. Scientists (non Physics)
6. Computer Scientists
7. Pure Mathematicians
8. Engineering Techs (machinists, draftsmen, etc)
9. Applied Mathematicians (statisticians, actuarys, etc)
10. Line of Average Respect - below here you'll be naturally disrespected unless you show otherwise
11. Management
12. Accountants (the maths is too easy)
13. Businessmen
14. People skills based careers (marketing, sales, etc)
15. Arts graduates

Engineers and Meetings

Good engineers like to be productive. Every minute they spend not getting the problem solved (with the Right Answer) is an irritant. This is why Google tried to go completely without managers (as have other engineer-driven companies). But your bad engineers laze around on reddit and have to be prodded to get them to do any real work. As a manager you need to be able to keep both types engaged and productive, which seems like an impossible task.

To your good engineers, almost any type of meeting will be seen as a waste of time. They don't care what the other members of your team are doing, they just want to get back to solving their problems. The bad engineers will be equally annoyed, but because they have to excuse their lack of performance. However, there is one kind of meeting which I've found almost all engineers enjoy. Engineers love big picture brainstorming design meetings, where you get the brains trust around a table and they get to compete with their technical abilities to come up with the best solution. Its like a kind of mating ritual to see who comes out on top of the engineers social hierarchy. So when you can schedule your catchup meetings around these, the engineers will be happy to contribute some status updates beforehand.

But there aren't normally enough brainstorming meetings to use these for all your meetings. So here are a few pointers on how to make those status meetings work.

1. Minimise them. If you need to know what Jane, Tom and Bob are doing, go and ask Jane, Tom and Bob separately and informally. If you've got half-decent engineers they'll talk informally between each other to make sure they don't overlap anyway. 
2. Invite the bare minimum number of people. I find meetings are most effective with 5 or less people, beyond that you'll just be wasting your engineers time. Split it up into smaller, more precise meetings where necessary. 
3. Your engineers will love it if you can get them out of meetings with the client or other stakeholders. Have informal discussions with the team members whose information you need beforehand and represent them wherever possible. They want to be left to do the problem solving, so this can earn you brownie points to spent on commercial solutions, crunch time or changes to working practices. However, there are still times where you'll need to have the subject expert present.
4. Formality is death. Engineers with their own social hierarchy and poor social skills don't see the need for formality - this is why Silicon Valley dresses in hoodies and sneakers. This should apply to your meetings too, keep them free flowing and informal. Nothing kills creativity and interest more than running through a handed out sheet of talking points. 
5. Minutes are for recording what happened last time, not deciding what happens this time. Keep last week's minutes out of this week's meeting. I've sat in more deathly meetings where managers droned through the last minutes and asked the person responsible for each item for progress on it in turn than I care to list. Nothing useful happened at any of them. Keep the floor open, the discussion organic and raise your talking points throughout the discussion as required to keep things flowing and get the information required
6. Segueing into technical discussion is good, but only if the whole team in the meeting needs to be a part of that discussion. If your two electrical guys are arguing over details the mechanical and fire guy don't need to know, then invite them to take it outside later (see item 2 as well, did those other guys need to be in this meeting?). On the contrary, if you've got an organic team brainstorming session going on, then let it flow - only good can come out of these.

Make sure your engineers can see the meetings as productive and you'll get them more engaged rather than hiding away in a cubicle.

The Right Answer

Engineers have been trained right throughout their schooling and later studies to solve problems which have a definite Right Answer. Any solution which is not Right is Wrong. 7 x 6 is always 42, any other answer is Wrong. Unlike humanities fields where there can be a number of right answers as long as they are correctly justified, engineers have spent their formative years studying maths and science. As a result, any good engineer will have an element of perfectionism to their personality. There is no higher guiding force on an engineer than the desire to get the Right Answer, so you'll need to take advantage of this.

This manifests itself in several issues which you need to take into account when managing them:

1. Your engineers don't care if the best solution is too expensive. The best solution is the Right Answer. If you overrule them (you might have to because of commercial imperatives), you'll end up with unhappy engineers. 
2. Your engineers will want to polish the design to a shiny gloss where everything is Right. Close enough will not be considered good enough. You will need to set rigid but reasonable deadlines to stop the tinkering and actually ship your product or the engineers will optimise it forever. But these deadlines do need to be reasonable - there is nothing an engineer hates more than having to half-arse things.
3. Wherever possible, don't get between an engineer and the Right Answer. Its fine to limit the scope of the problem at the start but once your engineer has started the design, locking off options that they have spent time pursuing will make them disgruntled. The best chance you've got is to engage them on a technical level and justify why the option they are pursuing isn't available (but see point 1).
4. You can throw non-technical problems at engineers and get surprisingly good answers. This is part of why you'll find ex-engineers working in finance, commerce and other fields which need good problem solvers. Even if your engineers don't have the background, if you give them a chance to step outside their field and solve other problems which have a Right Answer then you'll be rewarded.

Managing Engineers Is Like Herding Cats

You've just been hired or promoted as manager of engineering on the back of your business and management skills. Or maybe you are a small branch manager who doesn't have any middle-management between yourself and the engineers. But these guys with poor social skills don't listen to you or respect you, even though you are managing them the same way as has built great teams before. Why?

Managing engineers is hard, especially if you don't have the technical background. Engineers think differently and have their own hierarchy which doesn't respect the orthodox chain of command. This blog will teach you how engineers think and how you can get the best out of them. Posts targeted at you are tagged manager, but reading the other side will help you understand where your colleagues are coming from.

Equally, you are an engineer who has run out of technical promotions and has thus found his way into management. You've gone from being primarily focused on technical problems which you can solve yourself to having to rely solely on the work of your other engineers. A role where your people skills are more valuable than the technical ones which earned you the position. How do you make this transition?

Managing people needs a completely different toolset to what you have learned so far in your career, especially if you are to make the most of the opportunity. And now you need to navigate the political waters of upper management as well if you are to get the right resources for your team. You could go get yourself an expensive MBA, or you could read this blog. Posts targeted at you are tagged engineer, but for you especially being able to see things from a purer managers perspective will be very useful too.