News Flash: Programmers and Managers Don't Get Along Perfectly
Pull up your favorite aggregator of programming and software-project content, and do a quick survey: what percentage of recent articles are in some way about bad managers, dealing with management, how to appease your developers, how to stop being a bad manager, etc. ad nauseum? For a fun variant, what percentage of the "all time hits" fall into that category?

If your aggregator happens to look like mine (or Joel's), I bet the percentage is very large.


Now, presumably, since you're here, you have some aspect of the geek nature. (If you don't, this blurb isn't for you, so you may find it confusing and weird and possibly a bit frightening; you've been warned.) When confronted with an interesting statistic, like "a lot of people are churning a lot of words about programmers and management", any good geek should toggle the curiousity bit and ask the all-important question: why is this so?

This is by no means a recent trend; very wise people have been writing really good stuff for, quite literally, decades. More recently, we've given over to assigning icky words (like "immaturity") to the situation.

You don't have to read very many of these writings (old or new) to notice something telling: they all say pretty much the same stuff. The obvious conclusion is that the situation has, by and large, not changed tremendously over time. We can think of lots of icky tags, but not solutions.

So, we have two points: there's something of a tough situation, apparently, regarding programmers and management; and this situation has more or less not gotten cleared up in the past decades of growth and maturing in the software industry.

We can posit a few explanations:

1. This is a fundamental problem of human nature and will never go away


2. This is a fundamental problem of human nature but some combinations of people will be OK


3. This is an artifact of a comparatively very immature industry and will change over time


4. Someone's gone and buggered something up

Let's look at these in turn. There is anecdotal evidence that programmers and managers really can co-exist. (I've yet to see this myself, but I've decided to think of it the same way I think about Africa: just because I haven't been there doesn't invalidate the compelling evidence that it really exists.) That rules out option number one and possibly adds a point to number two.

For the sake of ruling out number two, let's invent a fictional situation where someone beat the odds and actually changed things properly. It's apparently very difficult but more or less plausible, so we'll fudge a bit and say it could happen.

Number three sounds good on the surface, but there really isn't much substance there. On a cosmic scale, yes, software is a very new thing, so naturally it's got some rough edges still. But the problem isn't actually software - it's human interaction, specifically between managers and programmers.

We can rule out number three with a careful study of ancient history. Go rent a copy of 2001: A Space Odyssey and watch the ape-man scene carefully. You will note that some of the ape-men seem to be in charge and have some initiative; these are the ancestors of what have become modern managers. Other ape-men in the scene are clearly the thinkers, who pore over hard problems and eventually find the all-important solutions (the star of the bone-smashing scene). These are the precursors of geeks and programmers. By this, we see that geek-types and manager-types have had, at the very least, a few thousand years to sort out their differences, and the fact that they have as yet failed to do so means it's probably not going to happen by itself any time soon.

In any case, managers-vs-engineers has been going on in some form for a long time, so point number three crumbles: the young age of the software industry is no excuse. I'll wager a beer that Michelangelo had some anal-retentive monk chew him out for taking so long on "that bloody ceiling... how hard can it be to paint a few square feet of scenery, anyhow?" - and another beer says that, if he had the means, he probably would have written a bitter blog entry about it and submitted it to The Daily WTF.


So, we're all out of options... damn, I guess this problem has us licked. We'll all just have to go back to work on Monday and quietly die a little bit inside, knowing we'll never resolve the programmer-manager disparity.

What? Option four, you say? Ridiculous! Nobody's screwing anything up... well, the managers are screwing things up, because they can't manage our projects right... but surely if anyone is at fault, it can't be us, the programmers.


Clue-by-four, incoming.


