13 Reasons Not to Be a Manager

13 Reasons Not to Be a Manager

As it happens, over the past several years I've held the most diverse management positions at half a dozen companies developing various types of software. I've been a team lead, a project manager, a program manager, a department head, and a technical direction lead; I've had anywhere from two to a hundred and fifty people reporting to me, and company sizes varied from three to two hundred thousand employees. Only one thing remained constant: purely managerial work, a gradual and final departure from technical tasks.

And now, in the period between Christmas and New Year's, when the tendency for deep reflection is particularly acute, comes the understanding that had I known certain "insider" details about management work in advance — I would have made a completely different choice about seven years ago.

That's why this somewhat chaotic and very mixed-caliber list of points was born, which I'd very much like to send back in time to about 2005 — let me know if someone has already figured out how to do that! In the meantime, perhaps someone will find some of the points listed below not entirely obvious, or even useful for themselves; it would be nice to know that I helped someone make a more informed career choice — or simply think about something important.

1. It's a Dead End

Funny as it may sound, one of the reasons I originally transitioned from technical to management work was precisely that notorious "glass ceiling" — the explicit or implicit limit to financial and career growth that every developer sooner or later begins to notice. It seemed that I just needed to abstract away from technologies, free myself from the need to almost completely switch to something entirely new every two years, and I could take one specific skill — say, management — and hone it to mind-blowing perfection, and then... boundless prospects await me! Yeah, right. Practice shows that it's developers who have boundless prospects: you can change technologies, try different roles on a project, you can work on staff or be a contractor, freelancer, shareware developer — or become an architect, for example. Once you become a manager, alas, you remain one forever. Having missed the next big technology shift, not getting any younger, having started a family, you suddenly realize that returning to technical/programming work will be either extremely difficult or perhaps impossible entirely — especially considering that, due to loss of currently marketable experience, this cannot happen without a significant pay cut. So the longer you stay in a non-technical position, the further the proverbial "train" goes.

2. The Glass Ceiling Returns

Yes, there's a second glass ceiling, a kind of invisible growth limiter that, from a developer's perspective, I personally didn't notice much — perhaps the "reflections" on the first glass ceiling masked it, who knows. In short, in a relatively realistic scenario — that is, without a radical industry change (for example, from IT manager to vice-president of some spherical "Gazprom" in a vacuum) and without changing country of residence — managers in software development have a rather narrow financial and career corridor in which they can "grow and develop." The ceiling consists of various directors and their deputies, who often turn out to be founders and/or co-owners of the company, or their appointees. Simply put, these are management positions you can't "grow into" — you can only "land" in them; interestingly, this applies equally to large multinational corporations, despite the fact that they actively promote themselves as free from such unfortunate deficiencies (see words like "transparency," "honesty," etc. in mission, vision, values — and similar texts).

3. What to Do?

Despite the pomposity of the subheading, this isn't about philosophical matters but about a very concrete question — what should a manager be doing from 9 to 6 on a workday? For technical specialties and positions, this is more or less clear and well-defined: people analyze requirements, write programs, test them — lots of different things. Transitioning to management — especially after a fairly long existence in the "engineering" Universe where everything is relatively well-defined — you inevitably face a staggering lack of understanding of what exactly you're supposed to be doing all day. If there is any documentation on the subject, a job description, it's usually extremely vague, non-specific, and overflowing with stock phrases and terms that have long since lost all meaning from overuse, now fit only for "bullshit bingo." But usually there isn't even that! Moreover, attempts to clarify at least the high-level goals of your management activities meet the same stream of undecipherable empty words: ensure, establish, support, achieve, create, etc.

4. Time Crunch

As soon as you land in the smallest management position, people start running in from all sides who need nothing — except a small portion of your time. After a couple of weeks, you discover that over 80% of your weekly work time is scheduled for various meetings and phone calls/conferences, and ultimately there's absolutely no time left to prepare for those very meetings even a little. This is exhausting. No matter what you do, you always end up being the one who either didn't make it in time, or didn't prepare, or both... and there's probably no way out — at least, I've seen people living in this mode for years, and they hardly chose this lifestyle consciously. But they do develop a bunch of adaptive mechanisms: for example, knowing that they won't be able to prepare for a meeting or work on any document after it anyway, they build that time into the meeting itself. So you end up spending all day in two, three, four-hour meetings where up to a dozen people are present, 90% of whom have no reason to be there. But just try not showing up! And one fine day you catch yourself marking lunch time in Outlook as another meeting, because otherwise you simply won't get to eat — fellow managers will devour your entire day. Like what happened last week.

5. Fragmented Day

