If cloud computing is simply the evolution of hosting, does an enterprise IT group need a "cloud services team," or will the existing hosting team suffice? It's a question that CIOs and other IT leaders should be asking themselves.

Most heads of enterprise infrastructure -- many of whom have restructuring efforts underway -- believe a cloud services team is necessary. More often than not, these teams are distinct from their current hosting structure.

Why?

Early implementations of highly virtualized private clouds offer some clues. Many organizations attempted to manage private cloud implementations with legacy team structures oriented around "technology towers." In doing so, they found unnecessary coordination costs and service quality degradation, whether in terms of the multiple touchpoints required to complete projects, architectural conflicts, or "ticket ping-pong" when trying to root-cause incidents and service failures.

The technology tower model for structuring teams provides incentives for optimizing the individual tower -- hosting, storage, network, etc… -- but not the combined architecture or "full-stack."

Figure 1: (Source: Geralt via PixabayCEB)

As a result, more organizations are standing up cloud teams that are horizontal rather than vertical.

Instead of optimizing for a specific technology tower, these teams manage cloud end-to-end from customer engagement to delivery. The difference is critical: In older models, a solution might require a consumer of infrastructure services to stitch together elements from hosting, networking, storage, and so on. But these newer team models erase those seams and oversee the delivery of full-stack capability through the cloud.

The horizontal nature of the cloud services team means the team roles are different than those for traditional hosting. With the growth of automation and software-defined technologies, cloud teams need "T-shaped," rather than "I-shaped" profiles -- technical depth in at least one technology area, architectural knowledge, or ambition for knowledge -- across the towers, and a clear view of how the end-to-end cloud architecture delivers a business outcome.

Figure 2: (Source: CEB)

The differences are in more than just the shape. A T-shaped team member needs to develop a better understanding of how decisions in any technology tower affect the architectural big picture.

To do that, they need to demonstrate an inquisitive, consultative mindset -- one that traces technology decisions and activities to business outcomes. Not surprisingly, the best cloud teams tend to have active, continuous learners who recognize how fast technology architectures evolve and are preparing for the skills they'll need in the future.

So, where to start?

There are three steps to take to build a cloud services team:

1: Map cloud customers' user stories and the anticipated delivery process
Organizations embarking on a cloud strategy can take a page from the Agile methodology and figure out what the end-to-end model for cloud will look like in terms of what the user will need and how that will be delivered.

Ask questions like: What capabilities will the customer -- including enterprise application development teams -- need? How will they be provisioned? What dependencies will cloud capabilities have on different technology stacks, and how will we resolve conflicts?

2: Map out key responsibilities for the cloud delivery model and identify the roles needed to own those responsibilities
At its simplest, the cloud map should surface clusters of responsibilities associated with customer engagement, design and architecture, and administration.

M&A activity is turning the cloud upside down. Find out what you need to know in our special report: Mergers, Acquisitions & IPOs Are Rocking the Cloud.

Cloud teams typically consist of roles anchored to these sets of responsibilities: Requirements, service catalog design and marketing of cloud capabilities; the architectural buildout, orchestration and automation of the cloud platform; and the day-to-day management of cloud operations. The number of roles required for each depends on the scope of the cloud platform and customer base.

3: Look internally for 'T-shaped' candidates
Standard recruiting and interview processes usually surface whether a candidate has the technical depth and ambition to work on a cloud team. It's more difficult to determine confidently whether or not the candidate has the right attitudinal characteristics or commitment to business outcomes.

An internal employee's track record can be a surer sign. Since these traits are arguably more important than technical expertise, the cloud team will have better success in finding qualified candidates quickly by looking for "T-shaped" candidates who are already part of the company.

These steps don't have to follow this order.

Some organizations argue that it's most critical to find the right candidates, then assemble them into a team, and then let them define roles based on customer need. That last point is the most important of all: Having a team that defines itself by cloud's outcomes, not by its technology.

Related posts:

— Mark Tonsetic is the IT practice leader at CEB, now part of Gartner. Follow him on Twitter @mtonsetic.