CASE STUDY: DEVELOPER ENABLEMENT

Executive Summary

In this case study, I describe how a focus on developer enablement led to cultural change at The Walt Disney Company. The strongly independent cultures of the company’s business units meant that technology was siloed across organizational boundaries. Establishing enterprise-wide communities where developers could share code, meet others with shared interests, and learn from each other, empowered developers to take on a transformational role in the adoption of new technology and evangelizing best practices.

Context

The Walt Disney Company is a media and entertainment company that has grown into a global conglomerate through a series of major acquisitions. A deliberate strategy of giving acquired companies a lot of autonomy over business decisions, had the detrimental side-effect of creating technology silos. Developers in one business unit were unaware of teams working on similar technology in other business units. The result: duplication of effort and lack of knowledge transfer. As one developer stated, “We know we’re reinventing the wheel, but we just don’t know where the wheel is”.

Developer Enablement

I saw an opportunity to bring developers together, across all Disney business units, to facilitate collaboration, share code and knowledge, and build self-sustaining communities of interest.

This initiative would have to be built bottom up, from a grass roots level — a top-down approach would be contrary to the established culture of business unit autonomy.

The philosophy of this initiative was developer enablement, and the best way to enable developers is to ask them to identify the obstacles they face in their day-to-day work.

My approach was to form a team of experienced technologists from across the company to conduct Voice of the Customer interviews with our key stakeholders: software engineers in business units’ engineering organizations. We visited these engineering groups and ran facilitated sessions where we asked developers to identify problems and solutions, in a series of collaborative round-table brainstorming sessions.

We then collated the problems and asked developers to prioritize them. After meeting with all engineering groups, we consolidated the results to get a cross-enterprise perspective. This gave us a set of addressable problems that would have the greatest impact on developer productivity across the entire company. These ranged from relatively straightforward infrastructure issues that could be addressed in a few days, to cultural changes that would take much longer to address.

A Commons of Code

A common concern rose to the top of the list: code collaboration. Developers were keen to collaborate with other developers by sharing code. This was especially important when teams from different groups were working together. Source code was siloed in repositories scattered across the enterprise. These were not discoverable, and access was locked down so that only developers in an organization or team could view their projects and source code. The repositories used a variety of legacy source code management tools that were not designed for open collaboration, further hindering developers.

I recognized that a community of developers in a large, global enterprise had many similarities to the worldwide community of open source developers. Adopting the same tools and practices that had proven successful in the open source world was an obvious strategy for enabling code collaboration across a global enterprise.

The first step was to establish a central “commons of code”; a single source code repository that could be used enterprise-wide by all Disney developers regardless of business unit affiliation. I deployed GitHub Enterprise with a small set of licenses for use by a “seed” group in Disney’s Seattle organization. Adoption expanded virally across the enterprise, with sustained exponential growth over a year. Growth was achieved by word of mouth with no marketing of, or mandate to use, the service.

To further remove barriers to adoption, we offered the service free of charge, rather than the usual chargeback model used for other shared services. Developers were also able to self-register without seeking approval. The principle we adopted was do not tax collaboration. In fact, cost savings were achieved when costly legacy source code management tools were retired. We subsequently applied the same free and open approach to the other services we made available enterprise-wide.

With this central source code repository in place, we had the foundations to build an “innersourcing” program that would facilitate developer-to-developer collaboration across projects.

GitHub laid the foundation for code collaboration across the enterprise.

Innersourcing Evolved

A good demonstration of the power of innersourcing occurred soon after the GitHub deployment.

Disney was rearchitecting and rewriting its DisneyID user identity and registration system as a set of RESTful cloud services. The impact of this was far-reaching, affecting over 1,000 applications and websites which were required to continue to operate during the multi-year transition period.

The DisneyID team worked with application owners to migrate their applications to use the new REST APIs. They quickly ran into problems because the teams adopting the new services were unfamiliar with REST, and integration with the new services required them to understand a new asynchronous service request paradigm. Eventually, members of the DisneyID team had to travel and sit side-by-side with the application developers to help them with the integration work. While this was ultimately successful, it wasn’t scalable across 1,000 applications and 100+ teams.

The solution hinged on code sharing. The DisneyID team and the application teams both published their source code in GitHub. This enabled them to review each other’s code and submit pull requests to integrate code changes and bug fixes; a symbiotic relationship that benefited both parties.

