Helping an organization to adopt new technologies is hard, as I’ve discovered to my peril on multiple occasions. I’ve summed up a few obstacles below, along with thoughts on how to navigate.
1) Cultural Norms
Culture is the human operating system that runs within organizations. Cultural norms are the rules by which it operates.
Cultural norms help people understand what to expect, providing reassurance against uncertainty and stress. They provide the psychological safety that conversely allows for experimentation and new norms to evolve.
Previously, I hadn’t understood that technology choices are cultural norms that cannot be overcome by making straightforward statements on technology X vs technology Y. Cultural norms may sway and bend, but they do not break easily. Sudden and large-scale change will often be met with fierce and entrenched resistance.
To introduce a technical change such as new language or different programming approach, we must win trust over time. We do this by showing that the new tools are complimentary to existing skills and experience, that will enrich rather than change for change’s sake.
Technology is just tooling, and should never be imposed top-down, or coerced bottom-up by stealth. No matter how good the tech is, people will fight you all the way.
2) The business
I’ve been there, wanting to introduce a cool new piece of tech, then the CTO suggests that my idea is just a “technology searching for a problem”.
Businesses crave predictability and R&D for the sake of it is going to have a hard time succeeding.
Therefore, we need to always be showing tangible gains for the business, demonstrating that it’s possible to beat the averages, by doing something new.
I’ve noticed that when a team is delivering successfully for the business, to the extent of winning industry awards and achieving a fantastic reputation, then questions of the underlying technology are rarely made. What gets talked are the broader themes for success such as it was ‘data driven’, and how it was built in such a ‘flexible way’.
3) Orthodoxy
I’ve been guilty of perpetually ramping things up, pushing through a number of new associated technologies as though it’s a closing window of opportunity. I’ve tried to conquer nay-sayers with deus-ex machina, but the response is often: ‘what the hell is this now, on top of the other thing!’, ‘no way!’.
Striving to achieve too much, too soon can risk change fatigue, and has people reaching back for the current orthodoxy.
This can be compounded if the organizaton is hit by broader challenges, such as economic, or high-level policy changes. When this happens then there is a human want to batten down the hatches.
For change to survive long-term, after the initial period of adoption, then technology needs to remain discrete and low-profile.
You also need the bridge-builders and long-term system-thinkers, who can evolve standards and existing governance, to give the new technologies roots.
4) Management-Led Engineering
So often in our industry, there exists a culture of process-heavy micro-management by non-technical project managers. Sometimes a reboot is needed.
One such approach is ‘Programmer Anarchy’, which is ripping off the band-aid and fully entrusting developers to meet the business goals, to create an engineering-led culture.
This is a high risk/reward approach requires strong senior leadership to provide air cover and to maintain the course. Buy-in is needed from all the engineers to take more responsibility.
Many initiatives will die out over time, sapping energy and creating rifts in the process. There is also the risk that the technology choices that survive the initial period of anarchy, might not be the ones that fit the organization long-term.
And yet over time, the bigger picture can still win out. If the company ends up with a better culture using more modern, efficient and productive technologies, with an empowered and trustful team at the end of it, then it will be have been worth it.
5) The Ivory Tower
When technology choices are made from a distance, disconnected from day-to-day pains and opportunities, it becomes difficult for better approaches to win favour. Making the case for change is hard when the decision-makers aren’t close enough to the practical realities of their chosen tech.
The term ‘Platform Engineering’ is in vogue and for good reason.
This is a move away from command and control ivory-tower dictatorship, to offering genuine support and aligning with developers’ needs in a bottom-up fashion. It wins hearts and minds by helping developers with tooling, documentation, and integrations, allowing developers to concentrate on adding business value.
Empowerment rather than control.
Conclusion
Helping companies to adopt new technologies is not easy. Make sure it’s not a hospital pass by ensuring that a) there exists a culture of trying new technologies and continuous improvement, b) you’re aligning with the business early, c) play the long game and remain discrete, d) think carefully before triggering a revolution, and e) it’s all about support/empowerment.
