So you’ve found the latest and greatest software development technology stack. You’re excited and passionate about it. You know if you could convince your team to migrate your software platform to this new technology it will save them time and money.
You may be promoting it’s use, but it seems like no one is listening. It seems like you’re calls for adoption are landing on deaf ears. You may be right, and your arguments may be completely rational, but your team is just looking at the hurdles to adoption.
I’ve consulted with a number of organizations on technology stack evaluations and migrations. An organization may see the potential benefits of technology adoption. Unfortunately they are quickly dissuaded by the risks.What will it cost us? How will it affect our current priorities? What if the effort doesn’t pan out?
Remember that all the success they’ve had so far has been with the current technology stack. Even if it has warts, it works. If you want to convince your team, they need to see how the investment will pay off and they need to feel like the risk of adoption is low. Here are some tips to do just that.
#1 – Why do We Need a Change
It’s great being a catalyst for change. But, there has to be a reason or the effort just won’t make business sense to anyone. I’m sorry, but this technology is really fun and interesting is not going to convince anyone. You need to develop a persuasive argument to push decision makers to allocate budget to an initiative.
My recent article on 6 Symptoms your Technology Stack is Holding you Back is a good primer for building this argument. Once you have established the reasons for a change, it’s time to start showing how, how much it will cost, and how much it will save.
#2 – Build a Proof of Concept
Start with my Technology Adoption Checklist. This list will help you build a strong case for the current and future viability of the technology within your organization.
A big part of this evaluation is building a proof of concept. The proof is in the pudding. It’s hard to argue with working features. When you can walk through the code, demonstrate the solution works, and show how it will save the team time and money, you have a much stronger argument.
This requires dedication on your part. If your company has a 20% rule, building a proof of concept solution is the perfect utilization of that time. If they don’t, you can recommend they allow you to spend the time. But be prepared, you may have to spend your own time recreating or developing a new set of features with the technology stack.
#3 – Make Learning Easy
Don’t assume that anyone on the team will be as passionate about learning a new technology as you are. The easiest way to grease the wheels of change is by making it easy for them. Many people just want to learn by osmosis.
There are several ways to do this:
- Make your example code easy to follow and as clean as possible.
- Document what you’ve done so it makes sense to someone unfamiliar with the technology.
- Create a learning guide that points them to the most up-to-date and useful documentation.
- Hold Lunch and Learn sessions where you present the technology to others.
Building disciples of your technology that will back you up will certainly help your argument.
#4 – Show a Clear Migration Path
Don’t create an impediment to the effort! It should be obvious how the team would migrate to your solution. Show clear examples of the before and after. Document the steps to migrate a general feature.
Is a full-scale migration really necessary up front? It may be possible to implement new sets of features, or a new application, with the new technology stack while continuing to support the existing platform. The existing platform can be migrated as time allows or once the new platform has fully solidified.
#5 – Estimate the ROI
Management is going to want to understand the cost of the effort and the ROI (return on investment). Once you have followed the previous steps, you should have a pretty good idea of how the technology stack will save time during development of a feature. Use this to create a rough percentage of the expected time savings.
Now we can create a simple formula for determining the expected cost savings:
X (number of developers on team) * Y (Avg Salary) * p (percentage of time saved) = Yearly Return
The number of developers on your team multiplied by their average salary multiplied by the percentage of time saved gives you the yearly return on investment. If you don’t have access to the average developer salary at your company, you can make a safe estimate by looking at your salary compared to industry averages and extrapolate from that.
The next factor is the time estimate and cost of the migration. Adopting a new technology stack will always have the cost of training and getting past the learning curve. The extent of the total cost will depend on whether a full scale migration is necessary.
If a full scale migration is necessary, be prepared with numbers based on your experience with the proof of concept and the migration path. In either case, the Yearly Return vs the cost of the migration will determine how long it takes for the effort to start paying dividends. This is what management wants to know.
#6 – Set a Meeting with the Decision Makers
You have now built a convincing argument and spread the word among your team, it’s time to meet with management. Find out who’s buy in you need to get the effort blessed and setup a meeting.
If you have created any important disciples along the way that could help your argument (e.g. senior developers, team leads, architects), include them in the meeting. Their buy-in could go along way toward convincing key decision makers.
Preparation is key! You will need to defend your position and provide convincing arguments. Depending on the personalities involved, this conversation can be challenging. All that said…
#7 – Be Ready to Hear No or Just Not Now
Sometimes the timing just isn’t right. You may have successfully shown that the benefits far outweigh the cost, and you’re arguments may be convincing. Unfortunately, there may be other variables that are outside of your control.
Important new customers may be coming on that will require quick development of new features. The timeline of the migration may be too long for what’s currently in the development pipeline. The organization doesn’t currently have the budget to support the cost.
There are many reasons you may hear no or simply not now. Don’t get defensive or angry. Maybe the timing will be right in a few months or a year. If not, simply see the effort as a stepping stone in your career. You gained valuable experience with a new technology and learned how to build a convincing argument along the way.
If you enjoyed this article, please share it! For more useful content, you can subscribe to our newsletter below.