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
   

   View Slide

2. View Slide

3. 10 years
   

   View Slide

4. Sensitive
   dependence on
   initial conditions
   

   View Slide

5. What were the
   initial conditions?
   

   View Slide

6. Post-GFC
   scarcity
   

   View Slide

7. Organisations were
   requiring increased
   operational tempo
   

   View Slide

8. Siloisation
   was becoming
   a less viable
   organisational
   strategy
   

   View Slide

9. 
   Infrastructure was
   becoming
   commoditised &
   on-demand
   

   View Slide

10. 
    Barrier of entry
    to dev tools
    had been lowered
    

    View Slide

11. View Slide

12. The last
    10 years
    

    View Slide

13. Three lenses:
    Delivery
    Systems
    People
    

    View Slide

14. Delivery
    

    View Slide

15. Operating
    models
    Delivery
    Before
    Waterfall
    

    View Slide

16. Operating
    models
    Delivery
    After
    Agile, Lean
    

    View Slide

17. Devops started as
    “agile systems
    administration”
    

    View Slide

18. Deploy
    frequency
    Delivery
    Before
    Weekly-to-monthly deploys
    

    View Slide

19. Deploy
    frequency
    Delivery
    After
    Multiple deploys a day
    

    View Slide

20. Continuous Delivery
    is the standard in
    web industry
    

    View Slide

21. Systems
    

    View Slide

22. Infrastructure Systems
    Before
    Blend of:
    ◦ bare metal + virtualised
    ◦ on-prem or “hosting”
    

    View Slide

23. Infrastructure Systems
    After
    IaaS, PaaS
    

    View Slide

24. Commodification
    of infrastructure
    

    View Slide

25. Infrastructure
    management
    Systems
    Before
    Scripting
    

    View Slide

26. Infrastructure
    management
    Systems
    After
    Powerful config management
    

    View Slide

27. Architecture Systems
    Before
    Monoliths
    

    View Slide

28. Architecture Systems
    After
    Microservices
    

    View Slide

29. Is this reality or
    aspirational?
    

    View Slide

30. Deployment
    unit
    Systems
    Before
    Virtual machines
    

    View Slide

31. Deployment
    unit
    Systems
    After
    Containers
    

    View Slide

32. Deployment
    unit
    Systems
    Future
    Functions?
    

    View Slide

33. People
    

    View Slide

34. How we
    respond to
    failure
    People
    Before
    Blame culture
    

    View Slide

35. How we
    respond to
    failure
    People
    After
    Just culture
    

    View Slide

36. Blameless
    post-mortems
    

    View Slide

37. Relationships to
    our co-workers
    People
    Before
    Silos
    

    View Slide

38. Relationships to
    our co-workers
    People
    After
    Empathy
    

    View Slide

39. Build DevOps
    culture through
    shared experiences
    

    View Slide

40. Devs on call
    +
    Ops shipping code
    

    View Slide

41. Organising around
    the deployment pipeline
    

    View Slide

42. What’s next?
    

    View Slide

43. “Prediction is very
    difficult, especially
    about the future.”
    

    – Niels Bohr
    

    View Slide

44. I’m not going to
    make predictions
    

    View Slide

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.
    

    View Slide

46. What are the
    conditions now?
    

    View Slide

47. The DevOps dream
    ain’t evenly distributed
    

    View Slide

48. View Slide

49. View Slide

50. …the overall industry
    is improving its
    software
    development and
    delivery practices
    

    View Slide

51. …low performers are
    struggling to keep
    up, widening the gap
    

    View Slide

52. View Slide

53. Increasing,
    fragmented
    regulation
    

    View Slide

54. ◦ GDPR
    ◦ NDB + APP
    ◦ “the Netflix tax”
    

    View Slide

55. Good for society,
    a PITA for us
    

    View Slide

56. View Slide

57. Frameworks for
    accountability
    

    View Slide

58. Custom ASICs
    are proliferating
    

    View Slide

59. View Slide

60. View Slide

61. View Slide

62. View Slide

63. Machine learning is
    becoming
    more accessible
    

    View Slide

64. Google
    Neural
    Machine
    Translation
    Source: NYT – The Great AI Awakening
    

    View Slide

