The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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 :).
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:
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).
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.
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.
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?"
Talk with your coworkers before trying to change how they do things, and be prepared to prove why something is worth changing.
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.