Why the Programmer/Manager Problem is Our (the Programmers') Fault
Consider the roles of engineers and managers. Programmers make stuff happen, and managers cause as much pain-in-the-arse as they can ... well, managers manage. God only knows what they really do; I tried to read one of those "management guide" type books once, and all the suit-speak gave me a nasty seizure. I try not to think about it.

Typical programmer snobbery aside, managers work with people. This is such a horribly abused and decaying cliche of a phrase that I feel vaguely ill for even bringing it up, but it's the truth. The role of managers is to interact with their team, and keep things running smoothly.

The core of this is vitally important, so I'm going to emphasize it: managers already, as a daily course of action, have their priority on interacting with other people. This is documented at great length, and the aforementioned brain-traumatizing books on management all handle a relatively ubiquitous issue: how to deal with people. By itself, this is no particularly shocking revelation. However, the implications are profoundly critical to understanding the problem.

Since managers, by definition, are in the business of working with people, any failed interactions between a manager and his team must be the result of either managerial incompetence, or the fault of the other party/parties involved. Although managerial incompetence is certainly a real issue in its own right, it is not sufficient to explain every case of programmer/manager friction.

The conclusion is plain. Unfortunately, it's uncomfortable and deeply painful for us programmers to hear. We want to deny it - and, I believe, we've been actively burying the inner voice for decades.

We don't have manager-problems because too many managers suck at dealing with programmers. We have manager-problems because too many programmers suck at dealing with managers.

At this stage, I'm envisioning my imaginary blog-audience rising as one, surging towards my imaginary blog-podium, waving little notepads and yelling questions like journalists in the press conference on Doomsday. The excuses pile up. I recognize many of them because I've read them in countless places. Worse, I recognize a lot of them because I've used them myself.

• My manager just sucks


• Software is hard/an art form/a craft/not empirically measurable


• Programmers tend to be introverts anyways so it's OK if we suck at dealing with people


• I've stopped caring (usually arrives in the form of "only naive newbies in the field care, and you can't fix it so grow up and deal")


• Our domain is really special/extreme/hard and so your advice doesn't fit my case


• I tried to implement change but my manager shot me down


• If you can't change your organization, change your organization (i.e. if you can't fix your job, get a new one)

None of these excuses is false. That's why, for so long, we've been content to accept them, tell that little inner voice to shut up, and gone back to work. Sometimes the voice needs a little bit of alcohol to keep it quiet, and every now and then the tension becomes critical and we have to go and write blog entries about how organizations are immature and project managers are glitches in the system.

However, true as these things may be, they're rather piss-poor reasons to avoid the real issue. Defeatism ("my manager sucks/I'll just change jobs") gets us nowhere, and sometimes isn't even really practical (poor job markets, for example). Yes, software is hard, but we don't need to try and make it easy - the solution lies elsewhere (I'll get there in a moment). Yeah, maybe you got smacked down for trying to change the system, but a nice frosty pint says you can try it again, with a different tack, and probably see some success. And I work in one of the most notoriously bad industries for programmer/manager friction, so when I say the problem is not insurmountable, just save us all a lot of time and believe me.


The Solution: a.k.a. Fix Yourself or Quit Whining
OK, fine... maybe we are the problem. Maybe there's something we can (or should) be doing differently to make our managers understand us. Let's get pragmatic so we can brush the whole last 30 years of agony under the rug and nurse our wounded egos in quiet solutide.

• If your manager doesn't understand you, it's probably not because he's dumb.
  This is not something most people enjoy being told, but the sooner we accept it the better things will be. I've always been a notoriously poor communicator, and still am rather bad at it. However, if there's one piece of advice my father really drilled into my head, it's that all the brains in the world don't mean a damn thing if you can't explain yourself to anyone. Next time you're in one of those miserable four hour meetings about why the schedule has slipped, think this quietly to yourself, take a deep breath, and start from the beginning.
  
  Each manager will be different; some can understand technical details, others can't, and still others think they can but really can't. Learn which category your manager falls into, and deal with it. Put yourself in his shoes and make a concerted effort to see things from his point of view. Now explain your situation from that perspective. Sounds like a dumb team-building-camp cliche, but it works.
  