It's no secret that for any knowledge worker — for example, a programmer — productive work requires "two F's": focus and flow. That is, the ability and opportunity to concentrate on the work that needs to be done, and surrounding conditions that support maintaining that concentration for a reasonably long period of time. It's no secret that every episode where something (a phone call, a conversation, just a loud noise outside the window) rips you out of the "flow" of concentrated work costs approximately 15 minutes — that's how long it takes to get back into that flow of concentration. That's exactly why developers and engineers so dislike calls, emails, "pings" on Skype/messengers/ICQ... and when you cross over to the management side, your workday suddenly starts consisting of 80-90% of such interruptions! Meetings where you're sneaking peeks at the latest batch of emails, phone conversations on the way from one meeting to another, and colleagues who always need something urgently, right this second! And while you're getting to the bottom of the issue, three more emails have landed in the inbox, two more missed calls have appeared on the phone, and you realize that the time you'd set aside for lunch has just ended — and the next meeting is in four minutes. And if, despite point 3 on this list, you realize you need to do some concrete, tangible work — say, write a document, slides for a presentation, or draw a diagram — finding any reasonably long uninterrupted period of work time is simply impossible!

6. Unlimited Working Hours

Actually, the existence of meetings filling the entire workday (see point 4), incoming correspondence in quantities sufficient to fill that same wretched day (see point 7), as well as the periodic need to actually do something real, leads to regularly finding yourself working from home in the evening, staying late at the office. Interestingly, this state of affairs is considered perfectly normal! For instance, at one company where I worked, overtime was paid to technical specialists without question at double the rate, but not to managers. That is, everyone knew that constant overtime was happening and was unavoidable — they just didn't pay for it! So it turns out that under certain conditions, a developer's income can easily exceed that of their direct supervisor. Another example: at one company, a developer's off-hours were sacred, but scheduling a meeting for half a dozen managers at 8:00 PM was just normal practice and a regular occurrence. The bottom line — suddenly, your personal non-working time no longer belongs to you; since the entire surrounding management "crowd" considers this situation normal, there's no painless way to "get off the hook" — only at the cost of permanently placing yourself on the list of the "disloyal," "unmotivated," or simply lazy scoundrels...

7. Inbox Overflow

Back in the days when I was quietly and peacefully doing development work, I'd get about half a dozen emails a day. Each one immediately received my undivided attention, was carefully read and replied to as quickly as possible — that was proper, good, and it created the feeling that I'd done everything in my power to help others successfully do their jobs — answered questions, forwarded materials, etc. But when you get subordinates, the number of daily incoming emails starts growing very quickly. Mine stayed around a hundred for months, which leads to rather unpleasant consequences: even deploying every possible email client "trick" — filters, folders, labels, etc., even applying all the wise and not-so-wise time management techniques, even spending evenings in Outlook at the expense of family and rest — there's still absolutely no real way to even thoughtfully read all the correspondence, let alone write meaningful replies to everyone. The net result is a steadily growing number of various "screw-ups" (emails sent to the wrong people, about the wrong things, or written wrong, forgotten attachments — and other things in the same vein), a pile of low-priority and non-urgent emails growing beyond even theoretical "clearability" — resulting in forgotten tasks, broken promises, and also the nagging feeling that you're not managing your incoming mail — rather, it's "managing" you. Chewing you up and spitting you out.

8. Pure, Unadulterated Responsibility

In management circles, they love handing out responsibility for things. This is typically done with enormous pomp, presented as an incredible positive and a great happiness for whoever receives such responsibility, but there are a couple of catches. First, refusing such happiness is practically impossible — at least without being placed on the list of disloyal, ungrateful saboteur-scoundrels. Second, virtually no details are ever communicated about what exactly you'll need to "answer for" (see also point 3). It's obvious why: the entire ritual is essentially passing headaches from higher-level managers to lower-level ones, and this passing happens either because the thing being passed "smells bad," or because the original happy "responsible party" simply didn't get around to figuring out what it even was. Sure, they didn't have time — it happens, but admitting that is out of the question, right? Third, of course, responsibility is handed out only in its pure form — that is, without any authority or resources that would allow you to actually influence the situation you're accountable for. Essentially, it's a veiled appointment of someone to blame for an inevitable future "screw-up," and the appointee is expected to weep with pride at being chosen. The result? The familiar feeling that there's even more to get done, even less time, meaning has completely evaporated, and failure is inevitable.

9. No "Not My Job"

What happens if you ask a developer to, say, mop the office floor? They'll twirl a finger at their temple and explain that it's not their job, and accordingly won't do it — and this will be perceived as completely normal, because everyone understands what a programmer's job entails, and therefore it's very easy to determine what it is not. Well, it was a huge surprise to me that in management circles, this isn't the case! Since management itself (as a specialty, a profession) is something murky, fuzzy, highly dependent on the organizational context where everything is happening, which context typically remains undefined (see point 3), managers have virtually no ability to say something is not part of their duties — without (of course!) another entry onto the list of unreliable traitors undermining the very foundations of the company. As a result, the average manager periodically finds themselves buying office furniture, searching for employees, writing marketing materials, and a bunch of other things that resist any coherent categorization. Simply because... well, you can't bother the developers with this, can you?

10. Spectacular Cast of Characters

