Because software is ephemeral if there isn’t one guy with the ability and will to limit scope [and someone to limit the expectations of scope] the whole project is doomed.

/profile link changed to my Python blog temporarily for purposes of street cred.
//more cred? Here is the eye rollingly geeking video of my PyCon 2009 talk.

For those interested in problems with large software projects, see my post about an FAA/IBM effort to reengineer the air traffic control system: the greatest debacle in the history of organized work?

jk

When you say “f you are not getting respect from your IT department, you should look to yourself to see why not”…I’m not sure why it should be assumed that if a person or organization has difficulty getting response out of IT the fault lies with *them*, any more than it would be assumed in the case of someone having trouble getting support from a manufacturing or IT department.

All of that said, I agree with you that it is a disaster to have managers who have “generic management skills” but are incapable of understanding what their staffs are actually doing. This is true in other areas as well–imagine a manager or mechanical engineering who didn’t know anything about the subject, or a finance manager who didn’t understand balance sheets–but for some reason, people of this type seem to be imposed on IT organizations more commonly than on other functions.

Amen.

The best working relationship between management and engineering is achieved when each side focuses on what they know best–business, technology–and trusts the other within its domain. And communication is vital. Management must provide engineering with priorities, with a business assessment of what benefits are worth what costs and risks. Engineering must provide management with an intelligible and honest assessment of what the technical tradeoffs are, what the costs and risks are for different approaches.

Trust is key. When management says, “the quick and dirty solution really is what we want,” the engineers must trust them enough to build it. When engineering says, “this costly problem will be resolved most quickly if you do nothing and leave us alone to solve it,” management must trust them enough to do exactly that.

That last one’s tough. In technical work, there very often are major unexpected storms. And the very best manager I ever had told me that the hardest part of his job was being in the midst of a crisis and doing nothing. I got to see it. A final system integration ran into technical problems, and a one week build stretched into four, and then six. He asked us daily if manpower or machinery would help, and offered to get what we needed. With a few exceptions, we declined. External pressure mounted. Senior management asked him what he was doing to resolve the problem–and he simply said, “letting the engineers solve it.” And it got solved in (relatively) short order for a technical problem of that size, largely because he had the courage to do nothing.

Now that was a manager I respected, and the technical cooperation he got out of his team in return was incredible.

Off topic, it seems to me politicians often find themselves at that same crossroads in a storm, and lack some measure of the wisdom or courage necessary to do nothing.

I had to beat that out of lot of people over the years. I had to get techs to take time to listen and to educate their internal and external customers. When I did training for Apple tech support I stomped down hard on people mocking ignorant customers. I pointed out that if everyone knew what we knew, we wouldn’t have jobs. I urged people instead to look at ignorant and frustrating customers as money in the bank. This not only improved service but took a lot stress out of the job.

One of our biggest failings as humans is believing that the things we know are easy and obvious and that people who don’t know them are less intelligent or capable. In reality, we are a civilization of specialist, each of which understands some small corner of reality. We require other people to flesh out the world for us.