Learning Frameworks for Developers: Gradual Release Model

Meetings are teaching. Knowledge transfer sessions are teaching. Onboarding is teaching.

Unfortunately, we don't typically arm professionals with pedagogical skills. That means those meetings, knowledge transfer sessions, and onboarding usually fall drastically short of their goal and sometimes they're a total flop.

I was a teacher and in a lot of ways I still am because I apply the principles and practices I learned in my time in education to my presentations, meetings, and pairing sessions as an engineer and developer.

In this series, I want to share three frameworks that can help you structure your meetings, presentations, lunch and learns, or any knowledge transfer session to ensure that your audience has a clear understanding of what your takeaways are and that the information you share really sticks. In the first post, I talked about the 5E Model - Engage, Explore, Explain, Elaborate, Evaluate. In this post we'll go over the Gradual Release Model.

The Gradual Release Model

I do. We do. You do. Also known as model, coach, fade. Also known as model, guided practice, independent practice (terms you'll see in the next post when I talk about the Hunter Lesson Plan).

When would this be most applicable: Any time you're introducing a new skill or concept or practicing a skill or concept. This can be done 1:1 or in a conference presentation or talk.

Girls washing dishes https://nappy.co/photo/1864

I Do/Modeling

This is when you demonstrate a skill or objective while the learner watches. For example, if I'm going over an intro to Terraform I would show my audience how to set up the main files I need and run terraform init. From my experience, most folks are pretty solid in this area. We can demonstrate the skills we're trying to teach someone.

We Do/Coach/Guided Practice

It's this step that is typically missing. The purpose of the coaching or guided practice "we do" step is to give your learner an opportunity to practice with training wheels. It's important to underline what this DOESN'T mean.

This DOESN'T mean that you point out every place where they're not doing it exactly like you would do. It doesn't mean that you correct every error on the spot.

The goal is for them to complete the objective. If the objective is for them to set up the necessary terraform files to start a project, let them do it as you watch. Let them know you're there to answer questions and give a push if they seems stuck, but it's a chance for them to walk through the steps WITH SUPPORT.

In a larger group setting, this could also look like going through the set up of the Terraform files and then stopping strategically to ask, "What should I do next?" or "Is there anything I missed or did wrong?" Making deliberate mistakes is also a good opportunity to check with your learner and make sure they genuinely understand and are following what you're saying. It's not meant to be a gotcha moment. If you make an intentional mistake and they don't catch it, point it out yourself and tell them why it was a mistake. For example, "I forgot the closing bracket when I added my provider, that's going to cause problems for me later." Another option is to let the mistake ride and wait for the system to catch it. If I run terraform init and I'm missing the closing bracket it will complain or throw an error and then we can go together to try to find the error.

You Do/Fade/Independent Practice

We tend to skip from model to independence which results in a lot of frustration for the learner and the teacher. This is because the teacher feels like, "Ugh I showed you this already," and the learner feels like, "I just didn't get enough practice to be independent." It takes repeated exposures to really solidify the learning and understanding of a concept. Recognition of a concept isn't the same as the ability to teach it.

Another place we have a gap in teaching skills as tech folks is understanding and recognizing the difference between understanding a high level concept and being able to actually implement it with a specific language or framework. I can explain the concept of microservices but that doesn't mean I can build a microservice with Rust. Make sure your learner has ALL the information they need to be successful.

Back to independent practice, if a learner goes off to do independent practice and still requires support, that's fine. IMO there isn't enough repetition of skills and practice before we send someone out into the wilderness to code alone. Another reason pairing can be so powerful and helpful is you're always in "we do" mode. The danger is making sure that when someone is working independently, they DO have the skills to do it themselves. Sometimes once we're on our own we realize what we don't know and also that we don't know some things as well as we thought we did. Make some time for coding alone for that truly independent practice time.

Git

Let's do another example with git.

I Do/Modeling

Here I'm modeling how to clone a repository. It's also important to break things into the smallest chunks. The worst thing that will happen is your learner feels an immediate sense of accomplishment and confidence at how easy they feel the steps are. It's like in video games - the first levels and enemies are usually pretty easy and then it gradually ramps up. It's ok to break things down too small. On the other side, if you put too much into a step it can become overwhelming and frustrating for both you and the learner.

We Do/Coach/Guided Practice

While I'm not right by your side, I can provide documents that offer support (also you can always hit me up on twitter). Using the steps in this lookbook, you should be able to clone that same repository. It's also embedded below if you don't want to make your own copy.

I should note that this lookbook covers FAR more than just cloning a repo. Feel free to go through and use, enjoy, share, copy, and/or remix it. It's designed to be pretty self-directed and it demonstrates similar patterns as I've talked about today and in the last post.

If this was a talk, I might ask, "Before I paste the url for the repository, what command do I have to type?" If this was a lunch and learn or a workshop, I would do as I'm doing here and have people copy the lookbook and work in pairs or teams for support. You don't always have to be the coach.

You Do/Fade/Independent Practice

Find another repository on GitHub or GitLab and clone it with the same command. You as the learner now has an opportunity to test out your skills. Similar to the Evaluate step of the 5E process. You're thinking about what you've learned and trying to decide if you feel you really have a handle on it or if you need more practice and support.

Biggest Takeaway

As the teacher, it's so essential to be intentional about getting that coaching step in. You have to step back from the keyboard and let the learner take the lead without micromanaging all the choices they make. Let them bump their heads a bit, let them make mistakes and get the natural feedback before jumping in. Ask questions like: