Mirrors, networks, and boundaries

This time ten years ago, a movement was starting to coalesce to better align developers and operators. Looking back in the rear view mirror, we can say pretty clearly that movement was on to something.

DevOps has transformed how organisations use technology and organise people to deliver value to their customers faster and more safely.

But the landscape is changing. New challenges are coming into view, and leaders need to start preparing themselves for what comes next. What’s got us here won’t get us there.

In this talk we’ll look at what organisational psychology, product design, and anthropology have to say about what skills we need when navigating uncertainty.

Transcript

1. Mirrors, networks, and boundaries what technical leaders need to know for the next 10 years of devops Lindsay Holmwood
3. 10 years
4. Sensitive dependence on initial conditions
5. What were the initial conditions?
6. Post-GFC scarcity
7. Organisations were requiring increased operational tempo
8. Siloisation was becoming a less viable organisational strategy
9. Infrastructure was becoming commoditised & on-demand
10. Barrier of entry to dev tools had been lowered
12. The last 10 years
13. Three lenses: Delivery Systems People
14. Delivery
15. Operating models Delivery Before Waterfall
16. Operating models Delivery After Agile, Lean
17. Devops started as “agile systems administration”
18. Deploy frequency Delivery Before Weekly-to-monthly deploys
19. Deploy frequency Delivery After Multiple deploys a day
20. Continuous Delivery is the standard in web industry
21. Systems
22. Infrastructure Systems Before Blend of: ◦ bare metal + virtualised ◦ on-prem or “hosting”
23. Infrastructure Systems After IaaS, PaaS
24. Commodification of infrastructure
25. Infrastructure management Systems Before Scripting
26. Infrastructure management Systems After Powerful config management
27. Architecture Systems Before Monoliths
28. Architecture Systems After Microservices
29. Is this reality or aspirational?
30. Deployment unit Systems Before Virtual machines
31. Deployment unit Systems After Containers
32. Deployment unit Systems Future Functions?
33. People
34. How we respond to failure People Before Blame culture
35. How we respond to failure People After Just culture
36. Blameless post-mortems
37. Relationships to our co-workers People Before Silos
38. Relationships to our co-workers People After Empathy
39. Build DevOps culture through shared experiences
40. Devs on call + Ops shipping code
41. Organising around the deployment pipeline
42. What’s next?
43. “Prediction is very difficult, especially about the future.” 
 – Niels Bohr
44. I’m not going to make predictions
45. Yes, but it’s not necessarily a bad thing. As long as the technology is an enabler of the underlying principles (communication, collaboration, a holistic view), the DevOps movement is still sound.
46. What are the conditions now?
47. The DevOps dream ain’t evenly distributed
50. …the overall industry is improving its software development and delivery practices
51. …low performers are struggling to keep up, widening the gap
53. Increasing, fragmented regulation
54. ◦ GDPR ◦ NDB + APP ◦ “the Netflix tax”
55. Good for society, a PITA for us
57. Frameworks for accountability
58. Custom ASICs are proliferating
63. Machine learning is becoming more accessible
64. Google Neural Machine Translation Source: NYT – The Great AI Awakening
65. Generative adversarial networks
66. Let’s talk about skills for managing uncertainty & ambiguity
67. Mental models for: ◦ Understanding culture ◦ Harnessing mirroring ◦ Mapping strategy ◦ Managing risk
68. Understanding culture
69. We don’t know shit about culture
70. Schein’s three levels of culture
71. Artifacts Values Assumptions
72. National ↩︎ Organisational ↩︎ Team ↩︎ Occupational
73. Artifacts
74. physical manifestations of culture
75. ceremonies
76. org charts
77. desk layout
78. documentation
79. software
80. most visible parts of an org’s culture
81. easiest part of a culture to adopt
82. Values
83. conscious goals, strategies, and philosophies
84. rules that guide how we interact with people
85. rules that guide how we do our work
86. “we will dominate the market”
87. “management is available, and listen to our concerns”
88. “we value quality over delivery speed”
89. “nobody will be fired for making an honest mistake”
90. values: lived vs aspirational
91. Communication We have an obligation to communicate.
92. Respect We treat others as we would like to be treated.
93. Integrity We work with customers and prospects openly, honestly, and sincerely.
94. Excellence We are satisfied with nothing less than the very best in everything we do.
95. Ethical We conduct business affairs in accordance with all applicable laws and in a moral and honest manner.
97. Work as imagined vs Work as done
98. Be clear about what values are what
99. Assumptions
100. beliefs, perceptions, thoughts, feelings
101. exist at an unconscious level
102. hard to discern
103. “anyone can take on leadership responsibility”
104. “bad outcomes come from bad people”
105. “it’s OK to withhold information”
106. “individual performance is valued over team performance”
107. “we can trust that team”
109. Artifacts Values Assumptions
110. Our systems are artifacts
111. Our processes are artifacts
112. Artifacts Values Assumptions
113. Tools are a snapshot of our org’s culture
114. Tools are a snapshot of our org’s values and assumptions
115. Artifacts influence behaviour
116. Encode the org behaviour you want to see into your artifacts
117. Change your org’s values by changing your artifacts
118. Artifact: All changes go through a CD pipeline.
119. Value: We create fast feedback loops to learn from changes in production.
120. Artifact: Developers and managers do on-call
121. Value: Performance, availability and sustainability are everyone’s responsibility
122. Artifact: Our ceremonies include and engage non-technical disciplines
123. Value: Nobody has all the answers. We succeed by working together.
124. But the tools are only a 
 means to an end
