Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Taking DevOps to the Org
Chart
Sriram Narayan
@sriramnarayan
A story of green dashboards and red-faced
users.
2
Availability =
3
no. of successful GET requests
total requests
ACTIVITY ORIENTED TEAMS/DEPARTMENTS
4
Beware the COE
5
ORGANIZATION ALSO IMPACTS CYCLE TIME
6
YOU BUILD IT, YOU RUN IT
“Giving developers operational responsibilities has greatly enhanced the
quality of the services,...
“Once you go upstream and have development
teams truly own their code in production there is an
accountability and a quali...
But we still have separate “change” and “run”
organizations at most banks, each sponsoring
their own DevOps initiatives wi...
10
TEMPORARY CHANGE & PERMANENT RUN IS OLD SCHOOL
Digital businesses function with permanent “ideate-build-
run” teams.
Ci...
A NEW NORMAL
11
A tiered set of
product-mode teams
each of which is:
“ideate + build + run”
EXAMPLE: IAG
• 1000+ org moved from projects to product-mode with 6
tribe-like structures. Each tribe owns:
• Assets: appl...
IN CONCLUSION
• It is time to realize the benefits of DevOps through re-
organization of “change” and “run”.
• It is time ...
THANK YOU
www.agileorgdesign.com
Upcoming SlideShare
Loading in …5
×

Taking DevOps to the Org Chart

1,356 views

Published on

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.

Published in: Software
  • Be the first to comment

Taking DevOps to the Org Chart

  1. 1. Taking DevOps to the Org Chart Sriram Narayan @sriramnarayan
  2. 2. A story of green dashboards and red-faced users. 2
  3. 3. Availability = 3 no. of successful GET requests total requests
  4. 4. ACTIVITY ORIENTED TEAMS/DEPARTMENTS 4
  5. 5. Beware the COE 5
  6. 6. ORGANIZATION ALSO IMPACTS CYCLE TIME 6
  7. 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. 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. 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. 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. 11. A NEW NORMAL 11 A tiered set of product-mode teams each of which is: “ideate + build + run”
  12. 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. 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. 14. THANK YOU www.agileorgdesign.com

×