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.