In the early 1990s, when I was at university, there were 4 groups of us programmers. Running parallel with us, 19 groups of economists and managers were gnawing at the granite of knowledge, and it would be naive to assume they'd vanish from the face of the earth upon receiving their diplomas. Surprisingly enough, they all went off to work somewhere, and some portion of them ended up in organizations developing software — naturally, not in programmer positions! These folks, by definition smarter and more cunning than everyone — they go straight into management. How and why people with zero experience and a "whatever" education, but with the coveted letters "MBA," are hired for management positions of any significance — this remains beyond my humble understanding, but the fact remains: while it's quite difficult to encounter a random person among developers (at minimum they can tell an interface from an abstract class), among managers it's easy! Hordes of people with bizarre work experience and no useful skills chaotically migrate from selling laundry detergent to software development, while sincerely seeing no difference — what does it matter what you manage? Accordingly, they have neither the time nor the desire to understand the intricacies of the industry — they're building careers, which is in fact their primary and sometimes only true "specialization." So, having suddenly found myself in this charming circle, within a couple of months I personally witnessed such a quantity of brazen lying, backstabbing, hysterics, cunning power-grab schemes, "friendship against" alliances, and various coalitions — in the previous ten or so years of non-management work, I hadn't seen even half as much! In short, the management layer has its own special, incomparable atmosphere; some will be like fish in water, while others may very quickly find it very, very disgusting.

11. Reporting Food Chains

A colleague of mine coined (or borrowed from somewhere) an amusing term — "reporting food chain." This is when the big boss demands some report and gives instructions to lower-level managers, who in turn start pestering their subordinates and demanding some data from them, and those — run to their subordinates... and so on. A chain (or more precisely, a tree) forms of people and their actions, the end result of which is some colorful report for someone very important, and such a chain can pierce through all levels of organizational hierarchy, right to the bottom. Needless to say, three or four levels below the big boss, nobody's even trying to understand why all this commotion was needed in the first place. What's more curious is this: in large organizations with multiple management levels, parasitic elements inevitably develop — managers who do nothing but participate in one or more such chains. Formally they may hold some very impressive-sounding title, but in essence they're in hibernation until awakened by the start of data collection for one of the reports that traditionally passes through them. At that moment, it's best not to get in their way: understanding that these little reports are the only thing justifying their existence in the organization, these folks will sweep away everything and everyone on the path to their precious figures and charts! They'll halt critical projects, pull important people out of teams, convene dozens of pointless meetings, create several scandals — but they'll get their precious numbers, and then — back into hibernation. The only thing scarier than getting in the way of such a data collector is permanent integration into the reporting chain at its very last stage — which is often exactly what happens to newly minted, inexperienced managers; the unfortunate soul who gets caught can expect endless tables of numbers nobody needs, which absolutely must be obtained by such-and-such deadline, or else...

12. Warm Human Interaction

According to PMI (Project Management Institute), a project manager typically spends about 90% of their working time on "communication" — that is, interacting with others: in person, by phone, by correspondence in one form or another. This may sound funny and naive, but it seems to me that this is a whole lot. Before the start of my active management career, I led the ordinary quiet life of a typical introvert programmer, who much preferred "interacting" with a computer rather than with colleagues. So I couldn't have imagined what such a quantity of communication with different people, without a break, day after day, could mean for me personally — it's catastrophically exhausting. Ideally, you can effectively communicate with about a dozen people — keeping in your head the entire history of relationships with them, remembering all promises given and received, knowing what interests whom and what drives them. When there are more people around you, the quality of communication predictably drops: a couple of dozen — you inevitably start losing useful information, fifty — you can barely keep in your head even people's names, their faces, and who's currently doing what, and if the number goes past a hundred, then... I don't know about others, but I couldn't even memorize the names of all my subordinates, and communication with them turned into unending torture, a parade of awkward moments and strained attempts to remember whether this was the guy who asked me something last week, or whether he just started here on Monday. Very soon I discovered that I'd begun simply hiding from colleagues! During those rare minutes that happened to be free from meetings, I preferred to be anywhere but at my desk, where subordinates could find me and (horror!) start yet another conversation, about work or otherwise. But there's a positive side too: I understood why, in my developer days, it was always so impossibly hard to "catch" my boss somewhere, let alone discuss something urgent with them!

13. No Longer One of Them

In any work team, certain social circles form, and if a team member isn't a complete hermit, they'll participate in at least one. This isn't about family friendships and weekend picnics together; it's much more prosaic — exchanging a few words about nothing, joking about management, clients, sending or receiving a link to something funny... these tiny particles of something not entirely work-related provide a break and keep you from going crazy during any given workday. However, as soon as you go from senior developer or team lead to some kind of manager — even a project manager — you begin to slowly notice that when you appear at the coffee machine or in the smoking area, lively conversations go quiet, the tone and/or topic of conversation changes, and then you accidentally learn that besides the official project chat somewhere in Skype, there's also an unofficial one for jokes and banter. Only they forgot to invite you; and at that moment you realize that for the team, you're — no longer quite one of them. And the moment you have the power over hiring, firing, and salary decisions — you become completely not one of them. It seems the issue isn't about the individual or the team; it's just a standard dynamic that exists, and changing it would be quite difficult — if possible at all. However, the net result is yet another negative factor actively affecting the psychological comfort of the newly minted manager...

That's all that came to mind off the top of my head. And a baker's dozen is probably the most fitting length for this list.