What Kind of PHB Do You Want? 541
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.
Three things (Score:5, Insightful)
- Decide on the plan, stand back, and let us implement
- Act as a filter for the politics
Re:Three things (Score:4, Insightful)
- Decide on the plan, stand back, and let us implement
- Act as a filter for the politics
Number 2 on your list isn't ever going to happen -- things change too much for that. That's why it's called Life. Because it's a changey kind of thing. Death is where it doesn't change much (for the participant) any more.
Simon
Re:Three things (Score:5, Insightful)
Number 2 on your list isn't ever going to happen
It's a continuum - i don't expect to fully define the system before beginning, but having requirements change every damn day makes it impossible to work.
Re:Three things (Score:5, Insightful)
It's that simple. And that's why I'm no longer a manager, I hate doing all the things a good geek manager should do.
Re:Three things (Score:4, Interesting)
I know this is more of a statement of my scenario than of what to do. But if you can do what she does then you're sure to do good. Not to mention that only techies can make good middle-management as long as those non-techies understand that they don't have to understand or fake understanding everything.
Re:Three things (Score:2)
Re:Three things (Score:3, Interesting)
FREX, at my last job, we had a consultant come in and tell us to "Do X to the database", and our Oracle Admin said that we couldn't. (Something about Oracle 7, which we had, vs Oracle 8i, which we told the consultant we didn't have, multiple times.)
The bosses listened to the consultant.
Loads of fun... In addition to paying the consultant, we ended up paying for the upgrade to 8i....
Re:Three things (Score:2)
They asked what it would take to get the consultant's ideas to work. The reply Oracle 8i.
That's when we upgraded.
Of course, a short time later, the company began a series of layoffs, including me, so it doesn't matter too much to me anymore.
Re:Three things (Score:3, Interesting)
A common error of my (ex)employers is assuming that, just because the customer pays, that means the customer is always right. That's not always the case.
In our web development area, we had to make stupid changes of design, make slow, unnavigable or ugly web pages, but "The client asked it that way". We are supposed to be experts, we KNOW what works and what doesn't. If the customer to knew how to solve his problems he wouldn't have the need for us.
Imagine you are a doctor and you have a patient that has cancer, but he wants an aspirin based treatment. You could give it to him and cash the check or you could try to convince him of what he really needs, even if it costs more.
Re:Three things (Score:2, Interesting)
But on the other hand my current gig is a nightmare because they DID listen to their consultant --> these people used Rational Rose to generate code {blekk!} and even worse they believed that their OOP guru knew what he was doing. These people now have to maintain more than 7,000 classes all of which have one or two {sometimes none} meaningful methods in them. None of the 7,000 classes in any way represents a meaningful problem domain entity...
Re:Three things (Score:3, Interesting)
Did your beautiful initial structure (which you wouldn't have to maintain, report against, etc.) have the potential to cause problems down the road?
Most consultants I have dealt with were carpetbaggers. It's the nature of the job...you come in, you recommend the setup you've recommended for the last fifteen jobs, and you leave before the dust settles. Those on the job are left to deal with the consequences.
Consultants, like everyone else, fit a bell curve - some horrible, some incredible, and most about average. The average guy doesn't understand the implication of what everyone is doing. Over time, those of us on staff learn that a consultant might have some good ideas and suggestions, but generally DOES NOT and CAN NOT have the big picture. We have the fractal view, from the smallest detail to the largest project. The consultant sees only a single project. The consultant does not contain within his head all the interconnections and potentials for problems.
It's entirely possible that the people you dealt with simply weren't as smart as you are (and I'm completely serious). They saw what you suggested and didn't understand how to maintain it. Maintaining 7,000 trivial objects, on the other hand, is simple...just tedious and time consuming. It's good for people to know their limits. And don't go suggesting that maybe they should quit or the company should hire someone smarter - there's only so much talent to go around and it can't work everywhere.
Re:Three things (Score:3, Informative)
from June '99 is still pretty good, IMO. I printed it and left it on my manager's desk. Then he got fired.
Maybe you should rephase it... (Score:5, Insightful)
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
Umbrellas vs. funnels (Score:4, Funny)
Umbrellas are good. I've had both.
Geek managers should be like third grade teachers (Score:4, Insightful)
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
Re:Three things (Score:2, Insightful)
People have to remember, it's not us VS. them. If consultants and programmers were both contributing, the results would be great. What the original poster should've said was:
Listen to us, AND the consultants.
Food for thought. (Score:3, Insightful)
So, are you sure that you know it all?
even? (Score:2)
No, not possible. Never happen.
What I've had in the past... (Score:3, Funny)
Re:What we have now ... (Score:4, Informative)
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?
incentives (Score:2, Funny)
Ex-programmers (Score:2)
Read the Mythical Man Month (Score:2)
What? (Score:2)
In other news, i'm at -5 karma, please mod me offtopic -1 so I can be back into troll land. Though I appreciate those who have dutifuly brought me from -14 to -5 karma, I regret that I will not last long at a 0 score.
Manager's job (Score:3, Insightful)
Make sure I have enough hardware.
Make sure I know where I can get required software.
Inform me quietly that you know about future layoffs. Stand up for me when the ax swings by.
Addenda (Score:4, Insightful)
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.
Suggestions... (Score:3, Insightful)
Another thing that geeks like (at least I do), is PEACE AND QUIET... get them an office of their own, one that's soundproof.
Let them take older hardware/computers home, so they can have something to play with without fear of destroying it. Chances are, it will become a server of some kind in their home.
Don't know how feasible these ideas are, but at least there's a couple of good suggestions.
Re:Suggestions... (Score:4, Interesting)
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.
Re:Suggestions... (Score:5, Interesting)
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.
Re:Suggestions... (Score:3, Informative)
Plus, cubies aren't a "leasehold improvement" that creating many offices would be, when getting into a lease. Furniture has more flexibility this way, and can be taken with you. Leaseholds can't.
And as you mention collaboration is another point. It's not just an excuse, but a reality, in my experience. I've worked with the same group of people (in the same company) in offices, and then later in cubies, and there was far more interaction and communication in the latter. A company should provide ample meeting rooms for when a group needs to get together to discuss something (without bothering their cubie neighbors), or to make certain phone calls, or whatever.
Independant of the cost factor, if I were to create an office from scratch, I'd use cubies (errr, workstations) rather than offices for all.
Of course, it does depend upon the nature of the work. Web-related programming generally works well with lots of collaboration. Cranking out the latest encryption technology or MPEG5 encoding algorithm, is probably something a programmer would best do in a quiet office.
-me
The Perfect PHB: (Score:2, Funny)
A beautiful deaf, blind, mute nymphomaniac who owns a liquor store.
'Nuff said!
Re:The Perfect PHB: (Score:2)
I want a smart boss! (Score:5, Insightful)
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
More Involvement in Planning (Score:5, Insightful)
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.
More FINALITY in planning (Score:3, Interesting)
THEN, on a sometimes daily basis: "Can we add this? How much trouble would it be to put this in? Can you squeeze this in? It would be really great if we could add this. I was thinking this would be a good thing to have in there. Just something to think about."
ARGH! Then they get all upset when the timeframe begins to get stretched. It's not our fault they don't take the time to carefully think it through at the beginning.
Re:More FINALITY in planning (Score:5, Informative)
"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.
Re:More FINALITY in planning (Score:3, Interesting)
"So, you want feature X? Put it in that box - we'll look at it after we release."
Re:More FINALITY in planning (Score:3, Insightful)
Earlier this week, I was in a meeting between our companies and representatives with one of our clients. They were asking for a timeframe based on a graphics creation task I would ultimately be responsible for.
I told them how long it would take.
Then they started saying they had a bunch of potential changes to the graphics that they might want to 'impliment down the line' which is marketing-speak for 'I think this is really cool and I want to do it, but I haven't stuck my nose in my boss's ass deep enough yet for him to tell me it's okay.'
For each change they suggested, I interrupted the meeting and very pointedly explained that particular change would add 'X' amount of time to the project.
One of the exec VP's for my company was sitting right there. He just kept nodding in approval every time I opened my mouth.
Our company is fairly successful, and we always come away with good 'customer service reviews' and this seemingly-rude behavior is one of the reasons why.
Re:More Involvement in Planning (Score:2)
None of the Above (Score:4, Insightful)
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.
Re:None of the Above (Score:2)
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".
--end quote
So how much programming should they know? You make it sound like no matter what you are screwed.
Trust (Score:5, Insightful)
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.
litlle fish eaten by bigger fish... (Score:5, Funny)
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....
in a perfect world... (Score:2)
ok, sorry, went off a little, but it would be nice to be included in the thought process, so we can add our very important $.02.
I wish you luck, most middle managers I know end up being told, "I don't care if the programming department says its un-realistic, just do it.
Three things ANY IT manager needs (Score:3, Interesting)
1. To be technically proficient. Perhaps he or she is not up on all of the bleeding edge technology, but he/she needs to be rooted in IT and not accounting or especially not marketing.
2. To understand the word "flexibility." Every part of IT is all about strange hours. Some coders do their best work at 3AM on the last night before a deadline, wired on Mountain Dew and pizza. A lot of network engineer types are in at super late hours, because that's when the maintenance windows are open. Because of this, managers -familiar- with all the quirks of IT schedules are an absolute must. Which once again goes back to choosing managers with backgrounds in IT. This is true for middle managers right on up to the director-level positions. As far as CTO/CIO executive positions go.. since it's more of a political position, I could see why someone not pure-bred IT might be a better fit. But then again, I think MBAs disguised as CIOs are a big part of the reason the IT market is in its current sorry state.
3. An even but -fair- hand. It is good to hold your people to their deadlines. It is BAD to pressure them to the point where they're rushing through their work and making mistakes for fear of not hitting a deadline and being publically lambasted by their managers. A SMART manager knows that his team's failure is HIS/HER failure as well.
Understand SLACK. (Score:5, Insightful)
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 [amazon.com] by DiMarco seems to be a good modern, complementary companion to the ever-favored The Mythical Man-Month [amazon.com] 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 down, look up! (Score:5, Insightful)
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!
I actualy have one of these. (Score:2, Insightful)
My word of warning, let your subordiant geeks do there job the way they want to. They may have a diffrent style, try to adjust to it. Good luck!
Listen. Listen. Listen. (Score:3)
Management horror story.
Reorg happens, I get stuck in a new team, with a manager who has a favorite group, and a least favorite group. I'm in the least favorite group.
He asks me to provide an estimate for a project. I tell him I can't until I get the necessary information from his favorite group.
He still insists on the estimate. I explain, in nausiating detail, how I can't give a reliable estimate until I have the necessary information.
He asks for the estimate again. So I finally give him one; as he wasn't going to go away until I did. Padded the estimate all to hell to make sure I had plenty of time, in case things got screwed up.
His favorites finally give me the information I need, and I do the project. It comes back from testing with all kinds of issues.
It turns out that the other group decided to change about 80% of the database after they gave me the information; but didn't tell me.
Needless to say, I missed the deadline. But it was all my fault because I couldn't mindread the work at home crowd. Two months later, I was involunatarily looking for a new job.
Listen to your employees.
What I Like in Managers (Score:2)
Fortunatly where I work, my boss pretty much does all of those things.
Political advocate (Score:3, Insightful)
i want a boss who... (Score:5, Interesting)
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.
Re:i want a boss who... (Score:4, Insightful)
There of course is a happy medium to being able to catch these slackers early without annoying those who get work done. How about code reviews once ever two weeks at least? Have the PHB be involved, but give the employees a stressless enviornment.
Listen (Score:2)
Listen to the developers.
Oh, and while you're at it. Listen to the developers.
PHB Deluxe (Score:5, Insightful)
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
No feature creep! (Score:2, Insightful)
recent job experience (Score:2)
What kind of PHB do I want? (Score:2)
ANY. Out of work since Sept 12th 2001.
Too late for special needs (Score:2, Insightful)
Time has passed when programmers/developers were given Aeron chairs and cappuchino machines. Now we are expected to work long hours and accept any conditions for what they are.
I am sure this is going to start a flame, but I really think so. Once you, my friend, will get into management, you will understand that your priorities will always be more important than of your developers, you will see that your decisions will make more sense to you and you'll push for that.
some developer suggestions: (Score:2)
...hand in hand with this is for big projects, do regular builds, preferably on a 'virgin' machine each week. This can be useful in goal setting/making as well as trying to avoid the "well it works on *my* PC" syndrome.
How about a boss that works? (Score:2, Insightful)
I wasn't in management directly, but when I was lead tech whenever I had a number of tasks to do I told my team I needed one less volunteer. I always picked up the task that no one else wanted to do and ran with it myself.
Personally I'm way more motivated when my management not only knows what I do, but can do it too. Not to realistic in today's corporate culture, but maybe it should be. At least it's true in the company I work for now.
What I want. (Score:2, Insightful)
Most important of all (Score:4, Interesting)
Programming knowledge (Score:2)
So looking at it from the bottom, I've found the best managers I've met have all been past developers, at least to a small extent. For some reason, it seems managers with no programming experience can not accept many of the statements of their programmers. One common mistake is to think the programmer's adding unneeded development time - "Oh, it can't possibly take that long" as he trims the project schedule. Maybe it's a trust issue, I'm not sure, but it sure messes up lots of projects.
Trust your most knowledgeable developers and get rid of all incompetent ones. One incompetant developer on a team seems to drag many projects down and makes the rest feel like they're making up the work of the bad programmer. Very bad for morale.
My biggest problem with management right now is to get them to open their eyes to all technological options. They look to MS for everything and assume they have the best solutions. They ignore more appropriate technologies because of a few senior people who are afraid of change. And the lower managers don't care about licensing costs, but their bosses sure do. The big bosses trust their managers, however, so while complaining of cost, they go right along with MS.
... had to stop myself before this turned into a full blown rant...
Addendum (Score:2)
We want... (Score:2)
Do not make assumptions... (Score:2)
Oh, come on... (Score:4, Insightful)
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.
I've been on both sides... (Score:3, Interesting)
What new managers and future-PHBs knew but all-too-quickly forget is that geeks really do know what is possible and what is not, and when they tell you what is Good from the tech point of view, you should listen real hard.
What techies who abhor management don't know, or at least fail to appreciate sufficiently, is that running a company involves all sorts of real-world trade-offs, and that technological Goodness is just one of dozens of factors that go into business decision-making. Having the best technology or product was never a recipe to business success (and the resulting ability to continue to pay techies and buy new toys).
Upshot: when the techies tell you how long something will take, believe them. Don't arbitrarily shorten the schedule to please the Big Boss. Have the guts to tell senior management the truth (this is the essence of "standing up for your people"). But when the realities of business balancing acts turns unfavourable to the techies (eg, top management says "no" to GPL code), try to explain the rationale and legitimate logic of the decision. Corollary: if there isn't valid logic to explain, then you've failed at the "tell the boss the truth" step.
Beekeeping (Score:2)
http://www.csn.ul.ie/~caolan/Texts/orson.html
Understand the "parts" of the product (Score:2)
All too often, management sees the product as one big "black-box" (i.e.: marketing perspective) -- until when they understand the different parts that it is made up of, ONLY than will they appreciate the complexity of the system and hopfuly they begun to manage better.
-----
what i wanted (Score:2, Funny)
unfortunately he made me redundant before i had the chance to see it
It's going to be a tough battle (Score:5, Insightful)
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^)
Re:It's going to be a tough battle (Score:4, Insightful)
I would love to code at a place like that.
I've asked my manager to let me have 5k a year less and let me work 40hours/week(I do that now) but on *my* time, if I wanna code at 3pm for 6 hours, let me.
His reaction "What if all the programmers want to do that?"
Hmm, 5K less a year * 12 happy coders == much better morale and tighter code, but my PHmanager won't do it.
Good luck... (Score:2, Insightful)
As I think a couple of other posters mentioned, even at the best companies its very difficult to keep a level head, and resist the pressures from upper management and marketing/sales.
As far as what I want:
- Assuming you do a good job in the planning phase and listen to your employees and make a schedule (don't laugh, it happens occasionally). The real trick is.....
6 months later when your boss wants to do another round of 'strategic planning'... Don't let them change all the plans again unless there is a good reason! It is very frustrating to constantly have the moving target goal as a developer. This is not to say that plans can't change, they always have to, but include your employees in the 'redesign' phase as well as the 'design' phase. I've seen plenty of good managers fall apart here when good plans had to get changed at the last minute
Anyway, good luck.
talk to us (Score:3, Insightful)
PHB (Score:2, Insightful)
- Able to manage the client's expectations! This has been the biggest failing of nearly all my manager's to date.
- Has enough specific technical knowledge and general intelligence to understand the task, the design, and the implementation, at least at a high level.
- Very well organized. Must keep track of all of a project's details, schedules, technical issues, budgets, etc.. Seems obvious but it's a good reason why I wouldn't make a good manager.
- Good communication skills (for obvious reasons).
- Able to hash out cohesive, complete, and unambiguous requirements with the client.
- Willing to kick some programmer ass (including mine) when they're slacking off. This won't win you friends amongst the programmers but will make projects run much smoother.
- Willing to act as a shield for the programmers to allow them to remain focused.
And still more: (Score:5, Insightful)
- 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.
Management rules to live by (Score:4, Insightful)
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.
10 Programmers Needs. (Score:3, Interesting)
2. When asking for the Time Estimate for a project to be done. Dont expect it to be fixed in stone. Some people overestimate their time and others underestamate. Usually programmers want to underestamate the time and their estimations is the time that it will take them to program if they are in top programming form witch most of the time they are not.
3. Try to keep destractions at a minimum. If you see the programmer staring or pointing at the screen try not to bug them because they are in usually in deep thought and need to concitrate on what is happening if they get distracted they loose it and have to start over from the start again.
4. Make sure that the tempture that they are working is confortable. A lot of time is spent on trying to warm up their hands. Or get groggy if it is to hot.
5. Allow programmer to distract them self with webbrowsing, games or personal contact for about an hour or so a day.
6. Try to have people work in teams. People have different skills and likes and dislikes. Although a programer should be able to do the other programmers jobs. But if one person likes making interfaces and the other likes more system level coding have them work together so the work get done faster and work with more effert because they are focusing on their favorate part.
7. Credit. Give them credit for their work. People like to know that they did something to make a difference.
8. Understand their morals. If the programmer hates SPAM dont give them a job to sort mailing lists.
9. Allow for the right tool for the right job. Dont force the programmers to use a fixed set of tools to get a job done. If your a web development company and you use FrontPage a lot. Dont discorage a Programmer who poped open a text editor to do some web development. The GUI may look nice but sometimes we need to go underneeth. Also the inverse is true to if you have all Text apps and the programmer is useing a GUI, Let him give it a try it may make the programming time quicker.
10. Keep their computers Up To date. Top of the line every 3 years or the Average system every 2 years. Or a chepo system every year. Your customers are using the modern systems as so should you. It helps to keep you on top of the new techoligy and by the time the project gets done is becomes standard. Also Less waiting for compiles and processing makes bug checking quicker and less painful.
Yeah, here's my advice. (Score:5, Insightful)
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 [slashdot.org] arrogant asshole.
Re:Yeah, here's my advice. (Score:4, Funny)
Re:Yeah, here's my advice. (Score:3, Insightful)
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.
Let's start out by not pretending that everyone is NOT of the same intelligence, shall we? Therefore, one person's "working hard" might be another's "bullshit busy-work". Just because you stay for the same amount of time a programmer does, doesn't mean you worked just as hard as (s)he did, and vice versa.
That said, it's not as if you can go out and claim any programming job without a degree, unless you are coding web scripts for Amazon. This is NOT programming. It's scripting. And frankly, anyone can learn to Script in 21 days. That said, programmers ARE very educated people and THEY make the product YOU are cold-calling people to trying to sell.
Let's pretend now that they didn't exist at your company - oops, now you have no job. I'm not saying that other people at the company aren't important, but let's not forget who is actually CREATING PRODUCT here.
Soda is 30 cents a can. Suck it up.
Exactly. If I make $40 an hour and drink 1 soda an hour, what's 30 cents more? Stop fucking whining.
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."
If you're "working hard" talking to a client, why are you in the development area? Typical of me, a developer, to blame management on this one, but shouldn't you be in an office so that even conversations at a reasonable volume won't disturb your conversations with potential customers? Seems like a no-brainer there.
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?
I don't know about everyone else, but I can't think when the clothes I'm wearing are uncomfortable. If I am more productive when I'm wearing jeans and a t-shirt then management will allow it. No one fucking sees me anyway, unless I go to the cafeteria and even then they probably think I'm on the janitorial staff. Who cares??
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!
It's funny you claim you're an adult - because after reading this rant, I don't believe it.
Re:Yeah, here's my advice. (Score:4, Interesting)
My guess is that if you think jeans and a tshirt are comfortable you have never had a pair of nice slacks on. I used to wear jeans and such. Then i discovered the art of Nordstroms and nice slacks. Yeah, they may cost $60 a pair. A good pair of slacks is like coding in pajamas.
I can fully believe he's an adult because I've had almost the same rant a few times. I've also worked in a really great development area that had no fucking special geeks with their damned starwars toys and imaginary light sabers and we did a lot better there.
There is no correlation between star wars obsessed dipshits and good coders. I view that as a deficit in their abilities. If they can't figure out how to behave in regards to those around them, they obviously don't have the problem solving skills necessary.
Outdated view of geeks (Score:3, Insightful)
clean
dressed tidily, if casually
socially adjusted
not likely to need to interact with clients
We may have some unusual needs for our work environment and many of the other replies have well explained the reasons for these.
My dream PHB... (Score:3, Interesting)
Lousy PHBs often want you to design something the way they want. Because they read an article about C# and
Geeks are efficient with the tools they know. Not with what you force them to use. If an employee wants to complete a project using QNX + WN + Python, give him the opportunity to do so. Don't judge him according to the tools he's using. Just wait for the result. It works? It has been finished on time? It looks bug-free? Ok. So why yell because the guy used his favorite tools instead of arbitrary recommended ones?
A geek will be bored, and inefficient if you force him to use software he doesn't like. The key here is : motivation.
3 Simple Things (Score:4)
2. Leave me alone until I'm done.
3. Pay me.
leave me alone = Recipe for disaster (Score:3)
There is a happy medium. "management is about balance" as someone else remarked in here.
Or, "don't go dark" as another project management guru remarked: If your project is in an unknown state, get it into a known state as soon as posible. Knowing that you are overtime is always better than not knowing.
My ideal boss in this case would:
- Orgainsise so that there is a real-world deliverable that will get used and bring feedback from end-users within six months.
- Help set milestones towards that occur regularly on the way to that goal.
- Make sure that activities besides coding take place, such as QA, code reviews, a modicum of design, documentation, etc.
- Ensure that the users are consulted so that what they get initially is vaugly usefull to them.
- Have a development meeting roughly once per week so that we can see if we are meeting our milestones, and if not, then revise our schedule, throw out features, or otherwise make sure that we are still in contact with reality.
Eighteen Suggestions (Score:5, Insightful)
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.
Middle Management (Score:3, Interesting)
We spent a lot (5 man years worth) of money developing an ad serving system. After it was put online, the upper management decided to change direction! They began to resell DoubleClick's ad space. Bizarre.
Once, when they cooked up one of their hair-brained schemes to make money, the developers had to cry out for a business plan to justify their decisions. As usual, they came up with numbers that were pulled from thin air and completely ludicrous. "Look, this justifies it."
One of the developers put together some statistics that were more realistic, regarding time to break even (it was over 20 years, in an ideal situation) His first draft didn't use enough pictures, so he added some charts. They still didn't get it.
Now said company is a spam marketing agency, using someone else's distribution lists, and someone else's servers to do the distribution.
I am ashamed to say I ever worked for such a place, but at least I know what not to do.
Moral of the story: Listen to your developers; anyone who can grok perl is probably better at math than your average marketroid.
Understand Basic Laws of Programming (Score:5)
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.
managers faq (Score:3, Informative)
http://www.plethora.net/~seebs/faqs/manager.htm
I could never manage at my company! (Score:3, Interesting)
This decision is made completely independent of that persons accomplishments, it is simply a matter of being on the low end of a very good team. I could never manage in a situation like this, in fact, I can barely work in it.
-Derek
What I love.. (Score:4, Funny)
And posted this on the door of our office.
if ((Date.DayofWeek == 'Friday') && (WorkDay == 'Over))
{
while (!PassedOut)
{
#include beer.h;
NumBeers++;
}
if (WakeUpInMorning)
{
Body.Mouth.TakeAdvil(NumBeers/3);
Body.Move.GotoBathRoom();
Body.Stomach.CoreDump();
}
Body.Sleep();
}
trust (Score:3, Interesting)
We're the professionals, we know what we're doing.
I worked for a financial orginization. There was a project that had failed twice, and they dumped it on some poor manager who didn't know the technology very well. So what did that manager do?
He hired an IT to be team lead, and said here's what we want, make it happen.
3 years latter thay had one killer application. It would of beendone sooner, but once people relized it was going to be a success we got a lot of upper managment leachs that new "what we need ot change".
total cost:80 million dollars. I know you think thats a lot, but we cut there total cost per loan so much, the made it back in the first quarter.
which brings me to my next point:
Rewards. We saved the company 80+million a month, they gave us baseballs. granted the complete team(developers, testers, document people, etcc was about 100 people) but still, baseballs?
no, what would have been cool is a bonus equal to a years salary. yes that would have been a lot of money, but nothing inspres employee loyalty then cash. They came to us with an idea that would save them another wad of cash, but because we busted are butt, and got the same thing we would of got if we didn't bust are butt, we all left to greener pasture. that was just as the boom was starting to ramp up pretty heavily, so it probably would have save them money to giave a hugh bonus like that.
in short
trust us, give proportionate rewards.
My short list of things to do for your team... (Score:4, Insightful)
Start the day with the idea that you are a tow truck on the expressway. Your objective is to remove as many obstructions that prevent your team from being successful as possible. Some are wrecks; some are just breakdowns. The tow truck driver's job is keep traffic moving.
Remember that some things cannot be removed by every tow truck. I cannot change the 401k contributions made by the company. I can get the client to test the PFB window because it is holding up the rest of the project.
Bill your team's time. Even if the company does not. Add up your team salary, double it (to include benefits, cost to manage their desktops, office space, etc.), divide by 2000 and you will get a rough idea of what an hour costs. The mistake I see managers make is to assume time is free if the person is on a salary.
I am strong proponent of the OA5 (Out At 5) Dilbert concept. If your team is constantly working long hours, what is wrong? (and yes something is wrong) Long hours should be the exception not the rule. Salaried workers are not "free after 40".
Just because someone asks for something right away, or declares it an emergency, does not make it an emergency. Ask the questions "How many? How much? How long?" Everyone should understand triage. (bill your time)
Watch for the 3:30 dump. This is common even among developers. I was notified of a problem at 10 a.m. then at 3:30 I dump it onto someone else as "not my area". This often results in unnecessarily long hours because now it is your issue.
Force teamwork. There are thousands of books on this. It is real easy to have 20 individual performers. It is hard to create a 20 person team. (Tip: I have found a a white board in the aisle for impromptu design sessions starts this process. It includes anyone who wants to listen. Team participation should be encouraged as newbies learn and wisdom comes from strange places.)
Ask your team what they expect from each other, not just from you. The 26-year-old college graduate has different expectations than the 20 year veteran. Some of it has to do with their personal lives (She does not mind working until 4.a.m. for six weeks straight), and some of it is experience.(He wants to see things go through change control, even 'trival' fixes, because he gets the call in the middle of the night).
Invoke the 360-degree appraisal process. This means evaluations by peers, teammates, and people working for the person and people who the person is working for. Keep it short. What three things can this person improve on and what three things do they do well?
Communicate with outside groups the status for your team. However, let your team take a role too. You do not always need to give the presentation or send out the status. If your team cannot commuincate, then that is an area to work on too.
Development is not like widget making. We wish it was, but it is not. Solutions come to people at different times in different ways. Some people are early morning and like to start at 5:30 a.m. Others are late night and like to start at noon. If at all possible let them, even if it is unofficial. However, be certain there is plenty of overlap so team dynamics get a chance.
CROSS TRAIN. Every person should be training someone else on the team to do his or her job. There are a few good reasons, but let me make the list simple: A team member goes to lunch and wins the lottery, or as a developer I cannot do project ZPQ because there is no one to take my position.
Never tolerate disrespect in any form against anyone. Everyone has frustration but disrespect is a different beast.
Finally, you cannot be part of a team if you are not there. Sit in the aisle with your team and listen. You will be amazed at how much is really happening when you are with your team hour by hour. Why does the customer call John directly? Why is Sue asking about a project that was completed three months ago? Mary, who hardly speaks in meetings, is the person the team goes to when stuck. Having an office is a great prestige item. Use it to meet in private or to have formal meetings.
Good luck. Being put in charge is easy, being a good leader is difficult.
Let's look at it from the other side... (Score:3, Insightful)
1. Let me know when there is a problem - early on so I can get help and resolve it. If a spec isn't clear, let me know so I can get an answer.
2. Remember, better is the enemy of good enough - at some point, it's time to let the working code go and not try to wring even more performance out of it - as long as it does what is needed.
3. Sure, writing documentation and help screens suck - but everyone has to take their turn in the barrel.
4. Don't keep trying to get your pet hardware/software through based on a project "need" or "solution." Yea, I know you want a bigger, faster box running Linux, but once it's clear that it ain't happening, constantly bringing it up as the "solution" to every problem is counter-productive. ( A real situation I ran into - one of our programers kept pushing a Linux server becasue he needed one for another project (that was on hold but that he wanted to revive))
4. Have a life - if your getting burned out, say so. Everyone needs a break, and let me run interference for you. As a follow-on, when the rules get bent to help the team, don't brag about it.
5. Finally, we're all part of the same team. As much as the engineer in me hates to admit it, without sales and marketting moving product, we don't get paychecks or new toys at work to play with. Th best we can hope for is to keep marketting and sales from lying to much when they make promises to a customer.
Re:Comical (Score:2, Interesting)
Ah, like,
Those who can't do, teach
Those who can't teach, manage
Yeah, I'm in stitches. I've been through periods where I couldnt' even read Dilbert because it was actually too close to the bone. Give the guy a chance, tho.
My dad worked 38 years at Dow Chemical, as a ChemE, and during much of that time it was a great place, because at all levels of management were people who started as engineers, and understood. Now the company is run by business people and, well, I don't hear a lot of good things anymore.
If you don't understand, you cannot manage! (Score:4, Interesting)
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]
Re:If you don't understand, you cannot manage! (Score:3, Insightful)
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 work well.