You have great software engineers. They work on autonomous product teams that deliver frequently. The products are doing well. But -- there is always a But. Things could be better. Something is frustrating team members or disappointing customers or slowing things down. What is it?

Friction. No matter how well things are going, there will always be friction. Consumers experience friction when using your product. Friction delays a team's response to a product request. Friction makes the code difficult to change. Differing expectations create friction among team members. Competing goals create friction between teams.

This talk looks at the most common sources of friction in software systems, and present patterns for reducing friction that can be used again -- and again -- to identify and address points of friction on an on-going basis.