Implementing new tech in your company is tougher than you think
Just last year, there was a clear need in one of my companies to bring in large-scale feature flagging. We had our own hand-rolled attempt at feature flags, but it was weak sauce, a crummy and rushed attempt to create something which is not in our core competencies. Rather than bother with this pile of drek, we opted to find a more standard solution. We needed to introduce a more standardised solution for feature flagging across the entire company, one which the company and our platform could grow into.
So I was issued this challenge. Bring in a robust feature flagging architecture for the entire platform. And in a lot of IT companies, I know how this would go. The expectation with IT types is often ‘Build it and they will come’. That is, if some team pops in this new technology, so useful and nifty needed, then everyone will just magically come to love and more importantly to use it.
Yeah, let me pop that collective bubble right now. I have been working in IT forever, and in all my years, this invariably never works out. If you are working in an IT company of more than five people, chances are the ‘Build it and they will come’ mindset is self-imposed delusion. You may very well build it, but that is no guarantee that anyone will come. Quite the opposite, actually.
People hate change (and why this matters)
People dislike change. Why? Because change is discomfort. Change means my having to do something new; to learn something new, to struggle with my brain’s natural tendency to favour what came before. Change means there is risk, or uncertainty. Change is, from an evolutionary perspective, usually bad. Change is a vicious predator, or a poisonous plant, or a dried-up riverbed. People avoid change in most cases because it doesn’t feel good to deviate from what one knows and does regularly. In a company, where one person might grumble a bit over a change; the larger the organisation, the more the resistance grows to change.
As you implement new technology in your organisation, you must prepare from this viewpoint. Assume that people do not want to change, that new tech or tools might excite the imagination of leadership, or even of the implementer, but it does not appeal to the whole. If you start from this premise, then the path to a successful implementation and rollout of a new technology is clear.
Your job as the implementer is to remove all barriers to entry, all excuses which might be raised, all possible paths to failure to this new technology.
Steps to success: Implementing new tech
In my case, the first job was to work out which feature flagging solution best met our needs. I did this by including stakeholders from each of our various disciplines, and we reviewed a series of existing solutions in the market, including our hand-rolled drek. This was step one: Get people talking about it. These few people then spoke with teammates, even if they were griping, and that talk (while some of it negative) got the conversation rolling.
Once we decided on a feature flagging solution provider (we went with LaunchDarkly), the next step was to work out how it would be used. This is probably one of the biggest lessons to take away from this.
You need to understand HOW the new tech will not only affect one portion of your business, but how it will impact your business from start to finish. You must document exactly how the technology will fit into your organisation, as if it already were in play.
This was probably the biggest body of work. This meant many days working with internal stakeholders, helping them to work out what the feature flagging tool could do, and how they would use it most effectively. A huge aspect for us was around the SDLC, and how feature flagging done correctly would change our SDLC overall.
Once we understood what we intended to use, and HOW it would be used in our organisation, it became clear that we really needed a step-by-step guide for people which would explain to them the WHY of it all. As I said above, people dislike change, but change can be made more palatable if there is a reason for it, especially a reason which benefits them. Identifying these WHYs really went a long way towards allaying fears and / or removing excuses or reluctance.
At this stage, we were ready to implement. This was the smallest body of work, actually. We built a NuGet package which wrapped LaunchDarkly functionality in a way which was palatable to our application, and made it available to DevOps teams. But that wasn’t the end.
One of the most satisfying tasks came last: Training. I cannot overemphasize the importance of training of a new technology. Taking people through not only the tech itself (most of which was just showing people the LaunchDarkly documents), but through how it would be used, and how it would fit into their daily routines, was one of the reasons the project was so successful. Without proper education, people would have floundered, or at the very least, stumbled about far too long before reaching anything approaching success.
New tech is great. There are any number of tools and gadgets and gizmos out there these days, but don’t imagine they will solve your problems for you. When introducing new technology, you must be prepared to involve your business in an adventure, and be willing to face resistance with information and buy-in from your teammates.
If you don’t, then be prepared for me to say I told you so.