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.
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.
a. clearly defines my tasks
b. clearly defines my deadlines
c. doesn't change priorities every freakin day
d. leaves me the hell alone to get my work done and doesn't come by every three freakin minutes asking for a status update
e. listens to me when I tell him it can't, or shouldn't be done
f. doesn't demand to know every single thing I know about what I am doing, but only to know the things that truly matter for him.
g. one that trusts me to come to him if I need help.
The difference between Theory and Practice is greater in Practice than in Theory.
Let. Them. Code. Don't change focus on a project just after they start to get into it. Don't watch over their shoulders and make meaningless uninformed suggestions. Don't waste their time with pointless meetings. Just let them do their job.
As a consultant I have some trouble with your item #1 suggestion. On my last gig nobody listened to me and they produced a distributed SQL Server database that didn't use transactions and did use "SELECT *" all over the place; I ended up quitting because I couldn't convince them of the utter stupidity of their ways...
But on the other hand my current gig is a nightmare because they DID listen to their consultant --> these people used Rational Rose to generate code {blekk!} and even worse they believed that their OOP guru knew what he was doing. These people now have to maintain more than 7,000 classes all of which have one or two {sometimes none} meaningful methods in them. None of the 7,000 classes in any way represents a meaningful problem domain entity...
I'm fortunate enough to work for a person who understands that she doesn't fully understand everything. However, just because she doesn't understand everything doesn't mean she doesn't want to know what's going on. When it comes to technical she asks us... We tell her our honest opinion / timeframe and she doubles it. As for the politics she handles it for us. We code. She keeps balance. it's a perfect relationship.
I know this is more of a statement of my scenario than of what to do. But if you can do what she does then you're sure to do good. Not to mention that only techies can make good middle-management as long as those non-techies understand that they don't have to understand or fake understanding everything.
I believe it's more of a, "If the consultant says it should be done, but the tech staff says it can't be done" listen to the tech staff.
FREX, at my last job, we had a consultant come in and tell us to "Do X to the database", and our Oracle Admin said that we couldn't. (Something about Oracle 7, which we had, vs Oracle 8i, which we told the consultant we didn't have, multiple times.)
The bosses listened to the consultant.
Loads of fun... In addition to paying the consultant, we ended up paying for the upgrade to 8i....
I like you, Stuart. You're not like everyone else, here, at Slashdot.
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.
Ah, like,
Those who can't do, teach
Those who can't teach, manage
Yeah, I'm in stitches. I've been through periods where I couldnt' even read Dilbert because it was actually too close to the bone. Give the guy a chance, tho.
My dad worked 38 years at Dow Chemical, as a ChemE, and during much of that time it was a great place, because at all levels of management were people who started as engineers, and understood. Now the company is run by business people and, well, I don't hear a lot of good things anymore.
A feeling of having made the same mistake before: Deja Foobar
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
For myself, I greatly appreciated the manager who brought me along to meet with higher-ups as we headed into major projects, both to be exposed to their concerns as well as to offer insight that headed off "snipe hunts" early on. Many geeks who bitch about management are in the same boat as non-voters who bitch about Bush winning the election. If you actually have an opinion, be open to getting involved and make a difference!
Stop by my site where I write about ERP systems & more
The entire office thing is important. Cube farms are NOT a productive environment to work in. And if you're going to force geeks into cube farms, at least make sure they have some breathing room.
I've had a cube so small I couldn't turn around in and it was stifling and made being productive difficult. An office is ideal, but unfortunately not too practical for most organizations, so at least give us some room to breathe.
Telecommuting isn't so important to me, but being flexible in work hours is very important. If I'm caught up or ahead of the game - don't get upset if I leave 2 hours early or come in two hours late. Believe me, if I'm behind or something is wrong I'll be there all night if necessary. But when it's slow, relax.
And stop being so damned serious. The end of the world will not come about if we don't do X, Y or Z right this minute. Give us a little slack once in a while. Those rubber bands and nerf guns aren't going to hurt anyone. At least not seriously.
I don't have a solution, but I certainly admire the problem.
Point 1 will also never happen. The consultants talk to the customers. The customers give the company money. The money pays your salary.
A common error of my (ex)employers is assuming that, just because the customer pays, that means the customer is always right. That's not always the case.
In our web development area, we had to make stupid changes of design, make slow, unnavigable or ugly web pages, but "The client asked it that way". We are supposed to be experts, we KNOW what works and what doesn't. If the customer to knew how to solve his problems he wouldn't have the need for us.
Imagine you are a doctor and you have a patient that has cancer, but he wants an aspirin based treatment. You could give it to him and cash the check or you could try to convince him of what he really needs, even if it costs more.
Kilroy was here!
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.
Whatever happened to offices? Some years ago, you always heard how much productivity of Engineering staff was enhanced by offices, but now, all you hear about is that "open" workspaces encourage collaboration.
Personally, I much prefer collaborating passing documents back and forth. Collaborating face to face has it's place, but to build anything of value, it's best to get all the ideas and opinions down in writing and diagrams, so they can be studied objectively. Usually when technical decisions are made in meetings, even informal drop-by-the cube or office meetings without anything written down, I find that they are poorly thought out.
That's what I want from management. An environment that values my ideas, but also READS and tries to understand the issues. Shoot from the hip environments are generally poor for a number of reasons, in my experience:
That being said, I do want to point out that there are a lot of comments in this thread about how good management insulates technical staff from politics. I agree with this, but I want to add that good workers who have management that does what they can to insulate workers from good management have a responsibility to do what they can to insulate their management from politics also. The corporate edicts may be stupid, but most middle management is powerless to fight a lot of these things. It's best to stand up and do what needs to be done to protect your (good) managers from feeling the heat if the edicts aren't followed.
Sometimes, like schedules dictated on high, it's not always possible, but at least give your boss lots of good technical reasons (not just whining) as to why the schedules can't be met.
Just my 2 cents.
I 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.
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}}
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.
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.
Were they utterly stupid, or did you utterly misunderstand their requirements?
Did your beautiful initial structure (which you wouldn't have to maintain, report against, etc.) have the potential to cause problems down the road?
Most consultants I have dealt with were carpetbaggers. It's the nature of the job...you come in, you recommend the setup you've recommended for the last fifteen jobs, and you leave before the dust settles. Those on the job are left to deal with the consequences.
Consultants, like everyone else, fit a bell curve - some horrible, some incredible, and most about average. The average guy doesn't understand the implication of what everyone is doing. Over time, those of us on staff learn that a consultant might have some good ideas and suggestions, but generally DOES NOT and CAN NOT have the big picture. We have the fractal view, from the smallest detail to the largest project. The consultant sees only a single project. The consultant does not contain within his head all the interconnections and potentials for problems.
It's entirely possible that the people you dealt with simply weren't as smart as you are (and I'm completely serious). They saw what you suggested and didn't understand how to maintain it. Maintaining 7,000 trivial objects, on the other hand, is simple...just tedious and time consuming. It's good for people to know their limits. And don't go suggesting that maybe they should quit or the company should hire someone smarter - there's only so much talent to go around and it can't work everywhere.
I don't know about everyone else, but I can't think when the clothes I'm wearing are uncomfortable. If I am more productive when I'm wearing jeans and a t-shirt then management will allow it.
My guess is that if you think jeans and a tshirt are comfortable you have never had a pair of nice slacks on. I used to wear jeans and such. Then i discovered the art of Nordstroms and nice slacks. Yeah, they may cost $60 a pair. A good pair of slacks is like coding in pajamas.
I can fully believe he's an adult because I've had almost the same rant a few times. I've also worked in a really great development area that had no fucking special geeks with their damned starwars toys and imaginary light sabers and we did a lot better there.
There is no correlation between star wars obsessed dipshits and good coders. I view that as a deficit in their abilities. If they can't figure out how to behave in regards to those around them, they obviously don't have the problem solving skills necessary.
Dacels Jewelers can't be trusted.
Do a Google search on "Extreme Programming." It's a lightweight methodology that actually presumes requirements will change as you go and allows for it.
It's probably the most sensible thing I've seen in this line of work.
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