Out of these early integrations came client-side integration code that could be reused across other applications. These client adaptors were published as GitHub projects that all teams could easily integrate without becoming REST API experts. With reusable components shared across applications, updates to the DisneyID services could be synchronized with client adaptor changes, minimizing disruption and client integration rework. It also had the beneficial side-effect of standardizing user experience across all of Disney’s applications and websites.

Each integration benefitted from improvements to the adaptors and services made by previous teams. This rising tide of changes elevated everyone’s code, and, importantly, shared the development load across hundreds of teams. While this is not remarkable in the open source world, it was remarkable for a siloed organization like Disney.

Note that this was not driven top-down as a “collaboration initiative” but happened at a grass roots level with developers collaborating with developers within a “united nation of code”.

GitHub laid the foundations, but developer collaboration changed the culture.

Learning & Development

When developers share code, it helps other developers become better software engineers; they learn by the example of more experienced developers. Within teams, developers can easily share best practices with each other, but this happens much less frequently across geographically- or organizationally-dispersed engineering organizations, unless there’s a formal enterprise-wide educational program.

To facilitate learning by and for developers, we established a series of themed Developer Summits to bring together subject matter experts and practitioners with shared technical interests. Initial summits focused on HTML5, REST, Web and Mobile Development, and Cloud Computing. These events were hosted at Disney venues, and proved extremely popular amongst developers. Developers got to meet their counterparts in other organizations, learning from each other, and building relationships that persisted through social media communities that emerged during and after the summits. Once established, these communities continued to grow organically.

Matchmaking developers in this way was an essential step in breaking down silos and instilling a wider cross-enterprise perspective about technology that improved collaboration and replaced reinvention with reuse as code sharing propagated.

Developer Summits brought developers together, but communities kept them connected so they could continue learning from each other.

Enablement Empowered Developers

Developers also expressed a desire for an internal service, like Stack Overflow, where they could ask questions and get answers from other developers. This seemed like a great idea that would bring a successful and well-respected tool from the outside world into the enterprise to facilitate communication and increase collaboration.

The introduction of Slack pre-empted Stack Overflow adoption because Slack usage spread virally across the company, just as GitHub had done earlier. Whereas Disney’s existing collaboration tools required service managers to create new groups, Slack enabled employees to create their own channels, and others could join them without IT involvement. The ability to create new communities, for others to easily discover them, combined with Slack’s developer-friendly features, such as integration with development tools and processes, quickly established Slack as the watercooler for developers to congregate, meet, ask questions, and get answers. The zeitgeist of developer collaboration had moved beyond Stack Overflow before we had chance to adopt it.

A “bring your own app” approach, enabled by freely available SaaS and open source applications, enabled developers to choose the tools they wanted, rather than being told what to use. This became another type of developer enablement, with developers taking over the decision-making role in their choices of tools and technology.

It’s important to note that a traditional Enterprise IT response would have been to crack down on the use of unauthorized tools. The proliferation of applications, and the large community of users that quickly emerged, required a different approach. IT moved from being a benevolent dictator to an enabler, licensing the enterprise versions of the free SaaS applications after adoption had proved their value. This gave IT oversight of usage, and the ability to manage risk from the use of unvetted applications. This went hand-in-hand with the Open Source program I established, which included Open Source Software risk assessments.

Enabled developers felt empowered to make decisions that benefitted themselves and the larger community of developers.

Summary

It would have been easy for technology leaders to prescribe a set of perceived developer-enabling changes and drive them top-down. Instead, I chose to drive developer enablement bottom up by talking to developers and listening to them. With feedback from across the company I was able to identify the issues to address that would have the biggest positive impact.

The first step in changing developer culture was to establish the right conditions for change to occur. My approach involved breaking down silos that were barriers to collaboration by providing a shared enterprise-wide source code repository, connecting developers across the enterprise through educational summits, and forming communities of interest to foster ongoing communication and collaboration. These were proven approaches, adapted from the open source world.

Giving developers control proved instrumental in driving a cultural shift at Disney. Developers were able to select the tools they needed to be productive, adopt cutting-edge technologies, and collaborating with their peers across the enterprise. Ultimately, this increased developer satisfaction, reduced attrition, and created a technology culture that was appealing to prospective employees. The best testament to the success of this initiative came from a new-hire who told me, “I came to Disney because of its technology culture”.