In this slide deck I try to explore the meaning of the often misinterpreted sentence "You build it, you run it". Starting with its origin in a 2006 interview with Werner Vogels and a short description of the misinterpretation of that phrase that can be seen quite often these days in companies that try to pick up concepts like DevOps without really getting the idea behind it, I then start a bit longer journey. It starts with the history and evolution of markets and IT. Based on that I dive deeper into the effects of uncertainty which these days is often predominant for companies facing narrow and highly dynamic markets. I try to approach from a financial point of view as well as from a risk management point of view (yes, even if we have become agile, managing risk and financial aspects have not gone away). The basic result is that we need to go faster (in terms of cycle times) without compromising quality. I also add a quick litmus test to figure out where your own company currently is located as reality never is as simple as a slide deck - to avoid turning a thought model that should support reasoning into a dogma. Having the task set and understanding that IT must support going faster without compromising quality, I look at DevOps as it targets exactly the same goal. After a short explanation of what DevOps actually means (we face a perfect confusion of ideas when talking about DevOps) and what the effects are if you do it seriously, I focus on the effects for the process organization. The traditional process organization - while usually being set up nicely for cost efficiency - is very poor in terms of cycle times. In order to shorten cycle times those organization will eventually become cross-functional, autonomous teams with end-to-end responsibility. And while those teams have all skills and the full authority for all their activities, they also need to take over the full responsibility for their actions - their is no one left to blame ;) And this naturally leads to "(You decide it,) you build it, you run it" which in the end is a required organizational prerequisite for going fast in a DevOps way. There is a lot left out in the slides that would also be worth talking about (after all it is just a 60 min talk) and of course the voice track is missing, but I still hope that those slides are of some value for you.

1. The truth about “you build it, you run it”
Reframing the context
Uwe Friedrichsen – codecentric AG – 2014-2017

2. @ufried
Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

3. “You build it, you run it!”
Where it comes from

4. ACM Queue, May 2006

5. “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 “A conversation with Werner Vogels” in ACM Queue, May 2006

6. “You build it, you run it!”
How it is often misused today

7. Developer

8. “We finally found the ultimate weapon …“

9. “... to control you $%@&! developers“

10. “You build it, you run it!“

11. “You are so screwed!“

12. “Bwuahahaharrr!!!”

13. They got it plain wrong
and have no idea what “You build it, you run it” actually is about

14. “You build it, you run it!”
What it actually is about

15. tl;dr:
“You build it, you run it” is about
uncertainty, moving fast
and risk management

16. “Woot?“
“Woot?“
“Woot?“
“Woot?“
“Woot?“
“Woot?“

17. Time for a bit of background …

18. Evolution of economy & markets

19. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
The “bathtub” curve
Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13

20. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
Pre-industrial era
Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
Tailor-made
solutions
“Mastery
is key to success”

21. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
Industrial era
Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
Cost-efficiently
scale production
“Get more done with less people
is key to success”

22. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
Post-industrial era
Source: BetaCodex Network Associates, “Organize for complexity”, BetaCodex Network White Paper 12 & 13
Continuously respond
to changing demands
“Continuous
customer communication
is key to success”

23. Key drivers
Industrial era
• Cost-efficiency
• Scalability
• Repeatability
• Stability
• Efficiency & scale
Post-industrial era
• Cycle times
• Adaptability
• Flexibility
• Resilience
• Effectiveness & speed

24. Evolution of IT

25. 1960
1970
1980
1990
2000
2010
2020
Complicated
(Business functions)
Complex
(Business processes)
Highly complex
(Business nervous system)
Software crisis
Software engineering
PC
LAN
Internet
Business
Support
of IT
Selective
Holistic
Complicated
Complex
“Moore’s law”
Mobile
IoT

26. 1960
1970
1980
1990
2000
2010
2020
Complicated
(Business functions)
Complex
(business processes)
Highly complex
(Business nervous system)
Software crisis
Software engineering
PC
LAN
Internet
Business
Support
of IT
Selective
Holistic
Complicated
Complex
“Moore’s law”
Mobile
IoT
We are
here …

27. 1960
1970
1980
1990
2000
2010
2020
Complicated
(Business functions)
Complex
(business processes)
Highly complex
(Business nervous system)
Software crisis
Software engineering
PC
LAN
Internet
Business
Support
of IT
Selective
Holistic
Complicated
Complex
“Moore’s law”
Mobile
IoT
… but we still base most of
our decisions on that
We are
here …

28. Formal part of
value creation
Solution:
machine
Dynamic part
of value
creation
Solution: man
sluggishness/low dynamic high dynamichigh dynamic
The historical course of market dynamics
and the recent rise of highly dynamic and complex markets
The dominance of high dynamics and complexity is neither good nor bad. It‘s a historical fact.
t1970/80 today
Age of
crafts manu-
facturing
Age of
tayloristic
industry
Age of
global
markets
1850/1900
Spacious markets,
little competition
Local markets,
high customi-
zation
Outperformers exercise
market pressure over
conventional companies
We call the graph shown here the “Taylor Bathtub”.
Remember the bathtub curve?
This adds an additional twist …

