Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Insubordination or Exploitation?

by Silicon Cactus (Scribe)
on Mar 26, 2002 at 18:13 UTC ( #154459=perlmeditation: print w/replies, xml ) Need Help??

As a newish person to the IT industry (2.5 or so years- but many more years in computing otherwise) I have gone from tier 1 tech support to Problem Management Software admin. During this time I have taught myself many things, developing with perl is one of them.

Throughout my various promotions here, I have always gone above and beyond. My supervisor, and her supervisor also have discovered that in addition to my willingness to do what it takes for the company, I also love to code.

As it stands (sorry, even though it is is gauche, it is relevant) i make slightly over 33k USD/year as an HOURLY employee in a 24/7 environ. Not a lot, particularly for my base job as it is. (I am willing to bet most of you agree to this.)

My company is switching help desk software, me and 3 others are doing the actual work, while outside implimenters are being contracted to design business flow. Cool. No big deal, except we are a 2800 tickets/day shop. Even more cause here for more money, at least I think so.

However it gets even better. Today my boss asked me to develop a web application that will let users look up tickets, create tickets, etc, etc. I was dumbstruck. Not only do I have to create this from scratch, with NO requirements, but I have to do this at my current pay rate. There is NO way this falls within my job description, and while I would LOVE doing it, do I?- but wait there's more!! In the same breath, I was asked to develop a database front end with - you guessed it- scanning support for a device line I know nothing about!

The question becomes, do I do what I love and develop these apps knowing I am being paid half of what the developers for these kinds of applications make? If I do let them exploit me like that, what stops them from doing it again? Am I being insubbordinate if I say no?

Help Monks, please. I am stuck. Badly.

Replies are listed 'Best First'.
(Ovid - catch 22) Re: Insubordination or Exploitation?
by Ovid (Cardinal) on Mar 26, 2002 at 18:41 UTC

    Just remember the old saying: "when life gives you lemons, make tequila shooters."

    Oh, wait. I think I messed up that saying somehow, but I can't quite put my tongue on it. (if you've never had a tequila shooter, that "humor" may not make a lot of sense)

    You may be faced with a Catch-22 situation, but not the one you are thinking about. Many people without paid programming experience want a programming job. However, companies won't hire them without paid programming experience.

    Yes, it sounds like your boss has put you in an awkward position. However, you have a brilliant opportunity: getting paid to build your résumé. I would accept and go through a product life cycle (there are variations on this, but this is a good start).

    1. Develop a problem statement.
    2. Do a requirements analysis.
    3. Write up a system specification and get your boss to sign off on it!.
    4. Build, debug, and test the system.
    5. Have users perform acceptance testing.
    6. Install the system and bask in the glory.
    7. Add that to your résumé and start job hunting while still employed.

    Now, that's a great way to get this done. However, there is an alternative. Spend three hours installing Bugzilla. It's not perfect, but it will probably satisfy most of your bosses requirements and it's free.

    Cheers,
    Ovid

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

      3. Write down a system specification and get the boss to sign off on it!
      4. Build, debug, and test the system.
      ...

      I'm gonna throw in some dissent here. What this lays out is a "Big Design Up Front" approach to the project, which assumes that you can (a) know it all up front, (b) design it all up front, and (c) deliver it to a customer who hasn't changed their mind in the meantime. The problem with this is that the customer in this case may have a pretty good idea of what they want at the moment, but they're also liable to change their idea once they start seeing a working system fall together. Requirements are going to change. Allow for this in your approach.

      I recommend borrowing some ideas from the eXtreme Programming and Agile Methodology camps. Build the system in discrete iterations (AKA "sprints"). At the beginning of each iterations, get your customer to prioritize a set of features that they would like to see appear in 30 days. Estimate each one, and draw a line through the list show what's "in scope" for the iteration. That's what you'll build. Any changes in requirements that show up while you're building go under the line on the list, to be revisited when you reprioritize before the next iteration.

      This approach gets some functionality into customers' hands early, and gives them the chance to either clarify what they really want, or to change their minds without throwing away a huge amount of work. It also avoids generating a set of documents that have, at best, historical interest once the project is complete.

      Your first iteration might be to install Bugzilla or RT, and do some minimal look-and-feel customizations. That'll give your boss something to play with, and it can engage real users. It also gets you a quick win, which is great for project momentum.

        For smaller, ill-defined projects, I think that agile development models are a Good Thing. However, the part about getting the boss to sign off is purely a CYA maneuver. I think this person is in an awful situation and as soon as the boss says "why the heck did you do that?", the reply is "well, here's your signature".

        Almost invariably, unless the project is very small, once I turn in a specification, the boss always changes something. I know of some people who deliberately put glaring problems (typically cosmetic) in specs merely so that the boss will hone in on those glaring problems and not screw up the core. Once the boss changes something, he or she has said "I've read this and approve, so long as these changes are made." It's tough for the boss to later turn around and shift the blame away from the signature.

        Frankly, in a dicey "me versus the boss" situation, I don't want the uncertainty of an agile model. I want good, clean specs that I can point to. I've had to hold up signed specs before and the result has always been something along the lines of "my signature? Oh, yes. Of course I read that. But requirements changed. Could you please work this in?" I still have to do the work, but I no longer face the heat.

        Mind you, if this were a normal situation, I think your advice would be spot on.

        Cheers,
        Ovid

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

      I agree with Ovid's post on this. View this as an opportunity. I had a similar experience where I accepted a political hot potato software project but the benefits in the end outweighed the negatives but, of course, you have to deliver.

      Make sure that you write down the requirements of the project so that you don't get burned by 'we wanted this or that'. Bug your boss. Bug potential users.

      Consider keeping a calendar notebook (if this is a political hot potato) so that you can make notes about your project and what people agreed to or what you accomplished. You may want to refer to http://useit.com in your development work as a reference on user interface do's and don'ts.

      metadoktor

      "The doktor is in."

      That is not a bad idea, but considering my title is "Tivoli Administrator," how can I claim development experience without fear of- well, the obvious:

      "How is it that you developed applications while you were doing pm administration?"

      I admit, I am a bit naive about things such as this.

        No worries. This happens all the time and no employer is going to be surprised by this. Just tell them the truth.

        Cheers,
        Ovid

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

        Don't worry about the title. If you send your resume off to another company, they'll look at the experience, not the technical title. Often titles have little meaning outside the company that you are in.

        My last job title was "Principle Telecommunications Technical Officer" I was paid to do cellular base station design and project management. Now my title is "Unix System Administrator". IMO Employers are much more interested in a demonstrated ability to do the job than in titles and qualifications.

        There are clearly other issues involved in making your decision about taking this task on but I wouldn't let details like this get in the way of gaining experience... most of the people I know who work in IT started off doing something else.

        --
        my $chainsaw = 'Perl';

