You’ve probably noticed this: someone asks ChatGPT to explain a concept, and it delivers a clear, structured response. Then they ask you the same question, and maybe you stumble through it. (Which is ironic, because you likely know that concept really well).
AI generates explanations instantly. It doesn’t mean it’s automatically a teacher.
It can’t read a room, adjust when someone’s confused, or know which detail matters for this specific person at this moment. That’s teaching. And the gap between generating explanations and actually teaching is real - and growing more important.
The Quiet Skill Gap
Maybe you can build complex data pipelines. You understand statistical modeling. You’ve solved problems that would take paragraphs to explain. But when your manager asks you to help the new analyst understand your approach, the words don’t come out right.
This isn’t impostor syndrome - you do know the material. It’s a skill gap.
Teaching is a separate skill from doing, and most of us never learned it because we were hired to do the work, not explain it.
The common failure modes: you either oversimplify and sound condescending, or you dump too much information and watch eyes glaze over. Neither feels good.
The frustrating part? The knowledge is there. Transferring that understanding to someone else is just a different skill entirely.
Why This Is Showing Up More
Remote work means fewer casual explanations. New team members can’t just watch you work. Everything requires more deliberate teaching now.
And as AI tools become standard, teams need people who can help others adopt these tools effectively, not just use them personally.
There’s a practical shift happening: when AI can execute most clearly-described tasks, helping others describe tasks clearly becomes more useful. Teaching becomes a way to expand what you can accomplish beyond your own hands.
That said, teaching ability won’t single-handedly make or break your career. But it’s increasingly part of what senior roles require, and most people don’t think to develop it deliberately.
Building Your Teaching Practice
Teaching isn’t talent. It’s practice built through specific habits.
Here’s are some ways to develop it without needing a formal teaching role.
Document for the person who comes after you
Next time you solve something tricky, write it up for someone who’ll face the same problem in three months.
Don’t just write what you did - include what you tried first that didn’t work, and why. Capture the false starts, decision points, and the question that unlocked progress.
This forces you to reconstruct your thinking process, not just your final solution. The person reading it later learns how to think through the problem, not just copy steps. It also saves you from explaining the same thing multiple times.
Insider tip: Add a small section called “What will likely confuse you” and list 2–3 gotchas. This forces you to think like a beginner again, which is harder than it sounds but incredibly useful.
Try explaining things two different ways
After you explain something once, pause and say: “Here’s another way to see it.” Then rephrase it completely using a different angle or metaphor - switch from big picture to example, or example to big picture.
Most people explain things one way and hope it lands.
But everyone processes information differently.
Some need the big picture first. Others need a concrete example to start.
Explaining twice trains you to hold multiple mental models of the same concept, which makes you more flexible when someone doesn’t get your first attempt.
Before → After:
Before: “You need to join these tables.”
After (first way): “A join combines data from two tables based on a common field - like matching customer names in your sales table with email addresses in your contact table.”
After (second way): “Think of two spreadsheets: one has customer purchases, one has customer details. A join is how you connect them so you can see what each customer bought alongside their contact info.”
Two passes catch more learners and help you see where your first explanation had gaps.
Ask yourself what would be confusing
Before explaining anything, consider: if I were learning this for the first time, what would trip me up? What assumption am I making that isn’t obvious? For example, when explaining joins, are you assuming the person knows what a “key field” or “primary key” means? What term sounds simple to you but might be jargon to someone else?
This is hard because expertise makes you blind to what’s actually difficult. But it’s useful.
The better you remember what confusion feels like, the better you can guide others through it. You don’t need to dumb things down - you just need to notice where the gaps in understanding might be.
Separate lookup questions from thinking questions
Not all questions deserve the same treatment.
Lookup questions: syntax, flags, function names → point to docs or AI.
Thinking questions: trade-offs, failure modes, model fit → slow down and reason together.
This protects deep-thinking time from being hijacked by quick facts. It also helps people learn when to search versus when to think - a critical judgment skill that gets lost when we treat all questions the same.
Here’s a prompt to try:
Give me three questions to test whether I’ve framed the problem well - before we jump to solutions. This shifts focus from answers to problem definition.
Treat code reviews as teaching moments
You’re probably already doing code reviews. Instead of just saying “this won’t scale,” add why and show an alternative. Instead of “you should join here,” include a quick explanation: “A join will connect these two datasets on the customer ID field, so we can see purchase history with contact details in one view - here’s when to use an inner join versus a left join.”
This builds teaching practice in small, low-stakes moments.
Nobody expects a lecture in a PR comment, but people notice when someone helps them understand the reasoning behind a change, not just the change itself. Micro-lessons in the flow of work build shared judgment without meetings or slides.
Troubleshoot: If comments feel too long, create a short snippet library of common patterns and paste links. You’re still teaching, just more efficiently.
Don’t wait until you’re an expert to share what you’re learning
When you’re figuring out a new tool or technique, document your learning process while it’s fresh.
Write about what clicked for you, what the documentation missed, or which tutorial actually helped.
Share the missing assumption, the example that clarified it, the pitfall the docs buried.
You’re not claiming expertise - you’re sharing what worked while you still remember being confused. This helps others who are one step behind you, and it forces you to organize your understanding clearly enough to explain it.
Here’s a guardrail: Label it “working notes” or “learning in progress” to set expectations. Fresh confusion memory makes for better guidance because you remember exactly what was hard.
What This Actually Looks Like
When a junior analyst asks how you built a dashboard:
Weak approach: “I used Tableau, connected to the database, and created the visualizations.”
Teaching approach: “I started by sketching what questions this needed to answer. Then I looked at our data structure to see what was already available versus what I’d need to calculate. Want me to walk you through how I decided which chart types to use?”
The difference? You’re showing your thinking process and inviting them into the problem-solving, not just the solution.
When your team is adopting a new AI tool:
Weak approach: “Here’s the documentation link. Let me know if you have questions.”
Teaching approach: “I spent an hour testing this yesterday. The thing that wasn’t obvious from the docs: you need to give it context about our data structure first, or the outputs are too generic. Here’s a template I’m using. Try it on your project and we can compare what works.”
You’re sharing what you learned through experience and creating space for others to learn through theirs.
The Obstacles You’ll Run Into
“I don’t have time to teach everything I know”
You don’t need to teach everything. Start with questions you get asked repeatedly. Every time you explain something twice, that’s a signal to document it once. Some writing now often means less repeated explaining later.
Future replies become one link plus a sentence of context. That’s not avoiding teaching - that’s teaching efficiently.
“People should figure things out themselves”
They will figure things out. The question is just whether they waste time on the same dead ends you already explored. Teaching isn’t removing challenge - it’s removing unnecessary friction so people can focus on the learning that actually matters.
The right friction stays; the useless friction goes.
“What if I explain it wrong?”
You probably will sometimes. Good teaching isn’t about being perfect - it’s about noticing when your explanation isn’t landing and trying a different approach.
Say “that didn’t make sense, let me try again” and you’re already teaching better than most. Course-correcting fast is a teaching skill, not a teaching failure.
Keeping Track of Your Progress
Every time you teach something, you’re creating evidence of a useful skill. That Slack thread where you helped someone debug? The documentation you wrote? The quick walkthrough you gave? That’s all evidence.
Keep a lightweight log:
Date, topic, who it helped
What changed (clarity gained, fix applied, doc created)
One sentence on the teaching move used (e.g., “explained twice,” “decision tree,” “showed failure case”)
These are concrete examples you can point to when someone asks if you can help develop others. In performance reviews or role discussions, this evidence shows capability that’s harder to demonstrate otherwise.
This isn’t a guarantee of promotion - there are many factors in career progression - but it’s proof of a skill that senior roles increasingly require.
If You Want to Go Further
Once the basics feel comfortable, here are ways to sharpen your teaching even more:
Create decision frameworks, not just instructions
Don’t just show what to do - show how to decide what to do. “If your data is over 1GB and latency matters, choose X; if it’s under that and you need real-time updates, try Y instead.”
You’re teaching judgment, not just process.
This is what helps people handle situations you haven’t explicitly covered.
Build deliberate failure into your teaching
Show a near-correct solution with a hidden flaw and ask, “What breaks in production? Can you see the issue?” This makes the learning stick far better than just showing the correct version.
People remember what they figured out more than what they were told.
Teach the questions, not just the answers
Instead of explaining how to optimize a query, help someone recognize when a query needs optimization. The skill isn’t knowing the solution - it’s knowing when to look for one.
“How to notice a query needs optimization” beats “how to optimize this query” because it transfers to new situations.
Context scaffolding for AI prompts
When teaching AI tool use, provide domain glossary, small schema map, and 1–2 gold-standard examples before prompting. Show people how to give AI the context it needs about your specific work.
Accuracy and consistency improve dramatically when AI understands your domain, not just the general task.
What You Might Notice Over Time
Over time, you might notice:
Smoother onboarding and fewer repeat questions.
Clearer handoffs and fewer brittle fixes.
More trust across technical and non-technical partners.
Stronger case for senior roles where developing others is expected.
None of these happen instantly. They add up with steady practice.
People who teach well tend to get pulled into certain situations more often. They’re the ones new hires get paired with. The ones who get asked to bridge technical and non-technical conversations. The ones who lead adoption initiatives because they can bring others along.
As AI handles more routine execution, helping others work more effectively becomes more valuable to teams. This doesn’t mean teaching ability is the only thing that matters—technical depth still matters plenty - but it’s increasingly part of what differentiates people at similar technical levels.
Try This Week
Pick one thing you understand that someone on your team is currently learning. Offer a fifteen-minute conversation where you share how you think about it. No slides needed.
Or pick one repeated question. Write a 6–8 line “future you” note: goal, pitfalls, decision points, and a tiny example. Share it the next time the question appears. Log it in your teaching portfolio.
You’ll probably feel awkward at first. You might stumble. That’s normal. You’re building a skill through practice, and first attempts are usually rough.
The goal isn’t to become the team’s designated teacher. It’s to develop an ability that makes you more useful as AI makes individual technical execution more accessible - and that opens opportunities you might not see coming.
Hope you found this article helpful.
Til next time!
Donabel