The Fallacy of Management

In case you missed Gates VP’s comment about The Fallacy of Management on my recent post Q & A on Leaving Management for Development, I’ve re-printed it below:

===

I have a working theory that I’ve titled The Fallacy of Management.

The basic definition is that current managers would have us believe that the work they do is the very reason for project success and therefore they believe (and have convinced others) that their’s is the most important role.

The real truth is that most managers are just overhead, projects would likely self-assemble without them, especially with good devs on the job. However, companies do things like targeting management for bonuses and taking other steps to make management a “position of privilege.” The truth is, good managers don’t deliver projects on time, good programmers deliver projects on time and managers just guide the process.

The concept of “separate streams” begins to address the problem of Technical Expertise vs. Managerial Expertise. But it’s also an industry thing. “Similar” professional industries, like engineering or accounting, all have a kind of set progression chart from grunt to project manager. Most current “managers” don’t actually recognize the difference between our and the engineering field, let alone begin to address the number of engineering project managers who probably shouldn’t be there anyways.

It’s the Peter Principle + poor management + uncertain staff (like yourself at times) that allow the whole vicious cycle to keep turning. Every once in a while, people get off the cycle (like you), but right now we’re still early in the game and there are more people hopping on the bike rather than off.

In 10 years, people will know better, the industry will mature (a little) and the Technical / Managerial divide will be well-documented. There’s a trend right now that’s dividing the industry and that’s the “Great Development Houses” vs. “The Body Shops.” Expect that the former will pick up on (or has picked up on) this divide and that they’re capitalizing by hiring the right people into the right positions.

===

[Rob]: Gates makes several excellent points, and I hope he continues to flesh out this theory.

While I agree with most of what’s said above, I have to chime in that a good manager is more than overhead. I’ve worked with managers who made a real difference on our projects, including motivating and rewarding the team, removing political obstacles, and removing the crappy tasks from our plates so we could produce. While most managers could be considered dead weight, a good manager can be invaluable.

Secondly, I question whether 10 years will make a difference in the cycle of developers moving into management. This cycle has a lot to do with figuring out your strengths and desires as a professional, and I think each person needs to go down this path for themselves.

After all the writing I’ve done on the joy of coding and my two trips to management and back, a developer friend of mine has decided to get his MBA so he can go into management. I forwarded him a link to Why Good Developers are Promoted into Unhappiness and he replied:

“I hear you, but I have to experience it myself.”

I can’t argue with that.

[tags]management, programming, software development[/tags]

Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.

6 comments ↓

#1 Will Sargent on 10.17.07 at 5:49 pm

I’d say the truth is somewhere in between. Managers aren’t responsible for delivering product; neither are programmers. The team delivers product. A manager may be a functional part of the team, or damage to be worked around.

I think a common management fallacy is that programmers work for managers, and managers for their bosses. Programmers and managers work for the team. The team is what produces success, and the manager can only take credit for being involved in the team.

#2 Jon Peltier on 10.18.07 at 7:30 am

Ten years will not make a difference. Twenty years ago I started working for the R&D department in a large corporation. They were truggling with the Technical/Management track back then, and went as far as to draw up specs (job descriptions) for the parallel steps on the two ladders. All the equal-pay, equal-authority objectives turned out to be just noise, and while technical expertise is in fact respected at this company, the technical ladder does not extend nearly as high as the management ladder.

I left five years ago for different reasons, and the company is still struggling with the two tracks. At my current company, the management and technical tracks are completely integrated, and the only job description is “whatever I’m doing right now.” I suspect that as soon as a company grows to more than one person that this unique situation breaks down.

#3 Mooch on 10.19.07 at 9:18 am

Your insights are based on a best case scenario. A team of mid-high quality programmers without management would likely not develop into a highly uccessful team on their own. They would develop into something, but none the less, someone would eventually take the “management role”.

I see project teams as a group of people that play roles. Not necessarily a group of developers with a manager above them.

#4 Mooch on 10.19.07 at 12:35 pm

My previous comment continued…

I had previously created this article at my current job and thought I should post it to back up my previous comment: http://www.moochweb.com/roles.aspx

#5 Jason on 11.02.07 at 1:25 am

A good manager is
* extremely hard to find
* invaluable
* one of the most important members of the team

A bad manager is
* common
* dead weight
* counterproductive

Here’s the thing: developers, especially great ones, typically make terrible managers. It takes a very, very special person to make the jump from developing to managing people. The one’s that do that successfully end up running companies. The rest just hinder future developers. Sad truth.

Bottom line: management is critical and that is why so few software projects get done at an enterprise scale. Good managers are hard to find; great ones are near impossible.

#6 Gates VP on 11.03.07 at 5:54 pm

Hey man, I didn’t even notice the ping-back, thanks 🙂

As to this Secondly, I question whether 10 years will make a difference in the cycle of developers moving into management.

I’m still young (27), so maybe I’m just being overly optimistic. I do know that I’m seeing something turn over the last year that wasn’t true 20 years ago:
1. Nearly all companies are touched by technologies!
2. Lots of them have seen the effects of bad technology.

I see this b/c of the sheer # of people who come in with shitty projects done in 2000-2004 and they’re realizing the inadequacy of the project. The project they want me to do is usually their 2nd or 3rd project, and they now have a much better taste for what “software means”.

Software is non-material concept that’s inherently difficult to grasp. What’s more, it’s a concept that is/was unfamiliar to many business owners. But that is is becoming a was. Nearly all business stakeholders are becoming familiar with software.

This is where I hold out hope in 10 years. That will give us another whole cycle. In 10 years, I’ll have clients on their 3rd or 4th or 5th generation of software. When the clients get there, they will have a much better concept of “software”, they will understand more and demand more. They will know that we are not cogs, they will meet a great programmer, they will appreciate the value and strength of “domain knowledge”.

And we the software companies will be required to deliver at a significantly higher level. I’m just hoping that by then, we’ll have weeded out the guys who carry too much weight in the middle 🙂