Sunday, July 08, 2007 11:07 PM
At my first job I was instructed that Sales and Marketing is the natural enemy of Development. They'll do anything to sell software, even if it means selling stuff you can't, won't, or don't want to build. But the truth is, business is driven by what customers need, not what engineers want to build. In my experience I have more frequently come into conflict with own immediate managers than with any marketing mastermind or sales rep. A good man(ager) for a dev team is hard to find. In fact, they're rare as hen's teeth.
This is because software dev managers usually come from one of two backgrounds: business or engineering.
Business-style managers, frankly, are not equipped to manage engineering projects. Software development is a highly technical, highly complex business that is full of risks you don't have in, say, a bank. Teams are made usually made up of smart, motivated, skilled, and largely unsociable individuals who don't like to be managed. Typical approaches taught to 'managers' just don't work on software engineers: they'll snicker at how lame corporate morale building activities are from behind their taped-up glasses. At the end of the day, engineers don't need to be motivated to do their jobs; they need to be coerced into working together. Micromanaging the creativity out of a dev team will just see the code base degrade and team members quit.
Managers who have come out of engineering--by which I mean, they used to do the job of the people they are managing--are often poorly equipped to manage ANYTHING. Again, we're dealing with antisocial individuals with big egos. They're proud of their intellects, but will often have low self esteem on everything else. They may believe that having been promoted into management proves their superiority over their fellows... very often a fallacious assumption. "People rise to their level of incompetence," is a much safer bet, I think. These engineers suddenly find themselves in a position of power with responsibilities they're not prepared for--and may not even acknowledge. And they don't get to code anymore, which is really what they love doing. You'll often see this kind of manager looking over his developers shoulders, criticizing their work, stopping them from doing their job because he or she has to prove that they still have m4d l33t 5k3312--while they neglect to actually manage their teams.
Like I said, software development can be infuriating for everyone, and I think this is the primary reason for it. No surprise that OFFICE SPACE and DILBERT are both set in corporate R&D environments.
B A D . M A N A G E R S
I've seen all kinds of ludicrous management decisions from both ends of the spectrum: a manager who asked us for the tightest estimate on how long it would take us to make something, then slashed the time in half to make sure we didn't slack off. A manager boasted that he liked to burn developers out and replace them. A manager who shipped a prototype, proof-of-concept hackjob, despite being told that it was for demonstration purposes only, and then wondered why, a year later, we hadn't sold a single unit. A manager who would stack the requirements list for a release as we worked through it to ensure that we couldn't get ahead, and would have to work weekends. A manager who did not understand that a task list is not the same thing as a system design, or even a requirement spec. A manager who spent a week explaining a flow chart of how a release would be preceded by QA cycles--and then became angry with the development team because he didn't schedule time for those QA cycles he harped about. A manager who wanted to fire me because I found a critical flaw in something somebody else checked in on the day before release.
I had one manager who changed the release schedule from yearly to quarterly so that he could show multiple "on time releases" on his resume. Management who had "strategy meetings" every week, but no plans for anything beyond the current fiscal quarter.
One manager that hired me specifically to do a particular job because he had nobody else had the relevant experience--and then wouldn't allow me to do the job because there was nobody qualified to oversee me. I wasn't allowed to present my own designs to the people who had to sign off on them, and mistakes made int he system that I was hired to fix were blamed on me--behind my back. So I worked on the project in my own time. When I finally showed it to that manager, he reacted by congratulating me... and then excluding me completely from any further discussion of the project. Despite the fact that I already had it working.
It's a curious mix of hubris and ignorance that makes a bad manager, whatever their background--people who believe themselves superior to those beneath them, but at the same time feel threatened by them. Who will favor cronies and bluster over the advice of more competent engineers. Corporate psychopaths and spineless ninnies in equal abundance.
I've had good managers, too, but they've been rare. They're the ones who leave you free to do your best work while helping remove obstacles. The ones who give credit where it's due and accept blame--the ones for whom the team and their work comes first and politics second. A good manager is selfless, responsible and accountable. A good manager knows who he can trust amongst his team with what task... and cultivates trust amongst everyone. It's a tough job--hell knows, I wouldn't want to do it.
Not all development woes are the fault of bad management, of course, although it is the responsibility of management to mitigate them. A lot of problems come from the organization above... but plenty of them are caused by those of us shoveling coal.
Next up: Bad.Devs.