29. 1960
1970
1980
1990
2000
2010
2020
Complicated
(Business functions)
Complex
(business processes)
Highly complex
(Business nervous system)
Software crisis
Software engineering
PC
LAN
Internet
Business
Support
of IT
Selective
Holistic
Complicated
Complex
“Moore’s law”
Mobile
IoT
… but we still base most of
our decisions on that
We are
here …
Business is very different today …
… than it was back then

30. Business
Market
IT today is a …
… Nervous System
… Medium
… Product
… Differentiator
Disruptive
Technologies
Business
Support
Systems
Continuous
Conversation
Digitization

31. What can we learn from that?

32. 1
We live in an age of uncertainty

33. Understanding uncertainty

34. t
Money
A project – CFO’s point of view
Launch
(End of project)
Representation heavily inspired by
a presentation of Gregor Hohpe

35. t
Money
The problem with uncertainty
Launch
(End of project)
We have no clue
if this line is correct
The line could have any slope
and we do not know it upfront

36. Why can’t we predict the revenue curve?

37. Uncertainty breaks the linear relation
between output and outcome

38. “Woot?“
“Woot?“
“Woot?“
“Woot?“
“Woot?“
“Woot?“

39. Internally controlled
Externally controlled
Output
Effort spent
(Units produced)
Industrial thinking
Outcome
Value created
(Units sold)
Certainty
(linear relation)
We are looking for this
Due to the linear relation
of output and outcome it
is sufficient to predict output
in order to predict outcome

40. Output
Effort spent
(Units produced)
The effect of uncertainty
Outcome
Value created
(Units sold)
Too many influencing factors outside of control
You can only measure it when it happens
You cannot predict it reliably upfront
No longer suitable
to predict outcome
Internally controlled
Externally controlled
Uncertainty
breaks linear relation
?

41. Internally controlled
Externally controlled
Output
Effort spent
(Units produced)
The effect of uncertainty
Under uncertainty you cannot predict
upfront which kind of performance
you are going to produce
Idle
performance
Value-adding
performance
Value-reducing
performance
Support
performance
Creates value (Outcome)
No effect
Destroys value

42. Uncertainty means that
every new feature you deliver
is a bet against the market

43. t
Money
Revisiting the CFO‘s point of view
Launch
(End of project)
There is a lot of money at stake
(a high bet against the market)
The project runs for a long time
which under uncertainty reduces
the probability of creating value
A hazardous bet
(very high risk)

44. How can we do better?

45. Dealing with uncertainty
• Do small bets
• Measure outcome of each bet
• Cut idle performance features
• Cut value-reducing features
• Develop value-adding features

46. t
Money
Creating a different value curve
Money on stake (risk)
is a lot smaller
Money spent (effort)
Money earned (revenue)
Break-even line
?
Value creation
(revenue) starts
a lot earlier
Idle and value-reducing
performance avoided by cutting
it immediately after detection
Original launch
(End of project)
Investments
mostly unchanged
Break even before launch
of original project

47. Under uncertainty you do not
maximize revenue by cutting costs
but by avoiding idle and
value-reducing performance

48. 2
We need to move fast
and learn all the time
to succeed in the face of uncertainty

49. But, know where you are!

50. A little litmus test

51. Take the “real magic triangle” …

52. Good
Fast
Cheap
Optimizing for quality and cycle times
will result in higher costs
Optimizing for quality and costs
will result in long cycle times
Optimizing for cycle times and costs
will result in reduced quality

53. ... and pick the two properties
that are most important for you

54. You may pick
two
Good
Fast
Cheap
Industrial IT
Deliver large batches at minimized costs
towards slow markets
Post-industrial IT
Quickly adapt to ever-changing needs
of dynamic, fast-moving markets
Startup IT
Test hypotheses and pivot as fast as possible
to discover a product-market fit
This is the domain
of uncertainty
This is the domain
of certainty

55. 3
IT today is a key success factor to survive
in a post-industrial market

56. 4
The traditional IT “best practices” are
counterproductive because they solve
a completely different problem

57. And now?

58. In a nutshell, we need to …
• Figure out how to go fast in IT
• Continue delivering high quality
• Avoid counterproductive “best practices”
A good first step is to check if there are already
concepts available that embrace those ideas

59. Enter DevOps ...

60. But, what is DevOps?

61. Perfect confusion of ideas

62. Let’s check the
“DevOps bible”
http://itrevolution.com/books/phoenix-project-devops-book/

63. The 3 ways of DevOps
Systems thinking
Amplify feedback loops
Culture of continual experimentation & learning
http://itrevolution.com/the-three-ways-principles-underpinning-devops/