65. Generative adversarial networks
    

    View Slide

66. Let’s talk about skills
    for managing
    uncertainty & ambiguity
    

    View Slide

67. Mental models for:
    ◦ Understanding culture
    ◦ Harnessing mirroring
    ◦ Mapping strategy
    ◦ Managing risk
    

    View Slide

68. Understanding
    culture
    

    View Slide

69. We don’t know shit
    about culture
    

    View Slide

70. Schein’s
    three levels
    of culture
    

    View Slide

71. Artifacts
    Values
    Assumptions
    

    View Slide

72. National ↩︎
    Organisational ↩︎
    Team ↩︎
    Occupational
    

    View Slide

73. Artifacts
    

    View Slide

74. physical
    manifestations
    of culture
    

    View Slide

75. ceremonies
    

    View Slide

76. org charts
    

    View Slide

77. desk layout
    

    View Slide

78. documentation
    

    View Slide

79. software
    

    View Slide

80. most visible parts of
    an org’s culture
    

    View Slide

81. easiest part of a
    culture to adopt
    

    View Slide

82. Values
    

    View Slide

83. conscious goals,
    strategies, and
    philosophies
    

    View Slide

84. rules that guide
    how we interact
    with people
    

    View Slide

85. rules that guide
    how we do
    our work
    

    View Slide

86. “we will dominate
    the market”
    

    View Slide

87. “management is
    available, and listen
    to our concerns”
    

    View Slide

88. “we value quality
    over delivery
    speed”
    

    View Slide

89. “nobody will be
    fired for making an
    honest mistake”
    

    View Slide

90. values:
    lived
    vs
    aspirational
    

    View Slide

91. Communication
    We have an obligation to communicate.
    

    View Slide

92. Respect
    We treat others as we would like to be
    treated.
    

    View Slide

93. Integrity
    We work with customers and prospects
    openly, honestly, and sincerely.
    

    View Slide

94. Excellence
    We are satisfied with nothing less than
    the very best in everything we do.
    

    View Slide

95. Ethical
    We conduct business affairs in
    accordance with all applicable laws
    and in a moral and honest manner.
    

    View Slide

96. View Slide

97. Work as imagined
    vs
    Work as done
    

    View Slide

98. Be clear about what
    values are what
    

    View Slide

99. Assumptions
    

    View Slide

100. beliefs, perceptions,
     thoughts, feelings
     

     View Slide

101. exist at an
     unconscious level
     

     View Slide

102. hard to discern
     

     View Slide

103. “anyone can take
     on leadership
     responsibility”
     

     View Slide

104. “bad outcomes come
     from bad people”
     

     View Slide

105. “it’s OK to withhold
     information”
     

     View Slide

106. “individual
     performance is
     valued over team
     performance”
     

     View Slide

107. “we can trust that team”
     

     View Slide

108. View Slide

109. Artifacts
     Values
     Assumptions
     

     View Slide

110. Our systems are
     artifacts
     

     View Slide

111. Our processes are
     artifacts
     

     View Slide

112. Artifacts
     Values
     Assumptions
     

     View Slide

113. Tools are a
     snapshot of our
     org’s culture
     

     View Slide

114. Tools are a
     snapshot of our
     org’s values and
     assumptions
     

     View Slide

115. Artifacts influence
     behaviour
     

     View Slide

116. Encode the org
     behaviour you want
     to see into your
     artifacts
     

     View Slide

117. Change your org’s
     values by changing
     your artifacts
     

     View Slide

118. Artifact:
     All changes go through
     a CD pipeline.
     

     View Slide

119. Value:
     We create fast feedback
     loops to learn from
     changes in production.
     

     View Slide

120. Artifact:
     Developers and
     managers do on-call
     

     View Slide

121. Value:
     Performance,
     availability and
     sustainability are
     everyone’s
     responsibility
     

     View Slide

122. Artifact:
     Our ceremonies
     include and engage
     non-technical disciplines
     

     View Slide

123. Value:
     Nobody has all the
     answers. We succeed by
     working together.
     

     View Slide

124. But the tools are only a 

     means to an end
     

     View Slide

