Jason Yip on Removing Friction in Development and DevOps at Spotify

• 0:50 Introductions & history
• 2:40 The reality of working at Spotify is that there are definitely opportunities for improvement
• 3:15 Scaling up excellence
• 3:48 What speed means in development
• 4:22 The difference between the perception of speed and the reality of elapsed time
• 4:44 Friction is the feeling that your environment is fighting you – examples include poorly named variables in code, editors configured incorrectly, access to environments etc
• 5:35 These things often seem small individually, but together they significantly and slow down development activities
• 6:00 It’s easy to ignore them from a management perspective because they are small and not constantly visible
• 6:15 Encourage the habit of not accepting these friction points and actively addressing them
• 6:44 Take a Kaizen approach of many small improvement steps
• 7:22 Cultivate refined annoyance; not tolerating these issues but actively resolving them
• 8:48 Where the original ideas around DevOps came from – remove the barriers and create a collaborative culture
• 9:39 You build it – you support it removes the distance and barriers between development and operations
• 9:44 On its own this does not remove the friction, it does remove the communication barriers.  Need to address the friction points as well
• 10:20 Communication barriers can exist anywhere in a value stream and DevOps alone does not overcome these
• 11:01 Addressing the communication gaps needs to be tackled at multiple levels
• 11:34 Think about the design patterns when looking at the communication structures in your organisation
• 12:44 Limitations of different approaches, and balancing different concerns since no one approach will be perfect, there are always trade-offs which have to be made
• 13:18 Deciding when to have a clear interface for communication outside a group vs bringing everyone into the single large group
• 14:14 Challenges facing Spotify come mainly from rapid growth – every design will fail if you just try to scale it larger and larger, you need to redesign for larger contexts, what worked yesterday may not work tomorrow and needs to be adapted
• 15:05 Looking at the organisation as a technical system and using software design approaches to identify opportunities for improvement in the organisation
• 16:05 Friction also exists outside the individual experience and there may be factors which feel slow at the individual level but are actually faster overall
• 16:23 Be careful not to locally optimize one part of the system at the expense of the overall throughput
• 17:04 Look beyond the individual contributor level and examine broader aspects such as co-ordination and scheduling to optimize the whole
• 17:28 Whose role is it to see the whole?  Make it everyone’s responsibility – the more people who can identify larger system issues the better
• 18:22 Part of leadership/management responsibility is to take the time to identify and address the larger system issues
• 18:55 Use ideas from Lean – value stream mapping and visualization as two techniques to help identify system-level issues
• 19:28 When concepts become too complex to hold in our minds it is important to be able to have tools to help cope with the cognitive load – this is what building models is for
• 20:15 We know how to address the problems, but organisations and people often don’t address them for a wide variety of reasons related to motivation and/or ability
• 21:10 These systemic problems are hard to identify because they don’t advertise themselves – finding them requires determined effort, unlike friction at the individual level which is constantly visible to the people impacted
• 22:15 Finding and addressing these issues in organisations is hard, and doing so is very valuable

Mentioned:

• QCon
• ThoughtWorks
• Spotify
• Book – Scaling up Excellence
• Kaizen
• Lean Software Development
• Six sources of Influence model