Is this workplace conflict too deep for an intern to get involved in?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
2
down vote

favorite
1












Background: Engineering, Europe, Intern



Through personal contacts I got hired into a company as an intern. That initial contact is now my boss. On good terms with all my colleagues.



  • Boss pushes through the purchase of a software package "everybody uses in this industry" for product management (five-figure price). Everybody hates it.


  • With that commitment, if he backed out he'd lose face and somebody suggested he might even be fired by higher management if it turns out all of this was lost money. Nobody knows how he marketed it to higher management.


  • Fellow colleagues are (properly) pissed off. One of them today said that he had lost all confidence in him. Emotions run deep.


I've been tinkering with the idea to reprogram it, since I have too little to do. The developments in the last two points have me concerned that I'd be getting too deep into company politics.



I can see three options:



  • Pretend I don't know the seriousness since I'm new and bring wireframes to his office Monday. Might not lose face but is it enough to push for change? I can play the unknowledgeable intern card without much risk.

  • Join meeting with my colleagues they were having next week with him and throw the idea in. Too much involvement?

  • Drop the idea of involving myself with it. I still have to use the crappy program in question for another two months and will have to sit around bored and unchallenged.


If I'm unclear with anything, please leave a comment before writing extensive answers :)







share|improve this question


















  • 2




    Reprogram? What are we talking about here? Writing modules/libraries for common use cases in the office? I don't know of that many software packages that provide source code and allow rewrites. It might be easier to answer if you just specify the package.
    – Lilienthal♦
    Nov 27 '15 at 17:07






  • 2




    Are you sure you could build a product management application in 2 months?
    – paparazzo
    Nov 27 '15 at 17:10






  • 3




    Are you sure you could build even a minimum viable product in 2 months? Are you an experienced developer? Have you built any multi user applications of similar complexity in two months?
    – paparazzo
    Nov 27 '15 at 17:28






  • 2




    Answering the title question directly: Any political conflict is too deep for an intern.
    – rath
    Nov 27 '15 at 20:39






  • 2




    I agree with @rath there is no way an intern should be getting involved, however I seriously doubt that the software is the problem, more likely the inertia of the people using it in terms of utilising it properly is the problem. This is something I have seen many times.
    – Kilisi
    Nov 27 '15 at 22:38

















up vote
2
down vote

favorite
1












Background: Engineering, Europe, Intern



Through personal contacts I got hired into a company as an intern. That initial contact is now my boss. On good terms with all my colleagues.



  • Boss pushes through the purchase of a software package "everybody uses in this industry" for product management (five-figure price). Everybody hates it.


  • With that commitment, if he backed out he'd lose face and somebody suggested he might even be fired by higher management if it turns out all of this was lost money. Nobody knows how he marketed it to higher management.


  • Fellow colleagues are (properly) pissed off. One of them today said that he had lost all confidence in him. Emotions run deep.


I've been tinkering with the idea to reprogram it, since I have too little to do. The developments in the last two points have me concerned that I'd be getting too deep into company politics.



I can see three options:



  • Pretend I don't know the seriousness since I'm new and bring wireframes to his office Monday. Might not lose face but is it enough to push for change? I can play the unknowledgeable intern card without much risk.

  • Join meeting with my colleagues they were having next week with him and throw the idea in. Too much involvement?

  • Drop the idea of involving myself with it. I still have to use the crappy program in question for another two months and will have to sit around bored and unchallenged.


If I'm unclear with anything, please leave a comment before writing extensive answers :)







share|improve this question


















  • 2




    Reprogram? What are we talking about here? Writing modules/libraries for common use cases in the office? I don't know of that many software packages that provide source code and allow rewrites. It might be easier to answer if you just specify the package.
    – Lilienthal♦
    Nov 27 '15 at 17:07






  • 2




    Are you sure you could build a product management application in 2 months?
    – paparazzo
    Nov 27 '15 at 17:10






  • 3




    Are you sure you could build even a minimum viable product in 2 months? Are you an experienced developer? Have you built any multi user applications of similar complexity in two months?
    – paparazzo
    Nov 27 '15 at 17:28






  • 2




    Answering the title question directly: Any political conflict is too deep for an intern.
    – rath
    Nov 27 '15 at 20:39






  • 2




    I agree with @rath there is no way an intern should be getting involved, however I seriously doubt that the software is the problem, more likely the inertia of the people using it in terms of utilising it properly is the problem. This is something I have seen many times.
    – Kilisi
    Nov 27 '15 at 22:38













up vote
2
down vote

favorite
1









up vote
2
down vote

favorite
1






1