64. • Maximize flow (minimize cycle times)
• Optimize for global goals (holistic view)
• Never pass defects downstream
• Limit work in progress
• Build systems and organizations that are safe to change
Ops
Dev
Business
IT value chain
Customer
Holistic optimization
Systems thinking

65. • Facilitate constant flow of fast feedback from right-to-left
• Create quality at source (provide knowledge where needed)
• Create shared goals and shared pain for everyone involved
• Implement fast automated test suites
• Pervasively measure outcome (customer value), not output
Ops
Dev
Business
IT value chain
Customer
Amplify feedback loops

66. • Create a culture that fosters two things
• Continual experimentation, taking risks and learning from success and failure
• Understanding that repetition and practice is the prerequisite to mastery
• Allocate at least 20% of available cycles to non-business requirements
• Constantly reinforce that improvements are encouraged & celebrated
Ops
Dev
Business
IT value chain
Customer
Continual experimentation and learning

67. Sounds good, but how does it work?

68. Cross-functional teams
(organized by business capabilities)
Autonomy
(incl. E2E responsibility)
Decentralized control
Microservices
Continuous Delivery
Heterogeneity
Cloud and Containers
Resilience
Operations automation
Craftsmanship & mastery
Outcome-driven
Beyond budgeting
Feature flow
Lean EAM
Continuous improvement
T-Shaped people
(being empathic)
DevOps
Quick feedback loops
Curiosity

69. Cross-functional teams
(organized by business capabilities)
Autonomy
(incl. E2E responsibility)
Decentralized control
Microservices
Continuous Delivery
Heterogeneity
Cloud and Containers
Resilience
Operations automation
Craftsmanship & mastery
Outcome-driven
Beyond budgeting
Feature flow
Lean EAM
Continuous improvement
T-Shaped people
(being empathic)
DevOps
Quick feedback loops
Curiosity
In the end, DevOps has a lot of effects …

70. Cross-functional teams
(organized by business capabilities)
Autonomy
(incl. E2E responsibility)
Decentralized control
Microservices
Continuous Delivery
Heterogeneity
Cloud and Containers
Resilience
Operations automation
Craftsmanship & mastery
Outcome-driven
Beyond budgeting
Feature flow
Lean EAM
Continuous improvement
T-Shaped people
(being empathic)
DevOps
Quick feedback loops
Curiosity
... but we want to focus on those effects

71. How does DevOps affect the organization?

72. Customer
Idea
Traditional IT organization
Operational structure
Organizational structure
…
Subject matter expert
Handover
Activity (process step)
Manager (Non subject matter expert)
Reports to

73. Customer
Idea
Traditional IT organization
Operational structure
Organizational structure
…
Subject matter expert
Handover
Activity (process step)
Manager (Non subject matter expert)
Reports to
Many (often manual) steps
result in long cycle times and
cause defects which introduce
additional approval steps
Lots of handovers
cause information loss
and increase cycle time
Problems in process execution
often need to be escalated
which increases cycle time

74. Reducing cycle times
• Reduce activities and handovers
• Automate everything
• Observe and tackle wait times
• Push decision authority at execution level *
• Create feedback loops at execution level *
• Improve continuously
* requires shared goals and pain

75. New (ideal) IT organization (1/2)
Idea
Customer
Operational structure
Organizational structure
Manager
Reports to
Massive automation increases quality,
shortens cycle times and removes
need for additional approval steps
Handovers replaced by collaborating team
working towards a shared goal and
creating feedback loops as needed
A
A
A
A
A
A
A
T-shaped expert
(Handover)
End2end value creation
A
Automation
Organizational structure
rot required anymore
for problem escalation

76. New (ideal) IT organization (2/2)
Idea
Customer
Operational structure
Side note: The distribution of ideas
to teams should be pull-based and
is by far not as simple as it looks here
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
…
Organize in many small teams,
each team responsible for a
dedicated business capability
or value delivery flow
in order to minimize
cross-team dependencies

77. Properties of the teams
• Clearly defined value delivery goal
• Shared across all team members
• Autonomous
• All required skills for E2E value delivery
• Full decision authority
• (Mostly) independent from other people
• Full accountability for value delivery
• No one else to blame … ;)

78. … which naturally leads to „You decide it, ...“
“You build it, you run it!”

79. tl;dr:
“You build it, you run it” is about
uncertainty, moving fast
and risk management

80. „You build it, you run it“
is about tackling uncertainty,
not about control

81. Wrap-up
• Misconception of “You build it, you run it”
• Evolution of markets and IT
• Understanding and tackling uncertainty
• Knowing your position
• Goals and effects of DevOps
• How DevOps affects the IT organization
• Actual meaning of “You build it, you run it”

82. We live in an age of uncertainty

83. @ufried
Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com