Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
News

How To Not Fetch and Still Be A Good Dog? 53

6footblondwhiteguy asks: "Having just finished a major system design review at work, I have collected many of what I call GFAR (Go Fetch a Rock). These are pointless, time-wasting actions, proposed by the clueless executives invited to these reviews... e.g. 'This other project is using SUN servers, see if you can use theirs'. I instantly know the answer to each of the GFAR's: (not in this lifetime, no way, or sometime after the sun burns out). So, how do you avoid your boss's boss's boss's newest bright idea without either highlighting it's futility or arguing its merit in a public forum? Surely the Slashdot community has some wise architects that have strategies for deflecting these actions. I suspect the window of avoidance to be about one minute (before it's written down)."
This discussion has been archived. No new comments can be posted.

How To Not Fetch and Still Be A Good Dog?

Comments Filter:
  • by HRbnjR ( 12398 ) <chris@hubick.com> on Thursday September 26, 2002 @03:54AM (#4334124) Homepage

    Uhh... dude, I'm a /consultant/, I encourage this kind of management behavior! :-)
  • My solution... (Score:2, Interesting)

    by bscott ( 460706 )
    I'm a freelance contractor for many of my jobs, so for the most part I get to say what I like to the people I work with directly, and let THEM deal with the clueless PHB's. (I highly recommend this solution to everyone)

    But in the past, the Dilbert-esque solution has worked for me in a few cases - just tell them it's a great idea and you'll get started on it right away, then ignore it. They go away happy, and nobody knows the difference.

    Of course, that doesn't help when you're trying to explain why you need money for something - but as noted above, I'm generally not in that situation.
    *relaxed sigh*
    *smug look*
    *frown as bank balance is recalled...*
    • Re:My solution... (Score:3, Interesting)

      by quintessent ( 197518 )
      Or you might try explaining the real pros and cons as you see it and let the super-boss decide against it using the actual facts. These people are paid to run the company, you know. Usurping authority is probably not as helpful as helping them see a little more light.
      • Re:My solution... (Score:3, Informative)

        by kevin42 ( 161303 )
        Let me know what you think again *after* you get a job in the real world.

        • After many jobs in the real world, anyone who blows a suggestion from a boss off deserves to be fired.

          Either explain the technical issues of it and listen to the business issues, or DO IT.

          If you say you're going to do it and you don't then you don't really want the job too much.

          sure there are some PHBs, but the only correct response to them is with integrity- treat them like they know whats going on and you'll get further with everyone else in the company. No company is all PHBs.

          Sounds to me like you're the one who's never had a job with responsibility.
  • ...is to go fetch them a SCHRUBBERY instead. That would be a GFAS.
  • I don't get it. (Score:5, Interesting)

    by Jon Peterson ( 1443 ) <jonNO@SPAMsnowdrift.org> on Thursday September 26, 2002 @04:59AM (#4334398) Homepage
    This is the second time we've had someone asking 'My boss is stupid, what can I do?'. Look, it's really simple.

    1. Management's idea is either good or bad.
    2. If it's bad, and you know why, you can explain that to management.
    3. If it's good, but for some reason you don't want to do it, because, say, it involves language X that you think sucks or OS Y that you think sucks, then just f***ing grow up, eh?

    Now, it may be that you explain why it's a bad idea, but management don't change their minds. This could be:

    1. There are arguments supporting the idea that you do not understand (maybe they are financial or business related, not technical).
    2. Management do not understand your (technical) arguments against the idea.
    3. There are arguments supporting the idea that you have not been told about, because management does not think it relevant.

    In case 1, that's kind of tough. If you are interested in other aspects of the business, then generally managers will be thrilled and will be happy to spend time explaining these things. but, if you don't care, then don't be surprised when someone says "OK, maybe the technology isn't ideal, but with this balance sheet, we ARE going down this route"

    In case 2, that's also kind of tough. Try to find someone who is good at making technical issues comprehensible to managers. Every team should have a person able to to do this. Find them and get them on your side.

    In case 3, guess what, that's kind of tough. Maybe managment figure that it's not your job to care about non-technical aspects of the idea. Personally I don't like this approach - I always let the geeks see the profit/loss sheet even if I'm pretty certain they won't understand it. That way they might let me see the database schema, and I will understand that :).

    So, this knee jerk "Whoa, my PHB is so dumb, he said this [...]" is really an attitude I expect from junior members of my team. Senior members can either shut up and code, or they can make a proper job of presenting a case supporting why the idea is so dumb.
    • I would agree with this in most cases. Management have (or should have) more info. They should, as Jon says, explain their thinking, and give your views a good hearing. If this happens, follow Jon's advice.

      But it can happen that you are working for an idiot. It happened to me once in my career. In that case there is only one thing to do. GET OUT. If your manager is an incurable idiot, you will *never* be happy working there, and staying will only make you miserable. But give him/her plenty of rope to hang him/herself; a real idiot will soon show up unambiguously. If the idiocy is not tranparently obvious, then maybe it isn't idiocy.

      (My idiot manager had a PROM brain. On day two, after looking over the job I was to do, I gave him a sketch of how I intended to attack the problem. On day about five, I found out that wasn't the right way - but it was too late; his proms were burned. For the next six months I had to shoehorn every weekly progress report into the headings from that initial handwaving guess at a solution.)
      • by Anonymous Coward
        For a manager with a PROM brain, don't tell him that your first idea wasn't right. Tell him that "I've found a better way to do it. It'll save time and money over the old way I had planned. I'm going to do that instead." Some people are very afraid of acknowledging that an idea was stupid -- mostly they're afraid that THEY will look stupid. The answer is to simply find a way to make them look good when they change their mind about how you're supposed to solve the problem.
        • I tried that - it didn't work. He really was PROM - write once. It wan't a question of looking good/bad, saving money or face.: his world model was formed and he wasn't changing it. Like arguing with a Jehovah's Witness - logic bounces off cast iron certainty.
    • The manager read something about a technology in a in-flight magazine, and decided that was the company's strategic direction. He does not change his mind once it's made up and if you were smart you wouldn't be working for him. Reportedly, he has pictures of his boss with an under-age girl, so he's not going to get canned.

      You can't make this stuff up.
    • I think youve missed the guys point. Its not his manager thats giving him pointless tasks, its other managers higher up in the organisation or other departments pushing him about.

      In this case his manager should be able to deflect much of this, but sometimes the other department has a mandate to send him running for that rock.

      I get this from our Alpha Testers. Usually things are fine: they find a defect, we fix it. But occasionally they get a real bee in their bonnet over some trivial thing, often because they confuse their personnal opinion with a properly run useability test. Something like capitalisation in error messages becomes the weeks hot topic, and you get lumbered changing something that was never broken.

      So:

      Do make sure your manager is aware of what you are doing, and make sure he is aware how pointless the task is. Then it wont go badly in your review if you do a slapdash job of it.

      Do try and understand why someone has pushed this work your way. In one case I got shafted because a tester needed to impress his boss with his assertivness. They were just protecting their job and picked me cos they knew they could explain things in the tea room later. Sometimes salesmen need a stupid feature added cos a customer is just testing the companies willingness to respond to change requests.

      Do avoid idiots. If you are in a meeting with a total documentation freak, just stay silent. Never visit someone you know likes to generate work. If you see them in the corridor, dive into the nearest office and ask if you can borrow a stapler, or be on the way to attend an emergency.

      Do be aware of any issues like this comming your way. Then you can not be there when it arrives, and maybe someone else will have to pick it up. Or you can already have done it if you get enough warning.

      Dont be rude. Many companies operate a policy of 'eliminate the assholes' so try not to be one of them. Politely point out how this will make things difficult for you, how it will cause the schedule to slip, how it will destabilise the product, etc, but never directly accuse someone of making your life difficult unless you are prepared to get another job.

      Dont avoid doing stuff. Cos you get paid to do the work whether its pointless or not.

      Do make sure that what you do doesnt adversly affect product quality. You dont want to be the guy who created the Word Macro Virus vulnerability cos some idiot wanted to embed a programming language in a wordprocessor document.
    • If you are explaining, you are losing.


      --Turvey

    • Someone who makes a dumb suggestion doesn't want to hear why they are wrong, especially not in a public forum. My guess is you tell them why they are wrong and you will spend the next bit of time arguing back and forth. Best bet is to ignore dumb ideas and the people who make them.
  • by ebbe11 ( 121118 ) on Thursday September 26, 2002 @05:30AM (#4334493)
    Work out how much their "solution" will cost compared to the one you prefer. Don't stack the numbers (too much :-). Things to consider are:
    • Amount of extra work needed multiplied with normal hourly rate.
    • Reduced earnings caused by project delay
    • ...whatever else that will add to the total cost.
    Tell the PHBs how much more their smart solution will cost in actual currency (dollars, kroner, euros...).

    Then they'll understand.

    • Amen!

      All businessfolk understand cost/benefit calculations. They also should all understand risk vs reward. If an idea is obviously dumb to you, then you should be able to explain it in one of those models. E.g.:
      Using the other team's servers would create a common failure point and an opportunity for one project to interfere with another. Although this would save us $100,000, we estimate that this would take our uptime from four nines to three, which is outside your requirements for the project.
      Also, you should work on changing your attitude. They think their questions are all smart and reasonable. That's because they know different things than you. If you take the time to help educate them, then they will ask better questions next time. Your goal should be to leave them feeling like smart people who just happened to be missing a fact, rather than pathetic assholes who are lucky they have you around.
      • Spot on! I have found that most of the people that think their boss is a moron are simply poor communicators. If it is so clear to you that the idea is a poor one, then it should be fairly easy to explain to your boss why it is a poor idea.

        On the other hand, there is a good chance that you are the one that needs a clue. For example, let's imagine that IT in your company has had its budget cut and their choices are to either share hardware between the two projects or close your project down. In that case, your GFAR is actually saving you your job.

        It is a little tiring to work with so many computer specialists that think they are some kind of super hero because they know how to code a for loop or have memorized the command-line flags for tar.

    • Excellent point.

      It's very simple: 90% of working effectively with people is communication. If you understand each other, you will at least know why the boss wants to do things a certain way.

      And the flip side of that: 90% of communication is LISTENING. No, seriously. Shut up. Listen. And when you listen, don't just parse the words -- try to shift your point of view to understand not what he's actually saying, but what he's trying to say. Then, when you respond, don't respond to the words he used; instead, respond to the ideas he was trying to communicate. If you don't quite know what he was trying to communicate, there's no shame in saying, "I'm not sure I understand what you're suggesting. Do you mean we should do X or do you mean Y? Keep in mind that there are A, B, and C that would affect X" or something to that effect.

      If you can learn how to really listen, listen and grok, then you will quickly become a skilled communicator. If you are a skilled communicator, if you can learn to speak bureaucrat-eese, then you will have no problems explaining to your boss why his idea is wrong, without offending him or making him look stupid.

      A good way to do that is to say "Do you mean we should replace our entire infrastructure and lose our existing technology investments [exaggerate his bad idea ad absurdam and make it obvious by your tone of voice that that would be a bad idea], or do you just mean that we should look into using Sun servers in new deployments [come up a good idea based loosely on his idea]." Now, you're not insulting his idea, you're presenting options.

      Use "look into" as much as possible. If he later asks you about it, just say, "Oh, I looked into it, but I found that [cost/benefit didn't justify it; it's impossible or impractical from a technological standpoint; the amount of time needed to implement the solution would cost us more than what we could hope to save]." Then, suggest a good idea to do instead.

      See? It's easy... :-)

  • I had a similar situation at my last job. Management had decided to out-source part of our processing to a business partner four hours away. They expected a 24 hr turn around in processing from departure to return. Knowing the number and capability of the equipment used, plus the transport time, I told management it wasn't possible with current inventory. I suggested that the only way it might work would be if one of our bank customers held more inventory. That solution got shot down by the bank. Management had already sold that part of the business and I was to follow their plan. So I decided to play their reindeer games and followed their instructions. When the turn around time was double initial projections, and communtication with all involved fail miserably, I got to be the one to tell our banks they didn't have any money in stock.
    In short, I let their idea fail. Even after trying to make it work, it fail. So, that is my suggestion. Work their idea as best you can, collect you paycheck, and let it fail. Never say I told you so, unless you don't need a job.
  • Anticipate! (Score:3, Insightful)

    by north.coaster ( 136450 ) on Thursday September 26, 2002 @07:44AM (#4335014) Homepage

    I used to receive a lot of these kinds of tasks, until I learned that if I spent a small amount of time before the review anticipating these questions I could defect them before they got any momentum. So the secret is to:

    1) Spend some time learning about what others are doing in your company/group/whatever.

    2) Anticipate the questions that you're likely to be asked regarding synergy, re-use, etc.

    3) Have the answer waiting in your back pocket (or better yet, in your presentation back-up material).

    In a few cases, during this pre-work you may even discover a better way to do something, and you can make it part of your proposal. And if you're clever, you might even find a way to make the bosses think that it was their idea! And then you're a hero for making them look good.

    /Don

    • If you know you will be presenting a proposal to an audience with some true PHBs, always put in a few obvious but minor flaws (e.g. spelling errors) for the Boss to catch. Some Type A PHBs just aren't satisfied with a good idea, they have to impose their will by forcing a change on you, even if trivial.



      So give them something easy to find and easy to fix on your part, them smile and apply your fix.

  • How about (Score:3, Insightful)

    by jsse ( 254124 ) on Thursday September 26, 2002 @08:27AM (#4335226) Homepage Journal
    go to his house, strike an axe on his skull, burn down his house with his corpose and everthing else inside and piss on the ashes?

    ...or just talk to him with your rationale?

    Man, sometime I really don't know which option is the best. :)
  • As a former sort-of-exective-with-a-clue, I'd say the approach should be to make sure you can explain to management, in lay terms, why your solution is best. Demonstrate you understand the business by explaining how your plans will resolve their problems. Remember, they're looking for the best business decision, not necessarily the optimum technical solution. Yes, sometimes management won't listen, but give it your best shot. (And, don't speak in "us" and "them" terms. That just convinces management you really don't want to be there.)

    I've sat through hundreds of briefings, watching the IT crew make their pitch with a combination of "magic happens here" and "you need to be an engineer to understand this". That's bogus. Rather, the IT folks don't know how -- or can't be bothered -- to explain things in plain English. You better believe that the management folks sitting across the table see this as condescendingly elitist and leave the room in a distrustful mood, convinced that the engineers are scamming them. Once that happens, the atmosphere is poisoned.

    • I would think that if management hired these individuals, they might want to try showing them a little trust. Yes, I think you are right, the Techies should be able to explain things in lay terms, but that isn't always the easiest thing to do even for a tech that knows the stuff inside out. Also, lets face it, most of the true geeks that I know really are not interested in slowing down long enough to try to explain what they are doing, this does NOT mean that they don't know what they are doing. If management is dealing with someone that has screwed up a number of times, I could see the distrustful mood, but then I would ask, why is that tech still working there? If that is not the case, then I personally think management needs to back up and re-evaluate their actions and attitudes, they hired these people to do a job, let them do it. BTW, (this portion is in reference to comments made by others) that lay terms blade cuts both ways. Many of the management seem to think that they shouldn't bother explaining the bussiness end of the project to the techs, 'because they wouldn't understand it...' Here comes the utopian statement, we are supposed to be working as a team to achieve the overall goals of the team, and this doesn't work when parts of the team are being treated as mushrooms and do not know what the goals of the team are.
      • >> Many of the management seem to think that they shouldn't bother explaining the business end of the project to the techs...

        Very true. Management often dances to the same tune. That's a signal to get out.

        In my case, I spent a lot of time in a place where management did not hire or supervise the IT staff. IT lived in an independent chain of command, but most of their funding came out of management's pocket. This led to all kinds of evil wierdness, like IT people receiving promotions and awards for failed, disastrous projects, while the "business" people were drawn and quartered. Very nasty all around.
        • That's kind of interesting, I have a friend in the situation where the IT staff was a separate entity as well, and in his case, it isn't management that was drawn an quartered, it was the IT staff. That happened on a regular basis because the IT staff answered to everyone, and were used by various management factions to annoy other factions. Basically it came down to everything rolling down hill, and it always landed on the IT Dept. and then they wondered why they couldn't keep IT staff. This situation is also very nasty all around. And the really sad part is that because of this, they never accomplished anything which is contributing to the reason that they (the company) is being desolved by its parent company this Dec.
  • by BitGeek ( 19506 ) on Thursday September 26, 2002 @12:22PM (#4337142) Homepage

    This is one of those life tests, and you should not fail.

    When some clueless executive suggests something, the correct response is *always* to respond taking them seriously. IF what they suggest doesn't make sense, explain why. You don't have to go into detail, for instance: "We can't run IIS on our Linux servers because Microsoft doesn't support Linux for IIS, however Apache does the job well and is proven technology. This route saves us about $250,000 in annual license fees."

    Geeks have a tendency to get huffy. Or worse, to pretend like its legitimate and put it on the "will investigate" list hoping it will just be dropped. Doing that will only make you look bad when you don't provide the results of the investigation later.

    IF what you have is a PHB (as opposed to merely a non-geek executive) then you MUST respond, or you will eventually be out of a job. IF you let PHBs tell you that you HAVE to install IIS on linux, then the gauntlet is thrown-- either you stand up to them right then and there, or they make you their bitch.

    There are some managers with the stupid idea that you have to be strong and force people to comply with your wishes when it seems like they don't want to, so if they don't want to install IIS on linux, then by golly you better make them, or they will never respect you! And unfortunately, sometimes these managers pick absurd things to get huffy over. But you have to respond immediately pointing out the fallacy of the idea.

    IF they disagree with you, then you should understand their issue-- likely they are considering something other than technology-- like they got a great deal on sun boxes and it sure helped that other project. This is always in your best interest-- because if you blow them off and ignore thier issues, then you will not get support later when the time comes. IF you stand up to them and tell them why some idea won't work, then you may well get a variation of the idea back in response that DOES. That that variation will likely accomplish some goal you know nothing about but is directly related to your job security.

    At my last job (I'm freelance now) the engineers groused constantly about management and marketing. They acted as if everyone who wasn't an engineer was an idiot. They didn't know how good they had it-- at that company executive management and marketing actually listened to what engineers said, rather than undermining them, but still you heard nothing but bitching from the engineers. Everything was a fight, and thus, nothing worked-- cause they were fighting amongst themselves as well.

    The definition of "Competent" for an executive is not being able to recompile a linux kernel. IF you want to go far, you will learn to bridge that gap and figure out how to meet the issues he's concerned about, even if he fails to phrase them in the engineering-correct way. Most executives really are competant - and that includes marketing guys-- you just have to add their value to yours, not fight it. And you have to understand what they really are bringing to the table.

    Occasionally you get a PHB that's really just out to make your life miserable, but even then, answering the questions on the spot makes his job harder. A competent executive will respect and appreciate the quick answers.

    It might even make the meeting worthwhile.
  • by Anonymous Coward


    Unless there is a concrete plan for further review, just ignore the suggestions that you find ignorant. Many managers seem to have a pathological need to give orders, and won't remember a day later what they said at the review.

    I used to work for a guy who literally gave me a major change of plan every day, making it impossible to get anything done. It finally dawned on me that he was just playing Napoleon, so I got in the habit of agreeing with whatever he said and then going on with whatever actually needed to be done.

  • If your ideas are really good, sell them to your manager well enough so that he can sell it to his manager. If you made good enough points to support your argument, and if you have a decent manager, it will usually get sold to the highest level that needs to approve it. Of course, there will always be situations where you don't get what you want. And you may have ineffective management, in which case you should perhaps consider changing jobs.

    I'm not sure how to deal with the situation where all the levels of management are there at the same time when you are selling it. The best advice I can give is to make sure you've sold it to your manager first (and a level or 2 up) before the formal presentation. The formal presentation should just be a formality to make everyone comfortable with the decisions they've already made.
    • If your ideas are really good, sell them to your manager [. . .]


      I think that this gets at the crux of the frustration. Why would you hire someone for their technical skills and knowledge and then make them freaking beg you to listen to their technical advice.

      To be even more specific, people who directly manage technical people like to micro-manage them in a way they would never want to be micro-managed. The same guy that gets royally pissed when his boss micro-manages him has no problem telling Joe, "Yeah, you are the Architect, but here is how you are going to design it."

      Anyway, the bottom line is that managers get to choose to either 1. trust their people or fire them and hire ones they can trust, or 2. deal with a constant struggle of us-vs.-them and never get to play golf or read Forbes or whatever the fuck these types do when everything is running smoothly.

      I've had two really good managers. One was highly technical (he is a co-author of an O'Reilly book) the other . . . wasn't. What they both had in common was that all they did (from my point of view) was 1. give me the tools I needed to do my job, 2. insulate me from higher levels of management and 3. say the fuck out of my way. Easy. But almost no one can do it :-(

      -Peter
      • Excellent points. I agree that those are almost exactly the things I look for in a good manager. There's a lot of politics in my current position. So much that it was pissing me off so much that I was ready to quit. But the new manager does an incredible job of sheilding us from bull-shit. We just have to be sure to make him aware of the BS as soon as we run into it. When it comes time to get stuff we want, we have to sell it to him well enough so that he believes in it and he can sell it to his management.

        The most frustrating thing in a job is not being given the chance to do your job well. It doesn't make any sense for management to be an obstacle to you doing your job, but I've seen a lot of it.
  • by zoward ( 188110 ) <email.me.at.zoward.at.gmail.com> on Thursday September 26, 2002 @12:58PM (#4337433) Homepage
    I find I am almost always in a position where I have more to do than I'll ever finish. Sometimes, someone comes up with an idea that doesn't make sense but they're in a position to push for it to happen anyway. At that point I don't argue about whether it should happen, but rather say, "Okay, I'll add it to my list of things to do", and always find other things that are higher priority until the submittor forgets they ever asked for it. If the submittor keeps asking about it and you're their direct report, this won't work, and you'll need to take care of it. But hey, that's what they're paying you to do, right?
    • zoward writes: ... say, "Okay, I'll add it to my list of things to do", and always find other things that are higher priority until the submittor forgets they ever asked for it. If the submittor keeps asking about it... you'll need to take care of it. I've been working on a Apache+ModPerl project to implement this process as a web page.

      Basically, anybody on the system can submit a project, and set what THEY feel the priority should be, relative to their other submissions. But when you go to view your own personal todo list, the program applies your own modifiers to the priorities, giving some submitters and jobs a higher priority based on your subjective view.

      The list also shows a little 'nag' button next to each job. Click this, and the job temporarily gets a 'bump' in priority (Multiplier jumps from 1.00 to 1.1 to 1.21, etc). If you don't get nagged about something for a while, the 'bumps' wear off (the multiplier degrades back down to 1.00).

      The code isn't anywhere near ready for release....

  • Educate the boss (Score:1, Insightful)

    by Anonymous Coward
    Politely explain to the boss why it won't work. You don't do anyone a favor by letting management ignorance slide.
  • The new president at my workplace is very fond of a particular phrase. When he asks about implementing something and someone starts talking about the steps involved he always cuts them off and says "It's not HOW you'll do it, it's WHO'S going to do it!" and then he smiles and expects you to bask in the glow of his catch-phrase wisdom.
    He's used it three times with me already and since I'm a department of one I already know (as does he) WHO'S going to do it: ME!
    But he doesn't let that stop him from saying it.

    Bear in mind that some employee complaints about the boss are legit. People who automatically reclassifly any employee complaint about the boss as a "whine" will burn in Hell.
  • > These are pointless, time-wasting actions, proposed by the clueless executives invited to these reviews...

    Simply suggest that a head extraction device would be more cost effective, as in remove head from rectum. :-P

  • You have completely the wrong mentality, and it's scary. Are you a slave? Will your matser beat you if you speak out against him?

    SNAP OUT OF IT!

    You are both human beings and completely equal in every respect. You simply need to tell him, "Look, I realize you are trying to be helpful, but you have neither the expertise nor the the technical knowledge to make any design descisions on this product. If you really feel a great need to be helpful, then argue for raises for your engineering staff at the next board meeting..."
    • by Anonymous Coward
      > You are both human beings and completely equal in every respect. You simply need to tell him, "Look, I realize you are trying to be helpful, but you have neither the expertise nor the the technical knowledge to make any design descisions on this product. If you really feel a great need to be helpful, then argue for raises for your engineering staff at the next board meeting..."

      ROTFLUntilTearsStreamFromMyEyes!!!

      I am actually pleased that you've only worked for companies with good people such that you can have this attitude and mean it, but I'm so sorry, there are other types, and they can make life very miserable and/or your job at said company very short-term.

      "Equal in every respect"?!? OK, Who's doing the hiring/paying/firing and who was hired/paid/WillGetFired for being such a clueless employee?
  • snip-- I suspect the window of avoidance to be about one minute (before it's written down)." --snip When they pick up a pen to write it down SLAP it outta their hands. If they go to a computer to write it down... pull the plug or throw their monitor off their dest. That should sufficiently divert them from their task of putting their idea into ink.
  • Ask questions... (Score:2, Interesting)

    by dvd_tude ( 69482 )
    A small confession: I hate having my time wasted. My personal work ethic and my own desire to have some control over my fate makes me really sensitive to the "GFAR" type of command. I think most bright people feel the same way, unless they're so worn down that they merely accept the status quo and just roll with it (a very dangerous apporach, career-wise.) Intelligence, experience, knowledge and initiative are good things. The question is, how can you use these to your advantage in this type of losing scenario?

    I think the number one thing you can do is ask questions. You're not in the military, you're not going to be court-martialled if you start probing the 'why' of a seemingly-stupid assignment.

    If you have an actual reasonable person for a boss, the dialog that results from them answering your questions (and vice-versa) not only helps paint a more complete and accurate picture of their problem for you, but also forces them to think more deeply (and creatively) about the problem. What can result at the very least is a better definition of the problem. At best, a better solution can be worked out.

    But, the more subtle long-term benefit to the dialog is to build a level of mutual trust with that person. You've shown a genuine interest in helping the business by being interested in that aspect of a technical strategy. Likewise, they understand more fully the technical (and ultimately strategic and financial) aspects of the direction they want to pursure. They become more clueful, and so do you.

    What you really have is that you and he/she are both teacher and student at the same time. When this works well, it's magic: you become allies in dodging and reforming ill-informed decisionmaking, becoming reliable resources for each other. Everybody wins: you, the manager, and the business as a whole.

    Come to think of it, most important communication in business is by its nature, teaching. But, like any good teacher, prepare to be a good student too: listen, take notes, and don't slack off on the homework.

    - dvd_tude
  • as a techy, you have to consider what the real nature of your job is. Do you get paid for cranking out code/building servers/tuning networks/administering boxen/installing cool stuff ? Uh...no. You get paid to make things better in the company than they would otherwise be. I hate using the expression "adding value", but that's what it boils down to.

    So, how do you make things better than they might otherwise be ? Being uber-competent at your specialisation is a good start, but being able to communicate and work as part of a team is usually even more important. So, when someone asks you something, just about the worst approach is "the moment their lips started to flap I could see they were monumentally stupid and deserved to be mocked behind their backs on some geeky web site". It's your job to make things better - that means listening to ideas from sources you wouldn't normally consider (your boss' boss), and treating their input with some respect.
    And guess what ? If you take a little time to explore the idea with people, they can usually work out it isn't going to work. If you handle the conversation in a professional way, and show you're being thoughtful and thorough, after a few times you won't get the "I have to say something to justify my presence at this meeting" kind of input - people will start to trust your recommendations and plans.
    Of course, you could just do the pained "that idea is so stupid I can't believe you tie your own shoe-laces" attitude thing, and you'll find the non-techies will fear and loathe you, and secretly delight in sending you on GFAR exercises.

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...