7 Things Executives Can Learn From Software Engineers Matt Stratton Staff Developer Advocate • Pulumi @mattstratton
Slide 1
Slide 2
Slide 3
The power of iteration
Slide 4
Slide 5
Small teams move fast
Slide 6
Small teams move fast ● ● ● ● Glue work between the teams Black box squads (input/output) Conway’s law Software contracts extend to teams (“this api does x” etc)
Slide 7
Fast feedback
Slide 8
Fast Feedback ● ● ● ● Set success criteria that is measurable Get changes in front of users/consumers quickly Create a process to share all feedback as soon as possible Automate feedback where possible
Slide 9
Trust but verify
Slide 10
Trust, But Verify ● ● ● Guardrails are good! Make the right way the easy way People want to do the right thing, but mistakes can happen
Slide 11
Collaboration over competition
Slide 12
Collaboration over Competition ● ● ● ● Power structures can create unintended consequences Ownership/fiefdoms “Who moved my cheese”? (or who touched it) Resource guarding
Slide 13
Westrum Model
Slide 14
Community spirit
Slide 15
Community Spirit ● ● ● ● Developers love to work in communities Communities can be internal and external We can learn from our peers - and help them as well Fewer things have to be secret than we think
Slide 16
Learning culture
Slide 17
Learning Culture ● ● ● Learning from Incidents Shadow rotations (not just for juniors and not just for tech) Blamelessness
Slide 18
Incidents are unplanned investments; their costs have already been incurred. Your org’s challenge is to get ROI on those events. - John Allspaw, Adaptive Capacity Labs
Slide 19
RCA != learning
Slide 20
Shadow Rotations
Slide 21
The impulse to blame and punish has the unintended effect of disincentivizing the knowledge sharing required to learn from incidents
Slide 22
Resilience and Organizational Dynamics
Slide 23
Blunt / Sharp End Blunt End Removed from experience Upstream decision makers Sharp End People directly engaged in the work “Chop wood, carry water”
Slide 24
Sharp End Constantly building and destroying systems Strong signaling Improve systems based on strain Will do so naturally if given ownership
Slide 25
[Psychological safety is] a sense of confidence that the team will not embarrass, reject, or punish someone for speaking up Amy Edmondson, Professor, Harvard Business School
Slide 26
Radical candor? If you are asking for candor/blunt feedback, what are you doing to make this safe?
Slide 27
Thank you! Twitter - @mattstratton GitHub - mattstratton Slides - speaking.mattstratton.com LinkedIn - linkedin.com/in/mattstratton Podcast - ArrestedDevOps.com DevOps Party Games - devopspartygames.com
