Strategies for Instigating Technological Change


Earlier today I attended a talk at CMU by Ryan Troll, Director of Engineering at Yahoo! He spoke on the topic of change management and how to instigate large changes at Yahoo. Obviously as Director of Engineering, he has a fair bit of authority at Yahoo in this area, but he still runs into surprising resistance. He posed a question: how would you get every group in Yahoo to agree on a middleware templating language?

Prior to 2002, Yahoo used a number of different templating languages, including an internally-developed proprietary language. However, changes to the templating language made on behalf one application could cause unexpected changes in other applications (as an example, changing the meaning of an operator could have unexpected consequences.) Yahoo decided to migrate to a standard, public templating language, and when the decision was made in 2002, they chose PHP.

Instigating the Change

In order to implement this change, the following strategies were adopted:

  • Tech Talks were given in order to inform the developers about PHP and tout its benefits.
  • Quarterly Status Updates were sent to developers showing the adoption rate and illustrating success stories.
  • Seeding the Source Tree: important chunks of code that were used across the organization were re-developed by the PHP group to speed adoption of PHP across those groups.
  • Encouraging the Early Majority: Many developers will be very enthusiastic to refactor their code, and porting it to a new language gives them that opportunity.

Currently, almost all of Yahoo is using PHP.

Follow-on Change: Upgrading to PHP 5

A couple years after choosing PHP, it became clear that an upgrade from PHP 4 to PHP 5 would be needed. The open source community which supported PHP 4 would eventually drop its support as more and more applications and providers adopted PHP 5. However, upgrading from PHP 4 to PHP 5 requires significant code changes.

In order to implement the change, developers were given a window of time where they had the choice to use either PHP 4 or PHP 5 for their development. A majority of common infrastructure was ported during this time, in 2004/2005. In mid-2005, PHP 4 packages were marked deprecated. As a warning sign, in late 2005 groups began complaining that they would not be ready for the transition. At the end of 2005, an End of Life was reached for support of PHP 4; departments wishing to maintain support or their PHP 4 had to do so on their own time.


In hindsight, Ryan would have done a few things differently.

  • Tech talks and roadmap updates, which were provided for the original PHP implementation, were not given for the upgrade.
  • Adoption tracking was not done, so it was difficult to judge the progress of the upgrade initiative until very late in the process.
  • Contact product managers, not just engineers as some engineering groups did not inform their product managers of the need to upgrade.

Thanks to Ryan for giving this talk. It was very interesting and informative, and it gives great insight into implementing technical change at a large, mature organization.

Did you enjoy this post? Please spread the word.