Engineer: ‘I think we should adopt Haskell for all our development going forward. It’s strongly and statically typed, purely functional, and its support of type classes allows type-safe operator overloading. It’s the most modern and technically superior choice.’

Manager: ‘How will that help us achieve our business goals any better?’

Engineer: ‘You don’t get it. Are you even technical?’

Like Thanos, the desire to introduce new technologies into the stack is inevitable. We, as leaders, have to strike a balance between technology progression and business risk. Let’s examine some of the motivations that have the potential to introduce technical risk.

Boredom

Of all the possible motivations, this is the most worrisome. Our work won’t always be glamorous and from time to time it will be tedious and mundane. Engineers generally understand that. However, if they continually feel that their work is uninteresting and that they’re not being challenged, they will look to change that somehow. Introducing new technology to their day-to-day work is one way to reignite interest. However, this is often done without examining the implicit and explicit costs that accompany the new technology.

Excitement

On the other end of the spectrum, we have excitement as a motivating factor. Most engineers are fascinated by technology and want to explore new ways to solve their problems. This is great and we should encourage people to stay curious. As with most things in life, such exploration is best performed in moderation.

Recognition

Cynics might view this as a way to pad the skills section of one’s resumé. A more generous view is that people crave mastery. Learning new technologies and approaches helps keep one’s skills sharp which, in turn, helps keep people employable. This desire is something that should be acknowledged, not discouraged.

False premise

‘X uses this technology and they’re successful so we should use it too.’ The challenge with this thinking is that while the premise may have merit, the conclusions are not always so straightforward. For example, many teams are trying to follow in Google’s footsteps in a variety of areas: container orchestration, service meshes, and OKRs. These are all great ideas and contributed to solving some of Google’s problems. The missing context for most is whether or not your 20-person company has similar problems to Google. If not, the application of their solutions may do more harm than good.

Manage risk, channel energy

By understanding the various motivations that are behind an engineer’s desire to affect your tech stack, you will be better equipped to come up with an answer that makes sense for your organization. That answer should rarely be a flat ‘no’ as you will always have to provide the rationale behind the decision and you’ll want to avoid dissipating your engineer’s positive energy. That said, there are a few times where ‘no’ is appropriate. If a technology is proven to be inappropriate, or performs too poorly for your jobs to be done, it makes little sense to entertain the possibility of using it aside from re-confirming the data you have.

The other valid reason for disqualification is obscurity. If the selected technology is so niche and its community is so small as to be non-existent, that’s a huge risk. Unless you and your team can identify real value in self-teaching and mastering the technology in order to train future team members, this choice should be avoided. Time is a precious commodity and the time required to find or train people familiar with a niche technology has to be exponentially outweighed by the value that technology will bring.

One approach to managing risk is through the use of innovation tokens – as is described in Dan McKinley’s frequently referenced post, Choose Boring Technology. The key idea is to set a limit to how many shiny new technologies you introduce into your stack. For example, you may decide that your company has three innovation tokens that can be used over the next two years. Overall, you should prefer boring (read: stable, mature) technologies. However, a newer technology may offer benefits for your particular application. In that case, you can choose to spend one of your innovation tokens. Spending that token should be a big deal and your team should be bought in. If not, eight months in they could discover that they’ve spent their tokens on Kubernetes, Kafka, and Rust and will be disappointed when you tell them ‘no’ when they insist that your application should be compiled to WebAssembly.

Changing your production technology stack is not the only option – internal tools are another way to redirect the energy to adopt something new. A new technology may be deemed too risky to use for customer-facing features, but you might have an internal use case that is both less risky and perfectly suited. Again, moderation is key as you do not want to end up with a suite of tools all written in different languages and integrated with dozens of different data stores. People still have to maintain these tools, so getting buy-in is important here as well.

What about hackathons and hack weeks? These are useful tools but you should know that they are often short-term solutions that result in the equivalent of a sugar high. Sure, the engineer gets a certain amount of dedicated time to play with the technology of their choice. Depending on their execution, they may even make a compelling case for adoption. The real question is, what are the expectations that are being set during this period? Often, people may think that if they get something working that that is enough to gain acceptance. If it’s not, they need to understand that in advance. Then, they can choose to continue exploring or switch their focus to something that might better align with your organization’s interests and have an impact.

There will always be the next new thing and engineers will want to use it. Don’t fight it! Instead, understand their motivations and determine how best to leverage them to benefit both the engineers and the organization.