> By suggesting you don’t need project managers, you’re saying that you, an engineer, want to do this work and my question is, “Do you or do you not want to be an engineer?”<p>I have a problem with that sentence. I read it as a false dichotomy. In fact, the good project managers I have met came primarily from a strong engineering background, with <i>additional</i> manager traits, and had more than just some interest in engineering problems: they not only understood the problems, but also were able to participate in those discussions, as they were respected by other team members for their technical ability.
I am project manager. The issue is that usually, when you go down the "project management" path, you end up having more people managing than actually working (because no smart person wants to report to someone who is not evidently better than him/herself.) Also, the more people managing, the more management reporting artifacts the developers have to produce or at least reiterate, and the more incentive is given to the smart team members to disregard any authority and play the system. I agree with the project manager as an entropy crusher, but creativity requires entropy. The ideal PM should manage entropy, not crush it (e.g. during definition entropy has to increase, as you approach delivery it has to decrease.)
I see project managers as facilitators:
- they help us, the developers, to get the job done
- they are the buffer between the client and us<p>On the project that I work for about 2 years, no PM has any experience in programming Perl - one is coming from an economic background and the other was a java dev. We get along really well - we are colleagues and partners, not in a boss/slave relationship.<p>They have to trust us that we get the job done and we don't bullshit them and we have to trust them that they don't overpromise and they hold our back against the client when that's needed. Until now, everything works perfect.
In my experience, project managers are hired by executives because of their ability to communicate with them.<p>Specifically, their ability to discuss tradeoffs in every decision is the reason that executives would prefer to speak with them over engineers.<p>Engineers, unless they've specifically been educated otherwise, tend to see the world in very black and white terms and, as a result, try to lecture executives on what they "have to do."
Maybe these mythical good project managers exist, but I've never seen one. I wouldn't have the first clue how to hire one. So I'd rather do a bit of less pleasant non-engineering work than lose the whole company.
Aaargh - no.<p>Crush chaos and entropy through decoupled design, through APIs that are simple and affordant, crush chaos by making it
everyone's job to make the whole simpler. Don't add people who cannot code and hope they will improve things.<p>You want to formalise it - have a checkin flag #simpler=+1 or 0 or -1. Everyone should look at a -1 and ask "what can I do to make that a +1"<p>Simpler simpler simpler.<p>Edit: I always come back to the idea that software is a new form of literacy - and if you see a software issue, reframe it first as "reading and writing". What we are arguing for here is there should be non-coding people running around finding out "stuff" in some super human manner and then reducing chaos with it.<p>Reframe that software house as a newspaper - What foolishness says hire illiterates to run around discovering what the newspaper needs? Hire editors, create a process around the writing, proofing and editing of the written word. At the software house - do you need project managers - or do you need editors? Senior developers who realise their time hands on the code base is now over and they need to guide, edit, mentor.<p>Now build respect into that. And then tell me how respected national newspaper editors will feel if the guy in the office next door, who now has as much influence on the decisions as they do - and that guy is illiterate.<p>Treat software like written words - build organisations like newspapers, and hire no-one who cannot read.