Re: Insubordination or Exploitation?
by maverick (Curate) on Mar 26, 2002 at 18:34 UTC
    There is nothing wrong with politely informing your superiors that they are asking you to do tasks that you are not being paid to do, not within the job you were hired for, and not qualified for. Turn it around on them...ask them if they would go fix the copy machine if one of the VPs asked them to. The last word of your title is 'Administrator' not 'Developer' or 'Programmer'...

    Even if you want to do it, do you want to be accountable for it? As you've already stated, you don't have a spec and that spells T-R-O-U-B-L-E. Period, end of story.

    I'd just say something to the effect that, "I can't do this. It isn't part of the job I was hired for. I have enough to do for the job I *was* hired for. If you want to transfer me into a development position, we can talk"

    Here's another thought...does your company have a development team? Why weren't they assigned this? Could it be because of the lack of a spec?

    update: minor typos corrected

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

      "I can't do this. It isn't part of the job I was hired for. I have enough to do for the job I *was* hired for. I you want to transfer me into a development position, we can talk"

      Unfortunately, I think this might be construed as insubordination. Not willing to do something, even outside your job spec, is viewed by our non-tech IT support Director as heresy/mutiny- I may end up doing this though.

      Yes our IT department has SEVERAL development teams. However, my supe and her manager will are loathe to ask for development help because then the project won't be 'theirs'. Yes, I do realise this is ridiculous, and and a heap of political garbage, but it is leaving me with a very very cold feeling.

        If you can't talk to your bosses rationally and reasonably then it's going to be trouble. Not performing tasks which are not your responsibility isn't insubordination...if these tasks were part of your job description then it would be. If they can't see that, then the fault isn't on you, it's on them.

        If you do as they ask and it doesn't come out *perfect* (remember you have no spec, and you still have to do your normal job too) there is going to be trouble.

        If you do as they ask and it does come out perfect, you've set yourself up to get *more* things like this in the future, until you hit paragraph #2.

        Brush up your resume...if they aren't going to listen to you, then you may have to find another job. Good bosses do exist.

        Good luck and don't loose heart...this has happened to others before...

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

        However, my supe and her manager will are loathe to ask for development help because then the project won't be 'theirs'.

        Can you hear the alarm bells ringing? Run, do not walk, run very fast away from this. You are being a pawn in a much higher level political power game. I am sure your direct management is looking for a quick and dirty (and no cost) solution to a IT problem, and when you have implemented it (at no additional cost to your unit), your management will then use this as ammunition to shoot at the development group(s), and thusly get more glory, power and budget to their empire.

        Start looking around for another job. Maybe the development teams need a keen developer. I would suggest it would be much better to find another employer that does not play such stupid and childish games. And I haven't even started on issues like lack of a proper spec, expecting you to take on more and more responsibilities for no additional pay, and the rest of the sorry tale.

