There’s a recurring question that often comes up in discussions about Excel training—particularly from educators like Oz du Soleil. The question goes something like this: “But you didn’t show how it’s done.” It’s a fair question—at least on the surface. But it also reveals something deeper about the different modes of teaching and learning that are often conflated in discussions about Excel and business skills.
The kind of teaching Oz refers to—screen recording tutorials, formula walkthroughs, click-by-click demonstrations—is literal. You show what’s on the screen, describe what buttons to push, explain what the formula does, and maybe even share a file that others can follow. It’s about transferring a visible set of steps from one person’s monitor to another’s. This is useful, of course, but it’s only one type of learning.
What happens, though, when the thing being taught doesn’t exist on the screen?
When the “lesson” is a mental model—a way of thinking about strategy, architecture, or how a process should be built for scalability? What if the “solution” is not a formula but a principle? What if it’s not about the button you press, but why that button is even needed?
This is where we move from literal thinking to lateral thinking.
Literal thinking is what happens when you’re learning what a VLOOKUP does. Lateral thinking is what happens when you’re designing a reconciliation system that solves a problem your organization hasn’t even fully articulated yet. It’s the difference between memorizing a recipe and learning how to cook.
This kind of teaching doesn’t happen in five-minute videos. It takes time. It requires example, iteration, trial and error, reflection, and, often, getting things wrong before getting them right. When we teach concepts—business strategy, data architecture, enterprise scalability—we’re asking learners to use a different cognitive process entirely. We’re not just feeding them buttons and functions. We’re trying to help them see in a different way.
Take, for example, something like the GET and PUT mechanism in Excel connected to a remote database. Yes, we could say: “Push this button and it will insert rows into a table.” That’s the literal explanation. But the real learning—what’s happening between the button press and the database update—depends on a foundation of concepts: structured data, table relationships, SQL queries, connection strings, data integrity, error handling, and more. Those can’t be crammed into a short how-to. They require prior learning, a framework to hang the new knowledge on.
This is not about withholding information. It’s not about mystifying or complicating what should be simple. On the contrary, it’s about inspiring people to want to learn the building blocks. I’ve created foundational material—what I call the “Startup Teaching” series—that lays down the basics in just about an hour. It’s not advanced content. It’s the concepts that help people stop asking “Where’s the button?” and start asking “Why does this matter?”
Sometimes, we need to unlearn before we learn. Misunderstandings about macros, cloud storage, or what “tables” really mean in a database context are widespread. We need to reframe. We need to tell better stories. For instance, I can explain the “librarian principle” in two minutes, but it works far better when told as a story, so people grasp it not just logically but viscerally.
So to answer Oz’s question directly: “Why didn’t you show how it’s done?”—because this is a different kind of teaching. This isn’t literal teaching. It’s lateral teaching. It’s about thinking, not just copying. It’s about principles, not just procedures.
And the real solutions? They aren’t on the screen. They’re in the mindset.
Add comment