9

This question already has an answer here:

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?

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
13

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.

  • Choosing between bottom up or top down would depend on the geographic locality as well as the company culture. For example, I've heard that in Asia, you should almost always do bottom up, but in the USA, you have to take into account several factors, so there's no clear-cut guidance. – YetAnotherRandomUser Oct 11 '18 at 1:57
11

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 :).

7

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.

0

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.

  • 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

Not the answer you're looking for? Browse other questions tagged or ask your own question.