Join 📚 Quinn's Highlights
A batch of the best highlights from what Quinn's read, .
Inversion: Avoiding stupidity is easier than trying to be brilliant. Instead of asking, “How can I help my company?” you should ask, “What’s hurting my company the most and how can I avoid it?” Identify obvious failure points, and steer clear of them.
50 Ideas That Changed My Life - David Perell
perell.com
The Factors That Hinder Knowledge Transfer Are Often Structural
Summary:
Barriers to knowledge transfer or knowledge sharing are often structural, rather than merely the result of skill set limitations.
Lessons can be transferred through storytelling, lessons with direction reviews and debriefs, analysis and research, and by allocating workload strategically. Placing the workload at the top, instead of burdening lower-level employees with excessive reading, is crucial.
It is essential to identify the structural barriers causing the hindrance and address them.
Transcript:
Speaker 1
And if something is learnt at one end of the state, I need to transfer that to the other. Now you can do that with story, but you can also do that with lessons without direction reviews and debriefs. You can do that through analysis and research. And you can do that by putting the workload where it should be, you know, up at the top, rather than on the poor people down below expected to read 160 documents a year about everything Because they're going to remember that really, they're going to remember that, not in my experience. So what we have to do is take those really important lessons and then think, well, what are the structures that are causing that to happen?
Speaker 2
And now we've already kind of hindered around this. What are the barriers to knowledge transfer or knowledge sharing? And is it just the skill set of listening and conversation? Is that the biggest barrier?
Speaker 1
I think a lot of the barriers that we deal with are structural.
Organizational Structures That Enable Knowledge Flow With Stuart French
Because You Need to Know Podcast ™
DEEP Framework: Documenting Decisions, Events, Explanations, and Proposals in Your Org
Summary:
The DEEP framework emphasizes the documentation of decisions, urging the recording of the rationale behind business and general decisions.
It also stresses the importance of documenting events such as meetings and town halls, highlighting the need for summarization. Furthermore, the framework encourages documenting explanations, especially in the context of onboarding, as they often involve repeated material.
Lastly, it emphasizes documenting proposals or ideas, allowing individuals to present their rationale to others and providing time for considered reactions.
The acronym 'DEEP' serves as a reminder for teams to consider the documentation created within their workflow.
Transcript:
Speaker 1
So I came up with an acronym as well, and I call that acronym deep. I think you'll identify with some of these. So deep for decisions, if there's ever a decision, then you should record the rationale for it. And we've talked about it endlessly on our tech radar's decision record systems. But I extend that to business decisions as well and general decisions as well. So similar format. Then there's events. So you have a town hall, you have a meeting, all of those are events, right? And you better document them for the benefit of other people. And when I say document, I mean, summarize, sure, you can have a recording or snippets of recordings if they are useful for people, but the summary is the more important thing. Then there's explanations, and I found these very useful in the context of onboarding, because there's a lot of explainer material that gets repeated in onboarding. And those are definitely great candidates for documentation. And the last one is proposals. And I called that proposals, but really I'm trying to talk about things like ideas. So let's take an example. I want to use this new library on my project. I have a certain rationale for it. Let me write down the thought process. What value is it going to bring? Let me present it to everyone. Everyone has the time to consume it. Oftentimes we go into decision making with a lot of cognitive load, where, you know, Ken explains in rapid fire things that he's been thinking about for the last 15 days. And now I have to consume it in the next 30 minutes and give Ken a year or nay. It's really difficult because Ken's done all the deep thinking, I need the time to process it and writing gives me the time to process it, right? And I can also not give knee jerk reactions, but considered reactions. So proposals, and that starts to include design documentation, idea papers, any kinds of proposals that you make on the team. So that acronym deep is a good trigger for teams to kind of hold on to and think about what is the documentation we're creating in the flow of work.
Asynchronous Collaboration — Getting It Right
Thoughtworks Technology Podcast
...catch up on these, and many more highlights
Readwise