125. The goal is
     transforming our
     ways of working
     

     View Slide

126. View Slide

127. Harnessing
     mirroring
     

     View Slide

128. "Organizations which design
     systems are constrained to
     produce designs which are
     copies of the communication
     structures of these
     organizations."
     – Melvin Conway
     

     View Slide

129. Mirroring
     

     View Slide

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.”
     

     View Slide

131. Two separate
     research traditions
     studying mirroring
     

     View Slide

132. 1. Computer science
     Conway’s law
     

     View Slide

133. 2. Management
     Org + product design &
     orgs + products as
     complex systems
     

     View Slide

134. What is mirroring?
     

     View Slide

135. Two networks
     

     View Slide

136. Organisational
     

     View Slide

137. Technical
     

     View Slide

138. Organisational Technical
     Mirroring
     

     View Slide

139. We do this to
     solve problems
     

     View Slide

140. We do this to
     take people to where
     the problems are
     

     View Slide

141. Who owns
     this system?
     ? ?
     ?
     

     View Slide

142. We do this because
     it’s economical
     

     View Slide

143. Organization design:
     an information
     processing view
     Galbraith, 1974
     

     View Slide

144. As uncertainty increases,
     the amount of
     information that must be
     processed by decision
     makers increases
     

     View Slide

145. The org can respond by
     reducing the need to
     process information
     

     View Slide

146. The org can respond by
     increasing the capacity to
     process information
     

     View Slide

147. The org can respond by
     Increase the capacity to
     process information
     devops
     

     View Slide

148. Creation of lateral relations:
     Direct contact
     Liaison roles
     Task forces
     Teams
     Integrating roles
     Managerial linking roles
     Matrix organisation
     

     View Slide

149. Creation of lateral relations:
     Matrix organisation
     Teams
     

     View Slide

150. Creation of lateral relations:
     Matrix organisation
     Teams
     Dev Ops Design
     Frontend Backend App eng Infra UX/UI Research
     

     View Slide

151. Dev Ops Design
     Frontend Backend App eng Infra UX/UI Research
     Why do we stop at
     dev and ops?
     

     View Slide

152. Dev Ops Design
     Frontend Backend App eng Infra UX/UI Research
     We can also include:
     support
     marketing
     design
     analytics
     legal
     finance
     

     View Slide

153. Dev Ops Design
     Frontend Backend App eng Infra UX/UI Research
     What happens
     if we don’t?
     

     View Slide

154. Architectural Innovation: The
     Reconfiguration of Existing
     Product Technologies and the
     Failure of Established Firms
     Henderson & Clark, 1990
     

     View Slide

155. 3 year study
     of semiconductor
     photolithographic
     alignment equipment
     industry
     

     View Slide

156. field based study,
     high rate-of-change industry
     

     View Slide

157. 4 waves of innovation
     between 1962-1986
     

     View Slide

158. 4 waves of innovation
     new leader after each:
     Kulicke ↩︎
     Kasper ↩︎
     Perkin-Elmer ↩︎
     GCA ↩︎
     Nikon
     

     View Slide

159. 4 waves of innovation
     each incumbent
     could not course correct
     

     View Slide

160. 4 waves of innovation
     each incumbent
     invested heavily
     in new technology
     

     View Slide

161. 4 waves of innovation
     each incumbent
     structured organisation
     and communication
     based on product
     architecture
     

     View Slide

162. 4 waves of innovation
     What about this
     makes sense?
     

     View Slide

163. Henderson & Clark’s
     framework for defining innovation
     Based on Schumpeter, 1942
     

     View Slide

164. Strongly mirrored
     Broken mirror
     

     View Slide

165. Henderson & Clark’s
     framework for defining innovation
     Based on Schumpeter, 1942
     Mirror
     Don’t

     mirror
     

     View Slide

166. Mapping strategy
     

     View Slide

167. Strategy is not just
     having a plan –
     

     View Slide

168. – it’s understanding
     how you react in a
     complex environment
     

     View Slide

169. Your criteria for
     making decisions
     when you
     face uncertainty
     

     View Slide

170. “Everyone has a plan
     until they get punched
     in the mouth”
     – Mike Tyson
     

     View Slide

