Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Management that just doesn't understand

by the_slycer (Chaplain)
on Oct 24, 2001 at 19:43 UTC ( #121151=perlmeditation: print w/ replies, xml ) Need Help??

I am fuming here. I had to write/tell something to people that would understand and this is the best place that I could think of.

First, let me set the stage, I am a User Services Specialist (read that as a helpdesk guy at a better than average helpdesk) at a large company (50000+ employees). Now, I hate my job.. I've been here far too long to get any kind of enjoyment (other than the fun with the co-workers) out of it. The only thing that keeps me going is the applications that I write to help out the other helpdesk analysts (ie: password change utils etc). We use a ticketing system called Remedy. Recently I discovered the ARSPerl module which interfaces to the Remedy system. Life is all of a sudden good, a light goes off in my head with all the new little applications that I could write up to ease some of the dumb-a$$ processes that we have here.

Then a big light goes off..
why not write a web-based application that can create, modify, list tickets, show clients their open requests etc etc etc, so, mostly for fun I start to write this up. After a couple of days of doing this, a remedy-admin type comes up to me and tells me that his boss is looking for somebody to do this exact same thing. Life is now really good. Alterior motives kick in and tell me that if I can do a good job on this, and get it done quickly, I can amaze the hell out of the remedy group and possibly end up with a job.

So, 4 days later, most of it done on my own time, I've got a good system in place, it accepts a (remedy) login id and password, stores that information in a session based cookie (ie: close your browser, have to login again). Brings up a list of all open tickets for the group(s) that you are a part of, allows you to view the details for those groups, make changes to the tickets, and save the changes. The HTML is pretty, it is pleasing to the eye, and is very functional. In addition to this, the code is very well commented, seperated completely (via HTML::Template) from the HTML. Uses CGI for the important parts (params), double checks everything that it can, errors are reported nicely, with a message stating what you may have done wrong.

And now come the problems.
First of all, people are very suspicious because this was completed so quickly - they obviously have not witnessed the power of perl before - so they start asking questions. All of which I am prepared for, and give reasonable responses to.
Secondly, the script is currently running on a linux machine that is sitting right next to me on my desk. This is a relatively base install of linux, with some minor tweaks (standard kernel recompile, kill services blah blah blah). It runs Apache. Currently on the box, Apache is not running mod_ssl.

The final decision from the management is that the script is not secure because it is not running SSL. Read that again, the script is not running SSL. They are demanding that it is removed from my teeny webserver because of this, and now will not use the code, meaning that they will spend the next few months attempting to replicate what I have already completed. Only to find out that their script or application doesn't run SSL either.

The thing that REALLY gets me about this is that no-one has talked to me about it. No one has asked ME about the code, other than through some very roundabout emails, and nobody thought to ask me whether it could 'run ssl'.

Definately time for a slapping of the upper management.

Thanks for listening to my whine. I really don't think that there is anything I can do about this, especially as a 'lowly helpdesk technician', but I definately think it's time to look for work with a new company.. but that's a different meditation...

Comment on Management that just doesn't understand
Re: Management that just doesn't understand
by maverick (Curate) on Oct 24, 2001 at 20:34 UTC
    First off, sorry that this is happening to you. It is unfortunately pretty common. You have two options.
    1. Apply a Clue-by-four to the manager's head. This approach takes some guts. Basically you have to tell the person that is the decision maker. Not the second level guy below him, but the decision maker himself. "Look. You're mistaken about this. This is how it really works. etc, etc." You're going to have to be VERY prepared to make it makes sense to someone who is clueless.
    2. The sneak attack. Compile Mod_SSL into your webserver. (Have you seen Apache toolbox yet? This will make compiling Apache a snap for you). After that, disable port 80, then send an email to ALL the managers, etc, in the group that has been discussing this. Tell them that their concerns have been addressed and the script has been altered to run under SSL. Yes, I know that that isn't accurate for what you did. BUT you're not dealing with someone with a clue remember?
    Good luck. Hope this Helps.

    /\/\averick
    perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

Re (tilly) 1: Management that just doesn't understand
by tilly (Archbishop) on Oct 24, 2001 at 20:43 UTC
    Why not install mod_ssl, run the script under ssl, and send back an email to all concerned saying it is now running under ssl, and re-open the question?

    Be sure to send email to a list of people (be sure to include the boss who wants the application the most) and make it polite and to the point. Something like this:

    I am sorry. I had no idea that SSL was a requirement. I reconfigured the webserver that I put my proof of concept on, and the script is now running securely under SSL. This changes the URL to https://xxxxx/xxx. I would be happy to make any other changes that are needed. Sincerely, xxxxxx
    The image you want is not upset or frustrated. Just ready, willing, and able to help. Focus on that. Because the fact is that you are making someone look really bad (namely whoever would normally produce this type of application), and that will cause political problems. (Hence the obviously stupid technical complaint about a non-issue.) But the nicer you are about the situation, and the more useful your stuff is, the more likely you are to handle the political problem.
Re: Management that just doesn't understand
by petral (Curate) on Oct 24, 2001 at 20:47 UTC
    Third possibility, laugh it off.  Be glad that real computing power isn't available to them (because it's hidden in plain sight) and that they will be kept harmlessly busy for months.  Meanwhile, you've picked up skills in putting it together that they can't take away from you.

      p