Re: Insubordination or Exploitation?
by mstone (Deacon) on Mar 26, 2002 at 21:29 UTC
    Am I being insubordinate if I say no?

    Are you being irresponsible if you say yes?

    Most companies can't estimate the size, complexity, dollar cost, labor cost, or schedule of a project to within even 50% accuracy. They have no prior metrics on which to base estimates, and no specs clear enough to show how much one project is like another. No two projects are alike, and every project requires heroic effort on the part of the developers. By the unofficial* standards of the Software Engineering Institute, this is called Capability Maturity Model Level-0 (CMM0).

    * (officially, there is no CMM0.. the scale starts at CMM1: repeatable)

    In CMM0 shops, bosses evolve a protocol for deciding what's possible: they tell the developers, "we want this," and watch the reaction. If the developers say, "oh yeah.. no problem," the boss knows that something similar has been done before. If the developers just giggle, the boss knows that the job is unreasonable. If the developers look strained, the boss knows that the job is possible, but will require heroic effort -- which is the 'sweet spot' of CMM0 development.

    The problem with the 'giggle test' is that it leads companies to move projects past their safety limits. Eventually something goes wrong, and instead of being a problem, it turns into a disaster.

    So -- do you really have the spare resources to take on this project, or are you just planning to dance faster and hope nothing goes wrong?

    'Hoping nothing goes wrong' is irresponsible. It exposes your employer to risk. Refusing to tell your boss that there might be a risk is irresponsible, because your boss's job is to allocate resources based on the probability of success, based on the risks he knows about. Refusing to tell your boss that there might be a risk and calling it 'loyalty' is -- hrm.. polite term -- misguided.

    Trust me -- if your boss has clue one about how to do his job, he wants to hear bad news before it reaches disaster status. His job is to make decisions, and he can't do that if you hide information because you think he won't like it. You don't have to throw a hissy fit, you don't have to complain that you're not being paid enough, you just have to say, "doing this would put a strain on the rest of my work."

    That's information your boss needs to know, and telling him is anything but insubordinate.

    ----

    PS -- running the text of your post through the 'giggle test' suggests that you do not have the resources to handle this new project without putting your other work at risk. So would you rather tell your boss about it now, or 6-12 weeks down the road when something has gone down in flames?

