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.
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.
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'm fortunate enough to work for a person who understands that she doesn't fully understand everything. However, just because she doesn't understand everything doesn't mean she doesn't want to know what's going on. When it comes to technical she asks us... We tell her our honest opinion / timeframe and she doubles it. As for the politics she handles it for us. We code. She keeps balance. it's a perfect relationship.
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.
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.
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.
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.
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.
Dacels Jewelers can't be trusted.
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