Software engineering has an optimal goal : To solve problems, and that is usually done by providing a technical solution. But Software engineering is also about having the best process that can enable a team to find optimal solution to a problem.
When you grow in seniority, it becomes less about solving a specific task , but rather enabling the team and the system (process) so that the optimal solution can be found.
basically if we take the analogy of a factory, it's making sure that the production line keeps working efficiently.

To do that sometimes we need to change the way that we are doing things, the way we are coding , the technology we are using , our deployment process or even our whole architecture.
Being in charge of change as a subject expert sometimes means not only finding the right solution, but also support its adoption and implementation.
To be able to do that efficiently there are some stuff that needs to be done, some of them are :

• Understanding the system and the tradeoff
• Explaining the Why (the Vision)
• Supporting the change.

Understanding the System.

This is one of the most important step. Usually as Senior or subject matter expert, we have our set of technologies or ways of doing things that we are used to and usually when tasking of finding new solution to a problem , we tend to go directly to the way we are used to doing things and that worked for us. It's not a bad thing as wisdom and knowledge are built through experience. But we need to be careful of the ecosystem we are in, the team , where the company is right now and other parameters.

So taking that into consideration, I think it's important to understand why this or that was done. why did they decide to use a VM and not containerized? (maybe time? maybe expertise ? or the infrastructure doesn't allow it ) . The most important thing here is not to come with some preconceived things in mind, but rather understand and ask questions because this will define how we implement things.
Understanding the system is not about knowing all the code or database , but rather finding the thought process behind the implementation: how things are tied together.

Explain the WHY? : Communication is key

The thing to understand here is : To be able to have a team rallied behind a vision, it's important for them to feel included and to know why the change is necessary.
Let's say you have a javascript codebase and because you have more and more people working on it , the need to have a certain structure becomes necessary thus you think about Typescript
If you just come to the team with "we are going to switch to typescript because it's better". You are going to create more confusion and also the team might be frustrated and feel like a change is imposed.

What needs to be done is understand the needs take time with the team to explain why the switch to typescript is important. Explain the Pro(s) , the con(s), the current process , how it will be with the implemented change , the goal behind that etc.
In my experience I have found this approach to rally the team. the team gets more excited if they subscribe to the vision and it makes the change smooth.
Ultimately this all comes down to : Communication and trust and these are the most important things.

Support the change

Last but not the least , and one of the most important step is to support the change and help the team.
This usually translate into :

• Documenting what needs to be done and how ?
• Implementing a template if needed on how to do it.
• Follow up and make sure every question/concern finds an answer.

Basically this means : Lead the troop. As the domain expert it is your task to make sure they are equipped to do it and also to establish the guidelines.

If for example it is about moving the codebase to typescript, some of the tasks involve writing some Development principles that will define the way the code is written , tests are written, what to allow and not , best practices and design pattern.

Lastly one of the most important thing to note is that Change is done gradually. Do not try to change everything at first, start with the core or the smallest possible change that could lead the way.
This gives you time also to make sure that your system keeps working and also give time to the team to digest and understand what is being done gradually , rather than having one big change that will cause more confusion.

About me

I'm a Senior software Developer based in Canada, I love software architecture and building stuff.
Feel free to reach out to me on :
twitter : https://twitter.com/Guialajr
GitHub: https://github.com/jrking365
linkedIn: https://www.linkedin.com/in/jean-roger-nigoumi/