Mirrors, networks, and boundaries

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.

Fad1e9ed293fc5b3ec7d4abdffeb636f?s=128

Lindsay Holmwood

March 27, 2019
Tweet

Transcript

  1. Mirrors, networks, and boundaries what technical leaders need to know

    for the next 10 years of devops Lindsay Holmwood
  2. None
  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

  11. None
  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

  48. None
  49. None
  50. …the overall industry is improving its software development and delivery

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

  52. None
  53. Increasing, fragmented regulation

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

  55. Good for society, a PITA for us

  56. None
  57. Frameworks for accountability

  58. Custom ASICs are proliferating

  59. None
  60. None
  61. None
  62. None
  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.
  96. None
  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”

  108. None
  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

  126. None
  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

  189. None
  190. None
  191. None
  192. None
  193. None
  194. None
  195. None
  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

  205. None
  206. None
  207. None
  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)