Lack of psychological safety - People are afraid to take risks or admit mistakes
Information islands - Knowledge fragmentation between different parts of an organisation, resulting in duplicated effort, potential clashes, and incomplete knowledge of the bigger picture
Single points of failure, and...
All or nothing expertise - some people know everything and some people know nothing
Mimicry without understanding (Not stated, but perhaps because of 1 and 4)
"Haunted Graveyards" - code no one will touch in case something goes wrong.
Philosophy / principles
A mix of knowledge sharing is likely necessary
Personalised 1-1 advice from experts allows that expert to synthesize all their knowledge and apply it to the asker's use case, but scales badly in big groups
Written/documented knowledge allows knowledge to scale to the whole organisation... though it comes with the cost of keeping that information up to date
Psychological safety is the "most important part of an effective team" - making people feel comfortable asking questions, being wrong, and learning new things. Honesty about what you don't understand should be encouraged. Always be asking new questions.
Especially leaders. The more you know., the more you know you don't know -- asking those questions publicly reinforces its OK for others to do so too.
"Publicly" : depends on the organisation - options include group chats, mailing lists, forums... the format must depend on the organisation
Mentors at Google are assigned to new googlers who are not on the same team, to allow the new joiner to ask for help in tricky situations. It is a way to formalize and facillitate learning, but learning should be done from everyone in a healthy team
The need for psychological safety is amplified in group / public settings, so the way to respond should strive to be helpful, patient and kind, with everyone working to find a soln together and the asker is not chastised but guided in the correct direction. Some don'ts...
No feigned surprise (makes people feel bad for not knowing
No "well actuallys" (pedantic corrections about grandstanding)
No back-seat driving (commit to the conversation
No 'isms' ("It's so easy my grandmother could do it!")
Sharing knowledge...
Office Hours
have a human to talk to
bad for urgent problems
hard to publicize and promote regularly, and takes up an expert's time
Tech talks and Classes
In tech-talks: Speaker presents directly to an audience and can be recorded - scalable
Classes - usually instructor led, can be more demanding, and curriculum needs to be formed; but increased participation can be helpful
Documentation
When to update : Usually when you first learn something - that's when you're most likely to see how the system can be improved. Try to update the documentation yourself. Helpful when a reviewer can quickly review your code and say OK.
Creating documentation -- update when you make new things, and make that documentation easy to find, and easy to comment on or flag an issue with it.
It is worth promoting documentation
Benefits help a lot of people down the line from the time investment of a few
The person who owns the code doesn't have to be asked for help all the time
If more people know how to do the thing, they can also take ownership of updating the document
WRT promoting documentation / and in general knowledge sharing, take note of incentives -- what sort of behavior is being rewarded? For example, is making noncode contributions going to get me a better grade in this class?
Another avenue: peer acknowledgement.
Some cool google specific tools:
g3doc -- displays documentation alongside source code, allwos the adding of comments, and automatically flags bugs for the documentation owners
go/ links. A short perma link is an internal URL shortener that links to the relevant docs, which can live anywhere, but is easy to point someone to and is easy to find or even to guess.
Codelabs
Guided, handson tutorials by combining explanations, working best-practice example code, & code exercises
Static Analysis
Code analysis tools (eg linter)
Readability
Google has a culture of code review where there are "Readability Reviewers" who comment on style and best practices. This allows google to standardise the code accross their organisation and ensure it is readable and easy to learn from across all teams, and new hires and all googlers learn from this personalised code review. However, since readability reviewers are all volunteers mentoring at google, about 1-2% at most, the scale does slow down code pace and some engineers feel it is not worthwhile. But the Engineering Productivity research team found...
The EPR team performed in-depth studies of readability, including but not limited to whether people were hindered by the process, learned anything, or changed their behavior after graduating. These studies showed that readability has a net positive impact on engineering velocity. CLs by authors with readability take statistically significantly less time to review and submit than CLs by authors who do not have readability.22 Self-reported engineer satisfaction with their code quality—lacking more objective measures for code quality—is higher among engineers who have readability versus those who do not. A significant majority of engineers who complete the program report satisfaction with the process and find it worthwhile. They report learning from reviewers and changing their own behavior to avoid readability issues when writing and reviewing code.
CONCLUSION / SUMMARY THOUGHTS
1-1 mentoring can help break through not feeling like you can ask for help in group settings, and unstick tricky problems
Wide range of things you can do for knowledge sharing - reward knowledge sharing where you can
Make it easy for people to admit their mistakes (and be kind!) so that people will ask for help
Book: SE@Google Chapter: 7 Knowledge Sharing
Summary:
Challenges to learning
Philosophy / principles
A mix of knowledge sharing is likely necessary
Psychological safety is the "most important part of an effective team" - making people feel comfortable asking questions, being wrong, and learning new things. Honesty about what you don't understand should be encouraged. Always be asking new questions.
Mentors at Google are assigned to new googlers who are not on the same team, to allow the new joiner to ask for help in tricky situations. It is a way to formalize and facillitate learning, but learning should be done from everyone in a healthy team
The need for psychological safety is amplified in group / public settings, so the way to respond should strive to be helpful, patient and kind, with everyone working to find a soln together and the asker is not chastised but guided in the correct direction. Some don'ts...
Sharing knowledge...
Office Hours
Tech talks and Classes
Documentation
When to update : Usually when you first learn something - that's when you're most likely to see how the system can be improved. Try to update the documentation yourself. Helpful when a reviewer can quickly review your code and say OK.
Creating documentation -- update when you make new things, and make that documentation easy to find, and easy to comment on or flag an issue with it.
It is worth promoting documentation
WRT promoting documentation / and in general knowledge sharing, take note of incentives -- what sort of behavior is being rewarded? For example, is making noncode contributions going to get me a better grade in this class?
Another avenue: peer acknowledgement.
Some cool google specific tools:
go/ links. A short perma link is an internal URL shortener that links to the relevant docs, which can live anywhere, but is easy to point someone to and is easy to find or even to guess.
Codelabs
Readability
Google has a culture of code review where there are "Readability Reviewers" who comment on style and best practices. This allows google to standardise the code accross their organisation and ensure it is readable and easy to learn from across all teams, and new hires and all googlers learn from this personalised code review. However, since readability reviewers are all volunteers mentoring at google, about 1-2% at most, the scale does slow down code pace and some engineers feel it is not worthwhile. But the Engineering Productivity research team found...
CONCLUSION / SUMMARY THOUGHTS