The document discusses building psychological safety and a "pull request culture" as important elements of inner source software development. It defines psychological safety as being able to speak up without fear of punishment. A pull request culture involves shared responsibility and collaboration through code and process reviews. The document recommends framing work as learning problems, acknowledging uncertainty and fallibility, asking questions to demonstrate curiosity, releasing work early and often to learn from mistakes, and adopting open source practices like radical candor, open decision making, and merit-based contributions to improve psychological safety.

1. Inner Source Building Blocks:
Pull Request Culture & Psychological Safety
Guy Martin
Director – Open@ADSK
guy.martin@autodesk.com | @guyma | @AutodeskOSS

2. 2
What I Do

3. 3
Why I Do It

4. 4
Inner Source Building Blocks

5. 5
Building a ‘Pull Request’ Culture
 Shared responsibility/control
 Code
 Processes
 Policies
 Information
 Tools
 Engaged employees drive collaboration
 Review prevents ‘anarchy’

6. 6
 Lack of psychological safety
 Lack of time/motivation
 Lack of tooling
Barriers to a Pull Request Culture

7. 7
Psychological Safety
A belief that one will not be
punished or humiliated for
speaking up with ideas,
questions, concerns or
mistakes.
Amy Edmondson
Harvard Business School Professor
Source: http://www.businessinsider.com/amy-edmondson-on-psychological-safety-2015-11

8. 8
Psychological Safety Particulars
Relevant For Areas Of
 High uncertainty
 High interdependence
 E.g. – technology/software development

9. 9
Psychological Safety Goals

10. 10
 Frame work as learning problems, as opposed to
execution problems
 Acknowledge uncertainty, ask for everyone’s help
 2. Acknowledge your own fallibility
 "I may miss something — I need to hear from you.”
 3. Model curiosity by asking a lot of questions
 Embrace the power of ignorance (different from stupidity)
Improving Psychological Safety

11. 11
 Frame work as learning problems, as opposed to
execution problems.
 Release Early, Release Often
 Allow the community to learn from/build on mistakes
 2. Acknowledge your own fallibility.
 High-functioning communities have this
 Not all communities do (Linux Kernel!)
 3. Model curiosity by asking a lot of questions.
 Active participation in chat, mailing lists, bug lists, etc.
 Ask (and try to answer) a lot of questions
Psychological Safety == Open Source?

12. 12
 Practice Radical Candor
 Be honest, but constructive
 Default to Open
 Decisions
 Communication
 Documentation
 Meritocracy
 Reward the best contributions, not the highest ranking people
 Egalitarianism
 Make it open to people of all levels
 Encourage a diversity of participation/viewpoints
Open Source Practices  Psychological Safety

13. Thank You