Join 📚 Quinn's Highlights
A batch of the best highlights from what Quinn's read, .
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 ™
Social Search Engines: Asking "I do X. Who do you think I should meet?" at Conferences
Summary:
Read the bios, not the session titles. Look for interesting people, not just panelists. Approach the moderators after panels and ask for recommendations.
Repeat this process to meet important people.
Don't oversell yourself when approaching referred individuals.
Offer to buy them a drink. This methodical approach helps navigate the overwhelming number of sessions.
Transcript:
Speaker 1
So how do you choose among all the sessions? You probly have some big, fat book that youre like, my god. How am i possibly gong to tackle any of this? Number one, read the bios, not the sessions. The session titles may not tell you the whole story. For interesting people, not titles of sessions. And secondly, don't just look at the people on the panel. Look at the moderators. And so what i did my first time to south by southwest is i would go to a panel, i would listen to these amazing people on the on a given panel, and then i would go up, not to the alisters on the Panel, afterwards, i would go to the moderator, many of whom are equally impressive, in their own right. And i would go to the moderator, whois usually not nearly as mobbed, and i would give them a quick explanation at sahe thisis my first time at southby. I don't know anyone. Connel lost. Just finish my first book. It's about a, b and c. Personally, i'm interested n at the time, say, brazilian jujito, this, this and this. Is there anyone here you think i might really hit it off with? Anyone you think i should talk to? I'm pretty good at this and this? And they be as sure, yes, i thinkshul o, this person and this person. And i just repeated that line of questioning over and over and over again. And that's how i met many of the people who led to the tipping point for the book. And when i went up to those people who were referred, by the way, don't say so and so, said, we should really meet. Don't, don't oversell it. Just say i went up to them, i asked them this. They said this. I figured, what the hell, maybe we'd hit it off. Can i buy you drink? It's a very methodical way to go about tackling deluge of sessions.
#99 — How to Build a World-Class Network in Record Time
The Tim Ferriss Show
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