Designing A Training Curriculum

If you get good enough at doing something valuable, at some point they’re going to reward you by not letting you do that thing anymore. They’ll ask you to spend your time teaching other people to be as good as you are. You will mourn the loss of what you enjoyed doing, but eventually you’ll start to see that a group of people you trained can get way more done than you ever could.

I’m starting to spend more time teaching people how to be good teachers and so I thought I would write down some thoughts on how to design your own training program when all you have is that you’re really good at the thing you’re teaching. This is a meta-description of how I developed the content I teach software teams, which is reproduced here on this site. I did it with software, but this is a general formula that you could use for anything (like, say, training recruiters).

Ultimately your goal is to figure out how to describe how you make decisions to other people. You get good outcomes because you make good decisions while you’re doing your work. You’re going to have to put what it is that you do into words.

Starting from a blank page is too overwhelming. I recommend you start by collecting all the things that you learned from. All the books, talks, articles, papers, blog posts, ideas and concepts you got from instructors, mentors, or other coworkers. Make your own list of aphorisms—things you find yourself saying over and over. I often remind people that if they want to learn how to do what I can do, they should learn from the people I learned from. Because after all, that’s how I learned.

Remember that some of the ideas that have had a great influence on you weren’t directly related to your craft. I was working on a training a team once where the bosses were very concerned about making the “transformation” stick this time. Their past training efforts had all reverted once the consultants were gone. I introduced the team to some of Seth Godin’s ideas on leadership and creativity, which helped them to feel confident enough to and responsible for pushing back against their own managers in public meetings. Those ideas had nothing to do with software, but are an important part of what makes me successful.

Curate this list down the concepts and ideas that have had a disproportionately high contribution to your success. The Pareto Distribution applies, so remember that 80% of what makes you great came from only a handful of places. Choose things that you find yourself talking about a lot. The best materials are anything that you have re-read/watched/consumed multiple times over the course of your career. Definitely include iconoclastic or against-the-grain ideas where you can get more success by doing the opposite of what everyone else is doing. People are much less likely to appreciate those kinds of ideas if they stumble across them on their own.

It’s a mistake to try to hide the source of all your ideas. Some people are worried it will make them look stupid if someone realizes that some of your ideas you got word for word from smarter people. That only happens if you pretend all these ideas are yours so don’t plagiarize. Encourage your students to watch/read/consume all your sources directly, or, do it with them in a classroom setting. I watch a talk with my teams every Friday at lunch and we have lots of discussion after.

You can start to transition into your own ideas by highlighting similarities and common themes between different sources. In my software talks the presenters use the terms complexity, interleaving, convexity, braiding, tangled, coupled, and generalized to refer to the exact same concept. You’re helping your students to make connections between the sources that the sources cannot make on their own, which deepens their understanding.

As you’re teaching, pay attention to the things you’re saying and notice any ideas that aren’t explicitly mentioned in any of your sources. Some of them may have come as an amalgamation of ideas from two or more of your mentors. Eventually an idea has so many parents that you can’t really tell where you got it from anymore and those are your truly novel ideas and concepts.

Ideally you’d like to distill a list of heuristics—loose rules or guidelines. The whole teach-a-man-to-fish idea is that you train people to answer their own questions. When my teams are having trouble deciding, I never tell them what to do—ever. I tell them how to think about the problem. I tell them what rules to use when making the decision.

Read The Checklist Manifesto by Atul Gawande. He describes the benefits that pilots enjoy from using checklists for absolutely everything they do and the reductions in surgical complications from using checklists in the OR. Heuristics and checklists are both decision making frameworks. They improve outcomes by helping people make good decisions more consistently.

Most people can’t explain why or how they make decisions while doing their work. This development process I’m outlining here is designed to help you flesh out the lists of heuristics that you are using when you’re doing really good work. That can be a real challenge since you don’t always need to be able to describe what you’re doing in order to be good at doing it.

Iterate. Particularly with the order in which you introduce the concepts. Notice which kinds of ideas and beliefs are force-multipliers—once your students learn them it makes it easier to learn many other things. Teach those things first.

Write it down. You won’t realize how terrible your explanations really are until they’re projected back from your computer screen. As they say in the music industry: the proof is in the tape. Read some Seth Godin and check out Austin Kleon’s book Show Your Work and see if either of them can convince you that writing down what you know can be of great benefit to the world.

Published by David Zuidema

Master Software Craftsman