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.