Background: Engineering, Europe, Intern



Through personal contacts I got hired into a company as an intern. That initial contact is now my boss. On good terms with all my colleagues.



  • Boss pushes through the purchase of a software package "everybody uses in this industry" for product management (five-figure price). Everybody hates it.


  • With that commitment, if he backed out he'd lose face and somebody suggested he might even be fired by higher management if it turns out all of this was lost money. Nobody knows how he marketed it to higher management.


  • Fellow colleagues are (properly) pissed off. One of them today said that he had lost all confidence in him. Emotions run deep.


I've been tinkering with the idea to reprogram it, since I have too little to do. The developments in the last two points have me concerned that I'd be getting too deep into company politics.



I can see three options:



  • Pretend I don't know the seriousness since I'm new and bring wireframes to his office Monday. Might not lose face but is it enough to push for change? I can play the unknowledgeable intern card without much risk.

  • Join meeting with my colleagues they were having next week with him and throw the idea in. Too much involvement?

  • Drop the idea of involving myself with it. I still have to use the crappy program in question for another two months and will have to sit around bored and unchallenged.


If I'm unclear with anything, please leave a comment before writing extensive answers :)







share|improve this question














Background: Engineering, Europe, Intern



Through personal contacts I got hired into a company as an intern. That initial contact is now my boss. On good terms with all my colleagues.



  • Boss pushes through the purchase of a software package "everybody uses in this industry" for product management (five-figure price). Everybody hates it.


  • With that commitment, if he backed out he'd lose face and somebody suggested he might even be fired by higher management if it turns out all of this was lost money. Nobody knows how he marketed it to higher management.


  • Fellow colleagues are (properly) pissed off. One of them today said that he had lost all confidence in him. Emotions run deep.


I've been tinkering with the idea to reprogram it, since I have too little to do. The developments in the last two points have me concerned that I'd be getting too deep into company politics.



I can see three options:



  • Pretend I don't know the seriousness since I'm new and bring wireframes to his office Monday. Might not lose face but is it enough to push for change? I can play the unknowledgeable intern card without much risk.

  • Join meeting with my colleagues they were having next week with him and throw the idea in. Too much involvement?

  • Drop the idea of involving myself with it. I still have to use the crappy program in question for another two months and will have to sit around bored and unchallenged.


If I'm unclear with anything, please leave a comment before writing extensive answers :)









share|improve this question













share|improve this question




share|improve this question








edited Nov 27 '15 at 20:18

























asked Nov 27 '15 at 16:56









Antonio

3591312




3591312







  • 2




    Reprogram? What are we talking about here? Writing modules/libraries for common use cases in the office? I don't know of that many software packages that provide source code and allow rewrites. It might be easier to answer if you just specify the package.
    – Lilienthal♦
    Nov 27 '15 at 17:07






  • 2




    Are you sure you could build a product management application in 2 months?
    – paparazzo
    Nov 27 '15 at 17:10






  • 3




    Are you sure you could build even a minimum viable product in 2 months? Are you an experienced developer? Have you built any multi user applications of similar complexity in two months?
    – paparazzo
    Nov 27 '15 at 17:28






  • 2




    Answering the title question directly: Any political conflict is too deep for an intern.
    – rath
    Nov 27 '15 at 20:39






  • 2




    I agree with @rath there is no way an intern should be getting involved, however I seriously doubt that the software is the problem, more likely the inertia of the people using it in terms of utilising it properly is the problem. This is something I have seen many times.
    – Kilisi
    Nov 27 '15 at 22:38













  • 2




    Reprogram? What are we talking about here? Writing modules/libraries for common use cases in the office? I don't know of that many software packages that provide source code and allow rewrites. It might be easier to answer if you just specify the package.
    – Lilienthal♦
    Nov 27 '15 at 17:07






  • 2




    Are you sure you could build a product management application in 2 months?
    – paparazzo
    Nov 27 '15 at 17:10






  • 3




    Are you sure you could build even a minimum viable product in 2 months? Are you an experienced developer? Have you built any multi user applications of similar complexity in two months?
    – paparazzo
    Nov 27 '15 at 17:28






  • 2




    Answering the title question directly: Any political conflict is too deep for an intern.
    – rath
    Nov 27 '15 at 20:39






  • 2




    I agree with @rath there is no way an intern should be getting involved, however I seriously doubt that the software is the problem, more likely the inertia of the people using it in terms of utilising it properly is the problem. This is something I have seen many times.
    – Kilisi
    Nov 27 '15 at 22:38








2




2




