feature article
Subscribe Now

Managing the Middle Manager

An Engineer's Guide

Middle Manager makes his way through the maze of chest-high walls, passing members of his team as he plans his morning, pausing a couple of times – pretending to understand what he’s watching as he peers into cubes where startled engineers suddenly switch from doing real work to doing things they think will look more like real work. This daily double-ended dance of deception lasts only seconds. Middle Manager moves on down the corridor, hoping to hear a hint of the mood in executive staff as he passes the cracked conference room door.

Electronics Engineer puts down the dated databook he was pretending to consult and pops the chat window back up on his monitor – the one where his best friend (working at a competitor’s company) is explaining the basics of pre-emphasis in high-speed serial transceivers amidst intermittent discussion about the next night’s basketball game.

Software Engineer relaxes back into his chair, closing the debugger window. He was faking it. He had been waiting for almost an hour for the build to complete when Middle Manager walked by. The debugger window was just big enough to cover the web browser with the aviation weather site up. He had been planning his afternoon flight when he heard Middle Manager’s signature key-jingle echoing down the hall.

Middle Manager can’t actually communicate with the Engineers. There is an impedance mismatch. The required coupling capacitor sits in the last cube on the end – the bigger one with the “door.” Team Leader knows what goes on in the cubes, and he understands Middle Manager’s world – to some degree. He bridges the gap between Middle Manager and the Engineers. He insulates the Engineers from the organizational chaos in the management levels as he consolidates and conceals the sometimes distasteful details of the process of creating real technology from Middle Manager – providing a scheduled, sanitized upward view of the design process that exists only in slides and spreadsheets.

Laurence J Peter postulates that Middle Manager may actually be one of our peers, promoted to his or her level of incompetence and now moving among us as a technological phantasm – an apparition whose engineering skills have become dated and whose lack of bureaucratic and business acumen have left him in a sort of professional purgatory where he is unable to move upward into the elite executive row, yet ill-equipped to rejoin the ranks of real, working engineers. According to Peter, Middle Manager’s main occupation must be simple self-preservation, claiming responsibility for successes while delegating responsibility for failures down into the scores of scapegoat-ready individual contributors waiting to take the fall.

This pessimistic “Peter Principle” perspective is too jaded and cynical for the reality of today’s typical high-tech company. In most modern engineering environments, middle management adds significant value and fulfills an important need in the organization. The challenge, for us engineers, is to understand what we can and can’t expect from middle managers so that we can be effective and successful as engineers without continually stumbling on the mechanisms of management. Presented herewith is a list of basic principles for protecting yourself from middle management mishaps – an engineer’s field guide to middle management.

Principle 1) Know your MM’s type:

There are several species of middle manager, and it’s important to know which one you’re dealing with. Otherwise, you may be putting a leash on a goldfish. On one axis, there are three levels of MMs: Micro Managers, Meta Managers, and Noble Gasses.

The Micro Manager is actually a Team Leader in disguise. He’s still an engineer in his head, and (also in his head) the purpose of all those people who report to him is to give him even more fingers to type with. The problem is, your fingers don’t always do exactly what he wants. Be very, very careful with the Micro Manager. If you don’t do what he wants, you’ll get blamed. If you do what he wants and it doesn’t work, you’ll get blamed. The best strategy is probably to do what needs to be done to make the project succeed, tell him you’re doing it his way, and hope for the best.

The Meta Manager doesn’t want to control your fingers. He’s actually the best case scenario. He’ll provide your team with broad-based goals, and then work with upper management to be sure you have the resources and support you need to reach them. He’ll give you credit for the good work you do and defend you when things go wrong. You can be honest with the Meta Manager and have reasonable confidence that he’s being honest with you. If you’re fortunate enough to have one of these – talk frequently and loudly about how effective he is and how he keeps your team productive. His success is your success.

The Noble Gas (as we learned in chemistry) sits in a cube on the right column of the periodic chart. He doesn’t react with anything. He neither adds value to the process nor presents any significant obstacle to progress. He’ll take your PowerPoint slides as-is and present them to upper management, then dutifully bring upper-management’s redeployment package in to present to you. The Noble Gas’s primary motivating factor is fear. He doesn’t understand what you do, and he doesn’t understand what the company does. He is terrified that someone will find out, so he is extremely careful not to rock the boat – or to steer it – or to row it. His primary purpose in the boat, in fact, is to act as ballast. Ignore him and do good engineering work.

Principle 2) “They” don’t have a plan for you:

