Becoming great requires apprenticeship, not just deliberate practice
Becoming great requires apprenticeship, not just deliberate practice
The Overlap #3
Welcome to The Overlap, a newsletter on the intersection of product management and organization design.
I'm experimenting with a biweekly cadence, despite our original monthly cadence. We've been getting a lot of positive feedback, so I'm wondering if readers want these more frequently. Let me know if you prefer receiving these biweekly or monthly.
On getting better as a PM/org designer
How do you become a better product manager? How do you become a better org designer?
I used to think the answer to this question was deliberate practice, but I’ve learned that it takes more than that. It takes apprenticeship.
Let's start by defining what deliberate practice is.
Deliberate practice is focused, systematic practice with the intent of getting better at a specific skill.
Deliberate practice = Writing every day from 7:30am to 9am. Getting feedback on early drafts from good writers. Posting a piece or newsletter every week.
Non-deliberate practice = Writing when I feel like it. Not asking for feedback. Posting on a non-regular cadence.
Many social scientists, educators, and researchers cite deliberate practice as one of the most influential ideas in the field of learning.
However, I’ve learned that deliberate practice is hard to apply to nascent fields that are still developing its pedagogy.
Deliberate practice makes sense if you’re trying to be great at violin, basketball, or writing. Each of these crafts has a well-known way of getting better: practice daily.
In the words of Allen Iverson, "We talkin' about practice."
However, it’s hard to deliberately practice product management and org design. What is the product manager’s equivalent to playing the violin daily? Writing recommendations for current companies on where to take their business next? Studying annual reports and S-1s? Reading Stripe’s API docs? Taking a statistics course? Writing blog posts?
Product management and org design are both developing fields. While both fields are converging on similar ideas for how to get better at the craft, both fields are far from having a default way of learning.
Tacit knowledge is more important than deliberate practice in underdeveloped fields
I recently read a piece on how tacit knowledge is more important than deliberate practice in underdeveloped fields.
Tacit knowledge is knowledge that is nearly impossible to explain but is necessary for developing expertise. Tacit knowledge is only gained through apprenticeship and experience.
Let’s take an example: riding a bike. From Cedric’s piece:
Riding a bicycle is impossible to teach through descriptions. Sure, you can try to explain what it is you’re doing when you’re cycling, but this isn’t going to be of much help when you’re teaching a kid and they fall into the drain while you’re telling them to “BALANCE! JUST IMAGINE YOU ARE ON A TIGHTROPE AND BALANCE!”.You can’t teach a friend how to ride a bike by explaining to them how to ride a bike. They have to try it on their own. And yet, most of our training and education assumes that explanation is an effective way to help others learn, rather than giving students the environment to try things on their own.
Explanation isn’t effective because it does not transmit tacit knowledge—the knowledge that’s necessary to get better at a craft. This makes sense: tacit knowledge by definition is impossible to explain.
So how do you gain tacit knowledge?
Apprenticeship.
While deliberate practice emphasizes practice in an effortful way, tacit knowledge emphasizes imitation, emulation, and osmosis.
When I reflect on my past experience, tacit knowledge resonates with me. When I started my org design job, I had some experience with facilitation and zero experience with consulting and coaching. My first way of getting better was by observing my colleagues who had years of experience in consulting, coaching, and facilitation. I attended the workshops they facilitated. Then, I led the facilitation with my colleagues’ support. Then, I facilitated workshops on my own. I even facilitated a workshop for a client on improving your facilitation skills.
I noticed the same pattern with my product management journey. I first observed and emulated Conor, my dedicated mentor at my current company. Then I led product discovery with minimal support from Conor. Now I’m running product discoveries on my own.
No matter how many books and articles I read on self-management, UX design, strategy, and facilitation, I’ve learned most in these areas through apprenticeship and real experiences. And it usually follows a similar pattern:
Observe someone else better than me at a thing
Put myself in situations where I have a) a stake in the outcome and b) someone to guide me
Do that thing on my own
Figure out my own ways of doing that thing
Follow the rule, break the rule, transcend the rule
Apprenticeship as a model for mastery reminds me of another concept: Shuhari (守破離).
Shuhari is a model for mastery in Aikido, a Japanese martial art. It has three phases:
Shu (守): Follow the rule. Imitate the teacher. Don’t deviate from the rules
Ha (破): Break the rule. Once you know all the rules, break them when necessary. Question rules
Ri (離): Transcend the rule. Rules are second nature to you. Abandon rules depending on the situation. Further the craft.
Shuhari is brilliant because it can apply to any field of expertise. Understand the rule before breaking it. And as tacit knowledge suggests, start by imitating the teacher.
To get better at your craft, be an apprentice
As someone who prides himself on being able to learn things on his own, I struggle to accept that I need mentorship. “I didn’t have a teacher for breakdancing nor writing. Why do I need one for product?” But that’s just ego getting in the way. It’s a sign that I have a lot more to learn.
I’m fortunate to have had teachers, coaches, and mentors who were willing to help me get better.
Find someone awesome at your discipline and figure out how you can learn from them.
What I’ve written recently
Should product managers learn design?
One thing I’ve realized as a product manager is how helpful it is to know design. I’m curious about why PMs worry about not knowing how to code yet don’t even think about learning about design.
What I’ve been reading
Shuhari is about master-apprentice, not solo learning - Erin Folletto
Erin makes the point that Shuhari is about having someone to teach you more than it is about following the three phases verbatim. To get the most out of this piece, read her primer on Shuhari first.
Apprenticeship Patterns (Book) - Adewale Oshineye and Dave Hoover
Though this book is for developers who want to accelerate their careers, its lessons apply to non-deves. Add this book to your reading list.
Do we need product managers? - John Cutler
This is one article of many that inspired me to shift into product management from org design. Complaints about “bad product management” is an early symptom of bad org design. Recall from our first newsletter: good org design makes for a good product.
Agile is ruining your product - Matt LeMay
In most organizations, you either have highly aligned teams with no autonomy or highly autonomous teams with no alignment. Matt’s article touches on the latter. Organizations that push for autonomous teams often have incoherent user experiences because there isn’t a coherent strategy that guides these teams.
The trouble with hierarchy - Clay Parker Jones
I once consulted for a big bank. My team and I were trying to visualize the organization’s structure. When we asked around, we got nothing. No one had a full view of the entire organization. Clay makes this point in his article: “Hierarchy pushes teams to learn more about the organization than about their customer.”
The majestic monolith - David Heinemeier Hansson
DHH shares how a microservice architecture—building an app as a collection of loosely coupled services—did not meet Basecamp’s needs. The general takeaway: be critical of what’s hype (“microservices” / “self-managing teams” / “Spotify Squads”) and architect/design based on your actual needs and constraints.
See you in two weeks,
tim