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
While some of what you say or suggest is true, the fact is that *everyone* here feels that they are more qualified to make the decisions than their PHB. But, when we look at the many posts to follow this one, we realize that regarless of what they think, many of these people aren't qualified to make any form of decision at all.
So, are you sure that you know it all?
Prevent higher up management from talking to me directly. Provide a buffer between upper management and me.
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.
Maybe once a month, or once a week, encourage geeks to stay home (and telecommute) for their jobs... saves wear and tear on them if they can code in their most natural environment once in a while..
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.
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
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!
I actualy have one of these geek-tech bosses. While this wouldn't be nessisarily true about all geek-bosses, he micromanages, A LOT. Since he knows whats going on he has an opinion about how everything should be done. It is incredibly agrivating. At the same time he does understand a lot more of the problems our group encounters. He also tends to get in the trenches and tech when we need to help. That has been a real life saver some times.
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!
One critical job for a manager is political support. Many projects have the potential to step on the toes of other groups. The project's manager needs to act as an advocate for the project. If a manager tries to smooth over conflicts and act as a peacemaker, the project will suffer.
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
The worse thing that a manager can do is start asking for more and more from the system. A good manager will recognize that the system is complete. Many managers, including mine, think of development as an on-going, never-ending process.
This could've been important 2 years ago, but now nobody in management really cares about your special needs. Tough market and economy means that you either take it or leave it, my way or highway..
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.
http://dtum.livejournal.com
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.
"The avalanch has already started, it is too late for the pebbles to vote." -Kosh
I want a manager that knows what the limitations are. Banging your head for hours on a problem might not be the answer when you could have redone it from scratch the correct way. Here's an example: just today I was asked to extract data out of an embedded processor on a board. There is no interface into the processor to get it out and the hardware possess no way of displaying this data. So, why the hell was I even asked to try when this is impossible?
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'
As a technical type who allowed himself to be pushed into the management arena, and dove back out as quickly as possible.... Good Luck!
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.
My manager is in a different state and I only see him 3-4 times a month. He gives me NO work or feedback... I have to dig it up myself from the users. In fact, he is a hardware guy on the PC side and I do Unix systems admin, so our talk is pretty much just "small talk". I've told him that I'm in the wrong group, but it goes nowhere. I wish I had a manager that I could talk with and who understood my work.
Must have the following qualities, in no particular order:
- 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.
- 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.
- Tell me what you want done, then leave me the hell alone to do it.
- If what you want for what I'm currently working on changes, let me know ASAP so I can compensate.
- Let me finish one thing before you start me on another.
- When I finish something, look at it, and give me some feedback; good AND bad.
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
I manage a small group, and my group has been highly successful in delivering "close to" on time and "almost within" budget. I have 2 pieces of advice.
1) You have to manage expectations to your customers. If marketing makes a change or asks for something, you have to go, ask your coders how long it will take, add some about depending on your expertise, then go back to your customers and make sure they understand that it will take that much extra time.
2) Minimizing bug creation always beats fixing them after your customers find them. Make sure that your environment in as many ways as possible minimizes bug creation. For example, I don't let tired programmers program! I don't care about the deadlines, if they're tired, they're useless to me and I send them home.
3) Programmers sometimes decide to get creative and add features or make assumptions that are contrary to business interests. You have to keep them on a tight leash. Have a good detailed spec that gets more detailed as time goes on. Keep the programmers to the specifications. Make sure they talk to you about decisions that may affect lots of things they may not know about.
There's others, but those are the the main ones.
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.
Steve McConnell has some excellent advice on managing a software team. Check out Rapid Development or any of his other titles. He definitely helps to balance the concepts of programmer freedom vs. responsibility.
Note that I'm all for having freedom to code without political interruptions and misdirections, but there are appropriate times for managers to intervene:
Siggy Wiggy Figgy Tiggy a bana bo Biggy!
First of all, u know this guy is bound for management because he probably thinks slashdot is a technical site. Anybody with half a cent of techical expertise would be able to tell you slashdot is more of a flamewar forum than it is a technical discussion. This idiot should either quit his job and get into a new profession (gas pumper, mcdonalds, etc.), or spend some time gaining expertise. Being incompetent in your field of work is bad enough as it is; being a incompetent leading a group of competents is even worse...
root> man -k lunix heterosexuality hygiene
nothing appropriate
root>
I want managers to understand one thing: it's their job to make my job easier.
If they understand that, they'll (try to) get me the resources I need, keep others off my back, listen to me when I speak, etc.
After all, we work for the same company. Our goals should be the same.
"The cost of freedom is eternal vigilance." -Thomas Jefferson
One of my biggest gripes is feature-creep. The essential functionality is planned out at the beginning, a realistic timeframe is projected, and coding beings.
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.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
Managing software developers is really a bit of a misconception -- "herding cats" is the common analogy. The manager's life [of delivering software written by geek-cats] is made easier not by pushing the cats, but by making it easy for the cats to wander and explorer in the direction the cats need to go.
You're not managing cats, you're managing the path that they're on or -- more precisely -- the demands that the business element places on them.
Get started by reading "The Mythical Man Month" (dated, but still very good) and any Extreme Programming book that deals with requirements and schedule -- as far as I know, they all do.
The short of it is, given a budget,
(FeatureCount * TimeToFeature) + now() = deadline
or
(Deadline - now()) / TimeToFeature = FeatureCount
And the business is never willing to accept that. But you're not going to herd your cats out of that mathematical reality. And that's why managers are worth money -- so that the geek-cats don't claw out the eyes of the evil whiney business people who still think that "push" is the way to herd because any feature can be done in no time if enough cats are pushed at it.
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.
The hardest thing about being a middle manager is building a team and making it work. Identify those who actually check in commented, debugged and efficent code on time. They will not be the same ones who kiss your ass and are bucking for your job (look in the mirror as well, you might just be one of those people). Select an experianced star to be you team lead and trust him above all others. Don't promote the butt kisser, that has been the death of many projects. Don't let you lead get bogged down in meatings. Ban marketing after the requirements are set.
Have zero tolerance for anybody taking credit for others effort. I've been on the short end of this, where I knew the boss knew better. He made a political calculation that keeping the project manager happy was more important the keeping the team lead happy. That was a bad idea, I cut down to 8 hour days and watched the project manager take rope untill he hung himself, then quit. The weasel did'nt understand why I would'nt break my back again (to earn him a huge bonus). I did'nt argue with him, walked to the presidents office and explained to him why I was gone. Even smart senior PHBs understand that the whole team knows who does the heavy lifting, nothing raises moral more then someone getting a just reward, nothing destroys it faster then a weasel getting an unjust reward.
Also keep at least six months of your personal burn in the bank. Otherwise your boss will force you to do the wrong things. Do that enough and you will forget there are other ways. To effectivly deal the the bastards you need to be able to walk away at any time.
A lot of the above is in conflict with one particular problem in the work place: slackers. These people come into work about 20 to 40 minutes late every day, surf the web and drink coffee for another hour, and then start work. They then do so in a hap hazard way, and pretty much try to hack their way through with no decent thought to the consequences. Then, when the boss asks for a status update, they simply say "everything is going fine." One example in particular that stands out is that I knew a consultant who was able to get away with this for 6 months. That was the end of his contract, and he had nothing workable to show for the time and money spent. There's 35k and a half year down the drain!
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.
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
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.
Let's turn this around shall we.
That said, salespeople ARE very talented people and THEY sell the product YOU are making.
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 SELLING the PRODUCT here.
Try working at a place that has lousy salespeople. As great as your code is, if nobody buys it then you're out of a job.
And yes, I do put out a product that people actully buy. There are no unimportant people in a company.
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.
I hope you're not pretending to be evil while secretly being good. That would be dishonest.
As someone who has lead technical projects, here's my viewpoint:
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.
I'm a consultant - I convert gibberish into cash-flow.
I will concede that you're probably right about programming not being a field where a non-expert would make a good manager.
However, your points do not illustrate this. Every one of those points represents a blunder on the part of someone other than a coder or lower level manager. Marketing decisions are not made by entry level coders. Weather to go with a GUI or CLI is not a decision made by a low level coder or bottom rung manager either. It'll be made at the top of the project, if not the top of the company itself. You also don't have to be a coder to make a decision like that. Just look at the world around you. What do you see surviving in the market? There's your answer.
Yes, I understand your point, but it was made by your more abstract arguments (prevention of painting yourself into a corner with bad code style, etc.). But I still wonder if this is necessarily true. Wouldn't this depend on your company's structure? How well you trust your coders? Netscape in it's prime, for example had the best and brightest. I'm sure it's coders were allowed far more latitude than say, coders in a non-glamorous code sweatshop like Norton or Corel or IBM. From what I know of their corporate culture, The same would not be true of Microsoft, but for different reasons.
And let's not forget coders for non software-companies. I have a friend that's a coder for a major pharmaceutical company. Should his direct manager be someone with a pure coding background? I doubt it. Since they have needs that he's not 100% sure of himself. His boss is a coder, but he has degrees in chemistry and that's where he spent most of his career. My friend is from a pure code background and he recognizes that he lacks the expertise to manage coders in this specialized environment. In a way, yes this supports your argument. But I do know that my friend is a better coder than his boss, and I'd go so far as to say the rest of his team as well (it's why they hired him in the first place without a pharmaceutical or related background). Does his boss give him leeway with code he doesn't understand? Absolutely. That's what they hired him for. If his boss audited every line of code he wrote, he might as well write it himself and the company would save ~$80,000 (not sure) or so a year.
Also, what happens if you're managing a small but diverse team? Not just coders for instance? Should the manager have to be an expert in coding and graphics and promotion and whatever else is on his team? Should he have to have 5+ years experience in EACH FIELD just to be a lower level manager?
I don't know about you, but I'd rather have someone with good leadership skills who knows NOTHING about his/her subordinate's jobs but knows how to delegate authority and will listen to his/her people. All the skill in the world is a poor substitute for good leadership. You don't pay managers to do a job for your employees. You pay them to make sure that they CAN get it done.
I used to be a member of a search and rescue unit. At one point, we got a new commander. A Lieutenant Colonel. Great officer. But he was from a Logistics background. He knew nothing of SAR. But, he listened to his people, assembled the best staff, and fought for us at higher levels in the chain of command for the resources we needed. Our unit flourished under his command until he was promoted to a higher level of command. He was a good leader. And because he knew his limitations, he was able to lead (well!) in a field unfamiliar to him. Our Air Crews and Ground teams of course had people of the proper backgrounds leading them (it's 100% necessary on an operational level), but in an office type environment? Not really. Sometimes I'd rather have a good bureaucrat in my corner in a sufficiently politicized environment. It means your less likely to get your budget slashed or people taken away from you.
Would I always seek a manager with a related background to a job? Absolutely! But it's not the only way to make things work well.
Touch everywhere, even when inappropriate.