Many an engineer has walked into a middle manager’s office, closed the door, and said, “I’d just like to know what my future is like with this company.” Usually, the real answer to this is “none.” The company doesn’t have a plan for you, and your middle manager almost certainly does not. If he knows what he’s doing, he’s got a plan for himself. The only person that’s likely to have a career plan for you is you. If you spend a lot of time wondering what “they” have planned for you, you’re likely missing the boat (not the one that the Noble Gas manager is in, however). It’s up to you, not your middle manager, to forge a career path for yourself. The presence or absence of a promotion path for you doesn’t mean you’re in a dead-end job. It means you’re not taking charge of your own future.

The better question to ask your middle manager might be something like “How do I get to be [insert your personal next desired role here].” A good middle manager will appreciate the chance to advise you on how to achieve a specific goal within his or her organization and will see the question as a sign of trust. The fact that you have a plan mapped out for yourself and you’re seeking counsel is a sign that you’re engaged, empowered, and energetic. Just asking the question will usually help your career.

A corollary to Principle 2) is the “no men in white labcoats” principle. Engineers frequently make design decisions based, not on their own best judgment, but on some ill-conceived perception of what they think “management wants.” Often, these ideas are forged from fragments of overheard conversations or misinterpretations of comments made by middle managers in meetings. In truth, middle management is often ill-informed on the subtleties of engineering tradeoffs. There are no men in white labcoats wandering piously through marble hallways and seated in ivory cubicles divining comprehensive technical strategies, and then embedding these in cryptic messages that are passed down through middle management to working engineers. The person best qualified to do your job is you, so don’t second guess yourself by trying to read tea-leaves in e-mail broadcasts. Make good engineering decisions, communicate them, and follow through with solid design work. Middle management will be proud.

Principle 3) Use the Team Leader

As we said before, your team leader is the best bridge between you and middle management. Learn to take advantage of that connection. Support your team leader and make him or her successful, and you’ll be pulled into that success as well. An engineering team is (to triple-overload a metaphor) a boat that sinks or floats as one. If the team and the project succeed, there will be reward for all. If the project fails, the whole boat sinks. A “your end of the boat is sinking” attitude is usually a short-lived strategy that ultimately leads to failure.

Usually, the worst thing you can possibly do is to take your issues about details in daily engineering directly to your middle manager without working them out thoroughly with your team leader first. The typical middle manager is a frustrating audience for such concerns because you’ll usually be putting him in a position to defend decisions he did not make, and possibly does not even understand. If he’s supportive of your team leader, you’re only making yourself look bad. If he’s not, you’re helping to further sink your own team’s boat. When that boat sinks, the middle manager won’t remember to exempt you because you jumped out first. Either way – it’s a bad idea.

Middle Manager management is not a skill to be taken lightly or ignored. If you’re in any organization with a triple-digit (or larger) number of people, you’ll be a part of a hierarchy, whether or not you want to participate. By and large, that hierarchy functions well at its intended role – making the company successful. Whether it also serves you well depends on your own level of awareness and how you balance self- and career- interest with providing the highest-quality professional service you can. Engineering school trains and disciplines us to solve difficult technical problems. The social and political challenges of working in a large organization demand a similarly savvy approach.

Leave a Reply

featured blogs
Jul 6, 2020
If you were in the possession of one of these bodacious beauties, what sorts of games and effects would you create using the little scamp?...
Jul 3, 2020
[From the last episode: We looked at CNNs for vision as well as other neural networks for other applications.] We'€™re going to take a quick detour into math today. For those of you that have done advanced math, this may be a review, or it might even seem to be talking down...
Jul 2, 2020
In June, we continued to upgrade several key pieces of content across the website, including more interactive product explorers on several pages and a homepage refresh. We also made a significant update to our product pages which allows logged-in users to see customer-specifi...

Featured Video

Product Update: New DesignWare® IOs

Sponsored by Synopsys

Join Faisal Goriawalla for an update on Synopsys’ DesignWare GPIO and Specialty IO IP, including LVDS, I2C and I3C. The IO portfolio is silicon-proven across a range of foundries and process nodes, and is ready for your next SoC design.

Click here for more information about DesignWare Embedded Memories, Logic Libraries and Test Videos

Featured Paper

Cryptography: A Closer Look at the Algorithms

Sponsored by Maxim Integrated

Get more details about how cryptographic algorithms are implemented and how an asymmetric key algorithm can be used to exchange a shared private key.

Click here to download the whitepaper

Featured Chalk Talk

LPC5500 MCU Series

Sponsored by Mouser Electronics and NXP

Security is key in today’s edge designs, but where to start with designing-in security? Ad-hoc security strategies are recipes for disaster. In this episode of Chalk Talk, Amelia Dalton chats with Brendon Slade of NXP about the powerful new LPC5500 series of MCUs from NXP that have great performance and security designed in from the ground up.

Click here for more information about NXP Semiconductors LPC5500 Series Arm® Cortex®-M33 Microcontrollers