Change is hard, scary, possibly risky and uncomfortable. But change is also great! It stops stagnation to irrelevance, it stops boredom, it can lead to great new discoveries and it definitely is inevitable.
I’ve wanted to write this blog post for a while now as I’m a big fan of change, don’t get me wrong it makes me uncomfortable and worried just as much as the next person but it’s one of the best tools I know for doing something I really enjoy: helping others get better at what they do and learn new things.
What kind of change?
I work as a developer so this post will discuss changes in software development teams, I’d be very surprised if what I describe here doesn’t or can’t be applied to teams in other areas of business or even in personal life.
I will be focusing on changes to development practises, processes, languages, supporting technologies and tooling.
Need for change?
This is the easy part. Can you honestly say that there is nothing you would like to change where you work? Nothing that could be done better? More effectively? Faster? Made easier or with more thought to how to make sure you don’t fall behind as the rest of the world around you changes?
No? Either you’re lying (it’s ok, I didn’t believe you anyway) or you haven’t thought about these things and looked into everything that has changed and why and how others have made changes. As you work, think about why you’re doing things the way you are, why you’re using the tools you’re using, why you have to do xyz in that order and not just xz.
If you’re not sure, ask, the worst that can happen is that you get a long, intricate, history lesson, the best is that you get “because that’s the way we have always done it”. Why’s that the best? Because it’s clearly something that has stagnated and could be investigated to see if there is a better way.
Still don’t believe there’s anything that needs changing in your workplace? Drop me a line on twitter @efexen as I really really want to hear from you!
Who can change things?
You can! Technical Directors, Lead Developers, Technical Leads or whoever all do this or should be doing this. But the truth is (and it took me a while to realise this) everyone can do it, it doesn’t matter if you are the newest junior hire or the most experienced person around.
If you feel you can’t champion change yourself (you can, you just don’t know it yet) you can still help by embracing it and supporting those who are changing things, this can be as valuable as leading the charge and we’ll talk a little more about this later.
Resistance to change
Resistance to change is extremely common and quite understandable. It leads to development teams full of developers who are counting the minutes till they can go home, it leads to products that get left behind when new competitors come along with motivated teams using new technologies, it leads to your company not being chosen to work on a project as you don’t have the know how anymore and it leads to employee dissatisfaction, mainly due to lack of personal growth.
So why the resistance? It tends to be either fear or laziness.
Fear can be the fear of making a bad choice, fear of losing your edge, fear of having to work a little harder initially, fear of not succeeding to change things and wasting of time and effort.
Fear of change is a normal human reaction and the way to deal with it is to mitigate the fears.
Laziness is no real excuse and as part of changing things these people will become easier to spot for everyone, including the management, they hate laziness and will want to deal with it swiftly as it is damaging to the rest of the team.
Unfortunately laziness has no simple solution but can be combated by improving motivation before changing things.
You might have a mix of these issues in your team and it is important to try and recognise what they are so you can address them effectively when you are trying to create change. You also need to be sensitive to why people might be resistant, we’re all people with lives, we’re in different stages of our careers and with different amounts of time and energy we can realistically muster up. Someone might appear resistant at first as they just do not have the time due to family commitments or another is 2 years from retirement and just wants an easy life until then.
These are all difficult issues but by identifying what they are it will be easier to judge how much you can hope to achieve and how to convince others.
Start small, easy and often
If your team is resistant to change and stagnant; starting out is the hardest part and the most important part. We need to remember the bigger goal is not to change anything in particular or to shake things up just for the hell of it. The real aim is to create a culture of change.
To introduce change easily, start by doing something small and something with an easy win.
For instance if you’re using MySQL always for your projects, why not suggest you try something like MariaDB for your new project?
What makes this a great starting change?
It requires no change to how you work, no one needs to learn different way of querying or nuances like case sensitivity or other oddities so it is not very disruptive.
It’s a drop-in replacement for MySQL so everything should just work, you can quickly test it out without spending lots of time.
There’s a ton of documentation to support your arguments and if you’re so inclined you can run some performance tests to back it up.
Granted it’s a rather large change but it should be an easy one. What if we thought smaller?
How about changing the text editor you are using or installing a new plugin? If you spend a lot of time writing HTML something like Emmet could blow your colleagues minds. Working in Visual Studio? Try the free trial of the ReSharper productivity tool from JetBrains. Worried about silly security mistakes in your Rails application? Run the Brakeman Scanner and see what it comes up with.
If you’re worried about the cost implications, don’t be, look first at all the awesome open source tools at your disposal, if you find something great you may even save your company money — way to be a hero ;)
What about looking at the way in which work is done? Do you find yourself in pre-meetings? Are they really necessary? Do you find that there’s not actually enough communication and you often don’t know what’s going on, should you therefore introduce a regular catch-up or stand up? Do you have to remember to manually do something every time you do a check in — can that be automated?
Some of these are easy small changes as they only impact you initially, but what is then important is that if you like the change, you talk to others about it, get them to try it for themselves and see if you can convince them to start by making a small change.
Once you’ve implemented a small change, if it’s a good one, you’ll very quickly forget about it and wonder why you didn’t always just do that. At that point it’s important to introduce another one, keep the initial momentum going, keep it small again.
If you’ve managed to convince your colleagues or managers about the initial change, this second one will be faced with a lot less resistance.
If you didn’t manage to convince anyone and just made the change for yourself that’s fine as well, just add another change to your own way of working and keep talking about it, at some point your colleagues will start wondering how you’ve started doing things faster and/or improved the quality of your work. That leads me to my next point.
Do things yourself
When you want to introduce change you need to convince others of why it’s a good idea, the best way to do this is to educate yourself as much as possible on the change you want to introduce. If it’s a new technology to your environment, read posts both for and against it so you have good answers when people ask why the change should happen and you can then anticipate what kind of counter arguments you are likely to hear and whether they have any merit or not.
If possible, start doing it yourself, the important thing is to keep doing it, if after a while it turns out it was a bad idea, move on and try something else.
Some changes you obviously can’t do by yourself so then you need to…
Talk about it
Start talking about changes, not by attacking what is currently being done, not by shoving it in everyones faces all the time but by asking other peoples opinions of it, it could be that it was already considered or even tried and not adopted for one reason or another. Do those reasons still stand true today?
If you enthusiastically talk about new things, it gets other people interested and if you’ve done your research, and even better if you’ve been doing it for a while already you can then start persuading others to look into what you’re doing.
Talking about it early and with as many people as you can find will quickly prevent you from running into potential issues that the change might bring along, for instance do you have an agreement you only use certain technology? If so, changing it might be harder and you will have to gather a lot more support from others but if you believe that it is the right thing to do, can the agreement be rewritten?
If your company culture allows for it, do a short presentation about it. I’ve done this in the past to get people talking about the technology. I’m not a great public speaker and you don’t have to be one either, just a couple of simple slides with your thoughts on it. If that’s just not possible, put together an email for your team and see what discussions it sparks.
The important thing to remember is that you’re NOT telling everyone what should be done, you’re not even telling them that your suggestion is better than what they already do.
What you’re trying to do is start conversations.
Get Others Involved
By talking about your changes with everyone, you might find people who have thought about these things at length before but for various reasons have not brought them up or have been unsuccessful in affecting change already. Everywhere I’ve worked, I’ve found people who are receptive to changes, either because they want to but haven’t been able to find a way to go about it, or they’re just not the kind of people who want to rock the boat.
If what you want to change is a good idea I can promise you will find people who agree with you and will welcome the change with open arms.
Finding other people who want to change things is great, you can then start sharing ideas together, they can tell you when the idea you have is a poor one or too risky. They will always show up to your presentation about a new technology or respond to your email, back you up in a meeting, whatever is helpful. They might also have insights that will help you figure out how to convince everyone else.
Keep changing
Once you’ve built some momentum, keep going. But be careful not to over do it, there’s a fine line between making sure useful changes are happening and getting on everyone’s nerves because everything is changing to fast to keep up. Yes, there’s a lot of things that can change, but let each alteration bed in before you add a new one.
How often you can change things and how big the changes can be depend greatly on the type of organisation you work at.
If you are working at an agency this is quite easy, make small changes for every new project you start. The key here is to make sure you don’t change too much, maybe change one of the gems or external libraries you are using, change how the team communicates with the Project Management team or change how your CSS code is structured for the project.
By the end of the project everyone should be entirely used to the change and we can introduce another one, if you do a lot of projects, that equates to lot of small changes that makes a big difference to the team as a whole.
If you are working on an existing codebase things get a bit tricker but not impossible, it’s hard to convince people that rewriting the whole thing in a different language is a good idea (it rarely is).
How about introducing some new code patterns for some of the new features being implemented? On one hand, I believe following the existing patterns of a project is a good idea but that can also mean that you might be doing poorer work just to satisfy the shortcomings of the previous language version or outdated design. The key here again is changing things little by little. Maybe leave all the old code alone but when that new feature request comes along that has a clear separation from the core of the codebase, why write it to be the same age as the rest of the system? Make sure it’s a little bit better.
If you are working in an agile environment, why not make a small change every 2–4 sprints to start with?
Don’t be a troublemaker
You might think I’m trying to incite a riot here? Absolutely not, the important thing in doing all of this is to get everyone moving slowly, if there is a lot of resistance you need to be patient, do it slowly until those opinions start to change, you might even get to the point where someone needs to hit the brakes a little, make sure you are prepared to do this.
I’ve talked a lot about doing things yourself and changing things often, but make sure you talk to others about these changes and slow down even more if you have to, it’s the culture of the team you want to slowly change in the end.
If, after all your efforts, you find yourself in a team where nothing is changing, everyone is strongly opposed to any change and you’ve tried to become the champion of change without any effect, maybe it’s time to find another company to work for?
Originally published at blog.fxndev.com.