Reprogram? What are we talking about here? Writing modules/libraries for common use cases in the office? I don't know of that many software packages that provide source code and allow rewrites. It might be easier to answer if you just specify the package.
– Lilienthal♦
Nov 27 '15 at 17:07




Reprogram? What are we talking about here? Writing modules/libraries for common use cases in the office? I don't know of that many software packages that provide source code and allow rewrites. It might be easier to answer if you just specify the package.
– Lilienthal♦
Nov 27 '15 at 17:07




2




2




Are you sure you could build a product management application in 2 months?
– paparazzo
Nov 27 '15 at 17:10




Are you sure you could build a product management application in 2 months?
– paparazzo
Nov 27 '15 at 17:10




3




3




Are you sure you could build even a minimum viable product in 2 months? Are you an experienced developer? Have you built any multi user applications of similar complexity in two months?
– paparazzo
Nov 27 '15 at 17:28




Are you sure you could build even a minimum viable product in 2 months? Are you an experienced developer? Have you built any multi user applications of similar complexity in two months?
– paparazzo
Nov 27 '15 at 17:28




2




2




Answering the title question directly: Any political conflict is too deep for an intern.
– rath
Nov 27 '15 at 20:39




Answering the title question directly: Any political conflict is too deep for an intern.
– rath
Nov 27 '15 at 20:39




2




2




I agree with @rath there is no way an intern should be getting involved, however I seriously doubt that the software is the problem, more likely the inertia of the people using it in terms of utilising it properly is the problem. This is something I have seen many times.
– Kilisi
Nov 27 '15 at 22:38





I agree with @rath there is no way an intern should be getting involved, however I seriously doubt that the software is the problem, more likely the inertia of the people using it in terms of utilising it properly is the problem. This is something I have seen many times.
– Kilisi
Nov 27 '15 at 22:38











4 Answers
4






active

oldest

votes

















up vote
13
down vote













I'd recommend you go with your 3rd option:




• Drop the idea of involving myself with it. I still have to use the crappy program in question for another two months and will have to sit around bored and unchallenged.




The other two options seem based on the idea that you as an intern can crank out commercial grade software that's better than the current stuff and feature complete in only two months.



Two months is a very short time and your software would not only have to perform the required tasks, it would also have to handle errors correctly, validate user input, be well documented, etc.



Software developers (all of us, not just interns) are notorious for underestimating how long it takes to write software.



If you want to dabble with a toy implementation in your spare time that's one thing, but please recognize that the time it takes to go from "working prototype" to "full implementation" can easily be many times the time required to go from "back of envelope" to "working prototype".



You run a very serious risk of over promising and under delivering. This can be very bad for you.



Don't worry about your boss. That's his job.






share|improve this answer
















  • 4




    Well said. As an intern he has zero political capital, and probably even less of an idea what a serious project entails (not trying to be mean, just the truth). His boss would have bought that software whether he was there or not, and must live with the consequences - that's why he gets paid the big bucks.
    – AndreiROM
    Nov 27 '15 at 18:41











  • Good response. I would add that work in the space will create an extra layer of noise as this situation unfolds - possibly harming the intern's reputation with the company simply through association. Best left alone.
    – gef05
    Nov 28 '15 at 0:42

















up vote
3
down vote













This is a good lesson for an intern. The problem your team faces right now is not about software, it is about management: getting feedback and buy-in from users before forcing new software on them.



If your team does not know how the software package was presented to upper management, then they were left out of the loop on it's purpose, why it replaced whatever was in place before it and why they "must" support it. All of us, at times, have to use software that we hate because it serves a purpose we must respect. Hating new software that you have to use is nothing new.



You are not well-informed enough to "help" the situation. And, your "fellow colleagues are (properly) pissed off" not because the software is bad, but because they weren't included in the decision. If you try to "fix" the problem by fixing the software, you will do exactly what your friend did by not including the team in the fix.



The only "fix" is for the boss to understand his mistake. As a "boss" his management will not fire him for managing a bad situation, even if he created it. However they will fire him for not recognizing his responsibility to manage, communicate and help your team understand how to solve this problem. (He may even be able to negotiate a refund, if the core issue is about money and given the problems you describe.) If your boss thinks of things like this, management will want to keep him, of course. It isn't the first time, or the last time, a decision will turn out to be a bad one; it's how he handles it that matters.



As an intern, unless you are close enough to your boss to help him recognize their role in the problem, you have no real role in this situation. From a social engineering standpoint, any action you take risks looking like an over-zealous, uninformed intern, which can suppress your advancement. Keep quiet and see what you can learn from your more experienced colleagues.