Re: Management that just doesn't understand
by footpad (Monsignor) on Oct 24, 2001 at 21:14 UTC

    Handle this very carefully.

    It's likely that the person that tagged your code as "insecure" manages (or is) the developer that would have been assigned to the project--meaning you may have inadvertantly triggered a turf war.

    How? In my experience, companies of the size you're talking about plan projects long before code gets written. They allocate resources, draw up specifications, etc. and so on. It's weird, but it's easier to get a $300,000 project approved than a $3,000 one--even when the latter project will save more money in the long run.

    Furthermore, most dev. teams in such shops have huge backloads. It can take a year or more for "permission" to start coding. During this time, middle managers wanting more people, budget, training, power, or whatever are dueling with senior managers wanting the same and to hold down costs. This is especially true in large organizations where some fear the next re-org.

    As a result, project estimates are frequently inflated, in terms of cost and development time. What seems like a simple 40-hour job may be estimated at taking six to nine months to complete. It sucks, but that's the way some companies work.

    Now, imagine yourself in such a position. You're bidding this project at, say, six months of dedicated time by however many developers. And you're close to getting approval. It's taken three months of wrangling, but you're almost there.

    Suddenly, this upstart no one's ever heard of (from Tech, of all places) comes along and shows a working version written in four days. At the very least, senior management is going to want to know why that was possible when your estimates were far longer. It's clear you need to discredit it and to do so in a way that will sound good to your budget minded, but non-technical superiors. So, you play the "security" card.

    Now, I'm not saying that's what happened, but I have seen it done before. And, yes, I'm speaking from experience.

    A number of years ago, I wrote a little program that would save countless hours and tens of thousands each year. I demoed it to the people that would be using it, generated some enthusiasm, made some fixes...and got abruptly shut down by a senior manager that was as technical as a fish in a locomotive.

    Furthermore, I handled it badly. I blew up, made a lot of disparaging comments, and very carefully dissected the senior manager's skills and reputation. I felt smug in my moral and technical superiority. I also lost my job a few weeks later. It was called a "reduction in FTE's" in public, but my manager told me (off the record) that the manager I'd embarassed (his superior) had me fired.

    Now, that was a long time ago and I spent a lot of time thinking about other ways I could have responded. My working theory is:

    • First and foremost, I should not have lost my temper. Period.

    • I should not have disparaged the senior manager--especially in public.

    • I should have accepted that there could be ways to improve it and asked the senior manager if he could spare some time to offer suggestions or to perhaps help find ways to "leverage" the "prototype" I'd written.

    • During that talk (assuming it took place), I should have asked how I could help him best achieve his goals and then listened very carefully.

    • I should have worked with my manager before publically demoing my work and gotten his input on how to deploy it most effectively.

    I really hated losing that job. While it wasn't the best one I ever had and I did end up with a better one (in Silicon Valley, no less), I always felt I'd been, um, had....and only because I was trying to do the best thing for the organization and because I'd been honest. Furthermore, I was right. Yet, I was the one that got fired.

    I think diplomacy is your best weapon at this point. Be tactful and try to co-opt the person(s) who shot your code down. Make darned sure you give people graceful ways out of an untenable situation...even if that means taking a little heat or giving them credit for "saving" your code. Do you deserve it? No. However, having your code actually deployed should help make up for it in the long run. It's probably not going to be easy, but gentle persistence should help.

    On the other hand, you may need to simply let it go. Above all, be discrete and respectful--especially when dealing with managers and senior personnel.

    In closing, here's a relevant quote (blacked out because some may find it offensive):
    Unless you intend to kill him immediately thereafter, never kick a man in the balls. Not even symbolically. Or perhaps, especially not symbolically.
    -- Robert A. Heinlein, Friday

    --f

