Challenging Conventional Wisdom About How to Build a Cloud Center of Excellence

What Success on Broadway can Teach us About Constructing Effective Teams

One of the foundational steps that enterprises take as part of their journey to the cloud is establishing a Cloud Center of Excellence (CCoE). The CCoE is a multi-disciplinary team that is assembled to implement the governance, best practices, training, and architecture needed for cloud adoption in a manner that provides repeatable patterns for the larger enterprise to follow. It might go without saying, but an effective CCoE requires both rock solid execution skills as well as creativity when endeavoring to create new cloud-based provisioning and delivery processes that don’t carry over the bureaucracy and limitations of their current operating model.

Given the criticality of this function it is understandable why enterprises frequently seek out guidance about the ideal composition and function of a Cloud Center of Excellence. There are two approaches to building a CCoE team that I see recommended more often than any others. The first is to assemble a new team with a wide-ranging skill-set from the constituent functional areas that have a stake in establishing a new cloud operating model. CCoE’s built with this approach typically include representatives from Infrastructure Ops, PMO, Enterprise Architecture, App Dev, Infosec, Procurement, and QA.

The second approach is to leverage an already high-performing project team and redeploy them to the CCoE. As opposed to the first approach, where the team has to form, then storm, starting with your A-team that already knows how to deliver results allows the CCoE to get off to a fast start. This second approach is more often employed by enterprises that have already established cross-functional teams for scrum or agile development.

There is agreeable logic in both of these approaches, and I have encountered anecdotal evidence of both operating effectively in the enterprise, but there is research that suggests the way we typically assemble teams like these could be diminishing the results we expect to see from our CCoE and other initiatives. Since coming across this research years ago, I have been employing its conclusions to construct innovation-focused teams (including cloud teams) with successful outcomes. The peculiar thing is that this research is a study about what made Broadway musicals successful in the better part of the last century, and how it applies more broadly to organizational design.

The researchers Brian Uzzi and Jarett Spiro studied the relationships of collaborators (composers, directors, lyricists, producers) from nearly five hundred musicals produced on Broadway between 1945 and 1989(a). Using a ratio for density of past working relationships they called Q, the researchers found that musicals with a low ratio of existing working relationships among the collaborators (low Q) were not likely to be a commercial or critical success. Maybe not surprising, but Uzzi and Spiro also discovered that so-called “A-teams” that had very strong connectivity or a track record of working together (high Q) on other musicals were not a good indicator of success either. It turns out that Broadway teams with a good mix of new and existing relationships (mid-range Q) were three times more likely to achieve box office success. Put simply, they found that most successful musicals were by teams that had a good balance of people that had worked together in the past and knew how to pull off a top production, as well as new blood that brought in a steady supply of new ideas.

If we apply these findings to the typical CCoE models that I described earlier, what challenges might they have?

Taking the first approach to building a CCoE, we have assembled all the functional areas we need to make up a cloud team with unique perspectives and skills. But these representation-focused teams usually have low Q, with little experience working together and might struggle to deliver results without a fair amount of trial and error. I have seen these teams struggle to deliver early wins, and they also require more coordination, which does not lend itself to the leaner operating model most enterprises expect to realize with the cloud.

The “A-team” CCoE approach has high Q, and while they might have the working model already in place to start delivering results quickly, their current status, position, and past successes have been based on optimizing or even manipulating the old way of doing things. They could develop a new cloud-based infrastructure provisioning process that reduces delivery time from eight weeks to four weeks, which sounds pretty good, but why not four days, or even four hours? These teams often have too much invested in their current working model and relationships to allow innovative approaches to take root.

Having already been exposed to these findings back in 2012 when we were faced with deciding who should lead the first cloud team at Edmunds, our goal was to create a new team with a varied assortment of relationships that could provide both new thinking and operational efficiency. Our infrastructure engineering team had a long list of relevant accomplishments to their credit, including a private cloud with a Chef-based infrastructure-as-code automated provisioning platform. By most measures, they were the best positioned team to lead our CCoE efforts.

However, our expectations went beyond just provisioning servers faster. We wanted to improve the way we architected and deployed applications as we moved to the cloud. These loftier expectations, combined with an understanding that a team balanced with execution capability and innovative thinking would be key components of success, required us to think more deeply about how our CCoE would be staffed.

The decision was an unconventional pairing of our infrastructure engineering leads and the senior members of our automated testing team. I have seen quite a few CCoE organizational charts from customers during my time at AWS, and I don’t recall ever seeing SDETs (software development engineers in test) having a lead role on a CCoE. But it worked for our purposes. While the infrastructure leads brought system automation experience to the group, the SDETs knew our applications better than anyone else in the company. Understanding which applications were well-architected , noisy, or had fragile dependencies allowed the combined team to work swiftly through a mapping of hundreds of on-premises applications and develop an accelerated cloud adoption plan, along with supporting tools and processes for the apps to be migrated. Edmunds successfully moved to the cloud and shut down its last datacenter back in 2016.

I have continued to consider the relationship density of teams when starting new initiatives, both for customer facing product development as well as back-end technology teams. I use a simple set of criteria for evaluating team composition:

1. What is the core deliverable expected, and what leaders or team members have shared experience with comparable execution? There should be just enough pre-existing working relationships to ensure that execution and delivery are not in question.
2. What is new or different about what we are trying to achieve, and whom can we tap to provide alternative perspectives on the challenge?

This won’t produce a tension-free environment. In fact, we are encouraging an environment where creative tension is expected in order to produce results beyond incremental change. We also aren’t just throwing random people together and expecting magic to happen. Instead, by seeding the team with execution capability, we are looking to reduce the “forming” tax typically associated with new teams that prolongs time to delivered results.

Enterprises often establish a CCoE to spearhead their cloud efforts with expectations of improved efficiency, better reliability, and faster time to delivery. It is important that the CCoE team they assemble has the right balance of working relationships, operational efficiency, and innovative thinking needed to achieve these goals.

Happy New Year!

Philip Potloff
Head of Enterprise Strategy, AWS
@philippotloff
LinkedIn

For a full read on the research referenced above by Brian Uzzi and Jarrett Spiro: Collaboration and Creativity: The Small World Problem

(a) Uzzi, Brian, and Jarrett Spiro. “Collaboration and Creativity: The Small World Problem.” American Journal of Sociology, vol. 111, no. 2, 2005, pp. 447–504. JSTOR, JSTOR, www.jstor.org/stable/10.1086/432782.