171. Mapping 101
     

     View Slide

172. Why do we map?
     

     View Slide

173. Build collective
     context
     

     View Slide

174. Inform strategic
     technology decisions
     

     View Slide

175. Understand and
     visualise tradeoffs
     

     View Slide

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”
     

     View Slide

177. Subjective
     

     View Slide

178. Navigate complexity
     Discover ambiguities
     Discover uncertainties
     

     View Slide

179. Don’t replace
     architecture diagrams
     

     View Slide

180. Arch diagrams + maps:
     complimentary tools
     

     View Slide

181. What is a
     Wardley map?
     

     View Slide

182. It’s a tool that clarifies:
     * Relationships
     * Position in value chain
     * Evolution/maturity
     

     View Slide

183. It’s a tool that clarifies:
     * Hot spots
     * Where new initiatives fit
     

     View Slide

184. Evolution/maturity
     Visibility to customers
     

     View Slide

185. Start with user needs
     

     View Slide

186. Then add
     most visible systems
     

     View Slide

187. Solid lines represent
     dependencies
     

     View Slide

188. Add dependent systems
     

     View Slide

189. View Slide

190. View Slide

191. View Slide

192. View Slide

193. View Slide

194. View Slide

195. View Slide

196. Direction of travel
     

     View Slide

197. Visualise
     opportunities
     

     View Slide

198. Keep in mind:
     * Subjective
     * Visibility informs priority
     * Maturity informs investment
     * Don’t replace arch diagrams
     * Maps change over time
     

     View Slide

199. As the complexity of
     a system increases,
     the accuracy of any
     single agent's own
     model of that system
     decreases rapidly.
     Woods' Theorem
     

     View Slide

200. medium.com/wardleymaps
     

     View Slide

201. learn.hiredthought.com/p/wardley-mapping
     

     View Slide

202. • What are complex
     system
     • Simple, rugged, and
     dancing landscapes
     • The interesting in-
     between
     • Explore/exploit
     

     View Slide

203. stella.report
     

     View Slide

204. Managing risk
     

     View Slide

205. View Slide

206. View Slide

207. View Slide

208. Likelihood
     % chance the thing
     will happen in the
     next 12 months
     

     View Slide

209. Impact
     $ cost of impact
     expressed as range*
     *90% confidence interval
     

     View Slide

210. Before
     

     View Slide

211. After
     

     View Slide

212. Use maps to
     understand your
     risk landscape
     

     View Slide

213. 1. Understand
     aggregate risk
     position
     

     View Slide

214. 2. Compare to
     appetite
     

     View Slide

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
     

     View Slide

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
     

     View Slide

217. 3. Invest in:
     ◦ Reducing uncertainty
     ◦ Mitigation
     

     View Slide

218. The biggest risk?
     

     View Slide

219. We only look for
     answers in our field
     

     View Slide

220. Our niche becomes
     obsolete
     

     View Slide

221. We used to laugh at
     the box huggers
     

     View Slide

222. But building your own
     PaaS in AWS?
     

     View Slide

223. The 2019 version of
     being a box hugger
     

     View Slide

224. COTS PaaS meets
     user needs of
     95% of teams
     

     View Slide

225. Your niche is
     going to disappear.
     

     View Slide

226. – Edward Deming
     "It is not necessary to
     change. Survival is not
     mandatory."
     

     View Slide

227. Move up the stack
     

     View Slide

228. Understand the
     business model
     

     View Slide

229. Learn skills to
     navigate
     uncertainty &
     ambiguity
     

     View Slide

230. Kill your heroes
     

     View Slide

231. Thank you!
     ❤ the talk? Let @auxesis know.
     

     View Slide

232. •
     Learn more:
     ◦ Algorithmic Impact Assessment report 2018
     ◦ Stella Report
     ◦ Wardley Mapping for busy people
     ◦ Wardley Maps book
     ◦ The Great Courses: Understanding complexity
     

     View Slide

233. •
     Learn more:
     ◦ How to measure anything
     ◦ How to measure anything in cybersecurity
     ◦ Organisational culture and leadership
     (Schein)
     

     View Slide

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)
     

     View Slide