Mixing
How can I get co-workers to buy into some of my ideas? [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
9
down vote
favorite
This question already has an answer here:
Should I propose a big change as a newcomer?
8 answers
I am very new in my workplace and would like to bring up some changes. Most of these changes would bring the environment up to industry standards for this field, software development.
How can I go about suggesting these changes and getting the approval / agreement of my peers without alienating myself this early on in our working relationship by seeming like I'm trying to take control?
communication new-job
edited Apr 23 '16 at 22:05
Joe Strazzere
224k107661930
asked May 5 '13 at 16:31
Xaisoft
14913
marked as duplicate by Jim G., gnat, jcmeloni, ChrisF, CincinnatiProgrammer May 6 '13 at 11:24
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.
add a comment |Â
up vote
9
down vote
favorite
This question already has an answer here:
Should I propose a big change as a newcomer?
8 answers
I am very new in my workplace and would like to bring up some changes. Most of these changes would bring the environment up to industry standards for this field, software development.
How can I go about suggesting these changes and getting the approval / agreement of my peers without alienating myself this early on in our working relationship by seeming like I'm trying to take control?
communication new-job
edited Apr 23 '16 at 22:05
Joe Strazzere
224k107661930
asked May 5 '13 at 16:31
Xaisoft
14913
marked as duplicate by Jim G., gnat, jcmeloni, ChrisF, CincinnatiProgrammer May 6 '13 at 11:24
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.
2
You might find this answer useful workplace.stackexchange.com/questions/9703/…
– Amy Blankenship
May 5 '13 at 19:35
4
@gnat similar but not duplicate, this covers a much broader scope of how rather than just should i. Answers to this can have a scope larger than just to 'newcomers' i feel
– Rhys
May 5 '13 at 20:29
Be very careful not to end up insulting your co-workers. Consider that there can be very good reasons for things being the way they are. Learn those, and then consider what low hanging fruit might actually help your coworkers . Those things will most likely be very welcome.
– Thorbjørn Ravn Andersen
May 6 '13 at 7:27
@SpikyBlue per my reading, answers in suggested dupe indeed focus on how instead of should I (and this feels right to me)
– gnat
May 6 '13 at 7:31
1
if you want other people to buy your idea you need to sell it (pun intended)
– ratchet freak
May 6 '13 at 10:22
add a comment |Â
up vote
9
down vote
favorite
up vote
9
down vote
favorite
This question already has an answer here:
Should I propose a big change as a newcomer?
8 answers
I am very new in my workplace and would like to bring up some changes. Most of these changes would bring the environment up to industry standards for this field, software development.
How can I go about suggesting these changes and getting the approval / agreement of my peers without alienating myself this early on in our working relationship by seeming like I'm trying to take control?
communication new-job
edited Apr 23 '16 at 22:05
Joe Strazzere
224k107661930
asked May 5 '13 at 16:31
Xaisoft
14913
This question already has an answer here:
Should I propose a big change as a newcomer?
8 answers
I am very new in my workplace and would like to bring up some changes. Most of these changes would bring the environment up to industry standards for this field, software development.
How can I go about suggesting these changes and getting the approval / agreement of my peers without alienating myself this early on in our working relationship by seeming like I'm trying to take control?
This question already has an answer here:
Should I propose a big change as a newcomer?
8 answers
communication new-job
edited Apr 23 '16 at 22:05
Joe Strazzere
224k107661930
asked May 5 '13 at 16:31
Xaisoft
14913
edited Apr 23 '16 at 22:05
Joe Strazzere
224k107661930
edited Apr 23 '16 at 22:05
Joe Strazzere
224k107661930
edited Apr 23 '16 at 22:05
Joe Strazzere
224k107661930
224k107661930
asked May 5 '13 at 16:31
Xaisoft
14913
asked May 5 '13 at 16:31
Xaisoft
14913
asked May 5 '13 at 16:31
Xaisoft
14913
14913
marked as duplicate by Jim G., gnat, jcmeloni, ChrisF, CincinnatiProgrammer May 6 '13 at 11:24
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 Jim G., gnat, jcmeloni, ChrisF, CincinnatiProgrammer May 6 '13 at 11:24
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.
2
You might find this answer useful workplace.stackexchange.com/questions/9703/…
– Amy Blankenship
May 5 '13 at 19:35
4
@gnat similar but not duplicate, this covers a much broader scope of how rather than just should i. Answers to this can have a scope larger than just to 'newcomers' i feel
– Rhys
May 5 '13 at 20:29
Be very careful not to end up insulting your co-workers. Consider that there can be very good reasons for things being the way they are. Learn those, and then consider what low hanging fruit might actually help your coworkers . Those things will most likely be very welcome.
– Thorbjørn Ravn Andersen
May 6 '13 at 7:27
@SpikyBlue per my reading, answers in suggested dupe indeed focus on how instead of should I (and this feels right to me)
– gnat
May 6 '13 at 7:31
1
if you want other people to buy your idea you need to sell it (pun intended)
– ratchet freak
May 6 '13 at 10:22
add a comment |Â
2
You might find this answer useful workplace.stackexchange.com/questions/9703/…
– Amy Blankenship
May 5 '13 at 19:35
4
@gnat similar but not duplicate, this covers a much broader scope of how rather than just should i. Answers to this can have a scope larger than just to 'newcomers' i feel
– Rhys
May 5 '13 at 20:29
Be very careful not to end up insulting your co-workers. Consider that there can be very good reasons for things being the way they are. Learn those, and then consider what low hanging fruit might actually help your coworkers . Those things will most likely be very welcome.
– Thorbjørn Ravn Andersen
May 6 '13 at 7:27
@SpikyBlue per my reading, answers in suggested dupe indeed focus on how instead of should I (and this feels right to me)
– gnat
May 6 '13 at 7:31
1
if you want other people to buy your idea you need to sell it (pun intended)
– ratchet freak
May 6 '13 at 10:22
2
2
You might find this answer useful workplace.stackexchange.com/questions/9703/…
– Amy Blankenship
May 5 '13 at 19:35
You might find this answer useful workplace.stackexchange.com/questions/9703/…
– Amy Blankenship
May 5 '13 at 19:35
4
4
@gnat similar but not duplicate, this covers a much broader scope of how rather than just should i. Answers to this can have a scope larger than just to 'newcomers' i feel
– Rhys
May 5 '13 at 20:29
@gnat similar but not duplicate, this covers a much broader scope of how rather than just should i. Answers to this can have a scope larger than just to 'newcomers' i feel
– Rhys
May 5 '13 at 20:29
Be very careful not to end up insulting your co-workers. Consider that there can be very good reasons for things being the way they are. Learn those, and then consider what low hanging fruit might actually help your coworkers . Those things will most likely be very welcome.
– Thorbjørn Ravn Andersen
May 6 '13 at 7:27
Be very careful not to end up insulting your co-workers. Consider that there can be very good reasons for things being the way they are. Learn those, and then consider what low hanging fruit might actually help your coworkers . Those things will most likely be very welcome.
– Thorbjørn Ravn Andersen
May 6 '13 at 7:27
@SpikyBlue per my reading, answers in suggested dupe indeed focus on how instead of should I (and this feels right to me)
– gnat
May 6 '13 at 7:31
@SpikyBlue per my reading, answers in suggested dupe indeed focus on how instead of should I (and this feels right to me)
– gnat
May 6 '13 at 7:31
1
1
if you want other people to buy your idea you need to sell it (pun intended)
– ratchet freak
May 6 '13 at 10:22
if you want other people to buy your idea you need to sell it (pun intended)
– ratchet freak
May 6 '13 at 10:22
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
13
down vote
There are a few methods to take into consideration when proposing changes at any company. Regardless of your position at the company.
1. Don't Play The Blame Game
Never play the blame game. Even if you can see that all of the problems stem from one person. Playing the blame game will stir up a whole mess of politics in the work environment that you will be much better off without.
Instead, suggest all of your improvements objectively, as team wide goals.
2. Confidence is Key
Before you even think about suggesting these changes go through it all yourself, write up your ideas, then go through it again and again. Don't focus just on what changes to make, but also how you are going to suggest these changes.
The changes need to seem simple and easy. If it takes you 20 minutes and 3 pages to detail a single change, it's probably too long and complicated with too many potential fail points for people to want to buy into it.
Pay attention to weak points in your own arguments, make sure you have answers, and make sure they are good answers. "I don't know" can be a killer when trying to get people to accept your changes.
Confidence is key, you need to seem like you know what you are doing, and you need to seem like you know how to do it. If you aren't confident in your changes, people won't be confident in you.
3. Bottom up Approach
Before you go suggesting your ideas to the CEO you need to check that the rest of the company even agrees with you.
Start with the people around you, the people you work with on a daily basis, talk to them about your ideas and see what they think. See what they like and what they dislike, and see if they agree that your changes would be for the best.
Then move on to your manager, show him your changes, show him you have support from the rest of the team. Show him that it's in his or her best interest to pursue these changes and you will have their support.
4. Follow proper protocol
Don't try to jump the gun, suggesting your changes to the top of the chain might seem like a good idea but if it hasn't gone through the proper internal processes then you're at a disadvantage.
These internal process make sure that everyone who needs to see it and agree to it gets a chance to give their input, address their concerns, and suggest improvements.
Getting buy in from your team is a difficult game to play, it involves making sure that they feel included, and that they feel their voice is being heard, it involves following proper procedure so that the change is bullet proof by the time it reaches people who can do anything about it.
Be a subject expert
But most importantly of all, you will need to know a lot about it, if you suggest the change you are likely to be the person needing to field all of the questions and concerns about the change. If you can't answer the questions or mitigate the concerns, you will lose backing.
answered May 5 '13 at 19:58
Rhys
5,73623558
add a comment |Â
up vote
11
down vote
It is really important to avoid being a know-it-all. When you come across feeling superior, nobody will feel inclined to listen to you. Playing the blame game is often also not really constructive. I think first you need to build a good relationship with your co-workers. After that, try and find moments where you can discuss these kind coding flaws. Objectively prove to then why some things are bad, using objective arguments is really key here in keeping the discussion away from ' but that is just how you like to do things, I'll continue like I did'. Some things, like the coding standards, might be a good topic for a staff meeting.
Be prepared to be patient. Change takes a long time. And always keep in mind you could be wrong :).
answered May 5 '13 at 17:34
Paul Hiemstra
3,8451621
add a comment |Â
up vote
7
down vote
Without going too far into behavioral change theories or other social sciences, I had a similar experience at a software company. I had been there for less than a year, and I found myself with process quality assurance responsibilities. At times, it was awkward trying to integrate new work habits into often undefined processes, and it could also be very disheartening to see my thoroughly-researched suggestions fall out of favor.
Here are some pointers that I picked up:
Business Value
There is no need to change if it doesn't provide an observable benefit to the organization. Be ready to provide empirical research or reports on the process areas you want to upgrade, and, if possible, prepare a metric collection and analysis plan. For example, maybe your company already tracks how long it takes to fix bugs. If bugs a, b, and c took x amount of time on average before your methods, maybe you can prove that bugs d, e, and f took less time on average to fix. There's a lot that goes into metric analysis in software engineering, and if you're interested in learning more, I would recommend looking into Goal, Question, Metric (GQM).
Talk with Your Peers
Suggesting new ways of doing things can alienate your coworkers, and, as Paul Hiemstra points out, it can get you the reputation of being a know-it-all (nobody likes a know-it-all). Take some time to talk to your coworkers and ask why they do things the way they do. It could be that they have very good reasons, but there's also a good chance that they know that things could be better. Try to make changing processes a team effort coming from within the organization and not as changes being imposed from the outside. For further reading, see organizational culture and cultural assimilation.
Right Time and Place
Too much change too fast will cause resistance. At our small company, we had retrospective meetings every month after we delivered our updates to our customer. This was a perfect time to say "I noticed that we were having some trouble with x this month. I've been looking into it, and I read about a lot of people in a similar situation who had success doing y. Is anyone interested in trying it out?" Rolling out changes one-at-a-time can give everyone a chance to practice the new process and get comfortable with it before trying something new. Also, it may help to roll-out a change when there's a little breathing room and not in the middle of a sprint.
Provide Options
This comes from talking with your peers, and it's pretty basic. Say, if your company doesn't provide version control, don't just say "OK, here's how you install git..." When it comes to updating processes, it's good to provide options. Again with the git example, introduce the organization to version control concepts: what is it and what benefits does it have. Then talk about the different options and how they compare to each other. Don't just jump in with your favorite tool because it's what you're most comfortable with; it's about giving the organization the freedom to experiment and play with different options. Heck, I've had many conversations with coworkers about new tools that started with "Hey, check out this new toy I got!" *demonstration* "Isn't that cool?"
TL;DR
Talk with your coworkers before trying to change how they do things, and be prepared to prove why something is worth changing.
answered May 5 '13 at 23:41
David Kaczynski
191118
add a comment |Â
up vote
0
down vote
In addition to what was said by Paul Hiemstra:
Xaisoft, at each level of seniority/hierarchy there is a limit to things you can change. A junior developer/engineer can suggest changes to routines, but s/he has to be perceived as a very bright person by almost all stakeholders for the change to succeed. As your experience grows, the scope of feasible changes expands. But the greatest potential to foster changes comes with middle-level management positions.
You have to ask yourself, though:
Is the change I'm proposing worth it?
What will be the negative effects of the change?
Must say that I profoundly dislike change for the sake of change, hate management fads and buzzwords. Anything that upsets the established routine and standard operating procedures in the workplace lowers productivity and is immediately detrimental to the bottom line while positive effects (if any) are delayed. Think about it.
EDIT: As usual, changes are a double-edged sword. If you significantly lag behind the bleeding edge in technology, you very often lose. If you make continuous changes to the way your organization works, people around you will be put under stress and possibly lose trust. The best solution to the technological part of the problem is when employees are used to keeping up with the state-of-the-art. Unfortunately, it doesn't work out for the internal structure and procedures - here, some degree of stability and freedom from superficial management-inspired "reorganizations" are necessary to be productive.
Here are the conclusions:
Please, start changes with yourself.
Gain some respect of your colleagues; do not try to impose revolutions on others unless you are reasonably sure of their success.
Always consider multiple avenues for improvement and perform cost-benefit analysis before coming to a meeting with half-baked proposals.
answered May 5 '13 at 18:20
Deer Hunter
937820
This is why I said "There is more..." in my post. I have only seen the code for 2 days and the things I mentioned were just simple things. It is not so much about those things in particular, but how to convince others objectively on alternative ways. I was merely giving a few examples. I only mentioned coding standards once, but I wouldn't say that any of the things is superficial. Everything affects everything.
– Xaisoft
May 5 '13 at 19:06
I have to say I disagree that anything that upsets the established routine lowers productivity. For example, introducing version control has a low to moderate negative impact on productivity on the front end, with a much higher return in the relatively short-term.
– Amy Blankenship
May 5 '13 at 19:24
@AmyBlankenship - please consider time spent on installing VCS and instilling the new routine. There is a transient negative spike; sometimes it's a purely psychological disruption. Is it swamped out by genuine improvement some time afterwards? Depends... The other problem here is the number of disruptions per unit time. Continuous disruption builds up stress and uncertainty.
– Deer Hunter
May 5 '13 at 19:44
1
Hm, in the situation I had in mind (my own experience) it was already installed, but no one was using it. The other side of the coin is that refusing to make any changes (or doing so too slowly) means that you don't have enough bandwidth to keep making the incremental changes you need to. This is how people are still on ASP classic writing HTML that was out-of-date in 2007, for instance.
– Amy Blankenship
May 5 '13 at 19:49
@AmyBlankenship - all right, different assumptions on VCS. There is no standard on how large change quanta should be because industries and organizations and skill sets differ. If employees are used to keeping up with the bleeding edge, the technology part of the problem is solved; not so for organizational changes (imagine your title, job description and direct supervisor being changed 6 times a year).
– Deer Hunter
May 5 '13 at 20:23
 |Â
