I came out of the Army having never really used a computer. Not exaggerating for effect, actually zero experience. So my first civilian office job started from nothing. I picked up just enough there to get by: enough Excel to move cells around and build a basic formula, enough of a database program called Access to pull a list together when someone asked.
Then I landed on an accounting team as a business process analyst, and “getting by” stopped being an option. Part of the job was standing in front of the charts and graphs our data produced and explaining what they showed and why. The first time I actually tried to do that out loud, I hit a wall I hadn’t noticed just looking at the chart. I could point at it. I couldn’t fully explain it. Trying to explain it, not staring at it, was what exposed the gap.
So there were two things to actually learn, not one. First the data itself, the real accounting behind the numbers, well enough to say honestly what was happening and why. Then Excel, deeply, because the chart was only ever as honest as the formulas feeding it, and I’d been treating half of those formulas as magic boxes instead of understanding them. Closing both gaps, one on the business side and one on the tool side, is what sparked something in me that’s never really turned off since: a genuine passion for automating the translation between “here’s the data” and “here’s what it actually means.”
Write Down What You Know, Learn What You Don’t
I didn’t set out to build a system for learning things. It’s a habit I fell into by accident, one broken formula at a time, and it took years, first a much bigger jump from Excel into AI automation, then into the change management work I do with organizations today, before I noticed I’d been doing the same thing the entire time. Every time, what actually worked was refusing to build on top of something I didn’t understand.
Nothing exotic. The only hard part is being honest about what you don’t know, writing “gap” instead of nodding along and moving on, which is what almost everyone does, and which is exactly why almost nobody actually gets good at the thing they’re “learning.”
Here’s how that played out over the years, in three phases: dissecting Excel until I understood it, taking that into automation and AI, and then pointing the same habit at problems that had nothing to do with software.
Phase One: VLOOKUP Was the Ramp
So I went formula-hunting, starting with the one I already half-knew: VLOOKUP. Not memorizing the syntax, but refusing to move on until I understood what every part of it actually meant instead of just where the buttons were.
Once VLOOKUP finally clicked, I went looking for more, mostly through the daily formula breakdowns Bill Jelen (better known online as MrExcel) has been publishing for decades, and the beginner-to-advanced walkthroughs in his book Slaying Excel Dragons, co-written with Mike Girvin. The pattern was always the same: learn one formula, use it that same day on something real, then explain it out loud, to a coworker, to myself, to no one in particular, until I could get through the whole thing without reaching for jargon I didn’t actually understand. If I couldn’t do that, I didn’t know it yet. I just knew where the button was.
That last part turned out to be the entire game, and it has an actual name.
Richard Feynman never published a paper called “The Feynman Technique.” It isn’t a method he sat down and formalized. It comes from how he actually talked about learning: pick one concept, try to explain it in plain language to a genuine beginner, and watch closely for the exact spot where the explanation breaks down. That spot is not a communication problem. It’s the edge of your own understanding, found honestly instead of assumed. Feynman’s own real edge came from a habit of distinguishing between knowing something and merely knowing the name of it, which he considered one of the most important habits behind his own success.1 Go back, study that one spot, and try again. Nothing more mystical than that, which is probably why it works on a Nobel-winning physicist and a business process analyst equally well.
Feynman used it on physics. I used it on VLOOKUP. The mechanism doesn’t care what the subject is: explain it simply, notice exactly where you stumble, go fix that one spot, try again.
Phase Two: From Excel to Robotic Process Automation to AI
Excel led somewhere I didn’t expect. Once I was comfortable stacking formulas, I started automating the boring parts of my own job, which pulled me into robotic process automation, software that clicks and types the way a person would, only faster and without complaining. RPA has a ceiling, though, and once I hit it, it was obvious what came next: AI.
So I planned the jump on purpose instead of dabbling. I joined a Skool community called AI Automation Society, run by Nate Herk, and started with his video “How I’d Teach a 10 Year Old to Build AI Agents,” a beginner walkthrough that builds a working agent on a no-code platform. Then I went into his structured multi-day challenge. Beginner explainer first, challenge second.
What mattered more than the course was how I worked through it. Every time a word came up that I couldn’t have defined out loud, I stopped the video and researched that one term, on YouTube or by asking Claude or Perplexity, until the gray area was gone. Then I un-paused. That’s learning what I didn’t know, again, just on a new subject. Today I run a full personal operating system built on that habit: I talk to my phone, it gets transcribed and synced to the cloud, and from there it updates my project plans, drafts my emails and social posts, and writes my one-pagers and templates.
Phase Three: Problems That Have Nothing to Do With Software
I once had to take a project running successfully on one team and scale it across an entire organization, leaning on systems I didn’t control, in well under three months. My honest first reaction was close to panic. I don’t know how to do that. So I did what had always worked: I wrote down what I knew and marked the gaps. The biggest one was who the stakeholders actually were, by name, and what each of them needed to call this a success. Skip that and you’re optimizing a plan nobody with power over it has agreed to.
Stakeholders First, Not Last.
That stakeholder-first instinct has a name in the professional world: change management. Any new system, process, or reorg lives or dies on how honestly you’ve mapped who’s affected and what they need before you touch a rollout schedule. These days I run change management and AI automation together: change management to get people ready for the shift, automation to build what the shift requires. Same habit underneath both, which is why I lead with it on client work.
It shows up in business development too. When a regulatory change or a new funding program reshuffles who has budget, the generic move is a cold pitch. The better move is to find out exactly what changed, find the organizations sitting in that blast radius, and read their mission and stated problems before reaching out. If I can’t explain in plain language what changed in someone’s industry and why it matters to them, that’s a gap, and I go do the research instead of the pitch.
Key Takeaways
None of this requires talent you don’t already have. It requires refusing to move past the part you don’t actually understand, which is a decision, not a gift.
Try It: Pick one tool or skill you use daily but couldn’t fully explain out loud right now. Write down everything you know about it, and write “gap” wherever you get stuck. Then research just those gaps until they’re gone, and explain the whole thing out loud to an actual child, or to an adult as if they were one.
-
Farnam Street, “Feynman Technique: The Ultimate Guide to Learning Anything Faster,” on Feynman’s own distinction between “knowing something” and “knowing the name of something,” https://fs.blog/feynman-technique/ ↩