Quoted from the parent post: "Just because someone isn't an expert in a job doesn't (always) mean they can't manage it." That may be true in some fields, but not programming. If you aren't a very, very good programmer, with an intuitive feel for coding, you cannot manage programming effectively. If you can't read code quickly, and see all the implications immediately, you will never know if a coder who works for you is in trouble. You will never know who is a good coder. You will never understand whether you are getting quality code, or future junk. You will never understand whether a programmer has coded himself or herself into a corner. Here are some examples of bad software development management. It is all my opinion: IBM killed OS/2 through marketing stupidity. That was 2 billion dollars flushed down the drain. They called the product "Warp", a term for something that has been damaged by being bent. They made many, many other foolish decisions. They were not attentive to business. They didn't realize the importance of having plenty of drivers for popular peripherals. Amazing. All that work of talented people, thrown away. Not just a waste, but immoral. IBM bought Lotus, and killed Lotus WordPro, and other Lotus products, through marketing neglect. WordStar was killed by a new version that lacked some of the features that customers loved. WordPerfect Corporation killed WordPerfect by being slow to make a version with a GUI interface. Novell bought the product, and sold it for $750,000,000 dollars less than it paid about 8 months later to Corel, I seem to remember. Novell killed Netware's sales potential by abusing its customers, the consultants who installed and maintained its products. Corel slowed Corel Draw's sales by being utterly foolish in marketing. I talked with [a top manager at Corel] for more than an hour about this. He agreed fully, but said he could not get the CEO to change things. Corel Draw is still around, but the company has laid off most of its former staff. Central Point Software killed PC Tools by bringing out a very, very buggy version. Before that, Central Point was doing hundreds of millions of dollars a year in business. Fastback from 5th Generation Systems was run by a man whose entire business history was in banking. I talked to him for about 45 minutes. He employed his daughter to do marketing. She had just graduated from university. He shipped a bad version, and Fastback died. It is now owned by Symantec, who stopped marketing the product. Xerox killed Ventura Publisher's popularity by continuing a design in which the drive letter and folder name were stored inside its files. This meant that the files could not be loaded from a diskette backup. Strange, but true. Corel bought Ventura Publisher, and fixed the file problem. Corel has slowed the sales of Ventura Publisher by poor marketing and poor design decisions. People say Ventura Publisher is the best book publishing software, but sales don't reflect that. PkWare killed PkZip by continuing a poor quality interface. Now most of PkWare's business has been taken by WinZip from WinZip Computing. I've only covered a few of the early failures here. I've said nothing about the dot-com bombs, which deserve a full investigation. The biggest cause of software company failure is neglecting the sociological challenges of marketing software. Usually marketing vice presidents lack the necessary skills. Often they lack both sociological skills and technical skills. Part of the marketing manager's job is to create connections between the customers and the technical staff. Usually marketing managers have no programming experience, so they have no hope of having credibility with programmers. Usually marketing managers vastly underestimate the challenge of knowing the customer's needs. The second biggest cause of software company failure is not understanding how to make a useful program. That means partly knowing how customers use their computers (see the paragraph above), but also thoroughly knowing the technical issues so that you know what can be and should be coded. When people say they can manage in a fast-growing technical field without understanding what their employees are doing, they are talking complete and utter nonsense. It is necessary to have a close business relationship with your coders. If you don't understand what they are doing, you can't be close to them. -- Links to respected news sources show that U.S. government policy contributed to terrorism: What should be the Response to Violence? [hevanet.com] [ Reply to This | Parent ] If you don't understand, you cannot manage! by Futurepower(tm) (Score:4) Moderation Totals: Interesting=2, Total=2. Re:If you don't understand, you cannot manage! (Score:2, Insightful) by PyroMosh on Friday February 08, @11:38PM (#2978118) (User #287149 Info | http://female-ejaculation.com/) I will concede that you're probably right about programming not being a field where a non-expert would make a good manager. However, your points do not illustrate this. Every one of those points represents a blunder on the part of someone other than a coder or lower level manager. Marketing decisions are not made by entry level coders. Weather to go with a GUI or CLI is not a decision made by a low level coder or bottom rung manager either. It'll be made at the top of the project, if not the top of the company itself. You also don't have to be a coder to make a decision like that. Just look at the world around you. What do you see surviving in the market? There's your answer. Yes, I understand your point, but it was made by your more abstract arguments (prevention of painting yourself into a corner with bad code style, etc.). But I still wonder if this is necessarily true. Wouldn't this depend on your company's structure? How well you trust your coders? Netscape in it's prime, for example had the best and brightest. I'm sure it's coders were allowed far more latitude than say, coders in a non-glamorous code sweatshop like Norton or Corel or IBM. From what I know of their corporate culture, The same would not be true of Microsoft, but for different reasons. And let's not forget coders for non software-companies. I have a friend that's a coder for a major pharmaceutical company. Should his direct manager be someone with a pure coding background? I doubt it. Since they have needs that he's not 100% sure of himself. His boss is a coder, but he has degrees in chemistry and that's where he spent most of his career. My friend is from a pure code background and he recognizes that he lacks the expertise to manage coders in this specialized environment. In a way, yes this supports your argument. But I do know that my friend is a better coder than his boss, and I'd go so far as to say the rest of his team as well (it's why they hired him in the first place without a pharmaceutical or related background). Does his boss give him leeway with code he doesn't understand? Absolutely. That's what they hired him for. If his boss audited every line of code he wrote, he might as well write it himself and the company would save ~$80,000 (not sure) or so a year. Also, what happens if you're managing a small but diverse team? Not just coders for instance? Should the manager have to be an expert in coding and graphics and promotion and whatever else is on his team? Should he have to have 5+ years experience in EACH FIELD just to be a lower level manager? I don't know about you, but I'd rather have someone with good leadership skills who knows NOTHING about his/her subordinate's jobs but knows how to delegate authority and will listen to his/her people. All the skill in the world is a poor substitute for good leadership. You don't pay managers to do a job for your employees. You pay them to make sure that they CAN get it done. I used to be a member of a search and rescue unit. At one point, we got a new commander. A Lieutenant Colonel. Great officer. But he was from a Logistics background. He knew nothing of SAR. But, he listened to his people, assembled the best staff, and fought for us at higher levels in the chain of command for the resources we needed. Our unit flourished under his command until he was promoted to a higher level of command. He was a good leader. And because he knew his limitations, he was able to lead (well!) in a field unfamiliar to him. Our Air Crews and Ground teams of course had people of the proper backgrounds leading them (it's 100% necessary on an operational level), but in an office type environment? Not really. Sometimes I'd rather have a good bureaucrat in my corner in a sufficiently politicized environment. It means your less likely to get your budget slashed or people taken away from you. Would I always seek a manager with a related background to a job? Absolutely! But it's not the only way to make things