Re: Insubordination or Exploitation?
by shotgunefx (Parson) on Mar 26, 2002 at 18:42 UTC
    Not sure what to tell you. I worked at a Tech support center in Cambridge, MA. I got paid much less. There were roughly 20 "Projects" each with a Project Manager. PM's had to handle "escalations". Basically any question that wasn't "Reinstall direct-x".

    Some of our techs were good but most just couldn't be bothered to distract themselves from Team Fortress. Each time you got another Project to handle, it was customary to get more $$$. Not me though. Before you know it, I had 10 of the 20 projects. Plus doing devel there too.

    Well Yahoo! bought one of our clients and the volume increased by over 1000% overnight. We only had two techs versed in it so I was f*cked. I had to handle 400+ escalations a day on this one project alone. They didn't give me any more $$$. This one account now accounted for 40% of their business. Plus they were bitching because I wasn't answering enough calls in the queue. LOL

    Finally they sensed that I was getting fed up and realized they were screwed without me. I started getting more money without me asking or telling me. I would just look and have a bigger paycheck. (Still sh*t money but a little better.) It was too late. I had already said "F" this. I can't do it. Not another day. I left one week before my two weeks paid vacation. I just couldn't do it anymore. Not even for a week. So I quit and struck out on my own.

    I think there was a point to all this bitching though. I think your employer has shown that they don't value your skills or time. They will most likely keep sucking you dry until you say "F" this and then they will start the cycle anew.

    I'm not saying you should quit or demand more money. If you are in a position where you can, I would call them on this if it were me. If you don't feel comfortable doing that, learn everything you can and blow that joint as soon as possible.

    My two cents.

    -Lee

    "To be civilized is to deny one's nature."
Re: Insubordination or Exploitation?
by Steve_p (Priest) on Mar 26, 2002 at 19:21 UTC

    The simple answer is do it for the experience. Say it takes you a year to build this intranet based system, when you finish it, you will have several advantages.

    • One, a full year of web and database development and design.
    • Two, a likely much better job market.
    • Three, project management experience.

    My advice is to suck up, take it in the you know where for a year, and in the end, look for a job elsewhere inside the company or outside.

    You first mission, if you decide to accept it is to begin the first step of a project -- managing expectations. You will not be able to work full time on two projects at the same time. Give a base estimate of how long you think it will take based on the information you have. Let them know how long it will be before you can even start on the new project, assuming your current projects go as scheduled. Once you get the project, run with it as if you are the project manager/analyst/programmer all in one. This experience will make you much more valuable than the typical person with 3.5 years of experience.

Re: Insubordination or Exploitation?
by redsquirrel (Hermit) on Mar 26, 2002 at 18:57 UTC
    I know what you're going through. I've had a similar career path over the last 2 years since leaving the field of psychology. Your situation seems to be an inevitability when an employee teaches himself and learns at a rate that outpaces his current job description.

    It is a very difficult situation, I know. You have learned and excelled very quickly, so quickly that your pay rate could not have kept up. Your company sees your abilities and your knowledge and wants to make use of it. Resentment begins to build as you realize that you are being taken advantage of.

    The way I see it (and I'm in a very similar situation currently), you should take this project on. It will be excellent ammunition against your company when review time comes and you demand the pay you deserve. And, in the meantime, I would use this project as a resume builder and begin looking for other opportunities. Sometimes when people grow as fast as you have, they outgrow their company.

    If you do choose to take on this project, I would advise you to not write a single piece of code until you have compiled an acceptable list of objectives. Since they have not offered any, it seems you will have to pull it out of them.

    Thanks for sharing you dilemma,
    --Dave

Re: Insubordination or Exploitation?
by dws (Chancellor) on Mar 26, 2002 at 18:48 UTC
    The question becomes, do I do what I love and develop these apps knowing I am being paid half of what the developers for these kinds of applications make? If I do let them exploit me like that, what stops them from doing it again? Am I being insubbordinate if I say no?

    If you want to get out of what you're doing, it may be that you've just been handed a ticket. Doing this will be great fun, and good for the resume. Sure, it's at half pay, but with Perl it shouldn't take you too long to do...

    It's not insubbordination to tell you boss that parts of the job are outside of your capabilities. Sign up for only the parts you have confidence that you can handle.

Re: Insubordination or Exploitation?
by broquaint (Abbot) on Mar 26, 2002 at 18:27 UTC
    > a web application that will let users look up tickets, create tickets, etc, etc
    If using external software is an option then I would look into using Request Tracker for all your ticket tracking needs :-)
    HTH

    broquaint

      Although Silicon Cactus has already noted that this software will probably not be a viable solution for his situation, I'd just like to point out for the benefit of the other Monks that Request Tracker is available under the GPL, since I didn't find that to be clear from their web site (I read the COPYING file in the tarball of RT 2.0 that I downloaded to check out). Also, as is quite clear from the web site ;), there are various levels of paid support contracts available, which could be very helpful for larger companies/institutions wanting to deploy this software.

      Unfortunately the problem management software we are using is ServiceCenter, produced by Peregrine. Our data at least is to be ported out of their flat file database <no comment on that> to a rdbms.

      I am working very hard on not saying anything about this product at all. Except for those familiar with it, my management wants me to recreate all the functionality of their Get.Services web application for my company so they need not purchase it.

