Fishing and Eating Fish

I’m reading The $100 Startup right now. I’m about 1/3 of the way into the book. I’m sure I’ll have more observations towards the end. But in the mean time, there’s one story that’s absolutely struck me. I’m totally guilty of doing it, which is part of what makes me love (and hate) the story so much.

It goes something like this:

You’re at a restaurant on a Friday evening. You’ve had a long week at work and you just want to relax with your friends and have a nice glass of wine. You order your meal (fresh lake trout) and about 10 minutes later the chef comes out from the kitchen and invites you back into the kitchen to help prepare the fish.

Normally you’d be very excited to get a cooking lesson. But that’s not what you’re here for. You’re here for the experience of the meal with your friends. You don’t want to learn how to cook fish tonight. You want to eat the fish and then go home. (And you definitely don’t want to do the dishes afterwards!)

Asking a client to participate in the process of your business can have the same unintentional side effect. You didn’t mean to make your customers uncomfortable. You were just really excited about teaching them how to cook. When I was working on the curriculum for the Drupal site building program last year, I ran into this problem. I sold instructions on how to build sites. But by the fifth site I started asking myself, “Why is this so hard?! Surely it shouldn’t take 100 pages of instructions to explain how to build this type of site?” Creating exceptional training products made me frustrated with the system I was trying to teach. It made me wonder:

No wonder people want to eat meatloaf!

The trainer’s job is to teach people to fish. It’s a delicate balance, but we also have a responsibility to inform the creators of the tools we teach where the pain points are for their tools. Spend a bit of time fixing the tools and you make it easier for people to eat fish dinner. On the flip side, I also think the trainer should take the time to step away from “How Things Are Done” to think about more efficient processes. In Drupal speak: why do we try to simplify the theme layer by adding very, very complex workarounds to it (template.php and preprocess functions)? Punting stuff into the theme seems like a holdover from the days when we competed with WordPress. Why not make module development more accessible and invite themers to use a more powerful toolkit? Why are we crippling them by implying that “modules are hard”?

Even if that last bit didn’t make a lot of sense to you, you probably got the gist of it: sometimes trainers uncover systematic problems with the toolmaker’s idea of “best practices”. Sometimes we need to step away from a community of tool creators and users and ask ourselves, “Is this really the best way to approach this problem? Am I forcing people to eat a fish dinner when they actually should be learning to fish for themselves?”