Here are some tips when you want to introduce new technology, language, or tool to your team:
Solve a Real Pain Point
Don’t just introduce something new to the stack solely because “it looks cool”.
Start with a concrete demonstration, a strong pitch.
Maybe it will increase the throughput of your web service by 10x. Or it can greatly simplify the tedious deploy process everyone’s complaining about.
It’s easier to sell when the customer already saw the benefit.
Start Humble
A better configuration DSL is a “safer” change than a complete rewrite of core algorithm.
It’s important to manage the fear. If people fear about the change, you won’t achieve anything. Make them fell in charge.
Start small. Don’t change everything in one step.
Encapsulation is the key. Wrap the change into things people familiar with: a C-like DSL, a well-known format like JSON.
Make sure the change is revertible. When technical change failed, it’s still a succeeded refactoring.
Provide Easy-to-use Instruction or Workflow
Make the process as seamlessly as possible. You want to solve problem, not introduce new work.
Think youself as a teacher. You need to make sure the material does not contains any basic mistake. Beginners should be able to follow it without any issue.
Learning new technology might be fun, but debugging misleading document is definite not.
Manage Tempo
After you introduced a change, give the team some time to cool down.
Try to find the correct tempo of your team to work with changes. Too fast, people feel fatigue, too slow, people feel bored.
