Change Management in Engineering Organization

Problem

I believe that every engineering initiative needs to be associated with business values. In other words, everytime there is a big architectural change or refactoring, we do that by releasing a feature, and that supposedly improves business. I was able to make that happen on the product roadmap. In order to do that, there needs to be a binding between the product roadmap and the engineering initiative. When we needed to refactor, the work had some fundamental tasks and it would take longer to release the first business value using the new architecture.

Actions taken

The situation was, we agreed to change the architecture of our mobile app to MVVMC. We decided to use the new onboarding flow that was being redesigned to do that because the architecture was providing a faster way to change the onboarding flow for optimization/iterations. It was the perfect feature for that.

The definition of the new onboarding flow was having trouble; although there were tests and discussions. Our product team at that time was a bit light, and they did not have the bandwidth to make things happen on time. We still had a global company objective that needed to be done on time with the onboarding profile within a certain date.

I was looking at a project that was being delayed from the start, and that was not acceptable. Therefore, I worked directly with the UX designers to fully understand their approach to the onboarding flow and which of the different pages fit together. Because the architecture of the MVVMC is connected with the way a designer looks at the different flows, I created a connection between the engineers and designers.

To enable the engineers to start the framework of architecture using the communal that the designer also had abstracted, even though it was not fully defined. We were able to start the architecture ahead of the onboarding flow being fully defined. The complexity revolved around the new architecture and how the engineers could test and implement it.

We were able to go through all the unknowns of the re-architecture, and when the onboarding flow was ready, it was only about finishing the pages. All the engineering work was implemented ahead of time, and when the product was ready, the final update took less time. The project was released within the high-level deadline, creating less pressure on the product team.

Lessons learned

• Involve the engineering team in any of the processes early on. During our process, the product team focused on executing, and not improving. Having the designers talk to the engineers, we had the courage to bring in the change.
• As an engineering leader, there might be a lot of pressure on you, but at the same time, it is also your responsibility to keep the technology up to date. Find those accelerators that enable you to add special technology without always being at the end of the chain.