show 1 more comment
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
13
down vote
There are a few methods to take into consideration when proposing changes at any company. Regardless of your position at the company.
1. Don't Play The Blame Game
Never play the blame game. Even if you can see that all of the problems stem from one person. Playing the blame game will stir up a whole mess of politics in the work environment that you will be much better off without.
Instead, suggest all of your improvements objectively, as team wide goals.
2. Confidence is Key
Before you even think about suggesting these changes go through it all yourself, write up your ideas, then go through it again and again. Don't focus just on what changes to make, but also how you are going to suggest these changes.
The changes need to seem simple and easy. If it takes you 20 minutes and 3 pages to detail a single change, it's probably too long and complicated with too many potential fail points for people to want to buy into it.
Pay attention to weak points in your own arguments, make sure you have answers, and make sure they are good answers. "I don't know" can be a killer when trying to get people to accept your changes.
Confidence is key, you need to seem like you know what you are doing, and you need to seem like you know how to do it. If you aren't confident in your changes, people won't be confident in you.
3. Bottom up Approach
Before you go suggesting your ideas to the CEO you need to check that the rest of the company even agrees with you.
Start with the people around you, the people you work with on a daily basis, talk to them about your ideas and see what they think. See what they like and what they dislike, and see if they agree that your changes would be for the best.
Then move on to your manager, show him your changes, show him you have support from the rest of the team. Show him that it's in his or her best interest to pursue these changes and you will have their support.
4. Follow proper protocol
Don't try to jump the gun, suggesting your changes to the top of the chain might seem like a good idea but if it hasn't gone through the proper internal processes then you're at a disadvantage.
These internal process make sure that everyone who needs to see it and agree to it gets a chance to give their input, address their concerns, and suggest improvements.
Getting buy in from your team is a difficult game to play, it involves making sure that they feel included, and that they feel their voice is being heard, it involves following proper procedure so that the change is bullet proof by the time it reaches people who can do anything about it.
Be a subject expert
But most importantly of all, you will need to know a lot about it, if you suggest the change you are likely to be the person needing to field all of the questions and concerns about the change. If you can't answer the questions or mitigate the concerns, you will lose backing.
answered May 5 '13 at 19:58
Rhys
5,73623558
add a comment |Â
up vote
13
down vote
There are a few methods to take into consideration when proposing changes at any company. Regardless of your position at the company.
1. Don't Play The Blame Game
Never play the blame game. Even if you can see that all of the problems stem from one person. Playing the blame game will stir up a whole mess of politics in the work environment that you will be much better off without.
Instead, suggest all of your improvements objectively, as team wide goals.
2. Confidence is Key
Before you even think about suggesting these changes go through it all yourself, write up your ideas, then go through it again and again. Don't focus just on what changes to make, but also how you are going to suggest these changes.
The changes need to seem simple and easy. If it takes you 20 minutes and 3 pages to detail a single change, it's probably too long and complicated with too many potential fail points for people to want to buy into it.
Pay attention to weak points in your own arguments, make sure you have answers, and make sure they are good answers. "I don't know" can be a killer when trying to get people to accept your changes.
Confidence is key, you need to seem like you know what you are doing, and you need to seem like you know how to do it. If you aren't confident in your changes, people won't be confident in you.
3. Bottom up Approach
Before you go suggesting your ideas to the CEO you need to check that the rest of the company even agrees with you.
Start with the people around you, the people you work with on a daily basis, talk to them about your ideas and see what they think. See what they like and what they dislike, and see if they agree that your changes would be for the best.
Then move on to your manager, show him your changes, show him you have support from the rest of the team. Show him that it's in his or her best interest to pursue these changes and you will have their support.
4. Follow proper protocol
Don't try to jump the gun, suggesting your changes to the top of the chain might seem like a good idea but if it hasn't gone through the proper internal processes then you're at a disadvantage.
These internal process make sure that everyone who needs to see it and agree to it gets a chance to give their input, address their concerns, and suggest improvements.
Getting buy in from your team is a difficult game to play, it involves making sure that they feel included, and that they feel their voice is being heard, it involves following proper procedure so that the change is bullet proof by the time it reaches people who can do anything about it.
Be a subject expert
But most importantly of all, you will need to know a lot about it, if you suggest the change you are likely to be the person needing to field all of the questions and concerns about the change. If you can't answer the questions or mitigate the concerns, you will lose backing.
answered May 5 '13 at 19:58
Rhys
5,73623558
add a comment |Â
up vote
13
down vote
up vote
13
down vote
There are a few methods to take into consideration when proposing changes at any company. Regardless of your position at the company.
1. Don't Play The Blame Game
Never play the blame game. Even if you can see that all of the problems stem from one person. Playing the blame game will stir up a whole mess of politics in the work environment that you will be much better off without.
Instead, suggest all of your improvements objectively, as team wide goals.
2. Confidence is Key
Before you even think about suggesting these changes go through it all yourself, write up your ideas, then go through it again and again. Don't focus just on what changes to make, but also how you are going to suggest these changes.
The changes need to seem simple and easy. If it takes you 20 minutes and 3 pages to detail a single change, it's probably too long and complicated with too many potential fail points for people to want to buy into it.
Pay attention to weak points in your own arguments, make sure you have answers, and make sure they are good answers. "I don't know" can be a killer when trying to get people to accept your changes.
Confidence is key, you need to seem like you know what you are doing, and you need to seem like you know how to do it. If you aren't confident in your changes, people won't be confident in you.
3. Bottom up Approach
Before you go suggesting your ideas to the CEO you need to check that the rest of the company even agrees with you.
Start with the people around you, the people you work with on a daily basis, talk to them about your ideas and see what they think. See what they like and what they dislike, and see if they agree that your changes would be for the best.
Then move on to your manager, show him your changes, show him you have support from the rest of the team. Show him that it's in his or her best interest to pursue these changes and you will have their support.
4. Follow proper protocol
Don't try to jump the gun, suggesting your changes to the top of the chain might seem like a good idea but if it hasn't gone through the proper internal processes then you're at a disadvantage.
These internal process make sure that everyone who needs to see it and agree to it gets a chance to give their input, address their concerns, and suggest improvements.
Getting buy in from your team is a difficult game to play, it involves making sure that they feel included, and that they feel their voice is being heard, it involves following proper procedure so that the change is bullet proof by the time it reaches people who can do anything about it.
Be a subject expert
But most importantly of all, you will need to know a lot about it, if you suggest the change you are likely to be the person needing to field all of the questions and concerns about the change. If you can't answer the questions or mitigate the concerns, you will lose backing.
answered May 5 '13 at 19:58
Rhys
5,73623558
There are a few methods to take into consideration when proposing changes at any company. Regardless of your position at the company.
1. Don't Play The Blame Game
Never play the blame game. Even if you can see that all of the problems stem from one person. Playing the blame game will stir up a whole mess of politics in the work environment that you will be much better off without.
Instead, suggest all of your improvements objectively, as team wide goals.
2. Confidence is Key
Before you even think about suggesting these changes go through it all yourself, write up your ideas, then go through it again and again. Don't focus just on what changes to make, but also how you are going to suggest these changes.
The changes need to seem simple and easy. If it takes you 20 minutes and 3 pages to detail a single change, it's probably too long and complicated with too many potential fail points for people to want to buy into it.
Pay attention to weak points in your own arguments, make sure you have answers, and make sure they are good answers. "I don't know" can be a killer when trying to get people to accept your changes.
Confidence is key, you need to seem like you know what you are doing, and you need to seem like you know how to do it. If you aren't confident in your changes, people won't be confident in you.
3. Bottom up Approach
Before you go suggesting your ideas to the CEO you need to check that the rest of the company even agrees with you.
Start with the people around you, the people you work with on a daily basis, talk to them about your ideas and see what they think. See what they like and what they dislike, and see if they agree that your changes would be for the best.
Then move on to your manager, show him your changes, show him you have support from the rest of the team. Show him that it's in his or her best interest to pursue these changes and you will have their support.
4. Follow proper protocol
Don't try to jump the gun, suggesting your changes to the top of the chain might seem like a good idea but if it hasn't gone through the proper internal processes then you're at a disadvantage.
These internal process make sure that everyone who needs to see it and agree to it gets a chance to give their input, address their concerns, and suggest improvements.
Getting buy in from your team is a difficult game to play, it involves making sure that they feel included, and that they feel their voice is being heard, it involves following proper procedure so that the change is bullet proof by the time it reaches people who can do anything about it.
Be a subject expert
But most importantly of all, you will need to know a lot about it, if you suggest the change you are likely to be the person needing to field all of the questions and concerns about the change. If you can't answer the questions or mitigate the concerns, you will lose backing.
answered May 5 '13 at 19:58
Rhys
5,73623558
answered May 5 '13 at 19:58
Rhys
5,73623558
answered May 5 '13 at 19:58
Rhys
5,73623558
answered May 5 '13 at 19:58
Rhys
5,73623558
5,73623558
add a comment |Â
add a comment |Â
up vote
11
down vote
It is really important to avoid being a know-it-all. When you come across feeling superior, nobody will feel inclined to listen to you. Playing the blame game is often also not really constructive. I think first you need to build a good relationship with your co-workers. After that, try and find moments where you can discuss these kind coding flaws. Objectively prove to then why some things are bad, using objective arguments is really key here in keeping the discussion away from ' but that is just how you like to do things, I'll continue like I did'. Some things, like the coding standards, might be a good topic for a staff meeting.
Be prepared to be patient. Change takes a long time. And always keep in mind you could be wrong :).
answered May 5 '13 at 17:34
Paul Hiemstra
3,8451621
add a comment |Â
up vote
11
down vote
It is really important to avoid being a know-it-all. When you come across feeling superior, nobody will feel inclined to listen to you. Playing the blame game is often also not really constructive. I think first you need to build a good relationship with your co-workers. After that, try and find moments where you can discuss these kind coding flaws. Objectively prove to then why some things are bad, using objective arguments is really key here in keeping the discussion away from ' but that is just how you like to do things, I'll continue like I did'. Some things, like the coding standards, might be a good topic for a staff meeting.
Be prepared to be patient. Change takes a long time. And always keep in mind you could be wrong :).
answered May 5 '13 at 17:34
Paul Hiemstra
3,8451621
add a comment |Â
up vote
11
down vote
up vote
11
down vote
It is really important to avoid being a know-it-all. When you come across feeling superior, nobody will feel inclined to listen to you. Playing the blame game is often also not really constructive. I think first you need to build a good relationship with your co-workers. After that, try and find moments where you can discuss these kind coding flaws. Objectively prove to then why some things are bad, using objective arguments is really key here in keeping the discussion away from ' but that is just how you like to do things, I'll continue like I did'. Some things, like the coding standards, might be a good topic for a staff meeting.
Be prepared to be patient. Change takes a long time. And always keep in mind you could be wrong :).
answered May 5 '13 at 17:34
Paul Hiemstra
3,8451621
It is really important to avoid being a know-it-all. When you come across feeling superior, nobody will feel inclined to listen to you. Playing the blame game is often also not really constructive. I think first you need to build a good relationship with your co-workers. After that, try and find moments where you can discuss these kind coding flaws. Objectively prove to then why some things are bad, using objective arguments is really key here in keeping the discussion away from ' but that is just how you like to do things, I'll continue like I did'. Some things, like the coding standards, might be a good topic for a staff meeting.
Be prepared to be patient. Change takes a long time. And always keep in mind you could be wrong :).
answered May 5 '13 at 17:34
Paul Hiemstra
3,8451621
answered May 5 '13 at 17:34
Paul Hiemstra
3,8451621
answered May 5 '13 at 17:34
Paul Hiemstra
3,8451621
answered May 5 '13 at 17:34
Paul Hiemstra
3,8451621
3,8451621
add a comment |Â
add a comment |Â
up vote
7
down vote
Without going too far into behavioral change theories or other social sciences, I had a similar experience at a software company. I had been there for less than a year, and I found myself with process quality assurance responsibilities. At times, it was awkward trying to integrate new work habits into often undefined processes, and it could also be very disheartening to see my thoroughly-researched suggestions fall out of favor.
Here are some pointers that I picked up:
Business Value
There is no need to change if it doesn't provide an observable benefit to the organization. Be ready to provide empirical research or reports on the process areas you want to upgrade, and, if possible, prepare a metric collection and analysis plan. For example, maybe your company already tracks how long it takes to fix bugs. If bugs a, b, and c took x amount of time on average before your methods, maybe you can prove that bugs d, e, and f took less time on average to fix. There's a lot that goes into metric analysis in software engineering, and if you're interested in learning more, I would recommend looking into Goal, Question, Metric (GQM).
Talk with Your Peers
Suggesting new ways of doing things can alienate your coworkers, and, as Paul Hiemstra points out, it can get you the reputation of being a know-it-all (nobody likes a know-it-all). Take some time to talk to your coworkers and ask why they do things the way they do. It could be that they have very good reasons, but there's also a good chance that they know that things could be better. Try to make changing processes a team effort coming from within the organization and not as changes being imposed from the outside. For further reading, see organizational culture and cultural assimilation.
Right Time and Place
Too much change too fast will cause resistance. At our small company, we had retrospective meetings every month after we delivered our updates to our customer. This was a perfect time to say "I noticed that we were having some trouble with x this month. I've been looking into it, and I read about a lot of people in a similar situation who had success doing y. Is anyone interested in trying it out?" Rolling out changes one-at-a-time can give everyone a chance to practice the new process and get comfortable with it before trying something new. Also, it may help to roll-out a change when there's a little breathing room and not in the middle of a sprint.
Provide Options
This comes from talking with your peers, and it's pretty basic. Say, if your company doesn't provide version control, don't just say "OK, here's how you install git..." When it comes to updating processes, it's good to provide options. Again with the git example, introduce the organization to version control concepts: what is it and what benefits does it have. Then talk about the different options and how they compare to each other. Don't just jump in with your favorite tool because it's what you're most comfortable with; it's about giving the organization the freedom to experiment and play with different options. Heck, I've had many conversations with coworkers about new tools that started with "Hey, check out this new toy I got!" *demonstration* "Isn't that cool?"
TL;DR
Talk with your coworkers before trying to change how they do things, and be prepared to prove why something is worth changing.
answered May 5 '13 at 23:41
David Kaczynski
191118
add a comment |Â
up vote
7
down vote
Without going too far into behavioral change theories or other social sciences, I had a similar experience at a software company. I had been there for less than a year, and I found myself with process quality assurance responsibilities. At times, it was awkward trying to integrate new work habits into often undefined processes, and it could also be very disheartening to see my thoroughly-researched suggestions fall out of favor.
Here are some pointers that I picked up:
Business Value
There is no need to change if it doesn't provide an observable benefit to the organization. Be ready to provide empirical research or reports on the process areas you want to upgrade, and, if possible, prepare a metric collection and analysis plan. For example, maybe your company already tracks how long it takes to fix bugs. If bugs a, b, and c took x amount of time on average before your methods, maybe you can prove that bugs d, e, and f took less time on average to fix. There's a lot that goes into metric analysis in software engineering, and if you're interested in learning more, I would recommend looking into Goal, Question, Metric (GQM).
Talk with Your Peers
Suggesting new ways of doing things can alienate your coworkers, and, as Paul Hiemstra points out, it can get you the reputation of being a know-it-all (nobody likes a know-it-all). Take some time to talk to your coworkers and ask why they do things the way they do. It could be that they have very good reasons, but there's also a good chance that they know that things could be better. Try to make changing processes a team effort coming from within the organization and not as changes being imposed from the outside. For further reading, see organizational culture and cultural assimilation.
Right Time and Place
Too much change too fast will cause resistance. At our small company, we had retrospective meetings every month after we delivered our updates to our customer. This was a perfect time to say "I noticed that we were having some trouble with x this month. I've been looking into it, and I read about a lot of people in a similar situation who had success doing y. Is anyone interested in trying it out?" Rolling out changes one-at-a-time can give everyone a chance to practice the new process and get comfortable with it before trying something new. Also, it may help to roll-out a change when there's a little breathing room and not in the middle of a sprint.
Provide Options
This comes from talking with your peers, and it's pretty basic. Say, if your company doesn't provide version control, don't just say "OK, here's how you install git..." When it comes to updating processes, it's good to provide options. Again with the git example, introduce the organization to version control concepts: what is it and what benefits does it have. Then talk about the different options and how they compare to each other. Don't just jump in with your favorite tool because it's what you're most comfortable with; it's about giving the organization the freedom to experiment and play with different options. Heck, I've had many conversations with coworkers about new tools that started with "Hey, check out this new toy I got!" *demonstration* "Isn't that cool?"
TL;DR
Talk with your coworkers before trying to change how they do things, and be prepared to prove why something is worth changing.
answered May 5 '13 at 23:41
David Kaczynski
191118
add a comment |Â
up vote
7
down vote
up vote
7
down vote
Without going too far into behavioral change theories or other social sciences, I had a similar experience at a software company. I had been there for less than a year, and I found myself with process quality assurance responsibilities. At times, it was awkward trying to integrate new work habits into often undefined processes, and it could also be very disheartening to see my thoroughly-researched suggestions fall out of favor.
Here are some pointers that I picked up:
Business Value
There is no need to change if it doesn't provide an observable benefit to the organization. Be ready to provide empirical research or reports on the process areas you want to upgrade, and, if possible, prepare a metric collection and analysis plan. For example, maybe your company already tracks how long it takes to fix bugs. If bugs a, b, and c took x amount of time on average before your methods, maybe you can prove that bugs d, e, and f took less time on average to fix. There's a lot that goes into metric analysis in software engineering, and if you're interested in learning more, I would recommend looking into Goal, Question, Metric (GQM).
Talk with Your Peers
Suggesting new ways of doing things can alienate your coworkers, and, as Paul Hiemstra points out, it can get you the reputation of being a know-it-all (nobody likes a know-it-all). Take some time to talk to your coworkers and ask why they do things the way they do. It could be that they have very good reasons, but there's also a good chance that they know that things could be better. Try to make changing processes a team effort coming from within the organization and not as changes being imposed from the outside. For further reading, see organizational culture and cultural assimilation.
Right Time and Place
Too much change too fast will cause resistance. At our small company, we had retrospective meetings every month after we delivered our updates to our customer. This was a perfect time to say "I noticed that we were having some trouble with x this month. I've been looking into it, and I read about a lot of people in a similar situation who had success doing y. Is anyone interested in trying it out?" Rolling out changes one-at-a-time can give everyone a chance to practice the new process and get comfortable with it before trying something new. Also, it may help to roll-out a change when there's a little breathing room and not in the middle of a sprint.
Provide Options
This comes from talking with your peers, and it's pretty basic. Say, if your company doesn't provide version control, don't just say "OK, here's how you install git..." When it comes to updating processes, it's good to provide options. Again with the git example, introduce the organization to version control concepts: what is it and what benefits does it have. Then talk about the different options and how they compare to each other. Don't just jump in with your favorite tool because it's what you're most comfortable with; it's about giving the organization the freedom to experiment and play with different options. Heck, I've had many conversations with coworkers about new tools that started with "Hey, check out this new toy I got!" *demonstration* "Isn't that cool?"
TL;DR
Talk with your coworkers before trying to change how they do things, and be prepared to prove why something is worth changing.
answered May 5 '13 at 23:41
David Kaczynski
191118
Without going too far into behavioral change theories or other social sciences, I had a similar experience at a software company. I had been there for less than a year, and I found myself with process quality assurance responsibilities. At times, it was awkward trying to integrate new work habits into often undefined processes, and it could also be very disheartening to see my thoroughly-researched suggestions fall out of favor.
Here are some pointers that I picked up:
Business Value
There is no need to change if it doesn't provide an observable benefit to the organization. Be ready to provide empirical research or reports on the process areas you want to upgrade, and, if possible, prepare a metric collection and analysis plan. For example, maybe your company already tracks how long it takes to fix bugs. If bugs a, b, and c took x amount of time on average before your methods, maybe you can prove that bugs d, e, and f took less time on average to fix. There's a lot that goes into metric analysis in software engineering, and if you're interested in learning more, I would recommend looking into Goal, Question, Metric (GQM).
Talk with Your Peers
Suggesting new ways of doing things can alienate your coworkers, and, as Paul Hiemstra points out, it can get you the reputation of being a know-it-all (nobody likes a know-it-all). Take some time to talk to your coworkers and ask why they do things the way they do. It could be that they have very good reasons, but there's also a good chance that they know that things could be better. Try to make changing processes a team effort coming from within the organization and not as changes being imposed from the outside. For further reading, see organizational culture and cultural assimilation.
Right Time and Place
Too much change too fast will cause resistance. At our small company, we had retrospective meetings every month after we delivered our updates to our customer. This was a perfect time to say "I noticed that we were having some trouble with x this month. I've been looking into it, and I read about a lot of people in a similar situation who had success doing y. Is anyone interested in trying it out?" Rolling out changes one-at-a-time can give everyone a chance to practice the new process and get comfortable with it before trying something new. Also, it may help to roll-out a change when there's a little breathing room and not in the middle of a sprint.
Provide Options
This comes from talking with your peers, and it's pretty basic. Say, if your company doesn't provide version control, don't just say "OK, here's how you install git..." When it comes to updating processes, it's good to provide options. Again with the git example, introduce the organization to version control concepts: what is it and what benefits does it have. Then talk about the different options and how they compare to each other. Don't just jump in with your favorite tool because it's what you're most comfortable with; it's about giving the organization the freedom to experiment and play with different options. Heck, I've had many conversations with coworkers about new tools that started with "Hey, check out this new toy I got!" *demonstration* "Isn't that cool?"
TL;DR
Talk with your coworkers before trying to change how they do things, and be prepared to prove why something is worth changing.
answered May 5 '13 at 23:41
David Kaczynski
191118
edited May 6 '13 at 0:55
answered May 5 '13 at 23:41
David Kaczynski
191118
answered May 5 '13 at 23:41
David Kaczynski
191118
answered May 5 '13 at 23:41
David Kaczynski
191118
191118
add a comment |Â
add a comment |Â
up vote
0
down vote
In addition to what was said by Paul Hiemstra:
Xaisoft, at each level of seniority/hierarchy there is a limit to things you can change. A junior developer/engineer can suggest changes to routines, but s/he has to be perceived as a very bright person by almost all stakeholders for the change to succeed. As your experience grows, the scope of feasible changes expands. But the greatest potential to foster changes comes with middle-level management positions.
You have to ask yourself, though:
Is the change I'm proposing worth it?
What will be the negative effects of the change?
Must say that I profoundly dislike change for the sake of change, hate management fads and buzzwords. Anything that upsets the established routine and standard operating procedures in the workplace lowers productivity and is immediately detrimental to the bottom line while positive effects (if any) are delayed. Think about it.
EDIT: As usual, changes are a double-edged sword. If you significantly lag behind the bleeding edge in technology, you very often lose. If you make continuous changes to the way your organization works, people around you will be put under stress and possibly lose trust. The best solution to the technological part of the problem is when employees are used to keeping up with the state-of-the-art. Unfortunately, it doesn't work out for the internal structure and procedures - here, some degree of stability and freedom from superficial management-inspired "reorganizations" are necessary to be productive.
Here are the conclusions:
Please, start changes with yourself.
Gain some respect of your colleagues; do not try to impose revolutions on others unless you are reasonably sure of their success.
Always consider multiple avenues for improvement and perform cost-benefit analysis before coming to a meeting with half-baked proposals.
answered May 5 '13 at 18:20
Deer Hunter
937820
This is why I said "There is more..." in my post. I have only seen the code for 2 days and the things I mentioned were just simple things. It is not so much about those things in particular, but how to convince others objectively on alternative ways. I was merely giving a few examples. I only mentioned coding standards once, but I wouldn't say that any of the things is superficial. Everything affects everything.
– Xaisoft
May 5 '13 at 19:06
I have to say I disagree that anything that upsets the established routine lowers productivity. For example, introducing version control has a low to moderate negative impact on productivity on the front end, with a much higher return in the relatively short-term.
– Amy Blankenship
May 5 '13 at 19:24
@AmyBlankenship - please consider time spent on installing VCS and instilling the new routine. There is a transient negative spike; sometimes it's a purely psychological disruption. Is it swamped out by genuine improvement some time afterwards? Depends... The other problem here is the number of disruptions per unit time. Continuous disruption builds up stress and uncertainty.
– Deer Hunter
May 5 '13 at 19:44
1
Hm, in the situation I had in mind (my own experience) it was already installed, but no one was using it. The other side of the coin is that refusing to make any changes (or doing so too slowly) means that you don't have enough bandwidth to keep making the incremental changes you need to. This is how people are still on ASP classic writing HTML that was out-of-date in 2007, for instance.
– Amy Blankenship
May 5 '13 at 19:49
@AmyBlankenship - all right, different assumptions on VCS. There is no standard on how large change quanta should be because industries and organizations and skill sets differ. If employees are used to keeping up with the bleeding edge, the technology part of the problem is solved; not so for organizational changes (imagine your title, job description and direct supervisor being changed 6 times a year).
– Deer Hunter
May 5 '13 at 20:23
 |Â
