Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Taking DevOps to the Org Chart

In order to realize the full potential of DevOps, it is insufficient to only aim for better engineering techniques and greater automation, hard as that may be in itself. One of the implications of DevOps is a merger of development and corresponding operations teams into several build-it-and-run-it teams. This calls for a re-org at the typical tech organization that supports an old-guard business. The re-org is a challenge for large tech organizations that are often split down the middle in the form of a change organization and a run organization.

This talk (at DevOpsDays Singapore 2017) explores the challenge and describes how it being addressed at some companies.

7.
YOU BUILD IT, YOU RUN IT
“Giving developers operational responsibilities has greatly enhanced the
quality of the services, both from a customer and a technology point of
view. The traditional model is that you take your software to the wall that
separates development and operations, and throw it over and then forget
about it. Not at Amazon. You build it, you run it. This brings developers
into contact with the day-to-day operation of their software. It also brings
them into day-to-day contact with the customer. This customer feedback
loop is essential for improving the quality of the service.”
—Werner Vogels, in an interview in 2006
7

8.
“Once you go upstream and have development
teams truly own their code in production there is an
accountability and a quality dynamic that happens
that is a very powerful incentive. That’s the
destination that we’re trying to get to across the
board.”
—Rob Alexander, CIO, Capital One
8

9.
But we still have separate “change” and “run”
organizations at most banks, each sponsoring
their own DevOps initiatives with no intention
of dissolving organizational boundaries.
9

11.
A NEW NORMAL
11
A tiered set of
product-mode teams
each of which is:
“ideate + build + run”

12.
EXAMPLE: IAG
• 1000+ org moved from projects to product-mode with 6
tribe-like structures. Each tribe owns:
• Assets: applications and environments
• New development and support
• End-to-End deployment from development to production
• Responsibility for security and business engagement
• Folded “change” team members onto existing “run”
12

13.
IN CONCLUSION
• It is time to realize the benefits of DevOps through re-
organization of “change” and “run”.
• It is time to move from temporary change teams and
permanent run teams to permanent ideate-build-run
teams.
• It is time to adopt these ways of working from the best
tech companies instead of saying “it doesn’t apply to
us”.
• It is time to start at least trialing new ways of working
without waiting for industry-peer case studies.
• Time is running out.
13