125. The goal is transforming our ways of working
127. Harnessing mirroring
128. "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." – Melvin Conway
129. Mirroring
130. “In a complex system, the technical architecture and the division of labor will “mirror” one another in the sense that the network structure of one will correspond to the structure of the other.”
131. Two separate research traditions studying mirroring
132. 1. Computer science Conway’s law
133. 2. Management Org + product design & orgs + products as complex systems
134. What is mirroring?
135. Two networks
136. Organisational
137. Technical
138. Organisational Technical Mirroring
139. We do this to solve problems
140. We do this to take people to where the problems are
141. Who owns this system? ? ? ?
142. We do this because it’s economical
143. Organization design: an information processing view Galbraith, 1974
144. As uncertainty increases, the amount of information that must be processed by decision makers increases
145. The org can respond by reducing the need to process information
146. The org can respond by increasing the capacity to process information
147. The org can respond by Increase the capacity to process information devops
148. Creation of lateral relations: Direct contact Liaison roles Task forces Teams Integrating roles Managerial linking roles Matrix organisation
149. Creation of lateral relations: Matrix organisation Teams
150. Creation of lateral relations: Matrix organisation Teams Dev Ops Design Frontend Backend App eng Infra UX/UI Research
151. Dev Ops Design Frontend Backend App eng Infra UX/UI Research Why do we stop at dev and ops?
152. Dev Ops Design Frontend Backend App eng Infra UX/UI Research We can also include: support marketing design analytics legal finance
153. Dev Ops Design Frontend Backend App eng Infra UX/UI Research What happens if we don’t?
154. Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms Henderson & Clark, 1990
155. 3 year study of semiconductor photolithographic alignment equipment industry
156. field based study, high rate-of-change industry
157. 4 waves of innovation between 1962-1986
158. 4 waves of innovation new leader after each: Kulicke ↩︎ Kasper ↩︎ Perkin-Elmer ↩︎ GCA ↩︎ Nikon
159. 4 waves of innovation each incumbent could not course correct
160. 4 waves of innovation each incumbent invested heavily in new technology
161. 4 waves of innovation each incumbent structured organisation and communication based on product architecture
162. 4 waves of innovation What about this makes sense?
163. Henderson & Clark’s framework for defining innovation Based on Schumpeter, 1942
164. Strongly mirrored Broken mirror
165. Henderson & Clark’s framework for defining innovation Based on Schumpeter, 1942 Mirror Don’t
 mirror
166. Mapping strategy
167. Strategy is not just having a plan –
168. – it’s understanding how you react in a complex environment
169. Your criteria for making decisions when you face uncertainty
170. “Everyone has a plan until they get punched in the mouth” – Mike Tyson
171. Mapping 101
172. Why do we map?
173. Build collective context
174. Inform strategic technology decisions
175. Understand and visualise tradeoffs
176. – Sidney Dekker “multiple overlapping and partially contradictory descriptions of the same act are always possible, and even necessary, to approximate the complexity of reality”
177. Subjective
178. Navigate complexity Discover ambiguities Discover uncertainties
179. Don’t replace architecture diagrams
180. Arch diagrams + maps: complimentary tools
181. What is a Wardley map?
182. It’s a tool that clarifies: * Relationships * Position in value chain * Evolution/maturity
183. It’s a tool that clarifies: * Hot spots * Where new initiatives fit
184. Evolution/maturity Visibility to customers
185. Start with user needs
186. Then add most visible systems
187. Solid lines represent dependencies
188. Add dependent systems
196. Direction of travel
197. Visualise opportunities
198. Keep in mind: * Subjective * Visibility informs priority * Maturity informs investment * Don’t replace arch diagrams * Maps change over time
199. As the complexity of a system increases, the accuracy of any single agent's own model of that system decreases rapidly. Woods' Theorem
200. medium.com/wardleymaps
201. learn.hiredthought.com/p/wardley-mapping
202. • What are complex system • Simple, rugged, and dancing landscapes • The interesting in- between • Explore/exploit
203. stella.report
204. Managing risk
208. Likelihood % chance the thing will happen in the next 12 months
209. Impact $ cost of impact expressed as range* *90% confidence interval
210. Before
211. After
212. Use maps to understand your risk landscape
213. 1. Understand aggregate risk position
214. 2. Compare to appetite
215. 2. Compare to appetite Probability of exceeding loss 0% 25% 50% 75% 100% Loss exceeded 10 100 1,000 10,000 100,000 1,000,000 10,000,000 100,000,000 Current Appetite Residual
216. Probability of exceeding loss 0% 25% 50% 75% 100% Loss exceeded 10 100 1,000 10,000 100,000 1,000,000 10,000,000 100,000,000 Current Appetite Residual
217. 3. Invest in: ◦ Reducing uncertainty ◦ Mitigation
218. The biggest risk?
219. We only look for answers in our field
220. Our niche becomes obsolete
221. We used to laugh at the box huggers
222. But building your own PaaS in AWS?
223. The 2019 version of being a box hugger
224. COTS PaaS meets user needs of 95% of teams
225. Your niche is going to disappear.
226. – Edward Deming "It is not necessary to change. Survival is not mandatory."
227. Move up the stack
228. Understand the business model
229. Learn skills to navigate uncertainty & ambiguity
230. Kill your heroes
231. Thank you! ❤ the talk? Let @auxesis know.
232. • Learn more: ◦ Algorithmic Impact Assessment report 2018 ◦ Stella Report ◦ Wardley Mapping for busy people ◦ Wardley Maps book ◦ The Great Courses: Understanding complexity
233. • Learn more: ◦ How to measure anything ◦ How to measure anything in cybersecurity ◦ Organisational culture and leadership (Schein)
234. • Learn more: ◦ Organization design: an information processing view (Galbraith, 1974) ◦ Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms (Henderson and Clarke, 1990)