Change Management in Engineering Organization
18 January, 2022

Vice President, Engineering at Pinger
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.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
21 December
Consideration for starting a multi year software infrastructure ( V2 ) project that involves hundreds of globally distributed engineers.

Ahsan Habib
VP Software Engineering at human
10 December
Supporting principles on why being data led (not driven) helps with the story telling.
Vikash Chhaganlal
Head of Engineering at Xero
29 November
Why DevSecOps matter and what's really in it for you, the team and the organisation?
Vikash Chhaganlal
Head of Engineering at Xero
28 November
The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.
Vikash Chhaganlal
Head of Engineering at Xero
25 October
Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Mrunal Kapade
Director of Engineering at Inspire Energy