In almost every team or organisation that you work in, you will see habits or behaviours that you wish you could change or improve. Whether it’s a tool or framework that you believe could enhance teams' productivity, or adapting a process to reduce bottlenecks and allow you to deliver more value to the business, every passionate developer, technical lead or CTO has ideas for how they could improve things.
But with a multitude of departments, backgrounds and skillsets, how can you persuade your colleagues to accept the change that you’re advocating? How can you ensure that the changes that you are able to make become successful? How can you make these changes permanent to prevent others from returning to the old status quo?
In order to understand how to advocate for technical change within your team or organisation, you need to identify the potential pain points and challenges that you could face. If you are able to anticipate these barriers before you encounter them, you can make a plan to overcome them.
In order to advocate for technical change within your team or organisation, you need to identify which of these sceptics may cause a problem for you. You should develop a plan for how to persuade them, or nullify their hindrance to your proposal.
You also need to identify the scope for the idea that you are proposing, to ensure that your ideas do not die before they have had a chance to bear fruit.
It is possible that the change that you are advocating is so obvious, well-planned and easy to implement, that you will see success from it instantly. However, it is more likely that there will be a period of adjustment and learning, and maybe, in the short term, the change that you’re proposing is creating more work for you and your colleagues. This period is often referred to as Death Valley: performance and value dip before your changes have had a chance to positively impact your team.
So long as the proposed changes are well planned, you should start to see improvements in your team and organisation. Suddenly you and others will see the success of your ideas. It is your job to calculate the size and magnitude of the change you want to implement, before acting on your proposal. You do not want your change to be such a severe pain point that it is abandoned before it has had a chance to improve your team or organisation and die in Death Valley.
Be sure that the proposed changes are small enough that you will see value from them before people become frustrated by them, and that they can be implemented within the scope of your own influence so that you can make sure that they receive full commitment before they are retired.
To plan properly the implementation of your proposed change, you need to understand the structure of the team or organisation in which you are trying to integrate it. If you do not know exactly how the team or organisation operates, you cannot be certain that your change can be integrated properly. Any half-hearted implementation of your idea may have a detrimental effect on its success.
Furthermore, you cannot be sure that your change is what the team needs. There may be behaviours of the team which are in direct conflict to what you’re advocating or even alternatives that are serving the same purpose as your proposed change. What exactly you need to understand about the structure will depend on the scope and size of your ideas; who will be affected and how?
Understanding this well can also be helpful when it comes to identifying the possible barriers or pitfalls that your idea may face. If you understand the framework to which your change will be made, you can better identify the sceptics and problems which may derail it, and plan accordingly.
A key part of advocating technical change within your team or organisation is establishing a clear reason for the change. Depending on the amount of friction or discomfort that your proposed change causes to your colleagues, it is likely that you will face a degree of challenge from sceptics within your organisation. You need to make sure you have a well-defined narrative to justify the change that you are proposing and convince those who might block it.
In his 8-Step Process for Leading Change, John Kotter highlights the importance of “creating a sense of urgency”. If you haven’t already, identify what potential issues or repercussions your team or organisation may face in the future if you do not change something now. Make this the key narrative behind your proposed change.
With a clear reason for change defined, you can make others see the importance of acting on this immediately, and in doing so you will go some way to convincing your sceptics that something needs to be done.
Once you have clearly identified the issue within your team or organisation, it is time to define your plan of how to address it. The better you have defined your reason for the change, the easier this should be. Firstly, it will force you to think exactly how the change that you are advocating relates to the problem that you have previously highlighted. It will also provide context to your vision when it comes to your colleagues understanding and processing it.
At this stage, you need to identify the core values of the change that you are proposing. Exactly how does it address the reason for the change? Make sure this is well-defined and understood by you and anybody else who may be championing your ideas. The better you define this yourselves, the easier it will be to communicate and convince others.
Having identified the problem that you want to address, and clearly defined how your idea for change can resolve it, you can begin to think about how you want to communicate this idea to others. This is your first chance to face the sceptics head-on and convince them: educate the uninformed, energise the herd, reason with the cynic and allay the concerns of the burned.
You need to ensure that your vision is as well understood by your audience as it is by you. Set out the context of your reason for the change, simplify your proposal to its core values and ensure that these points are clearly communicated.
If you are trying to convince managers or colleagues from non-technical backgrounds, translate the key values of your proposed change to the perspective and language that they will understand. If you are advocating the use of TDD to non-technical management or stakeholders, don’t preach its positive impact on the micro-design of your code, or how it acts as a form of documentation. You should explain how testing your code well now will prevent bugs emerging in the future in the future, and should any issues arise, your tests will save time when trying to resolve them. Explain how the technical change that you’re advocating translates to business value.
In order for people to welcome your idea, they need to fully understand it. It is your job to communicate it as simply and clearly as possible, and minimise any possibility of your colleagues misinterpreting your intentions. Anticipate what questions people might have about your proposed technical change and address it in advance.
Naturally, no matter how much you try to predict and address the issue, there will be people within your team and organisation that will oppose your ideas, or at the very least analyse and criticise it. Change always causes friction and, no matter how well planned your idea is, people will not readily change their established routines just because you want to. There will always be those who are suspicious of you or your idea, and some will simply be perfectly comfortable within the status quo.
It is important that you don’t become agitated or overly defensive when faced with criticism about your proposal. Remember – as long as the criticism that you face is measured and fair – that it is most likely not a personal attack on you, and that those with questions may not even disagree generally with the change that you’re advocating. It is natural for people to raise concerns when it comes to changing behaviours or habits. You should respond to these concerns with openness and honesty. Becoming aggressive in response will make people less likely to accept your ideas.
Listen carefully to what people are telling you and try to understand their point of view. If you don’t believe that their concerns are relevant, demonstrate that you have understood their point and explain why you believe that. If the questions raised are valid, discuss with them how you think you can overcome the issue.
Although you might feel very attached to your idea, remember that iteration and improvement is the key to getting things right. Any feedback that you receive could be important in developing your proposal further. You should therefore listen carefully and evaluate what’s being said.
The context of all technical changes that you might be proposing is different, so the approaches to advocating them will differ too. You need to work out what influence you have within the team or organisation that you’re trying to change and you should decide what scope of technical change is actionable within your remit.
Do you need permission from above before you start implementing the change that you’re advocating? It may be that you can start implementing change within the scope of influence that you already have. For example, you could start to research, learn and practise the idea that you want to implement. From there you can identify and address any drawbacks or weaknesses with your idea before anybody else has a chance to bring them up. You could start to clarify anything that you are unsure about and develop your idea before increasing the scale of the change. You will increase your credibility as the champion of your idea if you have practised what you preach.
For example, if you’re advocating TDD within your team, you don’t necessarily need to wait for your manager to accept the idea and dictate it to the team. Maybe you can start on some of your team’s tasks. If you’re pairing at the same time, you have a chance to show your teammates why you want the team to do TDD and convince them to support you and the idea.
Starting to implement technical change by your own influence and resources can be a good way to start, but for many ambitious and passionate developers, simply changing the behaviours within your small team is not enough. If you truly believe in the change you’re advocating, you will probably want to see it accepted organisation-wide. Alternatively, it may be that the change cannot be implemented in a guerrilla fashion, due to resource constraints or required permission.
How can you convince those gatekeepers of technical change to listen to and accept your proposal? Particularly when your influence within the organisation may be minimal, and you might not have any contact with those that you need to convince. One way is to identify those that lead to change within your organisation. Who is at the forefront of evolving the company? Who are the key stakeholders when it comes to the change that you’re advocating? Do you have any contact with any of these people, even indirectly?
John Kotter suggests building a guiding coalition for the change that you’re proposing. You can recruit colleagues with more influence within your organisation to support you and the idea, and maybe those people have access to the gatekeepers who need convincing. A cross-functional coalition of employees from different levels, departments and skills help increase your scope of influence and the size of your audience, increasing your reach and the chances of your idea being listened to. It also diversifies opinions when it comes to refining the plan, so when it comes to persuading the key people, you have a stronger proposal to submit.
At Codurance we use the concept of Initiative Circles: these are an open invitation to join a team of three or more employees to help develop, champion and take responsibility for a change that they want to see implemented, and anybody can start or join one. These were introduced at Codurance as a way of decentralising decision-making (Codurance’s flat structure means that scopes of influence are not such an issue), but the general concept could help you in any organisation with a traditional structure. A group of passionate people with different levels of influence can help your proposal gain momentum at a different scale.
We discussed how simplifying your idea for change can be useful when trying to communicate the change that you’re advocating to others, but it can also help minimise the disruption of the change that you’re proposing. As highlighted before, the bigger the change that you attempt to implement, the more severe a pain point it becomes. The bigger the disruption it causes and the more time it takes to fully implement, the more time it will spend in Death Valley, and the more likely it will be abandoned before it starts to deliver value.
Prioritise changes that will be easier to implement, and will bring success sooner. There will be less friction within the team and there will be less chance of frustrating your colleagues. Furthermore, smaller incremental changes are far easier to rollback, should they not work out. You will find it much easier to convince your colleagues to accept the changes you’re proposing, should you make it clear that they’re simple to revert.
If it is not possible to break your proposed change into small steps, try implementing it in a small part of the organisation, or on a trial or part-time basis e.g. your development team performing its tasks with TDD one day a week. It requires little commitment to the technical change, making it easy to rollback if there are any issues. However, you need to find the balance between making your changes incremental and easy to revert, and ensuring that there is a good level of commitment to trialling them properly.
Simplifying and breaking down the technical change that you’re advocating means that you can secure quick regular victories, which is also beneficial. Virginia Satir’s Model of Change looks in more detail at the J-curve above and puts particular emphasis on the importance of celebrating success when you reach the New Status Quo. This is the period when new behaviours have become habits or norms and the initial disruption has been overcome. Celebrating reaching this stage in the change cycle can help people become more receptive to future changes. By implementing changes in small steps, you can reach this period of value sooner, celebrate success more frequently and pave the way for more future change.
Furthermore, for you and the other members of your guiding coalition, this is a chance to celebrate shared success, build momentum and consolidate together. In his 8-Step Process, Kotter highlights the importance of short-term wins for both tracking progress and rewarding and energising those championing the process of change. Use these small achievable victories to build momentum and accelerate as you look to become more ambitious with your change. If there is still opposition against the change that you’re advocating, highlight these successes as proof of its value. Delivering quality and value regularly builds trust.
Reaching these periods of success also provides regular opportunity to iterate and reflect on the changes more frequently. This is a chance to draw parallels between the new behaviours that you have advocated, and the success and value-added to the team or organisation.
At this point, you should justify the changes that have already been implemented so that they become strong enough to replace old habits permanently. It is also a chance to learn from the successes and failures of the previous iteration, and start planning your next steps together as a coalition. At this stage, you can also invite others from outside your coalition to offer feedback and help you develop the plan. The feedback you receive will be valuable and it will also provide a chance to recruit more colleagues to champion your idea.
Scrum-style retrospectives within your guiding coalition can be a great way to evaluate what did or didn’t work in the previous iteration, and develop actionable ideas to take forward into the next one. A more general request for comments from those other employees affected by your change can be a good way to receive more diverse feedback.
Advocating for technical change within your team or organisation can be difficult. There are many reasons why you might face opposition from colleagues when you try to make significant changes to habits and behaviours. It might be that people don’t like the sound of the change itself, or that people don’t trust you or your motives for changing things. It could also be that the changes you’re proposing are just too significant and ambitious to be implemented painlessly.
It is important that you therefore do your best to anticipate the barriers that you might face before you propose these technical changes and adjust your approach accordingly. Communicate your ideas clearly and accept criticism when you receive it. Recruit fellow champions when possible to increase your influence and diversify opinions while you plan. Try to make the change as incrementally as possible to reduce friction, and respond to feedback while developing your idea.
