Hi there – this is a follow-on to my previous “How to Get and Keep a Job” question (https://www.embeddedrelated.com/thread/12258/how-to-get-and-keep-a-job).

As a continuation to my miniseries of columns aimed at young engineers (or wannabe engineers) about "How to get and keep a job" – these columns are currently in progress – I’m planning on adding one or two additional columns under the banner “So, You Want to be an Engineering Manager?”

This is in the context of being an engineering manager. Of course. In this case, any thoughts you have on what makes a good manager, what makes a bad manager, what you need to do if you want to evolve into a management role, etc. will be very much appreciated.

My boss back in my Toshiba days was a good example of an excellent engineering manager. I even wrote an example of his style here:

https://covemountainsoftware.com/2016/11/07/it-mak...

Basically:

• Hire the best people you can find.
• Support them. Get them the best tools and equipment you can (the point of the blog above)
• Shield them from as much corporate bureaucracy as you can.
• Set high level goals and standards, and then get out of the way.
• Be willing to fire bad apples. This isn't easy.

Hope that helps! Looking forward to seeing the article!

Best regards,

Matthew

https://covemountainsoftware.com/services/

This is great input Matthew -- I've seen some great managers and some awful ones in my time -- I will let everyone know when these blogs are posted -- Max

All excellent points, to that I'll add delegate, observe, review, Don't micromanage or interfere. Be open to different approaches, neither accept nor reject, but collectively evaluate. <<<)))

Good feedback -- thanks CustomSarge

Well, there is saying, that excellent engineers usually become not so good managers. Mindset for an engineer and a manager is not the same. Does anybody think opposite?

I've not heard this put quite this way -- but there is the Peter Principle -- a concept in management developed by Laurence J. Peter -- which observes that people in a hierarchy tend to rise to their "level of incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent.

There's also the Dilbert principle, which states that companies tend to systematically promote incompetent employees to management to get them out of the workflow.

There's a quite interesting book on the subject. It's old, but still, every bit of it still stands. It's "Peopleware" by Timothy Lister & Tom DeMarco. It is definitely worth reading.

And, of course, there's Dilbert: just do the opposite of what the PHB does :-)

Ah, Dilbert -- Scott Adams is a genius!

Hi, Max Maxfield!

I would advise reading Dilbert's comic strips to know what absolutely NOT to do!

I love Dilbert cartoons -- I'll add this comment about using them to learn what not to do into my column :-)

BOOP, somebody dropped the "r" from "Engineering"...

Frig!!!  And for some reason I can only edit the original post, but not the title of the thread -- give me strength!!!  I'll email Stephane at EmbeddedRelated and see if he can do anything from his end -- thanks for spotting this (said Max, ruefully)

Stephane added the missing 'r' back on -- phew!

I'm completly all right With the five points.

Cheers

All the points are valid but Assume that your employer is resource rich and large enough to employ a manager as just that. My title is “Engineering Manager” of a small organization and I will be the first to admit that I am not a very good one. 

About 20% of my time is management. The rest is engineering. I don’t have a budget to employ the best engineers, educate the ones that are employed or supply them with the new and/or best equipment even if it essential for a project. 

Nor is there sufficient autonomy where I can cushion my guys from the boss, or have my recommendations for pay increases accepted.

Utopia is hard to find.

The main thing is that you're having fun LOL

All the points so far are what it takes to be a good engineering manager from the perspective of the engineer. There are other aspects:

1. The manager must be able to listen and help resolve an engineer’s problems, both professional and personal if necessary.

2. The manage must resolve inter and intra departmental disputes.

3. The manager must be able to evaluate the engineer’s performance objectively despite personal emotions.

4. The manager needs to be able to differentiate between initiative on the part of the engineer and a waste of resources.

5. The manager must understand and impart corporate policy, strategy and decisions (if discernible!)

6. The manager must understand what standards apply to a design (including documentation) and somehow find a way to enforce them.

7. The manager must be able to resolve the responsibility delegated to him with the lack of authority to implement upper management’s desires.

8. The engineering manager must be able to understand and negotiate with upper management about project costs, delivery, employee performance

9. The manager must be able to make presentations, both spoken and written, to upper management about department performance, budgetary requirements etc.

This is "Golden" -- thanks so much Aubrey -- Max

Another thing- as a manager you are accepting responsibility assigned to you by professional and government agencies. For example in Ontario the manager is responsible for ensuring health and safety regulations (like safety shoes, safety glasses, chemical identification etc. Etc.) are followed. If some incident happens as a result of failure to enforce the regulations,the managers could be in deep doo-doo

Another really good point -- so remind me, why do people want to be managers LOL

Indeed, Thanks for view from the other side! I think it points out the "a good engineer rarely makes a good manager" principle. Good engineers usually don't possess great interpersonal skills - it's part of what makes them gravitate to objects / toys etc.  Whereas a manager is just the reverse - people skills are paramount.

I used to think my manager had to know most of what each of was working on. I'm now that they just have to have a good BS detector for those under them.

I'll give another vote for "Peopleware", and right along with it, Fred Brooks' "The Mythical Man-Month", 20th anniversary edition.

I briefly mentioned these in my blog post Review: Clean Agile, by Robert C. Martin, and More Effective Agile, by Steve McConnell.

People repeatedly make the mistake embodied in Brooks' Law: Adding human resources to a late software project makes it later.

Even now, a quarter century after his 20th anniversary edition, we make the same mistakes, over and over. We simply refuse to learn the lessons of the past. As George Santayana said: Those who do not remember the past are condemned to repeat it.

I would hope an engineering manager would have read these books and taken them to heart, even if they don't agree with everything in them.

Hi there -- thanks so much for taking the time to share this feedback.

"Oh, I wish I were a manager of software,

That is what I truly want to be,

'cause if I were a manager of software,

Everyone would be in love with me!"

CLASSIC!!!