Slashdot Mirror
What Kind of PHB Do You Want?
the_radix asks: "I'm not a great coder, but I love computers and especially programming. Those professional programmers that I know often complain of their managers not understanding the coding process and having unrealistic expectations of programmers. As such, I am considering a new career path: management. Since middle management is all about balancing, I'm looking for pointers before I start looking for positions. What do you, as coders and programmers, want from your immediate manager? If there are any geeks out there in upper management, what do you want from your lower-level managers who keep the techs in line? I'm not asking for the basic 'stand-up-for-your-subordinates' advice, but rather requests from a coder's standpoint. Geeks have special needs, and accommodating those needs (and 'odd' behaviors) is a good idea all around, for both employee morale and department output." I think many of us would rather like one who listened or who would at least take advice from the technical staff to heart. Many times managers will not consult their coders when they make plans, they'll make the plans first and tell their coding staff later, and this causes all kinds of problems. Generally, a superior with less "pointy hair" is something we'd all appreciate, but I'm sure the rest of you can expand what I'm trying to say here, or even say it better than I can.
- Listen to us, not to the consultants
- Decide on the plan, stand back, and let us implement
- Act as a filter for the politics
"It remains to be seen if the human brain is powerful enough to solve the problems it has created." Dr. Richard Wallace
The single most annoying thing for me (back when I could actually find work as a programmer) was the unrealistic expectations laid down by a management that had no concept of what goes into development. A former/aspiring programmer as a manager would be able to at least consider these factors when making project timelines and resource allocations. I would have also appreciated code reviews from my superiors, but for the most part, they have been of the mindset that what we did was magic and couldn't offer a shred of technical assistance or direction.
I applaud your choice of considering management, I'd love to work under someone that has more than the 'hey, the internet is down' mindset.
-72
-Those who dance are considered insane by those who can't hear the music.
My biggest gripe with some of my former employers was the lack of involvement in the design phase (eg: setting realistic goals, and not imaginary or impossible goals). By the same token, setting reasonable time-frames for completion of various tasks is another issue I've butted heads with management on-- a prime example is when I explicitly stated the project at hand would take 4 months to complete (longer with QA work). I was overruled and told that the entire project, with QA, could be completed in 3 months. Needless to say the project went beyond that limit and much complaining was heard from the management types (instead of realizing they were wrong, they took us aside and told us we weren't doing good enough-- somehow they thought this would speed things up).
Development takes time, and most geeks aren't like Scotty in Star Trek-- we don't multiply our estimates by 2 to make ourselves look like miracle workers when we get it done in half the time.
All I know about Bush is I had a good job when Clinton was president.
Or, perhaps, 'No One Above'. I like to work for myself. It's harder, possibly less pay, less guarantees. But at the end of the day, I have no one to blame but myself. And no one to thank but myself.
Be careful of PHBs who know a little programming. Kinda that "a little knowledge is a dangerous thing". Or those who know nothing "If C is good, C++ must be three times as good".
If you can, talk to people who work at a company. Just like you are going to lie, bend the truth, and put on your best face at an interview and in a resume, so is the hiring person/manager who you talk to.
Stay out of debt for a while. Keep driving that shitty car, and stay in that shitty apartment. You may get into a position that you hate, but be stuck in it due to debt and other responsibilities. Continue to stay flexible for a while. (That's why I'm not yet working for myself full time. F***ing mortgage.)
Sorry. Not really on point. But I hope it helps.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Of course, with that comes responsibility on our part to actually make the right choice, but we know if we lose that trust, life will be much harder.
Random Musings
The sad truth is that the PHB has an even Pointier-headed boss and so on up until we reach the Splendid Majesty of Satan who Owns The Souls Of The Workers.
As a manager of geeks you will come under ugly, ugly pressure from the next layer of idiots forcing you to make choices against your inclination, your will, it will be like an old 1950s horror film where your right hand is moving without your volition while the Demonic Forces Of Management snicker.
I forecast it will be under three months before you find yourself saying to the Unwashed Geeks in your charge that your Agree with their Point Of View and if it was In Your Power you would Do this Thing, But....
Upper managers want efficiency.
Creative line employees want effectiveness.
These are at odds with each other. You said it yourself, middle management is balance. Another way of stating this is that it's your job to provide the right amount of slack in the system.
Slack: the Myth of Total Efficiency by DiMarco seems to be a good modern, complementary companion to the ever-favored The Mythical Man-Month by Brooks.
It may not teach you anything earth-startlingly new, but it has got some good notes and ideas on how to deal with your prima-donna types, your slacker types, and your micro-managing cohorts.
[
Instead of looking at the "needs" of your subordinates, first look at the company you want to work for.
Sure, finding out how to support the people under you is important, but not the most important question.
The most important question, is, "what is the company/mamangement I must work under like?"
If your company is ethical and concerned about it's people (really concerned, not just financially concerned) your job will be much easier. Then the task only becomes finding ways to help your subordinates do their jobs. You'll spend lots less time fighting management above you to actually get this priviledge. That's a huge help.
I know this sounds simplistic, but my exp in this area is that when I am empowered by the employer/upper management, I can really focus on doing what needs to be done. Lots less time is spent on CYA, political fighting, empire building etc. Then you're happy, you can be honest and upfront with your subordinates, and gain their respect and trust. (Trust, i think, is of paramount importance!) Then they'll tell you when you're doing stuff wrong, and help you from looking like a schmuck. Then you can help them get their needs met and be productive.
The end result!? The company runs smoother, more efficiently, and more profitably.
Thus, see what you're empowered to do by your managers, than when it's right, figure out what the specific needs of your subordinates are. They're never the same, but the overall principals are!
Cheers!
a. clearly defines my tasks
b. clearly defines my deadlines
c. doesn't change priorities every freakin day
d. leaves me the hell alone to get my work done and doesn't come by every three freakin minutes asking for a status update
e. listens to me when I tell him it can't, or shouldn't be done
f. doesn't demand to know every single thing I know about what I am doing, but only to know the things that truly matter for him.
g. one that trusts me to come to him if I need help.
The difference between Theory and Practice is greater in Practice than in Theory.
Spend time each with with your analysts and coders, even if it's informal over coffee and doughnuts. Micromanage to your own peril, ignore staff to theirs and your own. Staffers are most productive when they feel their work has purpose and value. Keep informed on projects and status, don't just show up one day asking where a project is.
Be prepared to go to the mat for your staff, since bigwigs often are more clueless than immediate managers. Be sure you can translate, understanding each ends expectations, needs (often far different from expectations.) If your staff needs resources, you'll have to battle for them, make sure they can defend needs, because you'll probably have to relay to your manager. If cost cutting, be very careful. Damage to morale is the start of downward spirals. Fight for a training budget and for Q/A resources (i.e. people) as these are far more crucial than most senior managers are aware of.
Don't get dragged into more committees/groups meetings than you actually have time for. Poor time management of supers is one of my biggest gripes. Be available (see first topic.)
Best of luck
A feeling of having made the same mistake before: Deja Foobar
Let. Them. Code. Don't change focus on a project just after they start to get into it. Don't watch over their shoulders and make meaningless uninformed suggestions. Don't waste their time with pointless meetings. Just let them do their job.
I don't want to sound like a troll, but really, if you don't know the answer to this question already, you aren't ready to be a tech manager.
I'm serious. You say that you're "not a great coder," but you provide no other information about your technical skill level. So, one can only assume that you're an inexperienced coder/hacker, and that you've never worked on a real project team before, let alone led one.
My answer to your question is this: I've always wanted a boss who understood what I was doing as well as I did, and probably better. At the very least, I wanted a boss who had been through the grinder, and could understand why I was making certain choices, without second-guessing them. And honestly, if you don't have at least a few years of professional-level coding experience under your belt before you enter the world of tech management, you won't meet that requirement. In short: if you want to be a good tech manager, be a tech worker long enough to count.
Let's try not to let fact interfere with our speculation here, OK?
Encourage feedback and suggestions, but make sure everyone realizes that ultimately your decision is final (at least as far as anything is in this line of work).
It is NOT your job to tell your subordinates of upcoming layoffs, or any other "need to know" information. This will only inspire panic, and the smartest (read most valuable) employees will be the most likely to send out resumes. It is, however, in your best interest to keep your group as functional as possible. This means you try to protect the good workers from layoffs, but also swing the axe yourself at the dead wood.
I just recently stepped up to the plate you are thinking about taking a month or so ago at my company. My purpose in the office now is to act as a firewall between the developers and the rest of the company. So far, this has worked well - but it meant some sacrifices. Here is what I did:
First off is meetings. I'm in all of them now. I get callled into them on a whim. It sucks, but at least the developers can keep coding instead of being sucked into meetings.
No more code. I'm barely writing code in the office now. This has been an adjustment. I suggest you find a few projects to satisfy your coding needs in your off time and DO NOT BRING THEM UP AT WORK. I made the mistake of that once, and the company tried to sell my hobbies as products.
Be prepared to stand your ground. Upper management has no idea how the development process works. Writing code is a creative process, not a color-by-number process. It's going to take some work to make them understand that.
Take control of the development path for your team. Don't let the people above you bypass you and put your developers on other projects. Come up with a new management system. My immediate bosses are both Ph.Ds. They want down to the minute stats of what is going on - don't do it. You need to find a better model for managing deadlines and people (I adapted the management devices presented in eXtreme Programming).
Allow your developers freedom. The developers under me come and go as they please. They don't have fixed hours, but they do have fixed minimums. They are required 40hrs/week, but when is up to them. Remeber, coding is a creative process. If you have inspiration at 2am, then you should be able to excercise that inspiration.
Devlopers are not robots. Just because the boss (who doesn't sleep) sees a developer in the office at 2am doesn't mean that all the devlopers are available or that they should be interrupted. This one I am still working on. I get calls all weekend from my bosses asking for work to be done because they see one of the developers logged in.
Above all, be fair. Don't baby your developers and treat the rest of the company like trash. I have one (short) weekly meeting with the developers to discuss strategy and planning two days after the manager's meeting. This way the developers do not look like they are being treated special by not having to go to meeting, and everyone stays informed. It seems to work well.
Bumpy as this ride has been - it seems to be working. It will be tough for the first month (esp. if you are inserting code management, feature management, and bug management tools into your work flow), but it's a much needed thing. The productivity of our developers has gone through the roof sice I put on my flame-proof clothing and block the door to the developer cube-farm with my desk. 8^)
-Carl "No, we already thought of that one. 'Why?' '42' - It doesn't fit." -Hitchhiker'
One of my former bosses handled feature creep quite well.
"Yes, we can add that. It will push the deadline back 1 month and cost you (the customer) an extra $150,000. Do you want to add it at this time?"
Very often, they didn't.
I like you, Stuart. You're not like everyone else, here, at Slashdot.
The entire office thing is important. Cube farms are NOT a productive environment to work in. And if you're going to force geeks into cube farms, at least make sure they have some breathing room.
I've had a cube so small I couldn't turn around in and it was stifling and made being productive difficult. An office is ideal, but unfortunately not too practical for most organizations, so at least give us some room to breathe.
Telecommuting isn't so important to me, but being flexible in work hours is very important. If I'm caught up or ahead of the game - don't get upset if I leave 2 hours early or come in two hours late. Believe me, if I'm behind or something is wrong I'll be there all night if necessary. But when it's slow, relax.
And stop being so damned serious. The end of the world will not come about if we don't do X, Y or Z right this minute. Give us a little slack once in a while. Those rubber bands and nerf guns aren't going to hurt anyone. At least not seriously.
I don't have a solution, but I certainly admire the problem.
- Make sure there's more than one of us in the department so that we can communicate with like minds. Encourage us to do so. Pair us up on every project so we can learn from each other.
- Don't leave us out of the initial project development. We can provide valuable input when the software is being designed in the first place, by offering suggestions about what is and isn't possible or feasible.
- Respect our schedules. If we need to work odd hours, take erratic breaks, or do half the job from home -- as long as we get the job done on time and turn in our hours -- let us do it.
- Write things down for us. ESPECIALLY when we're not invited to the meetings. When someone spends their entire career in ASCII, it helps to have assignments in that format as well.
- If we don't want to do stupid changes, entice us to do them anyways. If we don't want to do impossible changes, help us work out an alternative.
- Hook us up with the client's geeks so that we can swap technical details without going through more time-consuming channels. Ask for CCs of all the emails so you can say you're still involved. Don't hook us up with the client's contact. They're not as intelligent as you are.
- Nod and smile when we play with our action figures or Nerf guns at our desks. They keep us sane.
- Motivate us with free food. When necessary, bribe us with it. Let us pick the restaurant. Relax, we're cheap.
1) *Always remember where you came from*. The biggest sin you could ever commit is forgetting what it was like to be the programmer/admin/etc.
2) Value the opinions of your staff. Listen to what your staff says & find the balance between what they want & the project requires. If your staff feels like their opinions count, they're more likely to trust you & follow your decisions.
3) Make a decision & stick to it. The worst decision you could ever make is not making one at all.
4) Find what success means to each member of your staff & help them achieve it. That is the key to *your* success as a manager. (Staff success == your success)
5) The definition of "management" is delegating responsibility to others. Delegate != give away (responsibility). You have LESS responsibility but MORE ACCOUNTABILITY as a manager.
Nothing is cooler than seeing the 'fiction' taken out of science fiction.
My first reaction was: Do you honestly expect anybody to accept those terms?
Then, I thought about it and realized you just weren't presenting your conditions properly.
FROM: Listen to us, not to the consultants
TO: Be skeptical of consultants selling snake-oil. Trust us: We're just trying to do a good job.
FROM: Decide on the plan, stand back, and let us implement
TO: Stick with the plan if it takes a little longer, persistance is more inportant than time to market. If you're manager is a programmer, then he should be tracking the code you check into the CVS system and keeping everybody on the same page with standards.
SIDE NOTE: It's best if your manager doesn't "stand back", but is rather involved in the process (given he's competitant enough to know what he wants).
FROM: Act as a filter for the politics
TO: Help us focus on our work by isolating us from beaurocracy.
Most of all, try to do everything within reason
"Communism is like having one [local] phone company " - Lenny Bruce
Whatever happened to offices? Some years ago, you always heard how much productivity of Engineering staff was enhanced by offices, but now, all you hear about is that "open" workspaces encourage collaboration.
Personally, I much prefer collaborating passing documents back and forth. Collaborating face to face has it's place, but to build anything of value, it's best to get all the ideas and opinions down in writing and diagrams, so they can be studied objectively. Usually when technical decisions are made in meetings, even informal drop-by-the cube or office meetings without anything written down, I find that they are poorly thought out.
That's what I want from management. An environment that values my ideas, but also READS and tries to understand the issues. Shoot from the hip environments are generally poor for a number of reasons, in my experience:
That being said, I do want to point out that there are a lot of comments in this thread about how good management insulates technical staff from politics. I agree with this, but I want to add that good workers who have management that does what they can to insulate workers from good management have a responsibility to do what they can to insulate their management from politics also. The corporate edicts may be stupid, but most middle management is powerless to fight a lot of these things. It's best to stand up and do what needs to be done to protect your (good) managers from feeling the heat if the edicts aren't followed.
Sometimes, like schedules dictated on high, it's not always possible, but at least give your boss lots of good technical reasons (not just whining) as to why the schedules can't be met.
Just my 2 cents.
No its not. If an employee can't act like a professional, you get rid of them. Very, very few projects require people smart enough to put up with a bunch of crap from them.
Yeah, its really hip to have that one guy come in at work at 2pm and work until 9 at night, because he's so damn elite, until you realize that he's unable to interact with all of the _adults_ who have children and real-life responsibilities. Its called a team. "Oh, I don't work well in the morning." Oh, i'm so sorry! Gee, because the rest of us automatically wake up at 6:30am chipper and ready to go!
Ooh, and lets pamper the programmers with soda and candy and teddy bears and futuristic chairs. Until the rest of the company, who work just as hard as the programmers, begin to get a little pissed off. Soda is 30 cents a can. Suck it up.
Lets not forget a dress code. Yeah, lets not enforce that, you don't need to look good to program, man. Until that one programmer wearing the 2 sizes too small phantom menace t-shirt with the body odor turns off a potential client. Is wearing a pair of dockers and a shirt that doesn't have a fucking wookie on it going to kill you?
Lets have a nerf gun fight! Woopie! Two guys want to fuck around, so the entire floor can't get anything done because two guys are running around screaming. "Oh, please hold Mr. Potential Customer, I have a nerf dart in my fucking eye." Maybe the rest of us _aren't_ working late that night and need to get stuff done. Maybe i'm at your cube, waiting patently for you to get done PLAYING.
I'm looking at moving up to management as well, but you sure as hell shouldn't. I'm not looking to liberate my brothers from clueless management, i'm just sick of working with people who are so busy playing video games, installing linux, and bitching about management, that they haven't developed the communication skills needed to EXPLAIN to someone why its going to take a certain amount of time to do something.
Nah, don't explain it to them. Just sit in your cubes and make Dilbert jokes.
Oh, here's a bonus tip for other people out there who blame management for everything: When you're only in a few hours of meetings a week, don't use that as an excuse why you can't get shit done. Yeah, it would be nice to work in a crystal castle with cushions and butterflies and nobody to bother you with petty problems that don't concern Mr. L33T Programmer, but that isn't going to fucking happen.
Damn, this was almost as bad at this arrogant asshole.
1. Give me a cool project to work on.
2. Leave me alone until I'm done.
3. Pay me.
Umbrellas are good. I've had both.
Stupid job ads, weird spam, occasional insight at
1) Communicate your expectations clearly.
2) Listen.
3) Focus on the work itself, not the window dressing. The hours, manner, and location in which I work don't matter so long as I deliver good results on time.
4) Recognize that some technical problems are not progressive and people cannot give a time estimate. "When will you find the bug?" often does not have a meaningful answer. There is no such thing as X percent done with this kind of task and the rate of progress cannot be measured. It's done when it's done.
5) Don't be afraid to discipline those who need it.
6) Dish out praise when it is warranted. Our egos sometimes need stroking.
7) Beware of false economies. When schedules are tight, do not throw good software engineering practices out the window. If you do so, it will usually bite you in the ass.
8) Pay attention to team building. Will a prospective new hire fit in well? How can you help people to work well together? This will sometimes mean finding a way to keep incompatible workers out of the others' hair. Play together outside of work.
9) Pay attention to skill building. When possible, assign people to tasks (or suggest methods) where they can grow. Some tasks will take a bit longer in the short term, but you win in the long term. Skilled people can do more and work faster. People who feel like they are growing are happier, more productive, and stay around longer.
10) Set priorities and stick to them.
11) Don't bullshit.
12) Set a good example.
13) Accept the fact that people have lives outside of work.
14) Realize that time is a finite resource. If I leave my primary task to fight a fire, that means I am not progressing on my primary task.
15) Negotiate realistic deadlines.
16) Know your stuff.
17) Give people good tools.
18) Keep your word.
1) Adding more people (especially entry level) to a project does not get it done quicker.
2) Most of the time, one cannot justify reducing the schedule of a project by equally reducing the requirements as requirements are often interdependent.
3) Every moment a programmer spends filling out paper work, attending training, or attending meetings goes against productivity by a factor of 2. Productive programming requires long uninterrupted durations of time. If these things are required, block them together to maximize programming durations.
4) Some problems just can't be solved by throwing money at them. Therefore it is important to have a knowledgable person within each team to determine whether something is technically feasible. Essentially, management should generally not try to determine the technically feasibility of a task.
5) Large teams are not more productive. While it's tempting to float unproductive people on productive teams, the team will take a huge productivity hit. It makes more sense to have some projects fail and other succeed rather than having everything delivered half-ass.
I partially agree with some of the things expressed about not given in to the dot-com type attitude. Managers really have to crack down on people that goof off too much. Goofing off too much should be judged by the individuals productivity and how their goofing off effects others productivity.
If you have a guy that helps everyone and is 3 or 4 times more productive than everyone else, then if he is surfing the net, leave it be. On the other hand, if you have an individual who hasn't written a working line of code in a month and sits around chatting all day, well, then a manager needs to step in.
The flexibility of a programmers work habits should be a priviledge, not a right.
int func(int a);
func((b += 3, b));
I was lucky enough to have the ideal manager without knowing it. I worked at a pharmaceutical company designing programs for the bioligists/chemists to use. My manager had degrees in chemistry, CS, and most importantly she had been a third grade teacher.
Why was this important? It gave her an aura of being in control without being condescending. You just wanted to make her happy. I realize this is vague, so here is a specific way you can achieve this effect - protect your geeks. Make it clear that you are the only person they report to, the only person they have to worry about listening to. Don't let marketing, sales, or even your boss tell them what to do. This relieves much of the stress of being in company. Remember "Office Space"? One the guys main complaints was that he had 10 different managers to report to.
Employees who have clear objectives, and who don't have to worry about retribution from unknown, unanticipated sources are (at least one step closer to being) happy employees. -Adam
What I would like in a boss is what I have right now. He knows more about the business than me, but he knows that he'll get the technical information he needs from me. He knows the right questions to ask and knows that he can trust my answers. It is his job to synthesize the information he is getting from various sources and make the decision that is best for the company. Sometime he takes my advice, sometimes he doesn't, but I try not to second guess him. I just remind myself that I'd probably be as good at his job as he'd be at mine.
Outside of work my boss has a life, and he recognizes I do too. He knows there wouldn't be any point in grinding me up just to get a little more productivity. I'm sure he'll never put a DVD player in the break room (although there is Cable TV) but I only work about 8 hours a day so I can watch movies at home if I want.
I've never understood why geeks are willing to work 12 hour days to help some VC get rich as long as they get nice breakrooms, free caffine and foosball/table tennis. And dvd/vcd/mp3/cd players? Why would you need that at work? Total productivity killer. Go to work, do your job, go home. If you can't get your job done in 40hrs a week (and you aren't incompetant) then you boss should hire more people.
Some of my best friends keep "drinking the kool-aid" (what an ironically appropriate metaphor). Only to get totaly screwed in the end. This seems to be even more prevelant in programmers than other geek type jobs.
Someone please explain to me what is so great about foosball that it makes programmers not feel exploited by a company that expects them to work 80 hours a week?
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
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?
Bush's education improvements were