Re: Insubordination or Exploitation?
by pizza_milkshake (Monk) on Mar 26, 2002 at 21:42 UTC
    Cactus,

    Well I'd say it comes down to two factors: How much your current job means to you and whether or not you think you have any chance at making some good progress with this app.

    If you really don't think you're qualified and don't want to take a chance, play it safe and simply say "I don't think I'm ready for this." Else,why not? Worst case is the thing is a huge disaster and you can either go on with your job or get sick of the place and leave for better money.

    I guarentee, though, if you take the job it will teach you some things about how much you really do and don't know, and that's valuable. About a year ago I was in a similiar situation stuck developing a complex reporting system in (ack) ASP. I managed to get a good deal done, but my planning and VB skills just weren't up to the task (that and the fact that they kept adding things on and on... went from one page to ~20 in around a month)

    Anyhow, I got sick of the place (I was working part-time for crappy money) and started working contract. I'm much happier where I am now than where I would have been if I was still working the other job. I also learned about the importance of design and planning, planning, planning before anything complex... also learned about getting people to sign off on projects before they start so they don't get out of control ("Ohh.. that was easy. Let's make it do this and this too!")

    Anyhow, if you do accept the project and it is a success (always an outside chance) you can then leverage that for a raise... knowing the plumbing of the system can be job security for you.

    Best of luck

    --pizza

    perl -MLWP::Simple -e'getprint "http://parseerror.com/p"' |less

      Lots of programmers get tossed into the programming world this way ... if you can put up with the stress, go for it.

      If you want to start programming fulltime for dough, here is your chance.

      Seriously.

      Do your best and try to tap the resources of your company to get as much learning experience as possible out of the project. Never give up. Always be forthcoming about any problem you are getting stuck on (mostly.)

      If and when this job ends, the next employer will most likely be encouraged by the size of your cojones, and your willingness to go out on a limb.

      However - in equal measure with your guts - make sure you put in a really REALLY strong attempt to do an honest-to-God, do-things-the-right-way good job!

      Good luck.
Re: Insubordination or Exploitation?
by Silicon Cactus (Scribe) on Mar 27, 2002 at 13:32 UTC

    I want to thank all of you for your advice and consolation. I have thought about it all night, long and hard. And while my stomach this morning was only slightly on fire, I took that as a good sign. :)

    I have decided to take on the web app project, but with two reservations.

    1. Solid requirements document, just as every other developer here gets.
    2. The ability to dev this on a linux box running apache with mod_perl. A first for this company, so I am praying on this.

    Once again, I thank you all from the bottom of my heart. Many of you have given me advice to leave, and that has given me some courage. Heck, it is quite scary to think of leaving my first job in this industry, but you are right, I should not stay.

    Thank you.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2019-12-08 16:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?