Mixing
Difficult relationship with Opinionated Senior Colleagues [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
Note: This situation originates from a student team, rather than a workplace, but I think it is quite fair to be regarded in similar fashion to a workplace/company environment. We treat our work seriously, our products with pride and we have targets/aim to reach. Only exception is that work is voluntary.
I am working with a group of electrical engineering students as part of a university student team (I'm in aerospace engineering myself). The senior members (including team leader) are very experienced and knowledgable. I have no doubt about that and appreciate their input and assistance.
There are a few points where they drive me nuts however:
They are incredibly opinionated. It's very much a strong black or white opinion if a technology is good or bad: "This software package is good, that software package is awful". They refute anything they don't like. Example: They hate the Arduino boards for whatever reasons. I really don't care if I use an Arduino to verify some sensor is working. I need to verify that it works, and I could not care less if it is 'slow' or 'unpuritan' or what not else if it's going to get the job done quickly and easily.
I have the feeling that they don't differentiate between bad solution and untested solution. For instance, they complain there are issues and downsides with reflow soldering, but in reality I think that they just haven't tried it enough to know. I think they are grossly overstating the downsides in the context of our work compared to manual soldering.
I'm feel I'm too inexperienced to want to put my foot down hard, since I'm certainly not always right being junior and outside the field. As reference, when plenty of good and proper videos on the internet what we are trying to do, there must be some sense in it. I am convinced countless hours go to waste since we just 'reject' possibly better and more efficient solutions.
On the occasions I have been able to push for change, it has worked well, and people appreciate it. But a new situation is a new battle. As a result of this (in my eyes) their credibility suffers. I cannot trust them to actually give me a unbiased and decent interpretation of a situation. I'd like to do stuff without getting hindered by their opinionated gibberish.
colleagues conflict-resolution
asked Jun 28 '15 at 13:33
Antonio
3591312
marked as duplicate by gnat, Joe Strazzere, Michael Grubey, Jenny D, scaaahu Jun 29 '15 at 4:49
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
suggest improvements |Â
up vote
0
down vote
favorite
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
Note: This situation originates from a student team, rather than a workplace, but I think it is quite fair to be regarded in similar fashion to a workplace/company environment. We treat our work seriously, our products with pride and we have targets/aim to reach. Only exception is that work is voluntary.
I am working with a group of electrical engineering students as part of a university student team (I'm in aerospace engineering myself). The senior members (including team leader) are very experienced and knowledgable. I have no doubt about that and appreciate their input and assistance.
There are a few points where they drive me nuts however:
They are incredibly opinionated. It's very much a strong black or white opinion if a technology is good or bad: "This software package is good, that software package is awful". They refute anything they don't like. Example: They hate the Arduino boards for whatever reasons. I really don't care if I use an Arduino to verify some sensor is working. I need to verify that it works, and I could not care less if it is 'slow' or 'unpuritan' or what not else if it's going to get the job done quickly and easily.
I have the feeling that they don't differentiate between bad solution and untested solution. For instance, they complain there are issues and downsides with reflow soldering, but in reality I think that they just haven't tried it enough to know. I think they are grossly overstating the downsides in the context of our work compared to manual soldering.
I'm feel I'm too inexperienced to want to put my foot down hard, since I'm certainly not always right being junior and outside the field. As reference, when plenty of good and proper videos on the internet what we are trying to do, there must be some sense in it. I am convinced countless hours go to waste since we just 'reject' possibly better and more efficient solutions.
On the occasions I have been able to push for change, it has worked well, and people appreciate it. But a new situation is a new battle. As a result of this (in my eyes) their credibility suffers. I cannot trust them to actually give me a unbiased and decent interpretation of a situation. I'd like to do stuff without getting hindered by their opinionated gibberish.
colleagues conflict-resolution
asked Jun 28 '15 at 13:33
Antonio
3591312
marked as duplicate by gnat, Joe Strazzere, Michael Grubey, Jenny D, scaaahu Jun 29 '15 at 4:49
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
@JoeStrazzere I specifically joined this team because electronics interest me and is an area that I have little engagement with otherwise. I'd really like to see if I could resolve it without going that far, but of course it remains an option. As the product remains a common goal between the (sub)teams, I also think quality/process suffers a bit for everybody as it stands and would like to push us forward to improve as I think I could.
– Antonio
Jun 28 '15 at 13:54
@JoeStrazzere I will admit that is not something I have done, I brushed it off as perhaps something unsuitable to do with them. Done correctly it may have potential now when I think about it again, especially with the suggestion in rath's answer to be more credibility/solution orientated.
– Antonio
Jun 28 '15 at 15:39
3
A tactic that has worked really well for me is to ask questions instead of arguing. "Oh, Arduino is terrible? What so awful about it? Oh, the API has no code partitioning and no abstraction? That is a big drawback. Does it really matter for this little thing we're doing here though? It seems like we have enough experience to hack around that and save ourselves some time." If someone is convinced they're 100% correct, you'll get nowhere by telling them they're wrong. Understand why they're so sure first, then edge-case them until they shift their view enough to be open to what you're saying.
– ColleenV
Jun 29 '15 at 1:12
suggest improvements |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
Note: This situation originates from a student team, rather than a workplace, but I think it is quite fair to be regarded in similar fashion to a workplace/company environment. We treat our work seriously, our products with pride and we have targets/aim to reach. Only exception is that work is voluntary.
I am working with a group of electrical engineering students as part of a university student team (I'm in aerospace engineering myself). The senior members (including team leader) are very experienced and knowledgable. I have no doubt about that and appreciate their input and assistance.
There are a few points where they drive me nuts however:
They are incredibly opinionated. It's very much a strong black or white opinion if a technology is good or bad: "This software package is good, that software package is awful". They refute anything they don't like. Example: They hate the Arduino boards for whatever reasons. I really don't care if I use an Arduino to verify some sensor is working. I need to verify that it works, and I could not care less if it is 'slow' or 'unpuritan' or what not else if it's going to get the job done quickly and easily.
I have the feeling that they don't differentiate between bad solution and untested solution. For instance, they complain there are issues and downsides with reflow soldering, but in reality I think that they just haven't tried it enough to know. I think they are grossly overstating the downsides in the context of our work compared to manual soldering.
I'm feel I'm too inexperienced to want to put my foot down hard, since I'm certainly not always right being junior and outside the field. As reference, when plenty of good and proper videos on the internet what we are trying to do, there must be some sense in it. I am convinced countless hours go to waste since we just 'reject' possibly better and more efficient solutions.
On the occasions I have been able to push for change, it has worked well, and people appreciate it. But a new situation is a new battle. As a result of this (in my eyes) their credibility suffers. I cannot trust them to actually give me a unbiased and decent interpretation of a situation. I'd like to do stuff without getting hindered by their opinionated gibberish.
colleagues conflict-resolution
asked Jun 28 '15 at 13:33
Antonio
3591312
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
Note: This situation originates from a student team, rather than a workplace, but I think it is quite fair to be regarded in similar fashion to a workplace/company environment. We treat our work seriously, our products with pride and we have targets/aim to reach. Only exception is that work is voluntary.
I am working with a group of electrical engineering students as part of a university student team (I'm in aerospace engineering myself). The senior members (including team leader) are very experienced and knowledgable. I have no doubt about that and appreciate their input and assistance.
There are a few points where they drive me nuts however:
They are incredibly opinionated. It's very much a strong black or white opinion if a technology is good or bad: "This software package is good, that software package is awful". They refute anything they don't like. Example: They hate the Arduino boards for whatever reasons. I really don't care if I use an Arduino to verify some sensor is working. I need to verify that it works, and I could not care less if it is 'slow' or 'unpuritan' or what not else if it's going to get the job done quickly and easily.
I have the feeling that they don't differentiate between bad solution and untested solution. For instance, they complain there are issues and downsides with reflow soldering, but in reality I think that they just haven't tried it enough to know. I think they are grossly overstating the downsides in the context of our work compared to manual soldering.
I'm feel I'm too inexperienced to want to put my foot down hard, since I'm certainly not always right being junior and outside the field. As reference, when plenty of good and proper videos on the internet what we are trying to do, there must be some sense in it. I am convinced countless hours go to waste since we just 'reject' possibly better and more efficient solutions.
On the occasions I have been able to push for change, it has worked well, and people appreciate it. But a new situation is a new battle. As a result of this (in my eyes) their credibility suffers. I cannot trust them to actually give me a unbiased and decent interpretation of a situation. I'd like to do stuff without getting hindered by their opinionated gibberish.
This question already has an answer here:
How can I get co-workers to buy into some of my ideas? [duplicate]
4 answers
colleagues conflict-resolution
asked Jun 28 '15 at 13:33
Antonio
3591312
edited Jun 28 '15 at 13:41
asked Jun 28 '15 at 13:33
Antonio
3591312
asked Jun 28 '15 at 13:33
Antonio
3591312
asked Jun 28 '15 at 13:33
Antonio
3591312
3591312
marked as duplicate by gnat, Joe Strazzere, Michael Grubey, Jenny D, scaaahu Jun 29 '15 at 4:49
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by gnat, Joe Strazzere, Michael Grubey, Jenny D, scaaahu Jun 29 '15 at 4:49
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
@JoeStrazzere I specifically joined this team because electronics interest me and is an area that I have little engagement with otherwise. I'd really like to see if I could resolve it without going that far, but of course it remains an option. As the product remains a common goal between the (sub)teams, I also think quality/process suffers a bit for everybody as it stands and would like to push us forward to improve as I think I could.
– Antonio
Jun 28 '15 at 13:54
@JoeStrazzere I will admit that is not something I have done, I brushed it off as perhaps something unsuitable to do with them. Done correctly it may have potential now when I think about it again, especially with the suggestion in rath's answer to be more credibility/solution orientated.
– Antonio
Jun 28 '15 at 15:39
3
A tactic that has worked really well for me is to ask questions instead of arguing. "Oh, Arduino is terrible? What so awful about it? Oh, the API has no code partitioning and no abstraction? That is a big drawback. Does it really matter for this little thing we're doing here though? It seems like we have enough experience to hack around that and save ourselves some time." If someone is convinced they're 100% correct, you'll get nowhere by telling them they're wrong. Understand why they're so sure first, then edge-case them until they shift their view enough to be open to what you're saying.
– ColleenV
Jun 29 '15 at 1:12
suggest improvements |Â
@JoeStrazzere I specifically joined this team because electronics interest me and is an area that I have little engagement with otherwise. I'd really like to see if I could resolve it without going that far, but of course it remains an option. As the product remains a common goal between the (sub)teams, I also think quality/process suffers a bit for everybody as it stands and would like to push us forward to improve as I think I could.
– Antonio
Jun 28 '15 at 13:54
@JoeStrazzere I will admit that is not something I have done, I brushed it off as perhaps something unsuitable to do with them. Done correctly it may have potential now when I think about it again, especially with the suggestion in rath's answer to be more credibility/solution orientated.
– Antonio
Jun 28 '15 at 15:39
3
A tactic that has worked really well for me is to ask questions instead of arguing. "Oh, Arduino is terrible? What so awful about it? Oh, the API has no code partitioning and no abstraction? That is a big drawback. Does it really matter for this little thing we're doing here though? It seems like we have enough experience to hack around that and save ourselves some time." If someone is convinced they're 100% correct, you'll get nowhere by telling them they're wrong. Understand why they're so sure first, then edge-case them until they shift their view enough to be open to what you're saying.
– ColleenV
Jun 29 '15 at 1:12
@JoeStrazzere I specifically joined this team because electronics interest me and is an area that I have little engagement with otherwise. I'd really like to see if I could resolve it without going that far, but of course it remains an option. As the product remains a common goal between the (sub)teams, I also think quality/process suffers a bit for everybody as it stands and would like to push us forward to improve as I think I could.
– Antonio
Jun 28 '15 at 13:54
@JoeStrazzere I specifically joined this team because electronics interest me and is an area that I have little engagement with otherwise. I'd really like to see if I could resolve it without going that far, but of course it remains an option. As the product remains a common goal between the (sub)teams, I also think quality/process suffers a bit for everybody as it stands and would like to push us forward to improve as I think I could.
– Antonio
Jun 28 '15 at 13:54
@JoeStrazzere I will admit that is not something I have done, I brushed it off as perhaps something unsuitable to do with them. Done correctly it may have potential now when I think about it again, especially with the suggestion in rath's answer to be more credibility/solution orientated.
– Antonio
Jun 28 '15 at 15:39
@JoeStrazzere I will admit that is not something I have done, I brushed it off as perhaps something unsuitable to do with them. Done correctly it may have potential now when I think about it again, especially with the suggestion in rath's answer to be more credibility/solution orientated.
– Antonio
Jun 28 '15 at 15:39
3
3
A tactic that has worked really well for me is to ask questions instead of arguing. "Oh, Arduino is terrible? What so awful about it? Oh, the API has no code partitioning and no abstraction? That is a big drawback. Does it really matter for this little thing we're doing here though? It seems like we have enough experience to hack around that and save ourselves some time." If someone is convinced they're 100% correct, you'll get nowhere by telling them they're wrong. Understand why they're so sure first, then edge-case them until they shift their view enough to be open to what you're saying.
– ColleenV
Jun 29 '15 at 1:12
A tactic that has worked really well for me is to ask questions instead of arguing. "Oh, Arduino is terrible? What so awful about it? Oh, the API has no code partitioning and no abstraction? That is a big drawback. Does it really matter for this little thing we're doing here though? It seems like we have enough experience to hack around that and save ourselves some time." If someone is convinced they're 100% correct, you'll get nowhere by telling them they're wrong. Understand why they're so sure first, then edge-case them until they shift their view enough to be open to what you're saying.
– ColleenV
Jun 29 '15 at 1:12
suggest improvements |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
I'm not an engineer but I rather appreciate the untested = bad mindset from the people who would potentially design one of the many devices that could kill me if they malfunction.
I see that there is one complaint missing from your question, so I'll ask it here: is work being done on time? If not, you have a legitimate grievance. But if that were the case I suspect that it wouldn't be missing from your description of the situation, so I'll assume that you don't miss any deadlines because of that.
Conflict is Good
With that in mind, here is my answer: Change nothing. Embrace the debate, learn to stand up and fight for what you think is the best overall solution. Your ideas got accepted because you convienced the team that they would. This is part of your training, you should treat it as such.
If you don't set a meeting agenda before hand, start with that. Then you can do your research on each topic that you want to propose a solution on and prepare for it as if you were preparing for a debate. Yes it's a lot of work, but did anyone say engineering was easy? If anything you might change your mind in the process. Now when you fail to get your own way you'll know it's because your idea or your defense of it wasn't good enough, and fix it next time around.
...but sometimes unnecessary
On the other hand I accept that sometimes you just have to make a mock of the gizmo and not the gizmo itself. Then you must convience your opposition of the importance of scoping It's a proof-of-concept and (if applicable) doing it the "bad" way gives us time to do awesome thing. If testing a sensor can be done realiably with a solderable breadboard, you don't have to make a dedicated PCB for the thing (scope creep). If Arduino is easy and available and the "pure" solution costly and time-consuming, there's no need to go pure. I understand engineering to be the art of compromise, if nothing else. Complexity breeds complications, and the KISS principle should be observed at all times. These are your arguments.
A related question deals with this situation when arguments happen just for the sake of arguing (which doesn't sound like your thing but I'll leave it here just in case): How to handle a coworker who likes arguing to cause conflict.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 28 '15 at 14:24
rath
12.1k74368
Work is being done on time, although sometimes with questionable quality as a result of the complicated and tedious process involved. Your point of creating credibility is most certainly very valid and I like your suggestion doing it in a more formal/structured way which is currently not the case. Thank you for the link, I think I might be listening and taking in too much out of respect/care for them but should really be more solution driven/orientated myself.
– Antonio
Jun 28 '15 at 15:25
suggest improvements |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
I'm not an engineer but I rather appreciate the untested = bad mindset from the people who would potentially design one of the many devices that could kill me if they malfunction.
I see that there is one complaint missing from your question, so I'll ask it here: is work being done on time? If not, you have a legitimate grievance. But if that were the case I suspect that it wouldn't be missing from your description of the situation, so I'll assume that you don't miss any deadlines because of that.
Conflict is Good
With that in mind, here is my answer: Change nothing. Embrace the debate, learn to stand up and fight for what you think is the best overall solution. Your ideas got accepted because you convienced the team that they would. This is part of your training, you should treat it as such.
If you don't set a meeting agenda before hand, start with that. Then you can do your research on each topic that you want to propose a solution on and prepare for it as if you were preparing for a debate. Yes it's a lot of work, but did anyone say engineering was easy? If anything you might change your mind in the process. Now when you fail to get your own way you'll know it's because your idea or your defense of it wasn't good enough, and fix it next time around.
...but sometimes unnecessary
On the other hand I accept that sometimes you just have to make a mock of the gizmo and not the gizmo itself. Then you must convience your opposition of the importance of scoping It's a proof-of-concept and (if applicable) doing it the "bad" way gives us time to do awesome thing. If testing a sensor can be done realiably with a solderable breadboard, you don't have to make a dedicated PCB for the thing (scope creep). If Arduino is easy and available and the "pure" solution costly and time-consuming, there's no need to go pure. I understand engineering to be the art of compromise, if nothing else. Complexity breeds complications, and the KISS principle should be observed at all times. These are your arguments.
A related question deals with this situation when arguments happen just for the sake of arguing (which doesn't sound like your thing but I'll leave it here just in case): How to handle a coworker who likes arguing to cause conflict.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 28 '15 at 14:24
rath
12.1k74368
Work is being done on time, although sometimes with questionable quality as a result of the complicated and tedious process involved. Your point of creating credibility is most certainly very valid and I like your suggestion doing it in a more formal/structured way which is currently not the case. Thank you for the link, I think I might be listening and taking in too much out of respect/care for them but should really be more solution driven/orientated myself.
– Antonio
Jun 28 '15 at 15:25
suggest improvements |Â
up vote
1
down vote
accepted
I'm not an engineer but I rather appreciate the untested = bad mindset from the people who would potentially design one of the many devices that could kill me if they malfunction.
I see that there is one complaint missing from your question, so I'll ask it here: is work being done on time? If not, you have a legitimate grievance. But if that were the case I suspect that it wouldn't be missing from your description of the situation, so I'll assume that you don't miss any deadlines because of that.
Conflict is Good
With that in mind, here is my answer: Change nothing. Embrace the debate, learn to stand up and fight for what you think is the best overall solution. Your ideas got accepted because you convienced the team that they would. This is part of your training, you should treat it as such.
If you don't set a meeting agenda before hand, start with that. Then you can do your research on each topic that you want to propose a solution on and prepare for it as if you were preparing for a debate. Yes it's a lot of work, but did anyone say engineering was easy? If anything you might change your mind in the process. Now when you fail to get your own way you'll know it's because your idea or your defense of it wasn't good enough, and fix it next time around.
...but sometimes unnecessary
On the other hand I accept that sometimes you just have to make a mock of the gizmo and not the gizmo itself. Then you must convience your opposition of the importance of scoping It's a proof-of-concept and (if applicable) doing it the "bad" way gives us time to do awesome thing. If testing a sensor can be done realiably with a solderable breadboard, you don't have to make a dedicated PCB for the thing (scope creep). If Arduino is easy and available and the "pure" solution costly and time-consuming, there's no need to go pure. I understand engineering to be the art of compromise, if nothing else. Complexity breeds complications, and the KISS principle should be observed at all times. These are your arguments.
A related question deals with this situation when arguments happen just for the sake of arguing (which doesn't sound like your thing but I'll leave it here just in case): How to handle a coworker who likes arguing to cause conflict.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 28 '15 at 14:24
rath
12.1k74368
Work is being done on time, although sometimes with questionable quality as a result of the complicated and tedious process involved. Your point of creating credibility is most certainly very valid and I like your suggestion doing it in a more formal/structured way which is currently not the case. Thank you for the link, I think I might be listening and taking in too much out of respect/care for them but should really be more solution driven/orientated myself.
– Antonio
Jun 28 '15 at 15:25
suggest improvements |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
I'm not an engineer but I rather appreciate the untested = bad mindset from the people who would potentially design one of the many devices that could kill me if they malfunction.
I see that there is one complaint missing from your question, so I'll ask it here: is work being done on time? If not, you have a legitimate grievance. But if that were the case I suspect that it wouldn't be missing from your description of the situation, so I'll assume that you don't miss any deadlines because of that.
Conflict is Good
With that in mind, here is my answer: Change nothing. Embrace the debate, learn to stand up and fight for what you think is the best overall solution. Your ideas got accepted because you convienced the team that they would. This is part of your training, you should treat it as such.
If you don't set a meeting agenda before hand, start with that. Then you can do your research on each topic that you want to propose a solution on and prepare for it as if you were preparing for a debate. Yes it's a lot of work, but did anyone say engineering was easy? If anything you might change your mind in the process. Now when you fail to get your own way you'll know it's because your idea or your defense of it wasn't good enough, and fix it next time around.
...but sometimes unnecessary
On the other hand I accept that sometimes you just have to make a mock of the gizmo and not the gizmo itself. Then you must convience your opposition of the importance of scoping It's a proof-of-concept and (if applicable) doing it the "bad" way gives us time to do awesome thing. If testing a sensor can be done realiably with a solderable breadboard, you don't have to make a dedicated PCB for the thing (scope creep). If Arduino is easy and available and the "pure" solution costly and time-consuming, there's no need to go pure. I understand engineering to be the art of compromise, if nothing else. Complexity breeds complications, and the KISS principle should be observed at all times. These are your arguments.
A related question deals with this situation when arguments happen just for the sake of arguing (which doesn't sound like your thing but I'll leave it here just in case): How to handle a coworker who likes arguing to cause conflict.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 28 '15 at 14:24
rath
12.1k74368
I'm not an engineer but I rather appreciate the untested = bad mindset from the people who would potentially design one of the many devices that could kill me if they malfunction.
I see that there is one complaint missing from your question, so I'll ask it here: is work being done on time? If not, you have a legitimate grievance. But if that were the case I suspect that it wouldn't be missing from your description of the situation, so I'll assume that you don't miss any deadlines because of that.
Conflict is Good
With that in mind, here is my answer: Change nothing. Embrace the debate, learn to stand up and fight for what you think is the best overall solution. Your ideas got accepted because you convienced the team that they would. This is part of your training, you should treat it as such.
If you don't set a meeting agenda before hand, start with that. Then you can do your research on each topic that you want to propose a solution on and prepare for it as if you were preparing for a debate. Yes it's a lot of work, but did anyone say engineering was easy? If anything you might change your mind in the process. Now when you fail to get your own way you'll know it's because your idea or your defense of it wasn't good enough, and fix it next time around.
...but sometimes unnecessary
On the other hand I accept that sometimes you just have to make a mock of the gizmo and not the gizmo itself. Then you must convience your opposition of the importance of scoping It's a proof-of-concept and (if applicable) doing it the "bad" way gives us time to do awesome thing. If testing a sensor can be done realiably with a solderable breadboard, you don't have to make a dedicated PCB for the thing (scope creep). If Arduino is easy and available and the "pure" solution costly and time-consuming, there's no need to go pure. I understand engineering to be the art of compromise, if nothing else. Complexity breeds complications, and the KISS principle should be observed at all times. These are your arguments.
A related question deals with this situation when arguments happen just for the sake of arguing (which doesn't sound like your thing but I'll leave it here just in case): How to handle a coworker who likes arguing to cause conflict.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 28 '15 at 14:24
rath
12.1k74368
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
1
answered Jun 28 '15 at 14:24
rath
12.1k74368
answered Jun 28 '15 at 14:24
rath
12.1k74368
answered Jun 28 '15 at 14:24
rath
12.1k74368
12.1k74368
Work is being done on time, although sometimes with questionable quality as a result of the complicated and tedious process involved. Your point of creating credibility is most certainly very valid and I like your suggestion doing it in a more formal/structured way which is currently not the case. Thank you for the link, I think I might be listening and taking in too much out of respect/care for them but should really be more solution driven/orientated myself.
– Antonio
Jun 28 '15 at 15:25
suggest improvements |Â
Work is being done on time, although sometimes with questionable quality as a result of the complicated and tedious process involved. Your point of creating credibility is most certainly very valid and I like your suggestion doing it in a more formal/structured way which is currently not the case. Thank you for the link, I think I might be listening and taking in too much out of respect/care for them but should really be more solution driven/orientated myself.
– Antonio
Jun 28 '15 at 15:25
Work is being done on time, although sometimes with questionable quality as a result of the complicated and tedious process involved. Your point of creating credibility is most certainly very valid and I like your suggestion doing it in a more formal/structured way which is currently not the case. Thank you for the link, I think I might be listening and taking in too much out of respect/care for them but should really be more solution driven/orientated myself.
– Antonio
Jun 28 '15 at 15:25
Work is being done on time, although sometimes with questionable quality as a result of the complicated and tedious process involved. Your point of creating credibility is most certainly very valid and I like your suggestion doing it in a more formal/structured way which is currently not the case. Thank you for the link, I think I might be listening and taking in too much out of respect/care for them but should really be more solution driven/orientated myself.
– Antonio
Jun 28 '15 at 15:25
suggest improvements |Â
@JoeStrazzere I specifically joined this team because electronics interest me and is an area that I have little engagement with otherwise. I'd really like to see if I could resolve it without going that far, but of course it remains an option. As the product remains a common goal between the (sub)teams, I also think quality/process suffers a bit for everybody as it stands and would like to push us forward to improve as I think I could.
– Antonio
Jun 28 '15 at 13:54
@JoeStrazzere I will admit that is not something I have done, I brushed it off as perhaps something unsuitable to do with them. Done correctly it may have potential now when I think about it again, especially with the suggestion in rath's answer to be more credibility/solution orientated.
– Antonio
Jun 28 '15 at 15:39
3
A tactic that has worked really well for me is to ask questions instead of arguing. "Oh, Arduino is terrible? What so awful about it? Oh, the API has no code partitioning and no abstraction? That is a big drawback. Does it really matter for this little thing we're doing here though? It seems like we have enough experience to hack around that and save ourselves some time." If someone is convinced they're 100% correct, you'll get nowhere by telling them they're wrong. Understand why they're so sure first, then edge-case them until they shift their view enough to be open to what you're saying.
– ColleenV
Jun 29 '15 at 1:12