Mentoring newcomers is also a learning process in how to mentor people.
Mentoring newcomers can sometimes feel like teaching students. But the workplace isn't a school with a set schedule—no one can teach everything within a limited timeframe.
Ninety percent of managers expect new hires to hit the ground running within days of starting, ideally requiring minimal guidance and not asking the same questions every day.
I once approached mentoring with a "teaching" mindset, only to end up with twice the workload and less time.
This time, to make things easier for myself, I started trying a different approach—from Harvard CS50 to Notion, AppWorks Accelerator, GitLab, Atlassian, and beyond.The Top 10% TeamEveryone is redefining new employee training with "teaching feedback."
Let's see if this logic can be applied to design teams.
Use "Feynman Learning MethodConduct a five-day mini-experiment to let him experience the process of "learning, memorizing, speaking, and re-explaining" in an actual project.
Establish a self-sustaining learning process.
The focus of these five days is not to expect new hires to be fully competent immediately, but to help them learn. "Find the answers yourself." 和 "Ask the Right Questions"
How long does it typically take for new hires to work independently?
In my experience, visual designers fresh out of college
- Completely self-taught: 3 months
- With guidance: 1 month (but the person providing guidance tends to burn out first)
The problem is that while hands-on training is meticulous, it easily traps managers in a vicious cycle of double the workload.
Why do new hires often struggle to learn? It's not about intelligence—it's about poorly designed onboarding processes.
Bringing people on board transforms a "high-energy-consumption" model into a "replicable system."
Design a self-learning process
I used the Feynman Learning Method to break down the training into five stages:
Day 1 Observation → Day 2 Implementation → Day 3 Reflection → Day 4 Collaboration → Day 5 Output
用 Design Management Framework Serve as the framework:
- Goal: Shorten the learning curve for newcomers and enhance the reproducibility of documentation.
- ProcessThe five-day training program consists of SOPs, hands-on practice, and Feynman feedback.
- Observation (Indicator)Comprehension speed, question quality, and independent execution rate.
The approach is straightforward: Hand him the existing SOP and say, "Follow along, then ask if you get stuck.」
Within five days, he must transition from "passive listening" to "active speaking." Most newcomers hit a wall on the third day, but that's precisely when his real learning begins.
The specific implementation details are as follows:
- Day 1 Observation CardAfter shadowing a senior designer for a full cycle, jot down: "What was done? Why? What tools were used?"
- Day 2: Practical CardRewrite it yourself and submit the first draft (focus on clarity, not polish).
- Day 3 Reflection CardOrganize where you're stuck and try to explain in words why you're having trouble here.
- Day 4 Collaboration CardsReview documents with colleagues to ensure consistent understanding. If descriptions are unclear, rewrite them.
- Day 5 Output CardProduce a self-assessment process for the first day at church, reviewing your work responsibilities.
Why does this approach work?
Traditional teaching is "I lecture, you listen." Newcomers nod and say they understand, but as soon as they start doing it, they forget everything.
The crux of the Feynman Learning Method lies in the principle that "you only truly understand something when you can explain it." This approach works in reverse: one must be able to teach their "first-day self" to uncover blind spots.
Pairing "Reproducibility" in Design ManagementConvert the file into standard parts Even a monkey could follow these steps—no need to ask me again. (Throw confetti)
Issues identified during the process
Several significant challenges were also identified during actual implementation:
- Document syntax is imprecise Newcomers often use overly colloquial language or design jargon when drafting documents, leading to communication gaps across departments. Reminder: Documents aren't written for designers alone—they're meant for the entire team to understand. Ideally, they should be so clear that even non-designers can grasp the content.
- Balancing Standards and Creativity If standards are too explicit, they tend to restrict creative thinking; if no boundaries are set at all, focus is easily lost. Emphasis: "Standards represent the baseline for achievement, not the ceiling for creativity."
This process made me realize that mentoring others is also a way to refine myself. I began re-examining which steps in the SOP were unnecessary and which documents were incomprehensible. Newcomers aren't the only ones learning.
Summary: How to replicate this process
If you wish to adopt this training method, three steps will get you started:
- Make the key observation points clear from day one. For example: Habit tracking, questioning logic, decision-making thinking. Modify according to each company's specific needs.
- Prioritize tasks; documents to follow. Let him run the project first, then consolidate his experience.Real-world scenarios are 10 times more effective than just reciting SOPs.
- 10 Minutes of Daily Feedback Let him put it in his own words: "What did you learn today? Where did you get stuck?" Managers are only responsible for poking holes and updating documents, forming Learn → Feedback → Optimize the cycle.
Summary after 5 days:
- Newcomers transition from asking "How do I do it?" to explaining "Why do we do it?"
- Document error rates have decreased, and delivery speeds have accelerated.
- From "Full-Time Nanny" to "Document Reviewer"
Just remember these two points: Document established procedures in SOPs, and conduct post-mortems after new tasks are completed. Instead of spending an hour teaching, spend 30 minutes designing a task that lets him learn on his own.(Of course,The prerequisite is that newcomers are willing to learn.）
Try this method and let me know how it works out for you!