share|improve this answer



























    up vote
    2
    down vote













    Option 4:



    1. Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.

    2. Contact the support of the software company and ask them how to achieve what you want.

    I would be genuinely surprised if the problem is actually the software and you get past step 1. Software is rarely the problem, the associated changes are, like:"Why do I have to write something down I didn't have to write down before?"






    share|improve this answer




















    • No one likes transitions, even if it's to a new email platform. 9/10 times I can get software to work nicely after tinkering for a week and directing questions to support. Knowing my coworkers do not do the same, I simply train them to use the program up to my own proficiency in the aftermath.
      – CKM
      Nov 28 '15 at 18:37










    • Having seen a number of "industry standard" project management packages out there, they all suffer from the enterprise software problem: they look good on paper, they have great sales people, and they absolutely suck.
      – Alan Shutko
      Nov 29 '15 at 0:26

















    up vote
    1
    down vote













    Newly implemented software systems often mean:



    • Employees are getting another added job responsibility.

    • Employees have to invest time / effort in learning the new system.

    • Employees have to contend with bugs and loss of efficiency while the new system is optimized.

    They don't get a raise (or typically any reward) for having to contend with the new system.



    Unless the system somehow makes their lives much better, it is reasonable to believe they are not going to be happy with the new system and may state they hate it.



    If you want to help think about how to make the implementation of the new system go more smoothly. Maybe talk to your boss about writing a easy to follow getting started guide? Maybe set up a spreadsheet for all the complaints about the system so that changes can be made to improve the system and so that management is made aware of any shortcomings or bugs the system may have.






    share|improve this answer




















      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "423"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      noCode: true, onDemand: false,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );








       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f58412%2fis-this-workplace-conflict-too-deep-for-an-intern-to-get-involved-in%23new-answer', 'question_page');

      );

      Post as a guest

























      StackExchange.ready(function ()
      $("#show-editor-button input, #show-editor-button button").click(function ()
      var showEditor = function()
      $("#show-editor-button").hide();
      $("#post-form").removeClass("dno");
      StackExchange.editor.finallyInit();
      ;

      var useFancy = $(this).data('confirm-use-fancy');
      if(useFancy == 'True')
      var popupTitle = $(this).data('confirm-fancy-title');
      var popupBody = $(this).data('confirm-fancy-body');
      var popupAccept = $(this).data('confirm-fancy-accept-button');

      $(this).loadPopup(
      url: '/post/self-answer-popup',
      loaded: function(popup)
      var pTitle = $(popup).find('h2');
      var pBody = $(popup).find('.popup-body');
      var pSubmit = $(popup).find('.popup-submit');

      pTitle.text(popupTitle);
      pBody.html(popupBody);
      pSubmit.val(popupAccept).click(showEditor);

      )
      else
      var confirmText = $(this).data('confirm-text');
      if (confirmText ? confirm(confirmText) : true)
      showEditor();


      );
      );






      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      13
      down vote













      I'd recommend you go with your 3rd option:




      • Drop the idea of involving myself with it. I still have to use the crappy program in question for another two months and will have to sit around bored and unchallenged.




      The other two options seem based on the idea that you as an intern can crank out commercial grade software that's better than the current stuff and feature complete in only two months.



      Two months is a very short time and your software would not only have to perform the required tasks, it would also have to handle errors correctly, validate user input, be well documented, etc.



      Software developers (all of us, not just interns) are notorious for underestimating how long it takes to write software.



      If you want to dabble with a toy implementation in your spare time that's one thing, but please recognize that the time it takes to go from "working prototype" to "full implementation" can easily be many times the time required to go from "back of envelope" to "working prototype".



      You run a very serious risk of over promising and under delivering. This can be very bad for you.



      Don't worry about your boss. That's his job.






      share|improve this answer
















      • 4




        Well said. As an intern he has zero political capital, and probably even less of an idea what a serious project entails (not trying to be mean, just the truth). His boss would have bought that software whether he was there or not, and must live with the consequences - that's why he gets paid the big bucks.
        – AndreiROM
        Nov 27 '15 at 18:41











      • Good response. I would add that work in the space will create an extra layer of noise as this situation unfolds - possibly harming the intern's reputation with the company simply through association. Best left alone.
        – gef05
        Nov 28 '15 at 0:42














      up vote
      13
      down vote













      I'd recommend you go with your 3rd option:




      • Drop the idea of involving myself with it. I still have to use the crappy program in question for another two months and will have to sit around bored and unchallenged.




      The other two options seem based on the idea that you as an intern can crank out commercial grade software that's better than the current stuff and feature complete in only two months.



      Two months is a very short time and your software would not only have to perform the required tasks, it would also have to handle errors correctly, validate user input, be well documented, etc.



      Software developers (all of us, not just interns) are notorious for underestimating how long it takes to write software.



      If you want to dabble with a toy implementation in your spare time that's one thing, but please recognize that the time it takes to go from "working prototype" to "full implementation" can easily be many times the time required to go from "back of envelope" to "working prototype".



      You run a very serious risk of over promising and under delivering. This can be very bad for you.



      Don't worry about your boss. That's his job.






      share|improve this answer
















      • 4




        Well said. As an intern he has zero political capital, and probably even less of an idea what a serious project entails (not trying to be mean, just the truth). His boss would have bought that software whether he was there or not, and must live with the consequences - that's why he gets paid the big bucks.
        – AndreiROM
        Nov 27 '15 at 18:41











      • Good response. I would add that work in the space will create an extra layer of noise as this situation unfolds - possibly harming the intern's reputation with the company simply through association. Best left alone.
        – gef05
        Nov 28 '15 at 0:42












      up vote
      13
      down vote










      up vote
      13
      down vote









      I'd recommend you go with your 3rd option:




      • Drop the idea of involving myself with it. I still have to use the crappy program in question for another two months and will have to sit around bored and unchallenged.




      The other two options seem based on the idea that you as an intern can crank out commercial grade software that's better than the current stuff and feature complete in only two months.



      Two months is a very short time and your software would not only have to perform the required tasks, it would also have to handle errors correctly, validate user input, be well documented, etc.



      Software developers (all of us, not just interns) are notorious for underestimating how long it takes to write software.



      If you want to dabble with a toy implementation in your spare time that's one thing, but please recognize that the time it takes to go from "working prototype" to "full implementation" can easily be many times the time required to go from "back of envelope" to "working prototype".



      You run a very serious risk of over promising and under delivering. This can be very bad for you.



      Don't worry about your boss. That's his job.






      share|improve this answer












      I'd recommend you go with your 3rd option:




      • Drop the idea of involving myself with it. I still have to use the crappy program in question for another two months and will have to sit around bored and unchallenged.




      The other two options seem based on the idea that you as an intern can crank out commercial grade software that's better than the current stuff and feature complete in only two months.



      Two months is a very short time and your software would not only have to perform the required tasks, it would also have to handle errors correctly, validate user input, be well documented, etc.



      Software developers (all of us, not just interns) are notorious for underestimating how long it takes to write software.



      If you want to dabble with a toy implementation in your spare time that's one thing, but please recognize that the time it takes to go from "working prototype" to "full implementation" can easily be many times the time required to go from "back of envelope" to "working prototype".



      You run a very serious risk of over promising and under delivering. This can be very bad for you.



      Don't worry about your boss. That's his job.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Nov 27 '15 at 17:13









      Dan Pichelman

      24.5k116882




      24.5k116882







      • 4




        Well said. As an intern he has zero political capital, and probably even less of an idea what a serious project entails (not trying to be mean, just the truth). His boss would have bought that software whether he was there or not, and must live with the consequences - that's why he gets paid the big bucks.
        – AndreiROM
        Nov 27 '15 at 18:41











      • Good response. I would add that work in the space will create an extra layer of noise as this situation unfolds - possibly harming the intern's reputation with the company simply through association. Best left alone.
        – gef05
        Nov 28 '15 at 0:42












      • 4




        Well said. As an intern he has zero political capital, and probably even less of an idea what a serious project entails (not trying to be mean, just the truth). His boss would have bought that software whether he was there or not, and must live with the consequences - that's why he gets paid the big bucks.
        – AndreiROM
        Nov 27 '15 at 18:41











      • Good response. I would add that work in the space will create an extra layer of noise as this situation unfolds - possibly harming the intern's reputation with the company simply through association. Best left alone.
        – gef05
        Nov 28 '15 at 0:42







      4




      4




      Well said. As an intern he has zero political capital, and probably even less of an idea what a serious project entails (not trying to be mean, just the truth). His boss would have bought that software whether he was there or not, and must live with the consequences - that's why he gets paid the big bucks.
      – AndreiROM
      Nov 27 '15 at 18:41





      Well said. As an intern he has zero political capital, and probably even less of an idea what a serious project entails (not trying to be mean, just the truth). His boss would have bought that software whether he was there or not, and must live with the consequences - that's why he gets paid the big bucks.
      – AndreiROM
      Nov 27 '15 at 18:41













      Good response. I would add that work in the space will create an extra layer of noise as this situation unfolds - possibly harming the intern's reputation with the company simply through association. Best left alone.
      – gef05
      Nov 28 '15 at 0:42




      Good response. I would add that work in the space will create an extra layer of noise as this situation unfolds - possibly harming the intern's reputation with the company simply through association. Best left alone.
      – gef05
      Nov 28 '15 at 0:42












      up vote
      3
      down vote













      This is a good lesson for an intern. The problem your team faces right now is not about software, it is about management: getting feedback and buy-in from users before forcing new software on them.



      If your team does not know how the software package was presented to upper management, then they were left out of the loop on it's purpose, why it replaced whatever was in place before it and why they "must" support it. All of us, at times, have to use software that we hate because it serves a purpose we must respect. Hating new software that you have to use is nothing new.



      You are not well-informed enough to "help" the situation. And, your "fellow colleagues are (properly) pissed off" not because the software is bad, but because they weren't included in the decision. If you try to "fix" the problem by fixing the software, you will do exactly what your friend did by not including the team in the fix.



      The only "fix" is for the boss to understand his mistake. As a "boss" his management will not fire him for managing a bad situation, even if he created it. However they will fire him for not recognizing his responsibility to manage, communicate and help your team understand how to solve this problem. (He may even be able to negotiate a refund, if the core issue is about money and given the problems you describe.) If your boss thinks of things like this, management will want to keep him, of course. It isn't the first time, or the last time, a decision will turn out to be a bad one; it's how he handles it that matters.



      As an intern, unless you are close enough to your boss to help him recognize their role in the problem, you have no real role in this situation. From a social engineering standpoint, any action you take risks looking like an over-zealous, uninformed intern, which can suppress your advancement. Keep quiet and see what you can learn from your more experienced colleagues.






      share|improve this answer
























        up vote
        3
        down vote













        This is a good lesson for an intern. The problem your team faces right now is not about software, it is about management: getting feedback and buy-in from users before forcing new software on them.



        If your team does not know how the software package was presented to upper management, then they were left out of the loop on it's purpose, why it replaced whatever was in place before it and why they "must" support it. All of us, at times, have to use software that we hate because it serves a purpose we must respect. Hating new software that you have to use is nothing new.



        You are not well-informed enough to "help" the situation. And, your "fellow colleagues are (properly) pissed off" not because the software is bad, but because they weren't included in the decision. If you try to "fix" the problem by fixing the software, you will do exactly what your friend did by not including the team in the fix.



        The only "fix" is for the boss to understand his mistake. As a "boss" his management will not fire him for managing a bad situation, even if he created it. However they will fire him for not recognizing his responsibility to manage, communicate and help your team understand how to solve this problem. (He may even be able to negotiate a refund, if the core issue is about money and given the problems you describe.) If your boss thinks of things like this, management will want to keep him, of course. It isn't the first time, or the last time, a decision will turn out to be a bad one; it's how he handles it that matters.



        As an intern, unless you are close enough to your boss to help him recognize their role in the problem, you have no real role in this situation. From a social engineering standpoint, any action you take risks looking like an over-zealous, uninformed intern, which can suppress your advancement. Keep quiet and see what you can learn from your more experienced colleagues.






        share|improve this answer






















          up vote
          3
          down vote










          up vote
          3
          down vote









          This is a good lesson for an intern. The problem your team faces right now is not about software, it is about management: getting feedback and buy-in from users before forcing new software on them.



          If your team does not know how the software package was presented to upper management, then they were left out of the loop on it's purpose, why it replaced whatever was in place before it and why they "must" support it. All of us, at times, have to use software that we hate because it serves a purpose we must respect. Hating new software that you have to use is nothing new.



          You are not well-informed enough to "help" the situation. And, your "fellow colleagues are (properly) pissed off" not because the software is bad, but because they weren't included in the decision. If you try to "fix" the problem by fixing the software, you will do exactly what your friend did by not including the team in the fix.



          The only "fix" is for the boss to understand his mistake. As a "boss" his management will not fire him for managing a bad situation, even if he created it. However they will fire him for not recognizing his responsibility to manage, communicate and help your team understand how to solve this problem. (He may even be able to negotiate a refund, if the core issue is about money and given the problems you describe.) If your boss thinks of things like this, management will want to keep him, of course. It isn't the first time, or the last time, a decision will turn out to be a bad one; it's how he handles it that matters.



          As an intern, unless you are close enough to your boss to help him recognize their role in the problem, you have no real role in this situation. From a social engineering standpoint, any action you take risks looking like an over-zealous, uninformed intern, which can suppress your advancement. Keep quiet and see what you can learn from your more experienced colleagues.






          share|improve this answer












          This is a good lesson for an intern. The problem your team faces right now is not about software, it is about management: getting feedback and buy-in from users before forcing new software on them.



          If your team does not know how the software package was presented to upper management, then they were left out of the loop on it's purpose, why it replaced whatever was in place before it and why they "must" support it. All of us, at times, have to use software that we hate because it serves a purpose we must respect. Hating new software that you have to use is nothing new.



          You are not well-informed enough to "help" the situation. And, your "fellow colleagues are (properly) pissed off" not because the software is bad, but because they weren't included in the decision. If you try to "fix" the problem by fixing the software, you will do exactly what your friend did by not including the team in the fix.



          The only "fix" is for the boss to understand his mistake. As a "boss" his management will not fire him for managing a bad situation, even if he created it. However they will fire him for not recognizing his responsibility to manage, communicate and help your team understand how to solve this problem. (He may even be able to negotiate a refund, if the core issue is about money and given the problems you describe.) If your boss thinks of things like this, management will want to keep him, of course. It isn't the first time, or the last time, a decision will turn out to be a bad one; it's how he handles it that matters.



          As an intern, unless you are close enough to your boss to help him recognize their role in the problem, you have no real role in this situation. From a social engineering standpoint, any action you take risks looking like an over-zealous, uninformed intern, which can suppress your advancement. Keep quiet and see what you can learn from your more experienced colleagues.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 27 '15 at 18:47









          Jim

          4,495623




          4,495623




















              up vote
              2
              down vote













              Option 4:



              1. Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.

              2. Contact the support of the software company and ask them how to achieve what you want.

              I would be genuinely surprised if the problem is actually the software and you get past step 1. Software is rarely the problem, the associated changes are, like:"Why do I have to write something down I didn't have to write down before?"






              share|improve this answer




















              • No one likes transitions, even if it's to a new email platform. 9/10 times I can get software to work nicely after tinkering for a week and directing questions to support. Knowing my coworkers do not do the same, I simply train them to use the program up to my own proficiency in the aftermath.
                – CKM
                Nov 28 '15 at 18:37










              • Having seen a number of "industry standard" project management packages out there, they all suffer from the enterprise software problem: they look good on paper, they have great sales people, and they absolutely suck.
                – Alan Shutko
                Nov 29 '15 at 0:26














              up vote
              2
              down vote













              Option 4:



              1. Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.

              2. Contact the support of the software company and ask them how to achieve what you want.

              I would be genuinely surprised if the problem is actually the software and you get past step 1. Software is rarely the problem, the associated changes are, like:"Why do I have to write something down I didn't have to write down before?"






              share|improve this answer




















              • No one likes transitions, even if it's to a new email platform. 9/10 times I can get software to work nicely after tinkering for a week and directing questions to support. Knowing my coworkers do not do the same, I simply train them to use the program up to my own proficiency in the aftermath.
                – CKM
                Nov 28 '15 at 18:37










              • Having seen a number of "industry standard" project management packages out there, they all suffer from the enterprise software problem: they look good on paper, they have great sales people, and they absolutely suck.
                – Alan Shutko
                Nov 29 '15 at 0:26












              up vote
              2
              down vote










              up vote
              2
              down vote









              Option 4:



              1. Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.

              2. Contact the support of the software company and ask them how to achieve what you want.

              I would be genuinely surprised if the problem is actually the software and you get past step 1. Software is rarely the problem, the associated changes are, like:"Why do I have to write something down I didn't have to write down before?"






              share|improve this answer












              Option 4:



              1. Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.

              2. Contact the support of the software company and ask them how to achieve what you want.

              I would be genuinely surprised if the problem is actually the software and you get past step 1. Software is rarely the problem, the associated changes are, like:"Why do I have to write something down I didn't have to write down before?"







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Nov 27 '15 at 21:58









              John Hammond

              4,3071329




              4,3071329











              • No one likes transitions, even if it's to a new email platform. 9/10 times I can get software to work nicely after tinkering for a week and directing questions to support. Knowing my coworkers do not do the same, I simply train them to use the program up to my own proficiency in the aftermath.
                – CKM
                Nov 28 '15 at 18:37










              • Having seen a number of "industry standard" project management packages out there, they all suffer from the enterprise software problem: they look good on paper, they have great sales people, and they absolutely suck.
                – Alan Shutko
                Nov 29 '15 at 0:26
















              • No one likes transitions, even if it's to a new email platform. 9/10 times I can get software to work nicely after tinkering for a week and directing questions to support. Knowing my coworkers do not do the same, I simply train them to use the program up to my own proficiency in the aftermath.
                – CKM
                Nov 28 '15 at 18:37










              • Having seen a number of "industry standard" project management packages out there, they all suffer from the enterprise software problem: they look good on paper, they have great sales people, and they absolutely suck.
                – Alan Shutko
                Nov 29 '15 at 0:26















              No one likes transitions, even if it's to a new email platform. 9/10 times I can get software to work nicely after tinkering for a week and directing questions to support. Knowing my coworkers do not do the same, I simply train them to use the program up to my own proficiency in the aftermath.
              – CKM
              Nov 28 '15 at 18:37




              No one likes transitions, even if it's to a new email platform. 9/10 times I can get software to work nicely after tinkering for a week and directing questions to support. Knowing my coworkers do not do the same, I simply train them to use the program up to my own proficiency in the aftermath.
              – CKM
              Nov 28 '15 at 18:37












              Having seen a number of "industry standard" project management packages out there, they all suffer from the enterprise software problem: they look good on paper, they have great sales people, and they absolutely suck.
              – Alan Shutko
              Nov 29 '15 at 0:26




              Having seen a number of "industry standard" project management packages out there, they all suffer from the enterprise software problem: they look good on paper, they have great sales people, and they absolutely suck.
              – Alan Shutko
              Nov 29 '15 at 0:26










              up vote
              1
              down vote













              Newly implemented software systems often mean:



              • Employees are getting another added job responsibility.

              • Employees have to invest time / effort in learning the new system.

              • Employees have to contend with bugs and loss of efficiency while the new system is optimized.

              They don't get a raise (or typically any reward) for having to contend with the new system.



              Unless the system somehow makes their lives much better, it is reasonable to believe they are not going to be happy with the new system and may state they hate it.



              If you want to help think about how to make the implementation of the new system go more smoothly. Maybe talk to your boss about writing a easy to follow getting started guide? Maybe set up a spreadsheet for all the complaints about the system so that changes can be made to improve the system and so that management is made aware of any shortcomings or bugs the system may have.






              share|improve this answer
























                up vote
                1
                down vote













                Newly implemented software systems often mean:



                • Employees are getting another added job responsibility.

                • Employees have to invest time / effort in learning the new system.

                • Employees have to contend with bugs and loss of efficiency while the new system is optimized.

                They don't get a raise (or typically any reward) for having to contend with the new system.



                Unless the system somehow makes their lives much better, it is reasonable to believe they are not going to be happy with the new system and may state they hate it.



                If you want to help think about how to make the implementation of the new system go more smoothly. Maybe talk to your boss about writing a easy to follow getting started guide? Maybe set up a spreadsheet for all the complaints about the system so that changes can be made to improve the system and so that management is made aware of any shortcomings or bugs the system may have.






                share|improve this answer






















                  up vote
                  1
                  down vote










                  up vote
                  1
                  down vote









                  Newly implemented software systems often mean:



                  • Employees are getting another added job responsibility.

                  • Employees have to invest time / effort in learning the new system.

                  • Employees have to contend with bugs and loss of efficiency while the new system is optimized.

                  They don't get a raise (or typically any reward) for having to contend with the new system.



                  Unless the system somehow makes their lives much better, it is reasonable to believe they are not going to be happy with the new system and may state they hate it.



                  If you want to help think about how to make the implementation of the new system go more smoothly. Maybe talk to your boss about writing a easy to follow getting started guide? Maybe set up a spreadsheet for all the complaints about the system so that changes can be made to improve the system and so that management is made aware of any shortcomings or bugs the system may have.






                  share|improve this answer












                  Newly implemented software systems often mean:



                  • Employees are getting another added job responsibility.

                  • Employees have to invest time / effort in learning the new system.

                  • Employees have to contend with bugs and loss of efficiency while the new system is optimized.

                  They don't get a raise (or typically any reward) for having to contend with the new system.



                  Unless the system somehow makes their lives much better, it is reasonable to believe they are not going to be happy with the new system and may state they hate it.



                  If you want to help think about how to make the implementation of the new system go more smoothly. Maybe talk to your boss about writing a easy to follow getting started guide? Maybe set up a spreadsheet for all the complaints about the system so that changes can be made to improve the system and so that management is made aware of any shortcomings or bugs the system may have.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 27 '15 at 18:02









                  Beo

                  41025




                  41025






















                       

                      draft saved


                      draft discarded


























                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f58412%2fis-this-workplace-conflict-too-deep-for-an-intern-to-get-involved-in%23new-answer', 'question_page');

                      );

                      Post as a guest

















































































                      Comments

                      Popular posts from this blog

                      Long meetings (6-7 hours a day): Being “babysat” by supervisor

                      Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

                      Confectionery