Mixing
How can I get colleagues to makes decisions based off research as opposed to whim?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
I'm a software developer and the codebase I work with is horrible. It is the result of no documentation and a high turn around of developers. The one constant is one of the leads, who seems to like making whimsical decisions without thinking about the long term effect on maintainability. The entire structure of the codebase and how files are organised is the result of subjective whim, and in my view is one of the reasons for the codebase being so terrible.
We have got to the point where we are looking at rebuilding the codebase (or at least small parts of it). Much to my dismay I hear this same lead sharing her same old ideas that in my opinion led to the demise of the codebase, when I know from my research that more established patterns and guides already exist that would be more maintainable and scalable.
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects? At the end of the day, our business requirements are no so unique that they require us to pioneer new conventions.
Some of the decisions have no obvious alternatives as they are unestablished concepts, for example he will decide we should have a "header-footer" folder in our UI component library (which would contain just the header and footer components) and will have some contrived reason for doing so, when really there is no established convention anywhere dictating we should do this, which would at least give me more context and confidence. For this particular example, my suggestion would be to not have a specific "header-footer" folder, and allow the header and footer components to sit along side the other components, but I digress.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?
software-industry conflict
asked yesterday
ESR
12616
New contributor
ESR is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
4
down vote
favorite
I'm a software developer and the codebase I work with is horrible. It is the result of no documentation and a high turn around of developers. The one constant is one of the leads, who seems to like making whimsical decisions without thinking about the long term effect on maintainability. The entire structure of the codebase and how files are organised is the result of subjective whim, and in my view is one of the reasons for the codebase being so terrible.
We have got to the point where we are looking at rebuilding the codebase (or at least small parts of it). Much to my dismay I hear this same lead sharing her same old ideas that in my opinion led to the demise of the codebase, when I know from my research that more established patterns and guides already exist that would be more maintainable and scalable.
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects? At the end of the day, our business requirements are no so unique that they require us to pioneer new conventions.
Some of the decisions have no obvious alternatives as they are unestablished concepts, for example he will decide we should have a "header-footer" folder in our UI component library (which would contain just the header and footer components) and will have some contrived reason for doing so, when really there is no established convention anywhere dictating we should do this, which would at least give me more context and confidence. For this particular example, my suggestion would be to not have a specific "header-footer" folder, and allow the header and footer components to sit along side the other components, but I digress.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?
software-industry conflict
asked yesterday
ESR
12616
New contributor
ESR is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
19 hours ago
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I'm a software developer and the codebase I work with is horrible. It is the result of no documentation and a high turn around of developers. The one constant is one of the leads, who seems to like making whimsical decisions without thinking about the long term effect on maintainability. The entire structure of the codebase and how files are organised is the result of subjective whim, and in my view is one of the reasons for the codebase being so terrible.
We have got to the point where we are looking at rebuilding the codebase (or at least small parts of it). Much to my dismay I hear this same lead sharing her same old ideas that in my opinion led to the demise of the codebase, when I know from my research that more established patterns and guides already exist that would be more maintainable and scalable.
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects? At the end of the day, our business requirements are no so unique that they require us to pioneer new conventions.
Some of the decisions have no obvious alternatives as they are unestablished concepts, for example he will decide we should have a "header-footer" folder in our UI component library (which would contain just the header and footer components) and will have some contrived reason for doing so, when really there is no established convention anywhere dictating we should do this, which would at least give me more context and confidence. For this particular example, my suggestion would be to not have a specific "header-footer" folder, and allow the header and footer components to sit along side the other components, but I digress.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?
software-industry conflict
asked yesterday
ESR
12616
New contributor
ESR is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I'm a software developer and the codebase I work with is horrible. It is the result of no documentation and a high turn around of developers. The one constant is one of the leads, who seems to like making whimsical decisions without thinking about the long term effect on maintainability. The entire structure of the codebase and how files are organised is the result of subjective whim, and in my view is one of the reasons for the codebase being so terrible.
We have got to the point where we are looking at rebuilding the codebase (or at least small parts of it). Much to my dismay I hear this same lead sharing her same old ideas that in my opinion led to the demise of the codebase, when I know from my research that more established patterns and guides already exist that would be more maintainable and scalable.
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects? At the end of the day, our business requirements are no so unique that they require us to pioneer new conventions.
Some of the decisions have no obvious alternatives as they are unestablished concepts, for example he will decide we should have a "header-footer" folder in our UI component library (which would contain just the header and footer components) and will have some contrived reason for doing so, when really there is no established convention anywhere dictating we should do this, which would at least give me more context and confidence. For this particular example, my suggestion would be to not have a specific "header-footer" folder, and allow the header and footer components to sit along side the other components, but I digress.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?
software-industry conflict
software-industry conflict
asked yesterday
ESR
12616
New contributor
ESR is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
ESR
12616
New contributor
ESR is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
asked yesterday
ESR
12616
New contributor
ESR is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
ESR
12616
asked yesterday
ESR
12616
12616
New contributor
ESR is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
ESR is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
ESR is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
19 hours ago
add a comment |Â
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
19 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
19 hours ago
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
19 hours ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
8
down vote
accepted
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects?
If you don't have any evidence and concrete data to support your ideas then he will think you are making a whimsical suggestion.
You (or your team or your lead) must decide how to organize source code (for example). It's not yes/no but A/B. Which one is better? Sometimes - honestly - it does not matter (think about all those holy wars about code formatting). When it matters then you have to make an informed decision but IT IS a decision: should you organize code/files in a highly hierarchical structure? For each decision (small or big) you have to ask yourself: why yes? why not? which are the pros and cons of each one?
If you can't say WHY his decision is bad (which are the cons?!) then you're just rejecting a gut decision with another gut decision. Don't fight a holy war, discuss about it but don't waste energy or time on this; if code base is such bad then I'm sure there are better topics to fight for. On the other hand you may have evidence (what went wrong because of this in the past?), in this case present it and be ready to discuss alternatives (but, again, carefully pick your battles).
Much to my dismay I hear this same lead sharing her same old ideas that in my opinion...
If you do not back up your assertions with data then they'll always be ignored. Everything else equal, to do it again in the same way it was is a very strong point in his favor.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?
That's absolutely reasonable, if there isn't any compelling reason then to stick to established and well-known conventions is a fairly good approach. You know it even if you can't explain why. Let me try to help you with this, most obvious benefits (and list is not exhaustive):
- You can pick any random programmer - without any experience on your code base - and she already knows how it works/it's organized.
- No wasted time to decide and to document these decisions.
- Someone already tried them in the real world and advantages already proved to overcome disadvantages.
- If you stick to community practices then there is a good chance to re-use existing tools to enforce those rules (think about fxcop, eslint & friends).
Each of these points is worthy of a separate discussion (because each one comes with its own set of secondary advantages and some drawbacks) but I'm going to be off-topic...
answered yesterday
Adriano Repetti
1,092412
add a comment |Â
up vote
3
down vote
You want this to happen, make it happen. My strategy is a lot of work, but it gets results. And once you sit down and start logically it's not really as hard as you'd think.
Spend less time arguing points or rationalising things.
Create a plan for a full solution, draw up the file hierarchy and anything else in broad strokes and as much detail as you can. Work out timeframes, responsibilities, conventions etc and then present it as a full viable solution.
Most people when faced with an actual solution to their problems that they didn't have to work out will go with it in broad strokes. The sheer volume of logical information intimidates them. The details can be hashed out later, but you will then have everyones attention when it comes to debating because subconsciously it's your product. You can pretty much hide any personal preferences you want amidst it all.
It's always best to talk from the viewpoint of solutions rather than problems. Take ownership if possible and just bulldoze your way through the general apathy. People will start contributing positively, it's natural to want to be part of a success story. Let everyone get involved if you can in the finer details, ask opinions you don't really care about etc, do a bit of social engineering.
If it doesn't work out... you still taught yourself some valuable lessons in designing a product... don't get frustrated or upset, you win either way.
answered yesterday
Kilisi
97.1k53221382
1
+1 because I've seen it used and use it myself sometimes and like you say, it gets results. Be prepared though that once in a blue moon, you'll get someone on the other side of the table that knows this trick, sees through it and doesn't just go along with it. Embrace that, make them an ally, and actually take their input seriously. They'll fight you throughout every step if you don't.
– DonFusili
yesterday
1
This is really good advice, and I do like this answer as it actually has a concrete action. I will certainly take this onboard.
– ESR
yesterday
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
accepted
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects?
If you don't have any evidence and concrete data to support your ideas then he will think you are making a whimsical suggestion.
You (or your team or your lead) must decide how to organize source code (for example). It's not yes/no but A/B. Which one is better? Sometimes - honestly - it does not matter (think about all those holy wars about code formatting). When it matters then you have to make an informed decision but IT IS a decision: should you organize code/files in a highly hierarchical structure? For each decision (small or big) you have to ask yourself: why yes? why not? which are the pros and cons of each one?
If you can't say WHY his decision is bad (which are the cons?!) then you're just rejecting a gut decision with another gut decision. Don't fight a holy war, discuss about it but don't waste energy or time on this; if code base is such bad then I'm sure there are better topics to fight for. On the other hand you may have evidence (what went wrong because of this in the past?), in this case present it and be ready to discuss alternatives (but, again, carefully pick your battles).
Much to my dismay I hear this same lead sharing her same old ideas that in my opinion...
If you do not back up your assertions with data then they'll always be ignored. Everything else equal, to do it again in the same way it was is a very strong point in his favor.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?
That's absolutely reasonable, if there isn't any compelling reason then to stick to established and well-known conventions is a fairly good approach. You know it even if you can't explain why. Let me try to help you with this, most obvious benefits (and list is not exhaustive):
- You can pick any random programmer - without any experience on your code base - and she already knows how it works/it's organized.
- No wasted time to decide and to document these decisions.
- Someone already tried them in the real world and advantages already proved to overcome disadvantages.
- If you stick to community practices then there is a good chance to re-use existing tools to enforce those rules (think about fxcop, eslint & friends).
Each of these points is worthy of a separate discussion (because each one comes with its own set of secondary advantages and some drawbacks) but I'm going to be off-topic...
answered yesterday
Adriano Repetti
1,092412
add a comment |Â
up vote
8
down vote
accepted
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects?
If you don't have any evidence and concrete data to support your ideas then he will think you are making a whimsical suggestion.
You (or your team or your lead) must decide how to organize source code (for example). It's not yes/no but A/B. Which one is better? Sometimes - honestly - it does not matter (think about all those holy wars about code formatting). When it matters then you have to make an informed decision but IT IS a decision: should you organize code/files in a highly hierarchical structure? For each decision (small or big) you have to ask yourself: why yes? why not? which are the pros and cons of each one?
If you can't say WHY his decision is bad (which are the cons?!) then you're just rejecting a gut decision with another gut decision. Don't fight a holy war, discuss about it but don't waste energy or time on this; if code base is such bad then I'm sure there are better topics to fight for. On the other hand you may have evidence (what went wrong because of this in the past?), in this case present it and be ready to discuss alternatives (but, again, carefully pick your battles).
Much to my dismay I hear this same lead sharing her same old ideas that in my opinion...
If you do not back up your assertions with data then they'll always be ignored. Everything else equal, to do it again in the same way it was is a very strong point in his favor.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?
That's absolutely reasonable, if there isn't any compelling reason then to stick to established and well-known conventions is a fairly good approach. You know it even if you can't explain why. Let me try to help you with this, most obvious benefits (and list is not exhaustive):
- You can pick any random programmer - without any experience on your code base - and she already knows how it works/it's organized.
- No wasted time to decide and to document these decisions.
- Someone already tried them in the real world and advantages already proved to overcome disadvantages.
- If you stick to community practices then there is a good chance to re-use existing tools to enforce those rules (think about fxcop, eslint & friends).
Each of these points is worthy of a separate discussion (because each one comes with its own set of secondary advantages and some drawbacks) but I'm going to be off-topic...
answered yesterday
Adriano Repetti
1,092412
add a comment |Â
up vote
8
down vote
accepted
up vote
8
down vote
accepted
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects?
If you don't have any evidence and concrete data to support your ideas then he will think you are making a whimsical suggestion.
You (or your team or your lead) must decide how to organize source code (for example). It's not yes/no but A/B. Which one is better? Sometimes - honestly - it does not matter (think about all those holy wars about code formatting). When it matters then you have to make an informed decision but IT IS a decision: should you organize code/files in a highly hierarchical structure? For each decision (small or big) you have to ask yourself: why yes? why not? which are the pros and cons of each one?
If you can't say WHY his decision is bad (which are the cons?!) then you're just rejecting a gut decision with another gut decision. Don't fight a holy war, discuss about it but don't waste energy or time on this; if code base is such bad then I'm sure there are better topics to fight for. On the other hand you may have evidence (what went wrong because of this in the past?), in this case present it and be ready to discuss alternatives (but, again, carefully pick your battles).
Much to my dismay I hear this same lead sharing her same old ideas that in my opinion...
If you do not back up your assertions with data then they'll always be ignored. Everything else equal, to do it again in the same way it was is a very strong point in his favor.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?
That's absolutely reasonable, if there isn't any compelling reason then to stick to established and well-known conventions is a fairly good approach. You know it even if you can't explain why. Let me try to help you with this, most obvious benefits (and list is not exhaustive):
- You can pick any random programmer - without any experience on your code base - and she already knows how it works/it's organized.
- No wasted time to decide and to document these decisions.
- Someone already tried them in the real world and advantages already proved to overcome disadvantages.
- If you stick to community practices then there is a good chance to re-use existing tools to enforce those rules (think about fxcop, eslint & friends).
Each of these points is worthy of a separate discussion (because each one comes with its own set of secondary advantages and some drawbacks) but I'm going to be off-topic...
answered yesterday
Adriano Repetti
1,092412
Without having any concrete data to prove why her ideas aren't the best for us, how can I dispute whimsical suggestions and suggest we only do things that have proven to work on other projects?
If you don't have any evidence and concrete data to support your ideas then he will think you are making a whimsical suggestion.
You (or your team or your lead) must decide how to organize source code (for example). It's not yes/no but A/B. Which one is better? Sometimes - honestly - it does not matter (think about all those holy wars about code formatting). When it matters then you have to make an informed decision but IT IS a decision: should you organize code/files in a highly hierarchical structure? For each decision (small or big) you have to ask yourself: why yes? why not? which are the pros and cons of each one?
If you can't say WHY his decision is bad (which are the cons?!) then you're just rejecting a gut decision with another gut decision. Don't fight a holy war, discuss about it but don't waste energy or time on this; if code base is such bad then I'm sure there are better topics to fight for. On the other hand you may have evidence (what went wrong because of this in the past?), in this case present it and be ready to discuss alternatives (but, again, carefully pick your battles).
Much to my dismay I hear this same lead sharing her same old ideas that in my opinion...
If you do not back up your assertions with data then they'll always be ignored. Everything else equal, to do it again in the same way it was is a very strong point in his favor.
So I guess my question is, how can I get people to make decisions based on research and established conventions as opposed to what "feels" right for them, and not get them to commit to ideas, with no evidence, that could potentially have bad consequences?
That's absolutely reasonable, if there isn't any compelling reason then to stick to established and well-known conventions is a fairly good approach. You know it even if you can't explain why. Let me try to help you with this, most obvious benefits (and list is not exhaustive):
- You can pick any random programmer - without any experience on your code base - and she already knows how it works/it's organized.
- No wasted time to decide and to document these decisions.
- Someone already tried them in the real world and advantages already proved to overcome disadvantages.
- If you stick to community practices then there is a good chance to re-use existing tools to enforce those rules (think about fxcop, eslint & friends).
Each of these points is worthy of a separate discussion (because each one comes with its own set of secondary advantages and some drawbacks) but I'm going to be off-topic...
answered yesterday
Adriano Repetti
1,092412
edited yesterday
answered yesterday
Adriano Repetti
1,092412
answered yesterday
Adriano Repetti
1,092412
answered yesterday
Adriano Repetti
1,092412
1,092412
add a comment |Â
add a comment |Â
up vote
3
down vote
You want this to happen, make it happen. My strategy is a lot of work, but it gets results. And once you sit down and start logically it's not really as hard as you'd think.
Spend less time arguing points or rationalising things.
Create a plan for a full solution, draw up the file hierarchy and anything else in broad strokes and as much detail as you can. Work out timeframes, responsibilities, conventions etc and then present it as a full viable solution.
Most people when faced with an actual solution to their problems that they didn't have to work out will go with it in broad strokes. The sheer volume of logical information intimidates them. The details can be hashed out later, but you will then have everyones attention when it comes to debating because subconsciously it's your product. You can pretty much hide any personal preferences you want amidst it all.
It's always best to talk from the viewpoint of solutions rather than problems. Take ownership if possible and just bulldoze your way through the general apathy. People will start contributing positively, it's natural to want to be part of a success story. Let everyone get involved if you can in the finer details, ask opinions you don't really care about etc, do a bit of social engineering.
If it doesn't work out... you still taught yourself some valuable lessons in designing a product... don't get frustrated or upset, you win either way.
answered yesterday
Kilisi
97.1k53221382
1
+1 because I've seen it used and use it myself sometimes and like you say, it gets results. Be prepared though that once in a blue moon, you'll get someone on the other side of the table that knows this trick, sees through it and doesn't just go along with it. Embrace that, make them an ally, and actually take their input seriously. They'll fight you throughout every step if you don't.
– DonFusili
yesterday
1
This is really good advice, and I do like this answer as it actually has a concrete action. I will certainly take this onboard.
– ESR
yesterday
add a comment |Â
up vote
3
down vote
You want this to happen, make it happen. My strategy is a lot of work, but it gets results. And once you sit down and start logically it's not really as hard as you'd think.
Spend less time arguing points or rationalising things.
Create a plan for a full solution, draw up the file hierarchy and anything else in broad strokes and as much detail as you can. Work out timeframes, responsibilities, conventions etc and then present it as a full viable solution.
Most people when faced with an actual solution to their problems that they didn't have to work out will go with it in broad strokes. The sheer volume of logical information intimidates them. The details can be hashed out later, but you will then have everyones attention when it comes to debating because subconsciously it's your product. You can pretty much hide any personal preferences you want amidst it all.
It's always best to talk from the viewpoint of solutions rather than problems. Take ownership if possible and just bulldoze your way through the general apathy. People will start contributing positively, it's natural to want to be part of a success story. Let everyone get involved if you can in the finer details, ask opinions you don't really care about etc, do a bit of social engineering.
If it doesn't work out... you still taught yourself some valuable lessons in designing a product... don't get frustrated or upset, you win either way.
answered yesterday
Kilisi
97.1k53221382
1
+1 because I've seen it used and use it myself sometimes and like you say, it gets results. Be prepared though that once in a blue moon, you'll get someone on the other side of the table that knows this trick, sees through it and doesn't just go along with it. Embrace that, make them an ally, and actually take their input seriously. They'll fight you throughout every step if you don't.
– DonFusili
yesterday
1
This is really good advice, and I do like this answer as it actually has a concrete action. I will certainly take this onboard.
– ESR
yesterday
add a comment |Â
up vote
3
down vote
up vote
3
down vote
You want this to happen, make it happen. My strategy is a lot of work, but it gets results. And once you sit down and start logically it's not really as hard as you'd think.
Spend less time arguing points or rationalising things.
Create a plan for a full solution, draw up the file hierarchy and anything else in broad strokes and as much detail as you can. Work out timeframes, responsibilities, conventions etc and then present it as a full viable solution.
Most people when faced with an actual solution to their problems that they didn't have to work out will go with it in broad strokes. The sheer volume of logical information intimidates them. The details can be hashed out later, but you will then have everyones attention when it comes to debating because subconsciously it's your product. You can pretty much hide any personal preferences you want amidst it all.
It's always best to talk from the viewpoint of solutions rather than problems. Take ownership if possible and just bulldoze your way through the general apathy. People will start contributing positively, it's natural to want to be part of a success story. Let everyone get involved if you can in the finer details, ask opinions you don't really care about etc, do a bit of social engineering.
If it doesn't work out... you still taught yourself some valuable lessons in designing a product... don't get frustrated or upset, you win either way.
answered yesterday
Kilisi
97.1k53221382
You want this to happen, make it happen. My strategy is a lot of work, but it gets results. And once you sit down and start logically it's not really as hard as you'd think.
Spend less time arguing points or rationalising things.
Create a plan for a full solution, draw up the file hierarchy and anything else in broad strokes and as much detail as you can. Work out timeframes, responsibilities, conventions etc and then present it as a full viable solution.
Most people when faced with an actual solution to their problems that they didn't have to work out will go with it in broad strokes. The sheer volume of logical information intimidates them. The details can be hashed out later, but you will then have everyones attention when it comes to debating because subconsciously it's your product. You can pretty much hide any personal preferences you want amidst it all.
It's always best to talk from the viewpoint of solutions rather than problems. Take ownership if possible and just bulldoze your way through the general apathy. People will start contributing positively, it's natural to want to be part of a success story. Let everyone get involved if you can in the finer details, ask opinions you don't really care about etc, do a bit of social engineering.
If it doesn't work out... you still taught yourself some valuable lessons in designing a product... don't get frustrated or upset, you win either way.
answered yesterday
Kilisi
97.1k53221382
edited yesterday
answered yesterday
Kilisi
97.1k53221382
answered yesterday
Kilisi
97.1k53221382
answered yesterday
Kilisi
97.1k53221382
97.1k53221382
1
+1 because I've seen it used and use it myself sometimes and like you say, it gets results. Be prepared though that once in a blue moon, you'll get someone on the other side of the table that knows this trick, sees through it and doesn't just go along with it. Embrace that, make them an ally, and actually take their input seriously. They'll fight you throughout every step if you don't.
– DonFusili
yesterday
1
This is really good advice, and I do like this answer as it actually has a concrete action. I will certainly take this onboard.
– ESR
yesterday
add a comment |Â
1
+1 because I've seen it used and use it myself sometimes and like you say, it gets results. Be prepared though that once in a blue moon, you'll get someone on the other side of the table that knows this trick, sees through it and doesn't just go along with it. Embrace that, make them an ally, and actually take their input seriously. They'll fight you throughout every step if you don't.
– DonFusili
yesterday
1
This is really good advice, and I do like this answer as it actually has a concrete action. I will certainly take this onboard.
– ESR
yesterday
1
1
+1 because I've seen it used and use it myself sometimes and like you say, it gets results. Be prepared though that once in a blue moon, you'll get someone on the other side of the table that knows this trick, sees through it and doesn't just go along with it. Embrace that, make them an ally, and actually take their input seriously. They'll fight you throughout every step if you don't.
– DonFusili
yesterday
+1 because I've seen it used and use it myself sometimes and like you say, it gets results. Be prepared though that once in a blue moon, you'll get someone on the other side of the table that knows this trick, sees through it and doesn't just go along with it. Embrace that, make them an ally, and actually take their input seriously. They'll fight you throughout every step if you don't.
– DonFusili
yesterday
1
1
This is really good advice, and I do like this answer as it actually has a concrete action. I will certainly take this onboard.
– ESR
yesterday
This is really good advice, and I do like this answer as it actually has a concrete action. I will certainly take this onboard.
– ESR
yesterday
add a comment |Â
ESR is a new contributor. Be nice, and check out our Code of Conduct.
ESR is a new contributor. Be nice, and check out our Code of Conduct.
ESR is a new contributor. Be nice, and check out our Code of Conduct.
ESR is a new contributor. Be nice, and check out our Code of Conduct.
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%2f119101%2fhow-can-i-get-colleagues-to-makes-decisions-based-off-research-as-opposed-to-whi%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
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
19 hours ago