• Install a bullshit-propagation limiter.
  Never, ever, ever, ever lie to your manager. Ever. I know this goes against the very deep grain of common sense, that says that the professional world is a political one, and you can only survive with a healthy dose of tact. Tact is good, but never let it become mistruth.
  
  This runs both ways. If you catch yourself (or another programmer) feeding bull to your manager, call them on it immediately. Do so in a friendly and non-confrontational way whenever possible, but do it. Stuff like "Erm... sorry, I don't see how that's true, can you explain your reasoning to me?" usually works fairly well. Conversely, if your manager is feeding you bull, call him on it.
  
  How you do this will depend a lot on your team culture, but there is always a way to bring up objections. Just don't frame them as objections - if you present yourself as the one at fault (i.e. "I don't understand your reasoning") you avoid putting the other person in a defensive frame of mind. Better still, you make the other person feel like they're helping you out - which, as an ego boost, is always a good thing.
  
  Just remember: if you have chronic bullshit infections at your place of work, it's because nobody is stopping it from propagating. It's your responsibility to call bull when you see it - often, your manager doesn't realize it's bull, especially in technical matters.
  


• One half-assed solution is more welcome than a dozen well-specified problems.
  This is rather backwards to us. Among my engineer friends (software and otherwise), we have a running joke: the worst torment for an engineer (or mathematician, for that matter) is a fully-specified problem that he can't solve. In programming, it's more or less a truism that if you can specify the problem completely, the solution is (comparatively) going to be easy.
  
  Therefore, it is tempting to present very careful analyses of problems ("our build process takes too long to do by hand every day", or whatever) to managers. We figure we're doing them a favor: by cataloging exactly what is broken and how, we're specifying the problem, and therefore we can all move forward on a solution.
  
  This is suicidal and outright stupid. I once had an exasperated boss ask me, almost word for word, "You're really good at finding problems, but can't you ever think of even one solution?" I owe him a hell of a lot of credit for that - it was a wake-up call I desperately needed, and it's formed the basis for my thoughts on the entire issue of programmer-manager relationships. As engineers, it pisses us off when someone with half the facts barges in and suggests a solution to our fully-specified problem; we know what we're doing, dammit, and quit offering your unsolicited advice on matters you know nothing about! This is a particularly serious issue in programming when one has a "hands on" style manager.
  
  However, we need to understand why managers do this: their role is to promote the realization of solutions. Problems are bad to them, and fully-specified problems are evil of the darkest kind. Managers offer half-assed, random, untechnical solutions to our code problems because that's their frame of mind: solve things. In pathological cases, this is embodied by the all-too-familiar "we have no problems, only solutions" rhetoric. We need to shut up and listen to those words carefully.
  
  Next time you have a problem, don't present it as a problem. Present a solution, even if it's a ridiculous, half-finished solution. In fact, in many cases, suggesting bad solutions can be helpful - because it will stimulate discussion. If you're good, you can then steer this discussion towards your ideal/preferred solution gently.
  


• Silent pain can only lead to prolonged misery.
  If you have problems, never let them fester. Don't let them sit around and cause morale problems. A good benchmark here is casual conversation at or after work: if you catch yourself bitching to co-workers about some problem on more than two days (not necessarily consecutive days), then you need to air the problem out with your manager.
  
  Just "shrugging it off", or "bucking up", or any other such denial-centered reaction will only make things worse. If you have an issue with a technical policy, for instance, there's a good chance your manager doesn't know it's a problem. In this case, if you just sit around and get bitter, all your manager sees is a bitter employee - and this is liable to land you in serious trouble. Instead, bring up the issue with your manager. If you deny your manager critical information about the problems in his team, you're actively preventing him from doing his job properly - and, in turn, you're furthering your own bad situation.
  
  The normal rules of tact apply here: don't call your manager out in public or in front of other people; do your best to place yourself in the "weaker" position, i.e. as the one with the problem or who needs guidance; and generally try to avoid triggering defensive reactions as much as possible. However, if you've done this repeatedly with no results, it may be time to pull your manager aside privately and apply some tough love.
  


