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.
This seems almost dilbert-esque. You are not able to cut it as a programmer, so the only obvious path is to advance to management.
- 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?
No, not possible. Never happen.
Can your IM do this?
praise once a year would be nice.
your jesus is another mans xebu. chew on that hypocrites.
A manager that reads Slashdot!
Encourage hourly pr0n breaks. Tell your management you're billing it as "administrative stress-management" time.
That's Mr. Eradicator to you.
trance-port
The best technical managers I've always had were ones that started out as developers themselves, and moved up into management.
Unix is user friendly, it's just selective about who its friends are.
It is a must read for any one involved in computer engineering. They reviewed it on slashdot a while back.
but I understand the 3rd edition Players Handbook is nice also.
What kind of GHB do I want? It's drug talk time on slashdot!
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.
security through obscurity = modding down anti-linux posts so maybe noone will see them
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.
A beautiful deaf, blind, mute nymphomaniac who owns a liquor store.
'Nuff said!
you shouldnt be a manager. Since you admittedly know little about software development or management, I suggest you stay out of both and go into the custodial arts.
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.
BOA Atm's run OS2 Warp
security through obscurity = modding down anti-linux posts so maybe noone will see them
However, having someone in charge over you is always going to be a stressful relationship, since stress tends to increase as control decreases.
I've been fortunate to "hands-off" bosses, the kind who tend to keep out of your work and let you do things as you see fit. And I've rewarded them with timely completion of tasks. Not everyone benefits from this type of business relationship, but at least it works for me.
+5 free karma to the person who manages to dig out the old Dilbert comic that asks this question and posts a link!
Or, perhaps, 'No One Above'. I like to work for myself. It's harder, possibly less pay, less guarantees. But at the end of the day, I have no one to blame but myself. And no one to thank but myself.
Be careful of PHBs who know a little programming. Kinda that "a little knowledge is a dangerous thing". Or those who know nothing "If C is good, C++ must be three times as good".
If you can, talk to people who work at a company. Just like you are going to lie, bend the truth, and put on your best face at an interview and in a resume, so is the hiring person/manager who you talk to.
Stay out of debt for a while. Keep driving that shitty car, and stay in that shitty apartment. You may get into a position that you hate, but be stuck in it due to debt and other responsibilities. Continue to stay flexible for a while. (That's why I'm not yet working for myself full time. F***ing mortgage.)
Sorry. Not really on point. But I hope it helps.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Of course, with that comes responsibility on our part to actually make the right choice, but we know if we lose that trust, life will be much harder.
Random Musings
The sad truth is that the PHB has an even Pointier-headed boss and so on up until we reach the Splendid Majesty of Satan who Owns The Souls Of The Workers.
As a manager of geeks you will come under ugly, ugly pressure from the next layer of idiots forcing you to make choices against your inclination, your will, it will be like an old 1950s horror film where your right hand is moving without your volition while the Demonic Forces Of Management snicker.
I forecast it will be under three months before you find yourself saying to the Unwashed Geeks in your charge that your Agree with their Point Of View and if it was In Your Power you would Do this Thing, But....
your boss would listen to you, not the marketing team. Perferably, he or she would be in a position where they could not be bullied by outside forces. What would be really nice would be to be included in those nifty meetings that the managers seem to have so much fun in, so I can raise my little hand and say, excuse me, but what you suggest is not feasible, much less realistic. However, since you seem hell bent on doing this, when I realease this product, feel free to take responsibility for having pushed this project so hard.
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.
Sent from your iPad.
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.
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!
Based on my current experience, I'd say that a manager who trusts you to make the right technology decisions is key. It's really about delegating. This is especially difficult for a person going from coding to management. For me management is about HR and resource management, not 'architecture reviews.'
----------- Sig what?
And don't play favorites.
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.
I like you, Stuart. You're not like everyone else, here, at Slashdot.
someone tell me?
Fortunatly where I work, my boss pretty much does all of those things.
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.
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.
Listen to the developers.
Oh, and while you're at it. Listen to the developers.
this is getting old and so are you
blog
The world seems to work on the Peter Principle where one is promoted to the level of their incompetence.
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.
- Firstly a good manager doesn't think of their team as a bunch of geeks
- Secondly the best managers are people who, if they weren't the manager, would have the coder's job. A manager who has been there, and done that is a great asset.
I recently found out I have ADHD, which made me a really good helpdesk tech. I could multitask like no other and was one of the most productive people there. I got along great with all of my coworkers and all the fulltime staff. Unfortunately, management didn't see it this way. I guess going above and beyond isn't appreciated as much as it used to be. I'm currently looking for another helpdesk job where I can geek out and fix things....and pick up some experience in the process.
ANY. Out of work since Sept 12th 2001.
Bitcoin pyramid: Join here: http://www.bitcoinpyramid.com/r/1427 it's FREE!
My job has a rather innovative idea ...
....
Keep everyone happy by providing lunchtime entertainment
They transformed the breakroom into a movie watching center, complete with 20" tv, this dvd/vcd/mp3/cd player, and a decent stereo....
Cheap electronics, let people bring movies from home, everyone's happy. It actually turned out pretty well: people knew that they had to get their current progects to a break point by lunch, to watch movies, and then they had a nice break, and were ready to work again.
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
Get adequate servers for dev work. PCs are relatively cheap. If you can set up a 'playbox' for each developer, as close to the final environment as possible, that can be a big boon. Too often I'm doing development on my NT desktop for something that's ultimately going to run on Solaris...it generally works ok because it's java, but any perl components and other things are likely to be screwed up. A linux box would be very useful, even if it's not in my cube...
...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.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
3rd Edition 2nd Printing Players Hand Book...You can't beat the D20 system!
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
More money (and mountain dew) dumbass!
Currently my "manager" is also the head programmer. Above him is the boss, who is a former programmer (also good). Apart from the eccentricity, life is good...
><));>
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?
First and foremost, she must be between the age of 18 and 25 and be strikingly beautiful. It is also absolutely imperative that she understand the benefits of having beer on top at the office. This is key. How can one expect to code anything without their trusty pitcher of Guinness by their side?
Oh, and I guess it's nice when they listen to you too...
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.
Background: CS degree, Full-time developer in financial compaies for over 5 years. I've worked for 2 worldwide companies with huge IT departments. I've had the opportunity to do just a little project management with consultants working for me.
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...
Developers: We can use your help.
is leadership and decision making through experience and training. Don't move up to management unless you've got the project experience behind you to know when to do what. Also, managers need to be technically detached enough to not get caught up in the details of implementation. Having been there before and knowing what causes setbacks and delays and bugs is MUCH better than being involved to the level where everything has to be rubberstamped before it's implemented.
And you've got to have the right face to present as the representative of the group. I can't stand it if I'm working under someone who's technically able to do the job, but a total social ass-bag. You're representing the people under you to the higher-ups and outside parties, ditch the jeans and t-shirt and act the part. Spiffy up.
I shed a tear for my now silent site linked below. Alas, I'm a continent away and she's dead, Jim.
DataSquid.net, a little about me.
to have a manager who actually manages, not simple a super programmer. That is, the manager should be someone who understands design processes, software architecture process, development processes, and manages the infrastucture to keep developers moving forward for whichever phase(s) they are currently working in. Technical experience is necessary, but studying management, including handling people and groups, is likewise necessary. This combination should result in a manger that doesn't make irresponsible promises (unrealistic goals). We know what happens when unrealistic goals are set: the geek corps to have to push the panic button, generally resulting in Bad Software. Reading something like Project Management : Best Practices for IT Professionals by Richard Murch (available from Barnes and Noble is a Good Idea.
I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher (1898-1972)
Act as a facilitator. Don't have your own agenda. Most importantly, allow individuals to define their own role. Given the choice, they will naturally choose a role that will compliment the efforts of their peers. Otherwise, don't hire them in the first place or fire them if they're already there. Peer pressure is the most important and effective form of "positive coercion", so allow people to state their projects and deadlines in the presence of their peers who will act as a witness.
As a non-management geek, here are some observations:
1 - A technical manager must run interference. There are a lot of things that need to be managed such as hardware and software tools. The manage rshould be on top of all of these things, not always doing as the geeks want, but providing what is needed.
2 - Manage non-technical expectations. Not allow the business type to make and change demands without understanding the consequences. This does not mean that things don't change, they do. This means that when the project scope is changed, expectations of delivery need to be changed as well.
3 - Honest feedback. I have had a lot of good managers. The best was one that sat me down and said "you are doing great expect in this one area. Here are some things to work on" yada-yada.
4 - Willing to step in and make decisions. Sometimes an executive type decision needs to be made. Make it and stand by it.
5 - Help eliminate office politcs. Decision making and managing expectations go a long way.
In conclusion, people work best when they are focused on a goal, have the tools to work with and feel they have the backing of the company.
See also: "Dogbert's Top Secret Management Handbook"
My biggest wish for the marketing/management types that i have to work with is that they wouldn't make assumptions about what is difficult and what is easy. For instance, they think of redesigning the whole look and feel of the U.I. as a minor cosmetic change, and they assume that changing some tweakable parameter in the code that does the real work is going to be difficult. The trick is that they have not always taken the time to understand the structure of the system, and aren't always willing to. They'll say "those are implementation details, you guys can do that however you think would work best", and then after the fact they will say "we want a change here". I guess the root of what I'm trying to get at is that anybody who is going to want code changes should make their needs clear during the design phase so the programmers know where to spend the extra time designing in excess flexibility, and where to spend their time writing a more optimized but less flexible solution. I know, people are going to say that everything should always be completely modular and flexible, and i agree, but it seems that no matter how much flexibility we design in, marketing comes up with one change that we have to rip up some serious code to accomidate.
---
Play Six Pack Man. I
Pick up Peopleware by Tom Demarco, it's a great book. Check out Deathmarch too.
Give me a nice chair in which to work.
Give me projects to work on without choking me with crazy deadlines.
Allow me to be creative. Being creative gives me a sense of ownership on the projects I work.
Understand 3 three virtues of a programmer as explained by Larry Wall. Do this and we shall get along.
I prefer the 3rd Edition PHB (Player's Handbook).
Having to figure out THAC0 was a pain in the ass..
You'll never make it playing the management game that way. If your boss wants your team to do project x in 3 months and you go back and tell him that your developers say it can be done in 10 months you might find yourself quickly replaced by a manager who can say "yes sir, we'll have it in 3 months."
I've been on many projects and the truth is almost all of them have been on time no matter how crazy the deadline was. A good team of developers will surprise you when pressure is applied.
'Same speed C but faster'
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?
The great majority of pain and anguish I've run into is when the PHB in charge demands that something be done to correct a situation that he himself has created. I'm sure you've seen it, the type where the only solution is to reverse his own decision.
Case in point, PHB wants to be able to immediately contact(24/7) any member of the department, and in fact communication has been his rallying cry for nearly a year. Cellphone bills are out of hand, and a quick look at them will show that IT is the ONLY department NOT abusing the cels. PHB's solution: ALL departments lose cellphones. Now PHB is angry he can never reach anyone and demands we find a solution. Go figure.
Now if you can look at that type of situation, as a manager, and determine that you may have in fact been mistaken in your course of action, then you'll be OK by me.
And I almost forgot: free coffee... ;-)
Developers: We can use your help.
A good manager first and foremost must realize that his employees know more about what they are working on than he does. Many managers mess this up and try to drive technical direction. That's not their job.
Second, flex time. Some guys like to come in at 2pm, let them. As long as they get the work done and put in a reasonable amount of time leave them alone.
Third. Leave them alone. Give them an office with a door of their own.
Fourth make any material they want available. If they want a copy of Knuth's Art of Computer programming buy it for them.
Fifth, send them to conferences if they want to go. Don't make them if they don't.
What being a good manager with highly motivated technical hard working people is about is communicating with others not in your group and staying out of their way.
Anyone who cannot cope with mathematics is not fully human.
I'm one of the lucky coders who happens to have a great boss. Of course, what makes him a great boss is that he's every bit as much a geek as the rest of us. He's worked as a programmer and a DBA for years, and then found himself in a management role.
The things that I appreciate is that he'll always ask our opinions - AND LISTENS TO US (unless we're in the car giving him directions - then he tends to get lost anyways), he keeps us out of meetings and lets us write code, and he does his best to see that we have all the technology we need and most of what we want.
Addlepated - punk & metal
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.
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.
Orson Scott Card's essay said it best. Managing programmers is analagous to beekeeping:
http://www.csn.ul.ie/~caolan/Texts/orson.html
I object to that article, and to the next reply.
I want a manager who understands the many "parts" of the product that I am working on (the building blocks, components, systems, what ever you want to call them).
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.
-----
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
Is just a little respect baby.
I think the basics of management should be about respecting the intelligence of your employes (not only true for technical workers, everyone has an intelligence of their own).
I think the worst PHB that one can possibly have is one that acts like "ohh, they can't understand cause they don't get the big picture". Most of the time, employees (or ressources) have a pretty good understanding of what is going on in a given project. Some of them may even know more than you tought they should know, just by simple deduction.
when it comes to techies (I manage three of them), I think that the key is to make them feel usefull, that they belong here. (unless they aren't being usefull and don't belong here)
Leave them some space and time to think, you'll be rewarded with both results and a friendly place to work.
(Forgive the poor english, I'm french-canadian)
was my manager's resignation.
:-/
unfortunately he made me redundant before i had the chance to see it
That man tried to kill mah Daddy
I had too many bosses that are blowoffs and will agree to anything (not actually carry it out) to avoid conflict.
My ideal PHB would be someone who would go to all the boring meetings, takes my word on technical issues, has command of the arcane SOPs and company rules and knows where they apply, and runs interference with the big shots and takes the flak from other depts and organizations in behalf of the technical staff, and brings home the resources we need.
On the other hand, Vince Lombardi was tough and hard to work for, but he was a winner. There are compensations for working with a boss like that, as well.
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.
A risk is an event that might or might not occur. Ask your team what the risks are. Document them. Have a contingency plan that the team and your customer understand. Better to be prepared for when shit happens than to assume it won't.
Also, the Capability Maturity Matrix is a good thing to be familiar with. The best managers I know have made it an integral part of their employees' professional development.
Oh, yeah, it's not easy to pad these out to 120 characters.
HURR, real creative variant on the old "Stephen King" troll there, buddy. Too bad you couldn't even edit out the "Maine" from the original.
Besides, even if the Hawkman were to buck the kicket, you can be sure that like his forbears in rockin' the mic, 2Pac and B.I.G., his music will live on for years to come.
- create a plan and stick with it
- provide direction
- ask for opinions of senior people and ask questions until you understand what's going on and why - listen
- keep your people informed (not spamed)
- respect, respect, respect
- micromanage only those who require it
- trust your people until they screw you over then give them one more chance
- if you have favorites don't let any of your people know including the favorites
- reward according to performanc
- show appreciation for good performance
-- ZeroZenith
Make your employeed feel part of the company, not just a hired gun to crank out code. Make them feel they are an integral part of the project, from beginning to end. Listen to their comments and integrate their suggestions into your project design. Make them feel the work they do is viewed more than just a bunch of code but rather an a product that they should take pride in. If management thinks they are just a bunch of code monkeys without brains or any kind of business sense then they won't respect management, they won't feel the same pride in the work they do, they will be less loyal to the company and they will most likely produce lower quality work.
Also, keep the developers informed as to what is happening on the business side of things. You may not think it matters but the developers will work much better if they have a clear idea of where and how the software they are using will be used. Keep your developers in the loop at all stages of the product development cycle. It makes them feel more important, they will be happier and will produce better software.
So, to summarize:
1. Listen to your developers and pro-actively ask their opinions, thoughts, suggestions, ideas.
2. Communicate to your developers how their work fits into the business plan especially if/when a business plan might change.
Most managers are hired for thier ability to "smooth" things over, good shoveling skills required. Higher management could care less about the day to day dealings with peons. A good manager is someone who can deal with higher managment and still work with the co-workers. A employee who was promoted helps, or a person who has technical background helps. A non-technical manager can bite you on the ass when they misunderstand facts and requote you to higher level management or other company groups. And the saying shit rolls down hill is 100% true, most good managers will shield you from the politics and let you do the work.
Being at a large company, Ive seen managers come and go every year. There has been super bosses that wouldnt care about your lunch hour ran late, to the extreme who would want you to clock in and send daily status reports of your phone calls, meetings and emails. (Total control freak)
The current manager is into office politics. Office politics are at an all time high, I currently spend 3 hours a day just in email to make sure that my ass our the rest of my group doesnt get blamed. But on the bright side, I smile knowing that all the shit my manager has to deal with Service outages and bad planning.
Sounds to me like you are trying to shift the paradigm from top down to botton up management!
good luck......
Rick B.
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.
I'm not a great hairdresser, but I love hair and especially hairdressing. Those professional hairdressers that I know often complain of their managers not understanding the hairdressing process and having unrealistic expectations of hairdressers. 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 hairdressers and hairdressers, want from your immediate manager? If there are any beauticians out there in upper management, what do you want from your lower-level managers who keep the hairdressers in line? I'm not asking for the basic 'stand-up-for-your-subordinates' advice, but rather requests from a hairdresser's standpoint. Hairdressers 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 shampoo girls to heart. Many times managers will not consult their hairdressers when they make plans, they'll make the plans first and tell their hairdressing 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.
love is just extroverted narcissism
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.
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.
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
But...
All too often development managers are such because they couldnt hack being a programmer. One of my previous managers had not coded in 8 years. And her last language of expertise was C in the Unix environment. When I worked for her, she was trying to manage an NT based web application on the enterprise scale! She joked about how she was "allergic" to coding, and basically did nothing for the project. Needless to say the project failed.
My point is that the best managers were once VERY capable coders, and, most important of all, STILL COULD BE.
A good manager is first a good coder (so he can relate to the staff he managers), second a good communicator (help translate techie talk to business speak for the stuffed suits), third a good filter of the politics and rumours, separating the fact from the BS and the relevant from the irrelevant.
If you want to be a good development manager, first establish a reputation as a good coder and you will gain more respect from those people you will manage.
IT talent is expensive; find room in your budget to give your developers good tools when they request them. It could wind up saving hundreds of man hours over the course of just a few months. (And remember, an employee who is denied $700 for a good IDE WILL wind up wasting a few solid days customizing emacs to be a viable editor; now you've wasted thousands of dollars and you don't even have a license to show for it!)
You're kidding right? Tupac isn't dead.
Since I have been there and done that, let me give you a word of advice.... The first thing you need to learn is to sell, and nextlook for your next place of employment.... Your idea of "what do the programmers want" is beautiful, but you will soon run into the brick wall of egos, politics and EBDITA, and the question will come down to do you want to pay your bills or be Mother Theresa. The only way to make it is to be able to sell yourself above, and once you can do that repeatedly, you will find out that all that programmers need is to be treated as a person. Be aware, you will have to learn what "a person" means to each one of them, as well as what factor to apply to each one to "normalize" their productivity and needs....
take credit for failures
place blame for successes on their employees
Is a book that I am sure you can find on amazon. It talks about exactly what you want in ANY boss. Works especially well for coders.
Please make sure you look at things from your coders perspective, and keeped them sheltered from but aware of customers and upper management concerns.
Root the horrible developers out (possibly by requiring people to get advance degrees if they don't have them). They really do make work a drag.
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
Words & phrases managers should never utter:
-"Appropriate"
-"Entity"
-"Mission Statement"
-never refer to what your company creates as "product"
-"Synergy"
-"Action Item"
-"Team Player"
-"Content"
-"Value-added"
-"Customer"
-"Positive/negative attitude"
Euphamisms & other false statements you should avoid:
-"Improvement Opportunity" when you mean "Fault" or "Weakness"
-"I'm not directing this to anyone in particular," when in fact you are
-"Everyone says _______," when in fact only one or two people say _______
-"Our customers sign your paycheck," when in fact the company signs your paycheck.
And if the pay wasnt good you wouldnt stay, Its hard to work for a place that makes no sense, but the paycheck keeps you there. (Until your resume on monster pays off)
So it's fairly simple what is expected of a manager, be it middle, or C-level, whatever. You as an employee have the sole responsibility to your manager of making him look good to his managers. And his (or her
In the last six years of being in this field, I've had numerous jobs, more numerous managers, and I have only had ONE manager who dealt with management this way. I busted my ass to make him look good when it came time that he had to report to his boss on the goings on of our dept. and he kept me happy, gave me raises when I needed, let me take time off when I needed it, etc.
Amazing what works, eh? boils down to respect, I guess.
"See, we plan ahead! That way, we never have to do anything now."
- 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.
A dead one. :)
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.
Honestly? I want less managers. Become a programmer instead.
Failing that, learn to take long, far-off business trips to different countries. Sandwich those business trips between weeks of vacation and offsite conference attendances.
Just stay out of the office and let me code in peace!
The one piece of advice that I would have is to try to understand what motivates software developers. If you can do that, you'll be on your way to being a good manager.
One mistake that I've seen frequently is for managers to cut features that are viewed as unnecessary when the schedule slips, as it inevitably does. Often the features that are the first to get cut are the ones that are enjoyable to work on, and so the morale of the development team falls, which causes the schedule to slip even more. Instead, if each developer has a few small "pet features" that are in the "nice to have but unnecessary" category, that will go quite far in motivating people.
If 95% of your job is uninteresting crap but even 5% is really enjoyable, then you will be much more motivated than if 100% of your job is uninteresting crap, and much more uninteresting crap will get done. The idea that a project can get done faster by adding features is alien to most managers.
So I can get some actual work done. Nothing is more exasperating than wasting a day making charts and supplying status so somebody has beans to keep them busy while my project slips beyond deadlines.
i would like a printout of my account balance.
Also, I would like to disagree with neal n bob in reference to your first post link, as that was a valid and original first post. I believe he was possibly being a sore loser.
security through obscurity = modding down anti-linux posts so maybe noone will see them
"..or even say it better than I can."
Are you implying that any of us could be more eloquent than you? Impossible!
:)
-- If no truths are spoken then no lies can hide --
Those that can, do.
Those that can't, become managers.
I ask you, I *beg* you in fact, to PLEASE tell me the company you work for. For my own future career plans, I will need to avoid you like the plague.
- 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.
You are going to have a rough time in management if your main goal is pleasing the tech staff. Quite the opposite, a manager's job is often to kick some butt and get people out of their comfortable zones. Too often, business as usual is not good enough, and its the manager's job to get people to perform better and faster. Encouraging people to expand themselves and their abilities doesnt always come easy.
This doens't mean you have to be a jerk to do your job! But you also cant be a fawning enabler who helps employees underperform.
Management is a skill, very different from coding, and not usually as pleasant. It is your job to make the right decisions, even when they are unpopular, perhaps even when it hurts someones feelings. Secondary to making the right decisions is making people happy about the decisions you make; certainly thats a good thing to do, but the priority is clear!
I wish Wizards would just make a Players's Handbook (PHB) with all of the other character and spell books added in. I hate having to spend 20-35 bucks a piece for them when only the initial PHB is really worth it. Thanks for listening :)
GeneralKael -- Slacker Extraordinaire
Never say, I thought all you had to do was drag-and-drop...
Also -
1. Read between the lines of marketing fluff. 2. Listen to your developers, they are the experts.
http://www.askthevoid.com
Yeah... this is typical.
I'm in the CSci program at the Univeristy of Minnesota and all the kids who couldn't make it through scheme and java in 1901 and 1902 because they were sucky programmers transfered over to the Carlson School of Business so that they can become the bosses of the people who actually DID have skill in the field.
Typical.
My best boss knew nothing about programing. That is what made him good. He knew that he couldn't make technical decisions so he didn't try to. Instead he ran the scheduals, interferiance with upper management, and drug requirements out of marketing.
The worst managers I've seen try to make technical decisions, and do the design. The design is the fun part, and by doing the design yourself you understand it, so management should NOT do it. Not only will management screw it up, but they will screw up everyone else too.
Don't try to code. If you want to write code, I know several open source projects that need your help. However if you know how to code, you are probably a poor manager. The people skills needed to be a good programer are not often found in good programers, and the act of learning how to program gives you too much knowlege, and will tempt you to get involved where you should keep your nose out of the works.
Many posters seem to want a manager who has plenty of technical knowledge. I don't think this matters at all. I've had managers with no tech knowledge whatsoever who did a great job. I've also had managers who knew more about coding then I do who sucked as managers. The skills required for being a good manager have nothing to do with the skills required to be a good coder. Managers need people skills. As a manager, you are responsible for the work of others, but you can't do all the work yourself even if you have the skills. That means you need to develop trust with the people who work for you, and that means trust both ways.
How come I can't seem to get the STYLE attribute to work with INPUT TYPE=hidden
..?
Torture the people who work for you.
Believe me, they will stick it to you first chance they get. Might as well have some fun with them in the meantime.
Sorry guys, but its true.
I used to be a nice guy, tried to do the right thing, and most people will crap all over you. I gave up treating people nice.
Take a look at the Extreme Programming project at http://www.extremeprogramming.org . It has a lot of useful tips and.. who knows.. a whole process you might want to adapt your staff to. I know at my company we've been trying out different elements of X/P, and we've been getting more efficient every step of the way. This sort of approach to development is refreshing to many, and the only way it is effective is if you, as the manager, push it and work by it.
Kein Mitleid für die Mehrheit.
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
1. As a programmer the things that usually gets to me the most is having more then one project, When I am programming I want to focus on my job and not a buch of jobs.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
If you are able to observer a person with his/her family in an unguarded moment and this person treats the family with respect, making them feel special, then the odds are that this is a quality person.
This has been an unofficial rule of mine for many years, and as times goes by and I get to know people better, it has been confirmed and re-confirmed.
I know I should reply to a comment rather than start a new thread in here where possible, but the idea I wish to convey is present in many comments here.
/. religiously, code in C, and an at 26 am being groomed for top management in one of the largest organizations in this country; I feel here I am qualified to drop a few remarks in the direction of this topic.
,mainly because they lack the motivation to check their work before passing it on. Ideally, however, they would want to be insulated from the needs of management; they should only be exposed to the requirements of their direct superior, the IT boss.
I'm a suit, and a would-be geek at once; I read
We have a smaller IT department, and I have found my work with them to be uniquely frustrating
The IT boss here would be the responsible person for translating vague management requirements into specific IT-related tasks. This reporting system requires these queries to be run at these times.
eeks don't understand suits and vice versa. This is not a judgment, it is a reality many of us face. There has to be a translation function, an interface if you will, and this should be the function of IT management.
Blearf. Blearf, I say.
I am going to paraphrase one of the required management classes I had that none of the other manager ever seemed to attend.
Theses are the different types of employees.
a. Unknowledgable but enthusiastic.
b. Unknowledgable and in dispair.
c. Knowledgable but need motivation.
d. Knowledgable and willing.
This represents the graph of our motivation to ability as we learn a new task/job.
Employee A need to be told what to do.
Employee B just realized how daunting learing this task/job is and needs to be told what to do and encouragement praise to keep him going.
Employee C needs support and praise for motivation but doesn't need want technical help.
Employee D wants a project and everyone to get out of his way so he can do it.
If you treat any of the different types of employees wrong you'll just piss them off. You need to explain to your employees why you are treating each of them the way that you are in areas (a type D employee with device drivers may be an A employee in web apps.) and listen to them if they don't like it. Recognize that employees grow and learn and change the way you treat them accordingly.
Try to grow all of your employees into catagory D.
The most important thing in my book, is for a manager to shield us from the bureaucracy and let us stick to what we do best, which is design and code systems.
Another nice thing would be if they knew what they don't know. In other words, it's very frustrating when they try to get involved in technical decisions with ramifications they don't understand.
Finally (and this is related to the previous point) it really annoys me when managers start spouting jargon that they've heard at a trade show or in a Microsoft commercial. We actually had this one guy who wanted a fairly large, customized, dynamic web site, and who claimed that it should take us about half a day to do, because Microsoft provides that sort of thing "out of the box". Yah, whatever.
"Luck is the residue of design" -- Branch Rickey
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.
and it was stolen. Hmmmm. guess same result either way.
If I'm developing for Unix, let me have Unix
on the desktop, and don't make me use MS Office
or some other standard environment that means I need
to flip between two systems using a KVM. Be
responsive when I want to install vim, viewcvs,
and other tools that make me more productive.
Actually, my current boss is being quite good about
the second, it's just the first that's irritating me
For every problem, there is at least one solution that is simple, neat, and wrong.
Lead, follow, or get the hell out of the way.
Explanation - I don't want a touchy feely manager, a paper-pusher, a weenie. I want a leader. You don't have to be super-tech, or Joe Cool, or an uber-boss, just an effective leader of men. And women. You know what I mean.
Display some adaptability.
Amazing that average-level programmers end up being would-be managers....
Developers don't need managers - they need people that are developers too but fed up of pissing down code.
To be a good manager for your programmers, be a programmer first, then after 10 years of trying to explain to people what's good/what's bad in the code they write, you can be a lead developer that would take over the design work and make sure quality code is written by your team.
You then switch naturally to organisational tasks.
But I have never seen a real developer becoming a manager, as I have never seen a manager managing developers properly without being a developer himself.
Developers are aliens on this planet and should be treated as such.....
Anonymous coward team leader.
This is only one piece of the puzzle, but one worth mentioning:
http://www.pmi.org/
I took their certification test (missed it by one point! DOH) So I can vouch for the quality of the material & cert.
***read on for more or less usless chatter***
p.s. I am in no way affiliated with pmi.org, just posting it for the peeps'
p.p.s. just got a new job with a new software devel co, and EVERYONE HERE IS ON THEIR SECOND SYSTEM. those who have read MMM will pray for me tonight. Also my manager is an air-head with no balls, so you can expect me to be laughing all the way to the funny farm.
*if you're giving your current employer the BOZAK as soon as the economy picks up wave you hand in the air and say Ho Ho
**yea this is going out to all my bros takin the big pay cut in 2001. Stay strong my brothers, we will prevail.
I'm in the same situation at my current job, where management doesn't understand the concepts and time required to do what needs to be done. That said, the most important thing I think a manager could do is try to understand that as programmers, when we give a time period to get something done, it's generally the minimum amount of time needed. Programming is something that takes time, and GOOD programming takes even longer. I would think it would also help to familiarize yourself with the project, and if possible try to learn some of what the programmers will be working with. I say this because I frequently get programming requests which seem simple to other people, but are actually somewhat difficult to implement. Sometimes, the reverse happens; a complex sounding request is actually quite simple to implement. Just learn to trust your programmers, and realize that very few of us are lazy. Most of us will work as hard as we can to get the job done as soon as we can.
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!
I think a lot of what you need to do is be a communicator and translator. Management gets a bad rap, often, because they do not have the training to understand software engineering. To be fair, however, most coders couldn't manage their way out of a wet paper bag (see also: dot come bust). The two groups speak different languages, and one primary task of any middle manager has to be to translate for both groups.
This goes beyond merely translating language; you also have to interfere with ideas. From managements standpoint, everything needs to have a hard deadline, a solid budget, etc. In engineering this is impossible. Similarly, (one of the most amusing things about programming, in my opinion), for coders, my way is best. It doesn't matter who I am or what I am doing, my way is best, management's way is stupid. Neither management nor the engineers are entirely correct. If you can successfully filter ideas so that management learns to build in some flexibility and the coders understand when seemingly Dilbert-esque requirements are unavoidable, you will be respected, valued, and trusted by both groups.
For what it's worth, I think you're making a good decision. The idea of having coders managed by people who have never written any themselves seems awfully silly to me. The CEO probably hasn't written any, and probably doesn't need to. But someone sure needs to explain how it works.
-db
I imagine this might appeal to some sort of
'revenge' urge, and perhaps might even work
to some degree with really lazy workers, but
I seriously doubt that proficient people really
work better when they're unhappy or uncomfortable.
You'll likely convince people to cut corners,
spreading bad attitude, or quit.
For every problem, there is at least one solution that is simple, neat, and wrong.
...don't fsck with me!
would be someone that simply want the project (or the network, or the database, according to what's your supposed to do) to *work* regardless of the *ways* it works.
.Net in a magazine, they want you do use it even if three lines of shell would achieve a similar (and bug-free) result. They have pre-established ideas like "Linux is unreliable", "MySQL is better", "Apache is supported, use nothing else", "Always design your project with UML first", etc. And they don't even want you to prove them that something else can also work.
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.
{{.sig}}
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>
1. Give me a cool project to work on.
2. Leave me alone until I'm done.
3. Pay me.
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
In my experience under good management, those that managed the people first and foremost were the best. I found that when they managed people first, if the people were talented, the projects mostly managed themselves.
Sure there were times when the manager would step in to make a decision, or change things around to fit a changing schedule. But for the most part, when the project management took a back seat to people management, things worked smoothly, and people were happier.
In conjunction with this, I think it is important for management to leave me alone. By that I mean, take a decision, inform me of it, and then leave me alone to implement it. It's important to have a daily presence to keep me up to date on news, etc..., and to ensure that I am making useful progress. However, stepping in all the time with phone calls and other interruptions is distracting. Condensing those activities to a once-a-day schedule would help keep me focused.
Finally, managers should provide useful guidance on both project and organizational issues. Management should be able to answer questions when they arise, or at least help me interface with those that can answer questions. Don't leave me stranded and expect me to somehow get through on my own. I need support to get my job done in an efficient manner.
You can always sell your house. You just get comfortable, that is the problem. If you want to do something put your balls on the line and do it. Hell I am. I've been developing a product for 2 years and I've saved enough cash to get it started and run without sales for 6 months, maybe more. I have it planned from no sales to overwhelming success. If you want to be successful at your own business you need 3 things, balls, brains & luck.
If you fight as hard to succeed as you would to live if you were drowning you'll succeed. If not dont bother.
Perspective makes everything possible.
Most importantly, I want a boss who is not a fucking moron.
:)
I want a boss who realizes I know more than him when it comes to technical things.
I want a boss who shares information with me, and keeps me informed about the politics at upper management, but also shelters me from the bullshit that comes with it.
I want a boss that defends me and looks out for me within management.
I'm lucky. I have a boss that does all those things. Not to mention, since he's a retired Colonel in the US military who works in Canada now (he used to work at the Pentagon, even), he has _lots_ of really cool war stories to share!
Jason.
I have been thinking about making the same transition in the not-too-distant future and I have been resolving to learn from my experiences under management with no software experience.
The big thing I have 'learned' is to trust structured process. A few months ago there was a review of a book about web redesign...we all pooh-poohed it as un-needed. The process though is there to protect the developer by providing an environment in which the goals are clear and the terms of success known. This also protects the enterprise and upper management and if you, as middle management, remember to articulate that to BOTH sides you will have a much easier job. (that is my theory and I am sticking with it)
This doesn't mean if the developers screw-up you can't play whack-a-mole with them but you have to make sure that the screw up is on their part and not as a result of mis-set priorities or expectations....therein lies the importance of those requirements documents and all that happy crap...
I think a boss should first of all know the staff under him and what their abilities are.
Know what each of them is good at and learn what each one wants to learn.
The biggest thing I can think of is to give credit where credit is due. The people that piss me off more than anyone are those who take sole credit for the work that their staff does.
So maybe it wasn't two cents worth.....let's call it a cent and a half then round up.
One thing I've noticed in my brief stint at a consulting firm is that whenever a technical person from the client is invited to a planning meeting to discuss what the goals of the project are, they get into the technical detail - where they should be looking at the project at a higher level, at the business process level.
My boss generally leads the meetings and I'm only there to get some experience at these meetings (I'm a developer - 8mos experience.) Also, I read in 1 post that when a tech says something can't be done, and the consultant says it can that one should listen to the tech. Personally, I would make both of them back up their statements before blindly accepting either answer. Documentation is not that hard to find these days.
A consultant should be someone (IMO) that specializes in a specific area (Doc Mgmt, ERP, Workflow Processes, etc) that a business requires guidance from - otherwise, you'd be using a tech who already works for you.
Umbrellas are good. I've had both.
Stupid job ads, weird spam, occasional insight at
You all miss the whole point of business. It isn't for a bunch of technocrates to cater to a bunch of techies, it is to make money for either the executives or owners of the company or for the enhanced glory of the executives (defined by the excutives and hard to generalize).
So from a middle management point of view, you either support the goals they executives and are good or you don't support their gaols and are bad. I can't belame middel managers for their lack of control, power and general willingness to do what ever executive management says. It is the name of the game.
So if you move in to middle management, don't let the powerlessness and being between a rock and a hard place get you down. Be as fair as you can without loosing your job. Take the blame for failure and don't let it bother you. And don't let you former geek friends ride you too much. (Yes former geek friends)
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.
Shit happens:
"I can be self-referential if I want to," said Tom, swiftly.
How about a company where the coders ARE the 'bosses.' Obviously this only works for smaller companies. But small is beautiful, especially with Open Source development. Get a really tight team together and provide a unique service in your area.
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.
Well said!
www.jmagar.com
-
I think that all managers, not just the ones who who herd geeks, have to be good with people first and foremost.
In my experience the best managers are acombination of psychologist, administrator, cheerleader, bookkeeper, and nanny.
You know the sort (hopefully) - The ones who credit their team after a success and blame themselves after a failure. The ones who listen to your ideas and sets you straight when you've been an ass. The ones who make make you feel like you're a part of a conspiracy, rather than someone who's being exploited by it.
About 1 in 4 managers (or less!) are like this, or are at least trying to be somewhat like this.
A manager who has coding, network, engineering, etc... skills has a big advanatage when herding geeks, but his/her human being skills are what really makes the difference.
The only thing that we learn from history is that nobody learns anything from history.
When possible, she doesn't try to manage engineering as much as she tries to assist engineering. Even when being firm, she still feels like she's being supportive, and trying to act in our best interests.
She keeps her overall focus on the work getting done. It doesn't matter if we come in late, leave early, or keep Baily's in our cubes to add to our coffee -- so long as we get our work done. Correspondingly, she knows when to look the other way (often!), but also when not to.
She's sympathetic to what's going on.
Her door is always open.
Get most of these things right (particularly the first few!), and it's far to go too wrong.
1. Death March: The Complete Software Developer's by Edward Yourdon
2. Peopleware : Productive Projects and Teams, by Tom Demarco, Timothy R. Lister
I know there are plenty of books out there but these are a few that comes to mind.
Everybody needs to work on a goal. Give the geeks plenty of resources and all the available chance to get things done, AND STAND OUT OF OUR WAY! =)-
- To every complex problem there is a solution that is simple, neat, and wrong.
First, realize that leadership is a discipline in itself. It can be taught, but the underlying capacity to lead is something some people have and others just don't. Most companies have *zero* leadership training. Those organizations that do have serious leadership training tend to prosper - take a look at how IBM and GE train their people to see what I mean.
Second, remember that the best leaders always lead by example. People don't listen to what you say as much as they watch what you do. If you're honest and direct with them, they'll usually reply in kind.
Third, remember that leaders build teams. If you can create a team that works together, where everyone feels involved and informed, you'll find your task much easier.
Leading well is difficult, and nobody will ever pat you on the back and say "Gee, you're a great leader!" but the effort you put into being a leader as opposed to just a manager will pay great dividends.
One more thing - don't try to be someone you're not. Ghandi was a great leader, and so was Patton, but obviously they had very different styles.
Read the EFF's Fair Use FAQ
Some time ago, Eric Schmidt (pre-Google, still at Novell) did a bit with Fast Company:
(from Fast Company, issue 25, page 174)
How to Manage Geeks
by Russ Mitchell
Eric Schmidt, CEO of Novell, believes that "geek" is a badge of honor.
(After all, he is one!) But how do you manage these geek gods? Just
follow his nine-point techie tutorial.
http://www.fastcompany.com/online/25/geeks.html
Some of the concepts and references are a bit dated, but it's still a pretty good take on what we need as geeks to get by (flexibility, projects we can sink our teeth into, peer review, etc.). I share it with all of my bosses, technical and otherwise.
Let people lecture you on how their stuff works. Don't be afraid of too much detail, but don't put up with overobfuscation either. Understanding lies in being able to explain.
Pushin' 'n dealin', shovin' 'n stealin'
I once worked for a dot-bomb banner advertising company in Vancouver.
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.
I'd rather have a dumb boss, one that's easy to manipulate. Their brain should be about the consistency of play-doh. Not as soft as, say, rice pudding, and not as hard as stone, but somewhere inbetween. Nice and malleable, that's the perfect boss.
You don't want a smart boss, they may figure you out too quickly.
Slashdot. News for Zealots, Stuff that matters (if you're a linux zealot!)
Lead, follow, or get the hell out of the way.
Steve's Computer Service, Hobbs, NM
http://freshmeat.net/articles/view/157
The group I'm in actually have a lot of these practices in place, and life is beautiful for us geeks...
-- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard
1) Adding more people (especially entry level) to a project does not get it done quicker.
2) Most of the time, one cannot justify reducing the schedule of a project by equally reducing the requirements as requirements are often interdependent.
3) Every moment a programmer spends filling out paper work, attending training, or attending meetings goes against productivity by a factor of 2. Productive programming requires long uninterrupted durations of time. If these things are required, block them together to maximize programming durations.
4) Some problems just can't be solved by throwing money at them. Therefore it is important to have a knowledgable person within each team to determine whether something is technically feasible. Essentially, management should generally not try to determine the technically feasibility of a task.
5) Large teams are not more productive. While it's tempting to float unproductive people on productive teams, the team will take a huge productivity hit. It makes more sense to have some projects fail and other succeed rather than having everything delivered half-ass.
I partially agree with some of the things expressed about not given in to the dot-com type attitude. Managers really have to crack down on people that goof off too much. Goofing off too much should be judged by the individuals productivity and how their goofing off effects others productivity.
If you have a guy that helps everyone and is 3 or 4 times more productive than everyone else, then if he is surfing the net, leave it be. On the other hand, if you have an individual who hasn't written a working line of code in a month and sits around chatting all day, well, then a manager needs to step in.
The flexibility of a programmers work habits should be a priviledge, not a right.
int func(int a);
func((b += 3, b));
More and more these days, I'm finding I get brought in as a contractor to write code, then I get "promoted" to team leader, then sometimes "promoted" further into some sort of management role. Not sure if this is because I'm a crap coder, or what...
Anyway, here's my approach in a nutshell:
- remember the things that pissed me off. Ever-changing requirements, people breathing down my neck to get me to work faster, being kept in the dark, etc. Sounds obvious, but don't do that to your own prople
- different people like to be treated in different ways. If you've got a guy who likes to be given a job then locked in a room for months while he works in complete isolation, don't bug him for status updates every few minutes. I've got one guy like this now; I've found that emailing requests for status updates to him, even though he sits next to me, works fine and I get a concise summary of where he's at the next morning (also in email). If you've got a guy who likes to be patted on the back, then pat him on the back at every opportunity
- "team meetings" generally get everyone pissed off. Try to make these as enjoyable as possible: arrange a time to take everyone offsite, even to the local coffee shop or park, and hold the meeting there there so people aren't making excuses to disappear like "I'll just check how this compile is doing". Hold meetings at the same time/day as much as possible, so people can arrange their time accordingly. If someone's holding out on attending, assemble the whole team immediately behind them and make it very obvious you're all waiting (i.e. piss off the offender); they won't do it again, and will be very ready to piss off the next offender
- enforce the use of a single calendaring tool. If MS Outlook is it, then tell everyone all meetings will be scheduled using only this tool, and get them to come to terms with it. Don't tolerate different tools for different people. Forcing people to use one tool simplifies things from your perspective, and people who don't like it will build their own interfaces to their tool of choice (e.g. SMS message to their mobile phone) and share them with other people in the team
- if you're a contractor, or you work with contractors, try to build up a pool of people you like to work with and bring them in when you need them. This used to be tough, but with the present labor market it's now a whole lot easier
- keep people informed, even of the political-style rubbish, but shield them from dealing with this rubbish with external people. Having a team gripe about some stupid upper-mgmt decision is usually a great way to let off steam, promote team bonding and keeping people aware of each other, without resorting to overt "team building" exercises which generally piss people off
- if people want to listen to music, wear sandals, etc., let them do it as long as they aren't going to bring down the wrath of upper mgmt on their own heads. You might want to keep those people out of view of mgmt floor-walkers...
- stupid things like buying people icecreams in the middle of the day works great. Just don't expect to involve people in a long discussion as you hand them over, but they make a great entry point for a serious discussion at the coffee machine an hour later...
- expect to write reports for upper mgmt yourself; don't bother trying to delegate this task
- try to get people working in teams wherever possible. Some people won't like this; don't push it, but swap them between tasks regularly so you ensure everyone's work is being regularly peer-reviewed
- don't beat around the bush at pay review time. Tell it like it is; I've never met a techo who wanted suger-coated info at this time
- keep other people away from your team. Best way is to use office cubicle layouts to your advantage; position yourself so intruders have to walk past your desk to get to the person they want to interrupt, then interrupt *them* as they pass to find out what they want. Encourage/force them to make appointments (using the aforementioned calendaring tool) with the person they want to see, rather than turn up unannounced
- try to keep train-of-thought interruptions to an absolute minimum. Ask for updates when people are chatting between themselves, not when they're hard at work coding
- ask for input all the time. You mightn't always be able to act on this input; if not, say so but show that the input was still valued by you (if not the organisation at large)
- finally, try to enjoy yourself. If you do that, you generally keep things enjoyable for those around you as a matter of course
Can't think of any more at the moment, but I'm sure there is more...
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.
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
Absolutely correct.
Note that late hours worked and social ability are not mutually exclusive. In fact those hours probably allow said coder and his wife to actually have a parent home all hours for their child(ren)... They can take care of their "responsibilities" before 2pm, as nothing that REQUIRES people to go to in order to handle "responsibility" (the DMV, the bank, support for Credit Cards, attorneys, accountants, etc.) are open other than 8 to 5.
And unfortunately most sales and marketting droids I know *DO* wake up at 6:30am chipper and ready to go.
Actually the company should pamper everyone with drinks and nice chairs at least. They will keep every employee in the building and working longer for cheap. At the absolute least I think the CO. should provide a vending machine nearby to keep "snack runs" to a minimum. People munch, even suits.
Nice and unbiased an uninflammatory...
And no. You do not need to look good to perform. You need to be comfortable to perform a task that requires nothing other than brains. Wether you influence the ability of those around you to do their jobs is another story, and can be mitigated by simple planning (and letting the coders work hours that customers won't be there!). Personnally I would work much worse if everyone around me was wearing a uniform dockers & tshirt...
So have a breakroom, like EVERY OTHER COMPANY and keep the games there.
I don't particularly think *YOU* should be in management either, as it's patently clear that you despise those who would be under you, like the majority of PHB's in the world. Ranting on about how coders can't/don't do work, while reading slashdot during the say...
Either way there will need to be comprimise. Require coders to be in during certain hours (1-4?) so that meetings and communication can still happen, and the rest of their days are available for production of code.
Allow freedom and relaxation, but only where/when it will not be a distraction to others/customers.
And remember always that you're at a business. A business I'd assume is designed to make money. Good coders make money. Productive coders make money. Coders that hate management don't make money. Coders that hate their jobs don't make money. Coders that do not pay attention to the customer do not make money.
Any company that sets itself apart from the field does so by doing something that no other company can do. If you wish to do that technically (imo the easiest route) you will need a coder (or a few even) that can do something no other coder has done. To get that you'll need to make some comprimises...
And just remember, you don't have to look like a professional to act like a professional, and you don't need to act like a professional to look like a professional.
Every so-called software development manager should read these two books twice!
The Mythical Man-Month: Essays on Software Engineering
By Frederick P. Brooks Jr
Addison Wesley Longman, Inc.; 10/1995; Anniversary ed
Peopleware: Productive Projects and Teams
By Tom DeMarco,Timothy R. Lister
Dorset House Publishing; 02/2000; 2ND
Wax on, wax off baby!
Listen to us. You hired me because I am good. If I wasn't good you shouldn't have hired me. What I say goes. We really don't want to run Oracle on a 486. That would be bad.
Decide on a plan. You can change the plan. But don't pester me with changes to the User Interface when I'm trying to make the back end work. Believe it or not a solid back end that takes a long time to create (while the boss things I'm doing nothing because there aren't results he can see) will be good for the project and the UI changes can be made in an afternoon with an intern doing them.
Act as a filter. Actually I don't like to be cut out of the loop. I like to know what is going on. Sometimes I can increase productivity by suggesting a feature slightly different but much easier to code. But I don't want to be in the middle of disagreements on features or whatever.
Coding Blog
Damn, this was almost as bad at this [slashdot.org] arrogant asshole.
That link you posted refers to a programmer who is sucessfull despite having no formal degree, and you call him an "arrogant asshole".
I had to reply here because I am in fact in the same situation of that person you despise (jealous?). Why do think people pay him so much more for his work? Maybe because he GETS THE JOB DONE, and is WORTH IT. Why do you assume that he is some overpaid snippity scripter?
50% salary growth per year for 5 years is not that hard when you are starting really low. From my personal observation education is inversely proportional to programming skill anyway. (every PHD of CS Ive met has been a complete idiot)
This person is clearly a hardcore programmer.
"as to 2) filter the politics - can't stress that enough."
Normal people would have labeled the third item in the list "3". On the other hand, real programmers count from 0... =)
gee. 1. you can't code well at freakin 9 in the morning, that's just obvious. 2. it's your own fault you had kids, don't even think about pulling that 'I'm an adult' bullshit. 3. dress code: it's not geeks jobs to meet clients. they shouldn't. that's your damn job. 4. any time you want to switch I'll sit around making friggin excel timelines or dumb powerpoint presentations while you code until your eyes bleed and you have to listen to people whine how about how they don't know how to set up a filter in outlook
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.
Keeping track that the end result is according to specification is central. I'm not advocating meetingmania, but updates are quite crucial. After all, if things start to slide timewise or specwise, it is crucial to identify this at an early stage.
Letting them code is extremely imporant. However, it is equally important that they code the right thing.
Stop the brainwash
>I'm not asking for the basic 'stand-up-for-your-subordinates' advice, but rather requests from a coder's
>standpoint.
And by believing that you already have this covered, I believe that you will be a lousy manager. Next you'll say you have an 'open-door policy'.
...
-- I care not for your foolish signatures.
My boss rocks the world.
He tells me what needs done, and gets the hell out of my way. And stays there. When I'm done with what I'm doing, or hit a milestone, I present, he looks it over, and I go back to the drawing board with changes in mind. Repeat until finished. We meet on the smoke bench or informally in either of our offices. He never gives me shit about being late, and gives me and my coworkers mad props when we get a job done right. If we need hardware or software, we get it- it's that simple.
The head of the department works on pretty much the same principal- hands off, out of the way, keeping the shit from hitting the people that get the content and systems work done.
So. To sum up:
1. If you have any say in hiring, hire competent individuals that you can communicate with [we get "tested" by being hired part time, then eventually, go on fulltime with benefits, etc. People get brought in on a "we need [___] NOW!" basis, and if they click with us, they stick around. If they don't click, they don't stick- it keeps the department a well-oiled machine that works smoothly.]- I can't emphasize communication ENOUGH. Email doesn't cut it- face to face.
2. Stay the hell out of the way of your employees- let them do their jobs without being baby-sat. This is especially necessary when you don't know the applications or processes they're working with [the old department head kept back-seat driving me in Macromedia Director, an application he's never used. He hasn't programmed since computers went 32-bit.]
3. Give 'em what they need to get the job done. And by "job done", I mean just that.
I'm one of the two staff members in the department that actually knows enough about hardware/software to maintain and work on the systems when they go boom- on top of everything else, we're the only division in the facility that does our own tech support.
So obviously, I troll at work! What could be better?
Oh, and Slashdot can suck my ass.
"Geeks have special needs". No WE DON'T.
First, We want more money. It's a damn lie when people say we just love what we do and we don't do it for money. Real geeks do love what we do, and we don't do it only for money. But by God we know when we are being taken advantage of!
Second, we enjoy having constructive and intelligent conversation with people. Most of the good programmers I know are warm, outgoing people. It's a myth that we hide in the basement.
Third, we want respect, acknowledgement, blah, blah, blah. Basically the same kind of things a postman would like to have.
Just because most people didn't work hard enough in their high school maths class to understand what we do, it doens't mean it's harder to understand us as individuals. (
That's right, most programme jobs don't need anything more than high school maths! )
The only things I'd add to that are:
Ceterum censeo subscriptionem esse delendam.
My manager is a coder who should probably give it up. He isn't bad at it but due to his schedule (meetings: regularly scheduled upper-management ass-kissing and/or shit-umbrella-ing) he is not keeping up with the pace of current projects. I think that it is critical for a release that a person who switches hats in mid stream make certain that they are wearing the right hat.
...
I have been "down-stream" from him too many times to believe that a full-time manager can still code effectively. I can code some of my portion but if I am waiting on him to code his portion before completing mine then the whole project is screwed schedule-wise.
So, if you are really planning to switch, please don't try to keep your hands in the code
is the same one on politicians. rot in hell, fuckface, no one wants another manager.
What do you, as coders and programmers, want from your immediate manager?
Respect.
Disclaimer: I'm a Junior Developer at a relatively small consulting firm and havn't been in the industry too long, but I've noticed a lot of areas in which my management could improve:
1. Set deadlines. This sounds really obvious and somewhat vague, but I find it very important. I work best under micro-deadlines, especially when I'm doing relatively large tasks: break down the problem and set deadlines for each part; or, ideally, collaborate with the programmer on the deadlines. Working towards deadlines will motivate your programmers and give them a sense of pride when they meet them.
2. Give your programmers a pat on the back when they do well. Knowing your boss and your company value your work makes doing work infinitly more enjoyable.
3. Talk with your programmers frequently, even if just for a short time. Ask them about their concerns and ideas. Programmers (myself included) are relatively egotistical and love to have their ideas heard. Be approachable too. Try not to stretch your time so thin that you can't talk to someone who has a pressing concern. Often when I have a pressing question my manager is running around doing something and doesn't have time to talk to me.
4. Do code reviews. I've heard a lot of mixed opinions on code reviews, but I think if they're done correctly they can really do great things for a team. Firstly, it gives the manager a chance to see who is producing good code and who is not.
Code reviews also give good coders a chance to show off their clever code to others. I can't stress this enough. I've often tried to show off some particularly clever piece of code to my manager (or whomever), but they usually don't care or understand. Code reviews give the programmer a captive forum in which to show off--definitly boosts morale.
Good luck in your endeavours.
-hgh
We need more time.....please give us time to make everything work right!!!!!!!!
© 2004 The SCO Group, Inc. All Rights Reserved.
I've read a lot of responses, and I agree with some of the things I've read. Here are few things I currently do as a manager:
Having said that, here are some things that don't work out in favor of the developer. They're mostly out of my hands.
I think that last point is one of the most difficult for developers. Sometimes a small, interesting project comes along and you really want to do it. But you know it does nothing for the company, and your boss will say no. So you sneak it in. Unfortunately, that sets precedent, and others will come to you as the "get it done guy." Which is great until you realize you want your boss to filter the jobs, as long as they're lame. But your boss has a different agenda -- he or she is taking on jobs that further the company. The developer wants jobs that are really interesting. You have to decide: if your boss is a firewall, you have to respect it even if you get a boring task once in a while. If you undermine that a few times, the firewall has holes and everything will get through.
My Greasemonkey scripts for Digg &
What do you, as coders and programmers, want from your immediate manager?
1. Honesty. Don't lie, prevaricate or dissemble. If you can't tell me about something, just say so. Don't try to feed me a line to get rid of me, either - I'll know what you are doing, and it will ruin you because then I will feel that there is no reason to tell you the truth either.
2. Respect. I am a human being, not just a coder, programmer, geek or techie. If you don't treat me like a person I will walk out the door with all the critical information that you need to finish that project the first chance I get.
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'm not a programmer myself, but it looks from the comments that what they want is simply trust, like anybody else. A PHB that trust you to do your job, and that you trust to do his own. If your good at what your doing, and your boss is good in managing, everything will turn out fine... ... if not, your bound to failure.
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
*Takes Breath*
- Listen to your employees
- Don't nod your head unless you understand- At least take ONE class in programming
- Give your employees time to plan their applications
- Stay off the servers
- Stay out of the code
- Never use the following terms:
- Don't talk if you don't know what the discussion is about
- Don't Suggest anything unless you know what you are talking about
- Leave the programmers to their job and never micromanage
- Don't promise customers deadlines that will require programmers to work 80 hours a week
- Don't sexually harass the women
- For the love of god, avoid buzzwords like the plague
- Don't get upset when an employee knows more than you
- Don't get upset when an employee corrects you when you are wrong
- When your employees roll their eyes, it's an indicator that you need to catch up
*Breathes out*
I could go on for hours, i have the phb from hell, when you take the path down the management road, just remember to try and keep your competence.
It's a bitch but someone has to do it.
Note I am not here saying that you do a "water fall" process where you go off with the customer (internal or external) and come up with some theory formalized in predicate calculus. That just doesn't seem to work at all. What I'm saying is that your process, whever it is -- rapid/rabid prototyping, function point analysis, etc. -- must produce the clear connection with business needs starting with the RANPV bottom line.
Seastead this.
This is the life I live now! My job as a weather forecaster and computer geek graduated into becoming management in charge of technique development. I get taskings like "make a new tool to forecast frost probability." These become codes and scripts which dip into our "9 GB Fresh Daily!" Oracle database to crank out tailored products for various customers.
I'll save you all the rants about code walk throughs and other such guy-in-charge type stuff and concentrate on the "How to be a Manager" items:
1. Twaddle Filter: You are the interface between the people who want something, although they might not know what, and the people who can make it happen. If your tasker types aren't clear on what they want, it's up to you to either drag it out of them, or use your team (and politics?) to tell them what they actually want. Look past the tasking and concentrate on the output. If you can corner them into telling you what they NEED (vs. want), you're off to a good start. It will change, to be sure, but now it's negotiation to improve, not disappointment at having failed to "understand."
2. Defender of the Faith: Yeah, it sounds like BS, but teamwork revolves around a team, and you must make it so to suit your needs. If upper management dumps on you, stand up and remind them why you do what you do -- serve the customer to profit the company. Likewise, if your team has cranio-rectal inversion, let them know that fun's fun, but paychecks are week-to-week. You want milk from the cow? Feed, protect, and care for it!
3. Calmer of Ruffled Feathers: People skills! Stay on top of who's (not) talking to who, both above and below you. If you can find a way to treat problems as opportunities, you will put your self in the good graces / esteem of the fixee. This can dull the blade of cutthroat politics if you have the misfortune of dealing with that sort of thing. If it continues, at least you're collecting blackmail ^H^H^H^H motivation brownie points.
4. Skill Sharpener: Projects and urgencies permitting, beg, borrow, blackmail, or cajole anyone who can serve you into coughing up $$ for training. Whether it's SmartForce CBT modules or $40 toward getting a new copy of "Pearl for Dummies," grab it and use it. Document your people's training courses for those annual reviews and raises.
5. Self Defense: Some must reading for management above and beyond the usual "Sun Tzu - The Art of War" and "Book of Five Rings" stuff:
The Art of Deception by Nicholas Capaldi is by far the best guide ever for beating the worst office politician, used car salesman, or oily customer rep to ever cross you path at their own game. Read it. Live it. Prosper!
Pacifist paratroopers yell, "Ghandi!" when they jump.
Most above average, eh? Want to explain THAT to me? Kinda defies the idea behind AVERAGE
SIG: HUP
Heres a few leadership/management tips I learned in the Marines:
1- Stick up for your subordinates
2- Listen to what they have to say, but be willing to go against their advice if needed. Be flexible but make sure they know you are boss.
3- Before you change things, make sure you understand why its being done the way it is, and what you intend to get out of the change.
4- Give them an end state, not a procedure. This allows them the freedom to come up with unique solutions to problems, while ensuring the end product is what you need. Only put the bare minimum restriction necesary to ensure compatibility and legality.
5- If someone willfully fucks up be firm but fair in your response. If they fuck up because they try something new that doesn't work, accept that progress sometimes means finding out what doesn't work as much as finding out what does. In all cases of correcting mistakes/misconduct, try to help both the company and the individual worker in your actions.
6- Constantly be on the lookout for ways of improving your managerial skills and understanding of your workers jobs.
7- Be honest with your superiors and juniors, whether its good news or bad.
8- Whenever possible, don't chew someone out or denigrate someone in front of their subordinates. Take them aside privately if such action is required. Of course, if its an immediate safety issue disregard this if necesary.
9- Never set a standard for them that you cannot or will not hold yourself to. Encourage them to go higher than you can/will go, but never require it.
10- Treat them with respect, and work to earn respect in return.
Leadership in any capacity is an honor- don't fuck it up.
George E Worroll Jr, Cpl/USMC IRR(for a few more days anyways)
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?
Because the system it runs on happens to have a conflict with the client's hardware or other installed software. Oops...
Will I retire or break 10K?
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.
What's the precise difference between programming and scripting? It's not whether the program needs to be compiled from a human-readable form into a binary file before it's run, is it?
Will I retire or break 10K?
Bugmaster: Ok, this will take me 5 days to implement. ... ...
PHB: You need to make it sooner. Why not just hack something for now ? Here's how you can hack it:
Bugmaster: Because then it will become impossible to maintain; in addition, it might backfire as follows:
PHB: Just hack it.
a month down the line
PHB: Hey, we have this bug, and when I looked through the code it was a total mess !
Bugmaster: This bug is probably due to the hack we implemented last month. Everyone ended up copy-pasting the hack, so the bug is everywhere. This would not have happened if we wrote a general API like I originally suggested.
PHB: Hack around it.
No wonder the company is extinct...
I was recently employed as a Client Services Representative at a now-dead company. But while I was there, my boss and I undertook a project to create a mission critical system for the company that everybody wanted but nobody would attempt. We started the project out of need due to the fact that everything from order processing to tracking and monitoring etc was left up to the client services department. All the while, the department was not given the budget or the resources to handle all these tasks with just a handful of people and no information to go by. So I started working on a small site just to help myself out but my boss caught on to the idea and wanted me to go all out on it. After a few months of him speccing out the project with all the functionality and features and me making it happen, we were able to anticipate what the other was going to do or ask for next. He knew when I was feeling overworked or needed an extra hour break and we often went off to a local fast food restaurant to grab a Coke and discuss things.
Since this was all being done within the client services department and by a "novice" programmer, political heat was started and some parties wanted the effort moved to the research and development people. My boss and I felt that since we dealt with it every day and were using it, we would know what would work the best and how it would work the best. With all the controversy, a shitstorm was amidst and my boss was there to shield me from 90% of it while I still worked on the project. Occasionally, I would have to go to a meeting with my boss to argue some points about the project with others in the company, but he would do most of the talking with me there to correct anything that was wrong and to offer backup in case someone thought he was lying.
After 6 months of the project's existence, people in the company actually took notice that it was working, and working well. About a month before the company filed for bankruptcy, the project was deemed official and would be used as the main repository of information and began allocating more resources to get the job done. Eventually, the company filed for bankruptcy and then closed and the project died.
Moral of the story:
1. Know your employees
2. Listen to your employees
3. Trust your employees
4. Try to shield your employees from any political interference (it's impossible to block it all)
5. Even though meetings take away coding time, don't be afraid to drag employees to them every once in a while if it is needed
6. Reward your employees (extra day off, extra hour break, raise, whatever)
7. Despite the heat, don't give up
8. Repeat steps 1 through 7 as needed
I want a PHB
Just like the PHB
That served for
Dear old Dad.
</MUSIC>
Work in a small company 50 ppl, you will likely work for a smart boss.
PHP's are heading toward the center of the Galaxy in droves. A reporter discovered that they saw a headline in the science section of the Sunday newspaper, and mistook it for a want-ad. It read:
"Hot air that orbits black hole"
Table-ized A.I.
Uh, that should be "PHB" and not "PHP". Sorry 'bout dat.
Table-ized A.I.
Most consultants have no idea what they are talking about. It's hard to come into someone's office as if you have answers when you don't. Honest consultants are looking for a good answer. If you provide them with one, they will advocate your answer to your PHB. Use this knowledge carefully...
Those five words have sunk more projects than you would believe. Everyone makes statements like that when trying to sell work. Consult your technical folks before committing to it, though.
I agree, however this causes a problem if the proposed technology isn't widely known. Mind you, I'm a fan of several obscure technologies, but the PHB has to consider the code maintenance in the long term. Standardization tends to make for slow adoption of new things, but it is the tradeoff.
-- Solaris Central - http://w
Many people will tell you many things. Rest assured what I am going to say will not seem unique, but it bears thought.
.... right. Don't be that guy. Fight, remember, you can move your family in with relatives if the going gets tough!
Many managers often are caught up by commercialism in magazines or even the tele (altho, to their credit, even most tech managers see the folly in TV). I am assuming you would not be such a manager, so let me say a few things now that my snappy headline has caught your attention.
Do not try to have a solution looking for a problem, please. Consult your people and listen to them, even the longhairs. Too often management folks, and not say just you but say your boss, sees something and thinks - wow, this will end all of our problems. Yeah
Think clearly, while someone might say here that m$ is wrong, who is to say Linux is better? Or BSD for that matter? your job is to match the problem. Sometimes that calls for something completely different.
Think outside of the company. Many people have a tendancy to look strictly at the needs of or the ideals of particular corporate culture, whether a college or dildo factory. Okay, the latter is probably a little more limited in scope compared to the former but you get the idea. Think about the technology you are implementing, how long will it last? Is it extensible? Can my staff MAKE it extensible? How much am I paying and for how long, is the return really worth it?
Last but not least, and I cannot stress this more, paying for a higher quality staff will result in long term gains. Filling air-beather slots will kill you. I am living proof of that idea. I am paid slightly above the average SA salary (the old carrot deal) and people have no idea who I am even though I have around 200 command line users and around 1000 abstract users across roughly 10 systems. I rarely, if ever, get called. The same goes for our backbone engineer who can setup a VPN with his eyes closed.
Invest in people, and you will have nothing to lose. Invest in products, regardless of the vendor, and you are fucked.
In the arse I might add.
Thats my penny ante for you, I hope it helps.
If you haven't already read it, I recommend the book Peopleware by Tom DeMarco and Timothy Lister. In addition to being highly readable, it offers some genuine insights into what makes Engineers productive.
But realistically, ANY manager would do better to read through and UNDERSTAND the Hackers Employment FAQ.
http://www.google.com/profiles/malachid
"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."
That's exactly right: "Every one of those [amazingly self-destructive business failures] represents a failure on the part of someone other than a coder or lower level manager." Whoever failed destroyed his or her own company and cost a lot of pain and millions of dollars. The person responsible for the failure: 1) didn't understand the technology thoroughly, or 2) didn't understand the sociology thoroughly, or 3) didn't understand either.
Creating software is creating intellectual property. It is a big intellectual challenge. Creating intellectual property cannot be reduced to crank-turning. They don't teach it in a university. You have to do it the old-fashioned way: You have to know what you are doing.
Bush's education improvements were
1) Act as an interface between the programming team and the sales/client world.
2) Control the creeping feature problem
3) Buy a big whiteboard and use it to keep the project hit-list in one corner. When a problem arises or a milestone is getting close it goes on the hit-list. The rest of the board is for the programmers to explain stuff to each other.
4) Review the interface descriptions for what people are building. You probably don't need to know exactly how things work, but you _must_ ensure that all the bits fit together
5) Plan training and career development for your team, and ensure that it happens.
6) When a project is completed on time and under budget, spend some of the remaining money on the team. If you're waaay under budget (does happen occasionally) host a party for some customer types so the programmers can show off how cool they've been.
7) Give the programmers some slack, but not too much.
An office is the best, then comes the cubicle and the loser is "open workspace". Its only purpose is not to promote communication, but to generate a social pressure so that everyone watches each other. ("Look now he's surfing, oh my")
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.
My Karma: ran over your Dogma
StrawberryFrog
> want from your immediate manager?
The best manager I've ever had put in roughly the same hours I did. If he tasked me with a job that forced me to stay late, he'd stay late too and help out as best he could. He wasn't a programmer, but he'd find ways to be useful with QA, documentation, gopher, etc.
By contrast the worst managers I've had invariably kept regular office hours regardless of what the programmer(s) were up to. As a result they'd have no clue what was going on, they'd become adversarial, and they'd eventually loose our respect.
Don't sechedule meetings with your staff, spend real time with them.
Slashdot monitor for your Mozilla sidebar or Active Desktop.
There's one thing I look for in a PHB, strong leadership. People need leaders, and strong willed intelligent people need a strong leader. If not your group all does whatever they think needs to be done, but since your the filter for the politics and company goals your going to be the one in a position to know where to go. Set the goals, motivate your people and lead them there. If you can be a strong leader with a group of coders you can probably lead anyone, but it's a hard skill to learn.
Darthtuttle
Thought Architect
A boss that is techy enough to understand why things work.
I've got a boss now who I respect for his coding skills and his knowledge. Thats GOOD.
that's for the geeks who have nowhere to go outside of work. They have pizza boxes stacked up to the ceiling in their houses so they stay 12 hrs at work where it's clean and bright.
When you spend that much time at work, you also need the entertainment.
QED
The attitude that you know everything already and asking other people's opinion is dishonourable and shameful is a requirement for programmers - this guy wants to be a manager.
In my experiance as a Quality Assurance geek and programmer, having well defined requirements is vital if you want good code. When the requirements document is written, you should be able to think of a test for every requirement in it. If you can't think of a good test, the requriement isn't clear enough. Enforce that as a manager and your programmers will love you.
Ray Benjamin
-All that is gold does not glitter - Tolkien
www.ra
when I don't like somthing, I'd like to curse and call it a pile of shit without my manager having "concerns" about my attitude. Some things I don't like, but mostly I find I need to "fly low and avoid the radar", less I be seen as a negative person.
Of course this negates any input I have positive or negative, which hurts the company in the long run.
"The Most Fun Possible on 4 wheels" is at SunBuggy in Las Vegas
The last company I worked at decided they needed to have a WEEKLY company-wide mandatory meeting. They were only about 25-30 employees (now down to 12, no surprise), and there was never any agenda or anything that required everyone to have so much time wasted...you see, everyone was working on something different, with different tools, but as Peopleware says, status meetings aren't about status of the project, it's about status of the manager. I was almost relieved when I was laid off from that joke of a workplace - when they decided to do these stupid meetings, and subject us to other silly things like "core hours", it was already too late - the market was so far in the crapper that it was impossible to find other work.
;)
In any case, let it be known that these weekly pointless meetings added the most to the staff's demoralization...it didn't help that the weekly meeting was mostly a weekly "spin" session - where we were always told that the condition of the company is absolutely spectacular despite the constant firings and layoffs.
dont ever add manpower to your projects running late. i have had first-hand experience about its futility in one of my earlier projects.
As Frederick Brook points out in the Mythical Man-Month: Adding manpower to a late project makes it later!!!!!!!
From the second-to-last paragraph of the parent post: "However, saying that a VP of marketing needs to be able to read code is kind of silly."
I realize it sounds extreme, but I think it is correct.
Either managers understand what is happening, or they don't. A top manager, who has not programmed and cannot read code, cannot possibly understand the very varied mental challenges of programming. If he doesn't understand, the decisions he makes will sometimes be flawed. The dot-com failures are good examples of this. Billions and billions of dollars were lost.
Sometimes changes to software that sound simple are very complex. Sometimes complex requirements are simple to program. Top managers need to know what is a reasonable request and what isn't.
I once wrote a report that showed more than 500 new numbers about sales data, but was quite simple to program. I was lucky to find an efficient algorithm.
On the other hand there have been times when correcting a seemingly small shortcoming would have required a major re-write.
Anyone who disagrees with this is invited to supply his or her own explanation for the dot-com failures.
Bush's education improvements were
I don't think you need to be an expert programmer
to be a manager, but it is certainly true that if
a programmer tries to explain a technical issue,
you NEED to be able to understand it. That means
you need at least 2 or 3 years programming
experience and that you can't be coming from a
background of having been a programmer and no
longer wanting to worry about the details. It is
very easy to ask for a new feature or a change
to existing code that sounds trivial but has vast
technical implications (worst case it may not
even be possible). You need to have a feel for
the complexity of a problem or request for code
change in the first place, and when further
issues arise, you need to be able to understand
these issues when a programmer presents them to
you. Ideally a manager should also have a good
grasp of the business issues as well in order
to understand the business' concerns.
A good manager is therefore a competent
programmer, a reasonably good BA, and of course
a good planner and communicator as well. I've
only had a few managers I'd consider good, and
the further up the chain they got, the less
suited they would become to directly managing a
small team - they become less and less in
practice at understanding code/technical issues,
and don't tend to keep up with the technology.
Certainly few managers continue to play with code
on the side in their spare time.
At the very least, don't hire someone to do a technical task who isn't up to doing the work. I've dealt with plenty of folks who were hired because they told a hard-luck story, filled a quota number, or had connections.
I think there is an awful lot of talk about how a boss should react, plan, and do, and very little about the personal responsibility of the [geek] programmer.
Managers are typically bound by a huge number of constraints - political, social, budgetary, etc. I think many here expect their management staff to have the same level of knowledge as their coders, dba's, etc. In my opinion, this is the last person I want as a manager (more about that below).
It is our duty to learn how to communicate our needs and thoughts in coherent, non-technical manners to (mostly) non-technical managers. We should be able to sway opinion and drive needs as much as upper management. Education is the key - both up and down the management chain.
As far as having a technically sound manager - I personally would rather have one that listens to me rather than has his/her own predetermined opinions on technology. I think that Managers need to be more socially mobile and agile than technically sound in order to get the political backing they typically need for technical projects.
I tend to prefer PTBs (Pony-Tailed Bosses), and GBBs (Grizzly-Bearded Bosses). They're usually more in tune with programmers.
It's 10 PM. Do you know if you're un-American?
Do you really think that one must be easy to
manage in order to be a great programmer? I've
seen a lot of really good coders who won't put
up with people making them miserable.. Of course,
I've also seen good coders who will.. the point is
that there probably isn't a correlation between
'easy to manage' and 'produces good code'.
For every problem, there is at least one solution that is simple, neat, and wrong.
There's another book which is worth the cover price just for three diagrams on the time dependence on the accuracty of estimates; the probability of completion at any particular date and the minumum cost of completing by any given date. Of course it's name escapes me (otherwise it'd be on my shelf).
All coders should have read
Beyond these (and the obvious things listed in other comments) there are a few things a tech PHB needs to do
Bug hunts need to be contained: if someone cannot fix it in the allotted time, escalate the problem. Even to the point of clean rooming the design.
Remember, you are asking your boss/customer to trust you with their money. And your team with their (working) lives.
CD
(Anon)
-- Butlerian Jihad NOW!
All the other attributes of managers you discuss derive from this primary interpretive function and, indeed, without it, all those other attributes are rendered without business value precisely to the extent that they are independent of business reality.
There's no real disagreement here, and certainly not about the importance of understanding business needs. But since the original request was for career advice, I thought it was useful to point out that, in all but small development organizations, the first- and second-level development manager is first and foremost a RESOURCE manager rather than a PRODUCT manager. The company expects that person to serve as a technical coordinator, forecaster, troubleshooter, and mentor, but typically NOT as a business analyst or architect. The new manager will typically be judged in terms of technical results -- what was done on time, what was late, how many bugs appeared -- rather than business results, which are the responsibility of people in a different chain of command. Furthermore, although the new manager may and should have input to questions of design/functionality/business purpose, in many organizations what filters down to the technical level doesn't leave a lot of wiggle room. The specs are the specs. It's an advantage to understand them and be able to explain them; but at this level, it may not be practical to challenge them or reinterpret them, and it's often more important simply to stick to them as written.
This division of responsibility is not actually as unreasonable as it may seem, because these low-level technical managers typically do not have the business experience to understand the underlying business needs that you (correctly) identify as being vital to long term company success. You can't go overnight from being a JAVA hacker to being a business planning or reengineering expert.
This being said, naturally it is in everybody's interest to strive to understand the user perspective and try to relate technical priorities to business needs -- no question. But to prepare yourself for a switch to management responsibility, I'd say the most important thing is to focus on 'management' and 'responsibility' -- getting good at making lists, following schedules, conducting walkthroughs, constructive brainstorming, and above all basic interpersonal skills such as how to critique without insulting, how to negotiate competing priorities, and how to resolve conflicts.
Again, this is less true in smaller organizations where a direct connection to user requirements pervades the entire staff. In those situations, the first-line manager is heavily involved in the interpretive function you describe, as is (or should be) every technician as well.
So I don't discount the importance of the communications role you mentioned; but in my experience, technicians who move into their first management jobs are most challenged by management problems, not by design problems.
I might add that it may sound like I'm advocating a kind of old-style programmer-in-the-closet approach to development. I'm not. It's ALWAYS good to have close links between developers and users, and the more a technician understands about the business environment, the better. (In fact, if the original question were "how can I be a better developer?" I'd say your advice would be right on the money. Who would I rather had a close understanding of the application -- the person doing the development, or the one who manages vacations and budgets? The developer, absolutely.) But companies are the way they are, not the way we wish they were. And so, IMO, to prepare for a technical management career in a mid- to large organization, learn the business by all means, but plan to focus on and be judged by your management skills.
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
What Kind of PHB Do You Want?
wow...I thought this article was going to be about different players hand books for D&D....
I had this whole idea of posting something about wanting a phb where the pages don't fall out.
"Only one thing, is impossible for god: to find any sense in any copyright law on the planet." Mark Twain
Read Peopleware by Tom de Marco.
Dunstan
The last scintilla of doubt just rode out of town
arrgh!
Ok, so your missile with its poorly written software does not stay on target. Shortly after, the other guy's missile, artillery shell, sharp pointy stick or whatnot kills you.
So just how do you see that your poorly written software prevented anyone from dying. Don't answer, because YOU ARE DEAD!