Re: Management that just doesn't understand
by dws (Chancellor) on Oct 24, 2001 at 22:55 UTC
    footpad did an excellent job of covering most of my response to this, so I'll focus on the warning signs you might look for to avoid getting into this mess again.

    You wrote:

    Alterior motives kick in and tell me that if I can do a good job on this, and get it done quickly, I can amaze the hell out of the remedy group and possibly end up with a job.
    This looks very much like a specific form of the behavioral trap called "inflicting help", which I know very well, having stepped into it many times before.

    In this trap, A anticipates a reward for helping B on A's terms, but A acts without first seeking B's permission. B thinks they're being meddled with, and takes offense. The result is hurt feelings on both sides, which could have been avoided had A first sought B's permission.

    One key point of this is that B won't grant permission if they aren't satisfied that A understands the real problem (i.e., the problem as B sees it). The real problem is often much wider, richer, deeper, more frought with political aspects, etc., than it first appears to the outside observer. Another key point is that by first engaging in a dialog, A and B can build the bonds necessary for B to feel comfortable with A's intentions.

    So how does that apply here? Simply this: If, like many technical people, you see things first as being technical problems, you're at risk of skipping non-technical discussions about a problem. This leads to lots of missed information, and before you know it you're getting dinged for inflicting help.

    Had you first sought the permission of the folks administering Remedy (through their management), your situation might have unfolded quite differently. First, you would have avoided surprising management. Surprising management can be a Very Bad Thing. Technical people who've been spared the opportunity of wearing a manager's hat often fail to realize just how and why surprises can be such a bad thing. (There's a whole Meditation there, at least.) Managment might have said "no thanks," but that's still better than the situation you find yourself in now.

    Second, by seeking an audience first, you might have increased the odds of your eventually getting a job with that group. By showing the technical people that you understood part of what they were up to, had thought about it, and had some ideas that might help them, you might have gotten their support. (Or you might have stepped into a nasty debate within the group). But by surprising their management, you likely screwed any chance of joining that team.

    Third, the ensuing discussion might have revealed addition context and constraints (such as SSL, if that is a real constraint and not just a blocking maneuver) that you could have coped with before this became a political problem.

    The meta-moral of this is that the next time you want to help someone, ask their permission first.

(Ovid) Re: Management that just doesn't understand
by Ovid (Cardinal) on Oct 24, 2001 at 23:23 UTC

    I suspect (as others have pointed out or alluded to) that the problem here is that you are a threat to the Powers That Be. You're the janitor in the background who makes the admins feel like idiots when you've asked "why they don't just plug in that thingy that someone tripped over?"

    I had a similar situation. I had a senior programmer, who I will call Connie (because that's her name) who was very protective of the system she worked on. One time she walked in on another programmer, Ann, fixing some problems on the system Connie worked on. Connie demanded to know what Ann was doing and Ann replied "I'm tired of getting paged at two o'clock in the morning to fix this thing."

    Connie's response: "But if it doesn't break, they won't need us any more."

    Connie was terribly concerned that other people would learn her system and make her redundant, or worse, improve the processes to the point where she wasn't needed any more. At one point, she gave me a job that should have taken about a month to do -- her way (side note: I think I've related this incident here before). I got it done in just a few hours by cobbling together a few scripts that I had previously written. I then sent out an email saying that since I had never done anything like this before, it would be helpful it others could double-check my work. As it turns out, I forgot to change the name of a couple of disk packs, but it only took about 30 seconds to fix once Connie pointed that out.

    The result of my finishing a month of work in a day? On my next review, Connie wrote that because I missed the name of a couple of disk packs, I was "inattentive to detail". There was no mention of the fact that I had saved a month of labor. I found out later that management was trying to get rid of Connie for stunts like this :)

    In short, be very, very careful about politics. It's miserable having to deal with this, but it's the real world. Sigh...

    Cheers,
    Ovid

    Vote for paco!

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Re: Management that just doesn't understand
by eduardo (Curate) on Oct 25, 2001 at 02:08 UTC
    Ok... a question to all those that have been in academia... *this* is the reason I am no longer working "in the real world" except for a contract gig here or there... and I have decided to go back and get a Ph.D and become a professor. Is it *any* better in academia?
      I think you're just trading one sort of politics for another. I've got a friend who's a PhD and really does know his stuff (not computers), was voted "Teacher of the Year" at the college he taught at, and then the same year was fired after criticising another professor's work. BTW, good luck :-)
        Well... I have heard about that... and I guess I can sort of understand how that sort of thing works, and I do see that I am trading in one sort of thought police for the next. My basic hope, to be brutally honest, stems from the horrible realization that even though it could be argued that I was within a few strides of being relatively successful in the "rat race" (I ended my relationship with my previous employer, and had some very nice management offers waiting for me) I realized that even if I were to win the rat race... I would still be a rat :(

        It got to me... I decided I had to find something at least *marginally* more fulfilling than sitting around and telling clients half veiled truths, wondering about accounts receivable, and waiting for the newest wave of buzzwords to wash over us so that I could retool the marketing documents so that they were "buzzword compliant." I am hopeing that maybe through teaching I will be able to actually see *progress* and *value* be created. I like the idea of seeing someone enter a classroom not knowing about _________ (whatever it may be I end up teaching, according to PhD friends of mine, I can expect my first few years to teach computer literacy...) and leaving the classroom 4 months later actually *KNOWING* something. And I know that for the average set of students most of them won't care... but maybe, just maybe, there will be one every once in a while that I can actually see *progress*... and *learn*... and become a better person... all because I was standing in front of the room waving my arms around wildly and ranting on about who knows what. (hell, I was able to convince clients I was interested in some of the most *boring things ever*... I know I can make damned near anything even mildly exciting.)

        And hey... If I get to sit around and research complexity theory for a few hours a week, and write some papers here and there... even better :) We'll see how it goes... One of my ex-professors has agreed to let me grade all of her most boring assingments for the rest of this semester... let's see if I can do this, eh? :) And thanks for the good wishes, I am going to need them!