• There is strength in numbers.
  If you have a problem that affects more than one person on the team (as most problems will), don't bring it up to your manager alone, if you can possibly avoid it. Don't present yourself as the sole squeaky wheel. This raises your visibility and is likely to make you come off as a whiny jerk who needs to get canned. It also minimizes the reality of the situation: that many people are hurting as a result of the problem.
  
  Whenever possible, approach your manager with everyone affected. Have everyone prepared to agree with you and back up your assertions. Be warned, though - some people may (sensibly enough) not want to rock the boat, and others may back out on you in the moment of truth. Employ sneaky tactics if you need to, like getting written statements/emails from people, but prove that you're not just bitching alone. Prove that you're bringing up something that is affecting the team.
  
  In many cases, citing trustworthy books and articles is extremely useful. It may seem scary to send your boss a link to a blog about bad managers - but if you can, do it. Show that this problem affects not only your team, but other teams as well. Even better, bring solutions to the table that have worked for others. This overcomes the impression that your problems are unique to the people on your team (and the logical follow-up that the team's people may need to be replaced).
  


• You probably won't get fired.
  Aside from some genuinely pathological scenarios, it's usually not a career-ending move to suggest that not everything is perfect. A common reason for inaction is fear of rocking the boat. Just remember, though, the boat is probably a lot more stable than you think - and, after all, rocking it is the whole point; we do want to solve the manager/programmer problem, right?
  


• Don't expect anyone to come to you - you're not that important.
  Don't wait for your manager to solicit input from you; it's rather rare for anyone to ask other people if they're doing things wrong. Similarly, don't expect your manager to make some huge effort to come to you and get things worked out. Never rely on "meeting half way" - always be prepared to go the full distance, and maybe a little farther. (This does not mean you should try to avoid compromising to arrive at a solution, however.)
  
  This is important for two reasons. First, it ensures the problem can't be ignored or forgotten. Second, and more critically, it shows that you are serious (and not just whining for the hell of it) and, moreover, that you are committed to fixing the issue.
  
  As a corollary, don't rely on subtle hints, subtext, or anything else. If you have something to say, be clear and explicit about it. Anything else is too easy for your manager to misconstrue or just plain write off and forget about. Always assume that your manager does not see the situation from the same perspective you do - he probably doesn't have the same assumptions. What's obvious and a natural conclusion for you will probably never enter his mind. Leaving yourself open to interpretation is an invitation to be misinterpreted.
  


• Assume your manager doesn't comprehend your job. That's why it's your job, and probably why he's not doing so good at managing you.
  This should not be a difficult stretch of the imagination by any means; it's actually almost a prerequisite to finding yourself in the situation we're trying to fix. However, your response to it makes all the difference.
  
  First and foremost, you need to make educating your manager your own personal responsibility. There are two reasons for this, one of which is likely to mean a lot more to you than the other: first, it's actually your responsibility as an employee and part of a team to keep the leadership well informed and making good decisions; managers make decisions based on the data available to them and their understanding of that data, so if you don't provide all the data (or if you don't explain it properly) you have only yourself to blame for the resulting bad decisions. This is a tough pill to swallow but it's critical.
  
  The other big reason to educate your boss is that it improves quality of life - not just for you, but for everyone else under his command. Believe it or not, it also improves things for your boss - if you succeed in improving the effectiveness of your team, he's in line to get some credit (whether or not its too much credit is immaterial). So it's in everyone's best interests for you to do this.
  
  I'm not recommending you slap your boss over the head with your favorite software engineering book or anything like that; just make sure you're clear on the realities of the situation. This may take some forcefulness - a lot of managers will instinctively assume that "this is a hard problem" is geek-talk for "I'm too lazy to work on this properly." First, apply the bullshit filter and be sure you're not inventing difficulties that don't exist. Next, stand your ground; if it's really a hard (or impossible) goal, be adamant about this. Once you establish some trust (read: once your manager learns to quit suspecting that you're lying about how hard things are) you should be in good shape.

If you don't try to fix it, nobody will.
It may not strictly be true that nobody else will fix the problems. However, if everyone expects "someone else" to come up with the fix, then truly nobody will do so. Situations can be hideously complicated and subtle; chances are there are a lot of reasons - some better than others - why nobody else is fixing the problem.

The bottom line, though, is that somebody has to be the first to take initiative. If programmers start taking the initiative to solve the management problem themselves, I fully expect that the problem will turn out to not be so insurmountable after all.