show 1 more comment
up vote
0
down vote
In addition to what was said by Paul Hiemstra:
Xaisoft, at each level of seniority/hierarchy there is a limit to things you can change. A junior developer/engineer can suggest changes to routines, but s/he has to be perceived as a very bright person by almost all stakeholders for the change to succeed. As your experience grows, the scope of feasible changes expands. But the greatest potential to foster changes comes with middle-level management positions.
You have to ask yourself, though:
Is the change I'm proposing worth it?
What will be the negative effects of the change?
Must say that I profoundly dislike change for the sake of change, hate management fads and buzzwords. Anything that upsets the established routine and standard operating procedures in the workplace lowers productivity and is immediately detrimental to the bottom line while positive effects (if any) are delayed. Think about it.
EDIT: As usual, changes are a double-edged sword. If you significantly lag behind the bleeding edge in technology, you very often lose. If you make continuous changes to the way your organization works, people around you will be put under stress and possibly lose trust. The best solution to the technological part of the problem is when employees are used to keeping up with the state-of-the-art. Unfortunately, it doesn't work out for the internal structure and procedures - here, some degree of stability and freedom from superficial management-inspired "reorganizations" are necessary to be productive.
Here are the conclusions:
Please, start changes with yourself.
Gain some respect of your colleagues; do not try to impose revolutions on others unless you are reasonably sure of their success.
Always consider multiple avenues for improvement and perform cost-benefit analysis before coming to a meeting with half-baked proposals.
answered May 5 '13 at 18:20
Deer Hunter
937820
This is why I said "There is more..." in my post. I have only seen the code for 2 days and the things I mentioned were just simple things. It is not so much about those things in particular, but how to convince others objectively on alternative ways. I was merely giving a few examples. I only mentioned coding standards once, but I wouldn't say that any of the things is superficial. Everything affects everything.
– Xaisoft
May 5 '13 at 19:06
I have to say I disagree that anything that upsets the established routine lowers productivity. For example, introducing version control has a low to moderate negative impact on productivity on the front end, with a much higher return in the relatively short-term.
– Amy Blankenship
May 5 '13 at 19:24
@AmyBlankenship - please consider time spent on installing VCS and instilling the new routine. There is a transient negative spike; sometimes it's a purely psychological disruption. Is it swamped out by genuine improvement some time afterwards? Depends... The other problem here is the number of disruptions per unit time. Continuous disruption builds up stress and uncertainty.
– Deer Hunter
May 5 '13 at 19:44
1
Hm, in the situation I had in mind (my own experience) it was already installed, but no one was using it. The other side of the coin is that refusing to make any changes (or doing so too slowly) means that you don't have enough bandwidth to keep making the incremental changes you need to. This is how people are still on ASP classic writing HTML that was out-of-date in 2007, for instance.
– Amy Blankenship
May 5 '13 at 19:49
@AmyBlankenship - all right, different assumptions on VCS. There is no standard on how large change quanta should be because industries and organizations and skill sets differ. If employees are used to keeping up with the bleeding edge, the technology part of the problem is solved; not so for organizational changes (imagine your title, job description and direct supervisor being changed 6 times a year).
– Deer Hunter
May 5 '13 at 20:23
 |Â
