Is this workplace conflict too deep for an intern to get involved in?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
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 :)
management internship
 |Â
show 2 more comments
up vote
2
down vote
favorite
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 :)
management internship
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
 |Â
show 2 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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 :)
management internship
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 :)
management internship
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
 |Â
show 2 more comments
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
 |Â
show 2 more comments
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.
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
suggest improvements |Â
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.
suggest improvements |Â
up vote
2
down vote
Option 4:
- Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.
- 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?"
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
suggest improvements |Â
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.
suggest improvements |Â
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.
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
suggest improvements |Â
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.
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
suggest improvements |Â
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.
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.
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
suggest improvements |Â
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
suggest improvements |Â
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.
suggest improvements |Â
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.
suggest improvements |Â
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.
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.
answered Nov 27 '15 at 18:47
Jim
4,495623
4,495623
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
Option 4:
- Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.
- 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?"
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
suggest improvements |Â
up vote
2
down vote
Option 4:
- Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.
- 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?"
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
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
Option 4:
- Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.
- 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?"
Option 4:
- Write down exactly what the problem with the software is, how it behaves and what you expected it to do instead.
- 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?"
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
suggest improvements |Â
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
suggest improvements |Â
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.
suggest improvements |Â
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.
suggest improvements |Â
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.
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.
answered Nov 27 '15 at 18:02
Beo
41025
41025
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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