Re: Management that just doesn't understand
by social_mandog (Sexton) on Oct 25, 2001 at 06:13 UTC
    A bunch of people have said useful things.

    Email is probably not the way to deal with this situation. You should schedule face time with whomever made the decision.

    If there are dysfunctional politics, it is unlikely anyone will clue you in writing. The odds are much better tha somebody will (perhaps confidentially) tell you the real issue in person.

    It has been my experience that email is not a good way to get willfully non-technical types to understand the important nuances. If somebody doesn't understand the difference between RAM and disc, they aren't going to bother with your email, but might pay attention when you make little circles with your finger to simulate a spinning disc.

    Hope this helps


    social_mandog aka mandog

Re: Management that just doesn't understand
by tonyday (Scribe) on Oct 25, 2001 at 12:08 UTC
    I've read through the replies and they all give sound advice about how to work the system. There is however a lesser known path to follow which I'll call the "secret way". To be precise, there is a vast underground of technological personnel like yourself that effectively bypass the status quo. Let me explain with my personal story of finding the secret.

    Phase 1 - the problem emerges

    It began with the decision to outsource the development of our back-office processes. Basic maintenance issues from user land (where I live) were either ignored or funneled into the spec development for the outsourcing solution. Suggested improvements to the existing process got you into a lot of trouble as this would have weakened the case for the outsourced solution.

    Phase 1 of the "secret way" began with non-sanctioned quick fixes by a few of the remaining developers. Usually we would sticky tape a spreadsheet dump of data to an existing process which would patch the system. A few of us in user land clandestinely took VB courses and put some logic to the information flow. Users taught each other about good spreadsheet design, how best to reconcile data and a host of valuable skills.

    Despite our best efforts, the process was decaying quickly. Bosses in user land were becoming scared with stressed employees and no news on the outsourced solution.

    Phase 2 - The Prototype

    We got lucky. The new BA we got in to help write the specs for the outsourced development wasn't interested in writing specs. He was an acolyte for the secret path and thus interested in helping us find solutions to today's problems. I began to have conversations like this...
    BA: "I think that if you put this data in a database you'd save a lot of time."
    me: "But we need the data by 9 am and they wont let us logon to the mainframe till after some backup process finishes at 11 am. It's gonna take 6 months to get this agreed to"
    BA: "Have you ever seen Access, they don't put it on your menu but you can get it here *click* ... You get the data in by doing this *cut* *paste*. You can get the answer by running a query which I wrote this morning *click* ... there you go"
    me: "Wow, so this job will take 10 minutes rather than an hour - great stuff"
    BA: "Actually you could automate this and those other things so that it would be done automatically when the data arrives"


    enlightenment


    As for the specs, we reasoned with management that doing spreadsheets was the easiest way for a user to explain what was needed (everyone knew that users couldn't write specs properly). What we were doing was building a Prototype using those baby toys like excel and access *sneer*. It's not going to actually work or anything *laugh*.

    Phase 3 - Back to the Future

    The two years were up and it became obvious to one and all that the new system was delayed. Well not actually delayed but rather not yet started. How was management to know that the system they were shown in the slideshow didn't exist. The project lapsed, the outsourcers left the building never to be seen again.

    The only thing left holding us all together was now the prototype. In the minds of management, chaos reigned and the gods of capitalism would descend to exact retribution. But they didn't - new IT guys came in and announced that we needed some serious inhouse development to replace all those spreadsheets and user databases. Management concurred. This time we were ready...

    Phase 4 - And now...

    There are a few golden rules we acolytes of the secret follow:
    1. When IT develops a shiny solution at great expense say "thank you, may I have another"

    2. Dont tell them the shiny solution isn't used for at least 12 months. They get a tick for the development (no user complaints) and a tick for identification of redundant processes.

    3. Protect identities of fellow travellers. Never ever send emails saying there is a better way or that someone did 6 months development in a day.

    4. If you're on the inside of the status quo, use the bloated schedule for good by helping users in the know. We will reward you with "official" projects that can be used to spread the way.

    5. To the status quo, disparage your solutions as prototypes or hacks that are obviously flawed, violating every known design rule and will ultimately doom the entire company. Just get them to agree that they should remain in place till they arrive at the proper solution.

    I assume it's the same everywhere so shifting jobs may not help. Let yourself be known as someone who can quietly help get the job done. The secret way is always recruiting ;)
Re: Management that just doesn't understand
by Anonymous Monk on Oct 25, 2001 at 15:57 UTC

    Most of the comments from footpad on down are incredibly on the mark here. Especially in a company the size of your the problem has nothing to do with the code but politics, however here's a technical add-on that might make your solution more appealing

    Propose to resolve the SSL issue with a product called BIG-IP and make a formal written proposal with the architecture including it.

    Why?

    The Big IP handles all of the load balancing and SSL striping eliminating the load from your server while bloating the budget to something they can accept easier. As well as making your product easier to handle heavier loads. Secondly it provides an opportunity for someone higher up the political food chain to 'discover' how else the BigIP could be utilized in other ways by your company. Let this bigger fish run with this idea and he'll bring your product along with his new 'brain child'

    It doesn't have to be this product, it just fit's into the methodology I'm trying to show you.

    Anonymous Monk -> It's called 'Management' not because of the work that's managed but the work required upon the ego's of those with the title ;)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://121151]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2014-08-28 04:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (256 votes), past polls