In comments to this post (about women in the “edublogosphere”) at Janey Clarey’s blog, Karyn Romeis talked about what I’ll call perceived expertise. The organizer of a tech conference asked why she wasn’t giving one of the seven-minute micropresentations or two-minute nanopresentations.
Karyn said in part, “…I didnâ€™t feel that I knew enough about anything to stand up and tell other people about it…”
I know that feeling. I’ve known it most of my career.
A workshop I attended early on introduced me to lean programming and other ideas developed by people like Dale Brethower and Geary Rummler. That in turn led to my first ISPI conference, where the variety of talent and the openness of sharing were intoxicating.
(Something like Winston Churchill talking about FDR: “Meeting Franklin Roosevelt was like opening your first bottle of champagne; knowing him was like drinking it.”)
For a long time, I felt as though others had things to teach, and I had things to learn. My project at the time was creating computer-based training for Amtrak’s new reservation system. I was so focused on the specifics of our software that I couldn’t see how anyone would be interested in whatever I was doing.
But I wanted to participate in that community of practice, to contribute as well as benefit. Stepping back from the details of our CBT package, I thought about our team’s successes and what had led to them. We’d used a lean, inductive approach; we created short, focused courses; we avoided pointless midlevel branching; we had a high level of interaction; and we supplemented formal instruction with the creation of “training trains” on which people could practice any transactions of the actual Amtrak system.
And we learned a lot from trying things. “Good judgment comes from experience; experience comes from bad judgment.”
I decided I didn’t have to beÂ the ultimate guru regarding CBT, which in those days was slightly less confusing than the Code of Hammurabi. I could share what we at Amtrak had done, why we did it, what worked, and what didn’t.
I would go with what I knew, without pretendingI knew everything.Â This was the description in the conference brochure:
CBT: Your Mileage May Vary
This session presents ways that CBT offers individualization and student feedback and asks: why bother? It keeps the delivery cart behind the instructional design horse. You’ll find out what you could do, ways to decide, and examples of things to keep in mind when looking at CBT systems. The presentation includes mistakes we made. Based on Amtrak’s experience with the Scholar/Teach 3 system, but requires no detailed CBT knowledge.
I’d love to be a guru (or even been seen as one, though that’s a different issue), but I’m not. What works for me, and what I encourage others to consider, is to talk about “here’s what I’ve found” rather than “here’s what I know” (or, heaven help us, “here’s what you should know”).
(Thanks to Karyn for agreeing to be quoted in this post — and for triggering it in the first place.)
2 thoughts on “Go with what you know”
Great post, Dave. Starting from the approach of “here’s what I’ve found” vs. “here’s what I know/what you should know” is great advice. Keeps us all in the position of a humble learner participating in a community of practice rather than a snooty expert in an ivory tower of knowledge.
One of the things that more appealed to me about ISPI was its empirical approach. (Claude Lineberry said once in a memorable 99-second presentation, “Data are plural. By the way, where are your damn data?”)
That runs in several directions — e.g., how do you know you have a training problem? When it comes to participating in a community of practice, the questions I hear are “What did you try?” “Why did you try it?” and “So what happened?”
Isaac Asimov said that the phrase heralding the greatest discoveries is not “Eureka!” but “That’s funny…” (He also said that the true delight is in the finding out rather than the knowing.)