Developing a Product Mentality in Engineering-Centric Organizations

Problem

VMware has a large engineering services organization that is responsible for providing development infrastructure for the R&D community. Among the services provided include the Build system, IDE (integrated development environment), Source Code Management (SCM), malware, and open-source scanning. This organization has a strong engineering focus and historically no product function. This resulted in an inadequate focus on end-user needs which caused the output of the organization to not be viewed positively. The quality of the services was perceived as poor, Service Owners were not responsive to their user base, documentation was insufficient, etc.

The organization has begun a journey to mature itself by adding the product management function in the same way as external-facing organizations and help it align with stakeholders and adequately address customers’ needs.

Actions taken

The organization needed to mature and behave more like a commercial entity in its end-user focus. This was effectively an organizational and cultural change initiative. First, it was clear that this initiative needed to be championed to-down. Working at the lower levels with the engineering managers is always beneficial, but without decisive and consistent involvement from the VP / Senior Director-level, nothing would happen.

In a nutshell, we had to put a structure in place for an organization that generally disliked the idea of structure. The structure was viewed as process overhead, something that stifles innovation, and suppresses engineering creativity. However, after a series of conversations with the leadership, it became apparent that innovation without structure was possible, but if you don't have structure, quality, and responsiveness no one would care for your innovation. However, innovation without reliability, quality, and responsiveness have little value in a “Build-and-Run” organization.

The first positive outcome was to get an acceptance, clarity, and unity that this was a problem that had to be solved. Then, we had to create a governance process -- or the structure -- to ensure that all new services or products would go through a life-cycle process that would scrutinize:

• Why were we doing something?
• Is this the right thing to do, i.e. are we solving a big enough problem for multiple stakeholders?
• Can we resource this program properly?
• What does success look like?
  

We created a formal stage-gate process for launching any new service or product. We established a committee headed by the VP and included all his direct reports that meet monthly to review new initiatives and/or retire legacy products. Before anything can go into beta or GA, it has to go both through business review as well as a technology review. By separating the reviews we ensured focus is maintained and that business reviews did not deep-dive into the weeds around architectural choices.

Lessons learned

• Though we are still in the early stages of the implementation, the first half dozen services that went through this process were rejected and had to re-present their cases. That means that governance is being taken seriously. We have also noticed that the preparation for these reviews is much higher quality than in the beginning.

• For this type of initiative, an extraordinary amount of time was spent convincing people that this was not overhead. People who have gone through the process appreciate it because they like the transparency it brings to the entire organization. Everyone understands why we are doing it and that the success criteria are clearly articulated (which removes the possibility of backroom deals). Change doesn't happen overnight but in small phases. Therefore be prepared that something like this will require time and patience to take root.