show 1 more comment
up vote
0
down vote
up vote
0
down vote
In addition to what was said by Paul Hiemstra:
Xaisoft, at each level of seniority/hierarchy there is a limit to things you can change. A junior developer/engineer can suggest changes to routines, but s/he has to be perceived as a very bright person by almost all stakeholders for the change to succeed. As your experience grows, the scope of feasible changes expands. But the greatest potential to foster changes comes with middle-level management positions.
You have to ask yourself, though:
Is the change I'm proposing worth it?
What will be the negative effects of the change?
Must say that I profoundly dislike change for the sake of change, hate management fads and buzzwords. Anything that upsets the established routine and standard operating procedures in the workplace lowers productivity and is immediately detrimental to the bottom line while positive effects (if any) are delayed. Think about it.
EDIT: As usual, changes are a double-edged sword. If you significantly lag behind the bleeding edge in technology, you very often lose. If you make continuous changes to the way your organization works, people around you will be put under stress and possibly lose trust. The best solution to the technological part of the problem is when employees are used to keeping up with the state-of-the-art. Unfortunately, it doesn't work out for the internal structure and procedures - here, some degree of stability and freedom from superficial management-inspired "reorganizations" are necessary to be productive.
Here are the conclusions:
Please, start changes with yourself.
Gain some respect of your colleagues; do not try to impose revolutions on others unless you are reasonably sure of their success.
Always consider multiple avenues for improvement and perform cost-benefit analysis before coming to a meeting with half-baked proposals.
answered May 5 '13 at 18:20
Deer Hunter
937820
In addition to what was said by Paul Hiemstra:
Xaisoft, at each level of seniority/hierarchy there is a limit to things you can change. A junior developer/engineer can suggest changes to routines, but s/he has to be perceived as a very bright person by almost all stakeholders for the change to succeed. As your experience grows, the scope of feasible changes expands. But the greatest potential to foster changes comes with middle-level management positions.
You have to ask yourself, though:
Is the change I'm proposing worth it?
What will be the negative effects of the change?
Must say that I profoundly dislike change for the sake of change, hate management fads and buzzwords. Anything that upsets the established routine and standard operating procedures in the workplace lowers productivity and is immediately detrimental to the bottom line while positive effects (if any) are delayed. Think about it.
EDIT: As usual, changes are a double-edged sword. If you significantly lag behind the bleeding edge in technology, you very often lose. If you make continuous changes to the way your organization works, people around you will be put under stress and possibly lose trust. The best solution to the technological part of the problem is when employees are used to keeping up with the state-of-the-art. Unfortunately, it doesn't work out for the internal structure and procedures - here, some degree of stability and freedom from superficial management-inspired "reorganizations" are necessary to be productive.
Here are the conclusions:
Please, start changes with yourself.
Gain some respect of your colleagues; do not try to impose revolutions on others unless you are reasonably sure of their success.
Always consider multiple avenues for improvement and perform cost-benefit analysis before coming to a meeting with half-baked proposals.
answered May 5 '13 at 18:20
Deer Hunter
937820
edited May 5 '13 at 20:35
answered May 5 '13 at 18:20
Deer Hunter
937820
answered May 5 '13 at 18:20
Deer Hunter
937820
answered May 5 '13 at 18:20
Deer Hunter
937820
937820
This is why I said "There is more..." in my post. I have only seen the code for 2 days and the things I mentioned were just simple things. It is not so much about those things in particular, but how to convince others objectively on alternative ways. I was merely giving a few examples. I only mentioned coding standards once, but I wouldn't say that any of the things is superficial. Everything affects everything.
– Xaisoft
May 5 '13 at 19:06
I have to say I disagree that anything that upsets the established routine lowers productivity. For example, introducing version control has a low to moderate negative impact on productivity on the front end, with a much higher return in the relatively short-term.
– Amy Blankenship
May 5 '13 at 19:24
@AmyBlankenship - please consider time spent on installing VCS and instilling the new routine. There is a transient negative spike; sometimes it's a purely psychological disruption. Is it swamped out by genuine improvement some time afterwards? Depends... The other problem here is the number of disruptions per unit time. Continuous disruption builds up stress and uncertainty.
– Deer Hunter
May 5 '13 at 19:44
1
Hm, in the situation I had in mind (my own experience) it was already installed, but no one was using it. The other side of the coin is that refusing to make any changes (or doing so too slowly) means that you don't have enough bandwidth to keep making the incremental changes you need to. This is how people are still on ASP classic writing HTML that was out-of-date in 2007, for instance.
– Amy Blankenship
May 5 '13 at 19:49
@AmyBlankenship - all right, different assumptions on VCS. There is no standard on how large change quanta should be because industries and organizations and skill sets differ. If employees are used to keeping up with the bleeding edge, the technology part of the problem is solved; not so for organizational changes (imagine your title, job description and direct supervisor being changed 6 times a year).
– Deer Hunter
May 5 '13 at 20:23
 |Â
