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.

1. Taking DevOps to the Org
Chart
Sriram Narayan
@sriramnarayan

2. A story of green dashboards and red-faced
users.
2

3. Availability =
3
no. of successful GET requests
total requests

4. ACTIVITY ORIENTED TEAMS/DEPARTMENTS
4

5. Beware the COE
5

6. ORGANIZATION ALSO IMPACTS CYCLE TIME
6

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

10. 10
TEMPORARY CHANGE & PERMANENT RUN IS OLD SCHOOL
Digital businesses function with permanent “ideate-build-
run” teams.
Cities function with permanent “run teams” and on demand
“change teams”.
Enterprise IT has traditionally followed the same approach.
Both exhibit similar levels of responsiveness to needs of
stakeholders—not viable for a digital business.
ThoughtWorks, Inc. © 2017 Proprietary & Confidential.​

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

14. THANK YOU
www.agileorgdesign.com