show 1 more comment
This is why I said "There is more..." in my post. I have only seen the code for 2 days and the things I mentioned were just simple things. It is not so much about those things in particular, but how to convince others objectively on alternative ways. I was merely giving a few examples. I only mentioned coding standards once, but I wouldn't say that any of the things is superficial. Everything affects everything.
– Xaisoft
May 5 '13 at 19:06
I have to say I disagree that anything that upsets the established routine lowers productivity. For example, introducing version control has a low to moderate negative impact on productivity on the front end, with a much higher return in the relatively short-term.
– Amy Blankenship
May 5 '13 at 19:24
@AmyBlankenship - please consider time spent on installing VCS and instilling the new routine. There is a transient negative spike; sometimes it's a purely psychological disruption. Is it swamped out by genuine improvement some time afterwards? Depends... The other problem here is the number of disruptions per unit time. Continuous disruption builds up stress and uncertainty.
– Deer Hunter
May 5 '13 at 19:44
1
Hm, in the situation I had in mind (my own experience) it was already installed, but no one was using it. The other side of the coin is that refusing to make any changes (or doing so too slowly) means that you don't have enough bandwidth to keep making the incremental changes you need to. This is how people are still on ASP classic writing HTML that was out-of-date in 2007, for instance.
– Amy Blankenship
May 5 '13 at 19:49
@AmyBlankenship - all right, different assumptions on VCS. There is no standard on how large change quanta should be because industries and organizations and skill sets differ. If employees are used to keeping up with the bleeding edge, the technology part of the problem is solved; not so for organizational changes (imagine your title, job description and direct supervisor being changed 6 times a year).
– Deer Hunter
May 5 '13 at 20:23
This is why I said "There is more..." in my post. I have only seen the code for 2 days and the things I mentioned were just simple things. It is not so much about those things in particular, but how to convince others objectively on alternative ways. I was merely giving a few examples. I only mentioned coding standards once, but I wouldn't say that any of the things is superficial. Everything affects everything.
– Xaisoft
May 5 '13 at 19:06
This is why I said "There is more..." in my post. I have only seen the code for 2 days and the things I mentioned were just simple things. It is not so much about those things in particular, but how to convince others objectively on alternative ways. I was merely giving a few examples. I only mentioned coding standards once, but I wouldn't say that any of the things is superficial. Everything affects everything.
– Xaisoft
May 5 '13 at 19:06
I have to say I disagree that anything that upsets the established routine lowers productivity. For example, introducing version control has a low to moderate negative impact on productivity on the front end, with a much higher return in the relatively short-term.
– Amy Blankenship
May 5 '13 at 19:24
I have to say I disagree that anything that upsets the established routine lowers productivity. For example, introducing version control has a low to moderate negative impact on productivity on the front end, with a much higher return in the relatively short-term.
– Amy Blankenship
May 5 '13 at 19:24
@AmyBlankenship - please consider time spent on installing VCS and instilling the new routine. There is a transient negative spike; sometimes it's a purely psychological disruption. Is it swamped out by genuine improvement some time afterwards? Depends... The other problem here is the number of disruptions per unit time. Continuous disruption builds up stress and uncertainty.
– Deer Hunter
May 5 '13 at 19:44
@AmyBlankenship - please consider time spent on installing VCS and instilling the new routine. There is a transient negative spike; sometimes it's a purely psychological disruption. Is it swamped out by genuine improvement some time afterwards? Depends... The other problem here is the number of disruptions per unit time. Continuous disruption builds up stress and uncertainty.
– Deer Hunter
May 5 '13 at 19:44
1
1
Hm, in the situation I had in mind (my own experience) it was already installed, but no one was using it. The other side of the coin is that refusing to make any changes (or doing so too slowly) means that you don't have enough bandwidth to keep making the incremental changes you need to. This is how people are still on ASP classic writing HTML that was out-of-date in 2007, for instance.
– Amy Blankenship
May 5 '13 at 19:49
Hm, in the situation I had in mind (my own experience) it was already installed, but no one was using it. The other side of the coin is that refusing to make any changes (or doing so too slowly) means that you don't have enough bandwidth to keep making the incremental changes you need to. This is how people are still on ASP classic writing HTML that was out-of-date in 2007, for instance.
– Amy Blankenship
May 5 '13 at 19:49
@AmyBlankenship - all right, different assumptions on VCS. There is no standard on how large change quanta should be because industries and organizations and skill sets differ. If employees are used to keeping up with the bleeding edge, the technology part of the problem is solved; not so for organizational changes (imagine your title, job description and direct supervisor being changed 6 times a year).
– Deer Hunter
May 5 '13 at 20:23
@AmyBlankenship - all right, different assumptions on VCS. There is no standard on how large change quanta should be because industries and organizations and skill sets differ. If employees are used to keeping up with the bleeding edge, the technology part of the problem is solved; not so for organizational changes (imagine your title, job description and direct supervisor being changed 6 times a year).
– Deer Hunter
May 5 '13 at 20:23
 |Â
show 1 more comment
2
You might find this answer useful workplace.stackexchange.com/questions/9703/…
– Amy Blankenship
May 5 '13 at 19:35
4
@gnat similar but not duplicate, this covers a much broader scope of how rather than just should i. Answers to this can have a scope larger than just to 'newcomers' i feel
– Rhys
May 5 '13 at 20:29
Be very careful not to end up insulting your co-workers. Consider that there can be very good reasons for things being the way they are. Learn those, and then consider what low hanging fruit might actually help your coworkers . Those things will most likely be very welcome.
– Thorbjørn Ravn Andersen
May 6 '13 at 7:27
@SpikyBlue per my reading, answers in suggested dupe indeed focus on how instead of should I (and this feels right to me)
– gnat
May 6 '13 at 7:31
1
if you want other people to buy your idea you need to sell it (pun intended)
– ratchet freak
May 6 '13 at 10:22