August 18th, 2020
Before I became a developer, I was an educator. After college, I served a year as a City Year AmeriCorps member in New York, where I worked as a teacher's aide in a third-grade classroom in the Bronx. After that, I was a curriculum writer at two different CS education non-profits. When I decided to join ThoughtWorks as a full-time software developer consultant, I thought I was going to have to put everything I'd learned about teaching and education behind me.
But once I started actually consulting, I realized that there's quite a bit of overlap between the skills that make you a good teacher and the skills that make you a good consultant. I'm going to spend the rest of this post talking about some of the similarities I've noticed. In particular, I'll highlight three teaching strategies that you can apply to your own work:
- Start with the end goal.
- Make your thinking visible.
- Use positive framing.
When you're first starting to plan a lesson, it can be tempting to get bogged down in the details of what activities you're going to run or what examples you're going to use. As hard as it may be, resist that urge. Before you do anything, you need to zoom out and think about the big picture. What are you hoping that students will leave your session being able to do?
Understanding By Design (UbD), written by Grant Wiggins and Jay McTighe, is a widely used framework for curriculum design. It's a tool I referenced frequently as a curriculum writer. UbD argues that the main goal of education is building student understanding - the ability to transfer knowledge to other subjects or new contexts. The UbD framework helps educators create curricula that achieve this goal by working through the following stages:
- Stage 1: Learning Goals
- What skills and knowledge should students achieve?
- Stage 2: Assessments
- How will you measure success?
- Stage 3: Lesson Planning
- What activities will help students achieve the learning goals?
The authors refer to this process as "backward design." In other words, you start with the end result (what you want students to be able to do), then you figure out what metrics will indicate that students have achieved that result, and from there you decide what day-to-day work will help students get to where you want them to be.
For those of you who have been through some kind of inception phase or concept sprint, this way of thinking may be familiar to you. On any software project, it's important to understand the business and user goals before you start trying to actually build something. What are you hoping users will be able to do? What outcome do you expect to see? What metrics will show you whether or not your hypothesis is correct? Starting with these high-level questions before getting into the nitty-gritty details of writing code forces you to think through the "why" of your project. Why are you building this? Why is your chosen solution the right one (or, at the very least, the best guess)?
By starting with the end goal, you can make sure your team is building the right solution, not just the first solution that comes to mind.
As a teacher, you cannot assume that students will meet your expectations if you haven't told them what those expectations are. (Come to think of it, that's a good communication tip for any kind of relationship.) When introducing an activity, explain to your students:
- What you want them to do (Goal)
- How you want them to do it (Process)
- Why it's important (Rationale)
I want to call attention to the third piece: the "why", or the rationale. Just like with backward design, it's important to know why you're asking students to do something. But while backward design helps uncover the overall goal of a lesson, making your thinking visible is more about handling day-to-day interactions. It's about getting students to buy into the system you've created. If you can provide a convincing reason for why a task is useful or important, students will be more willing to do it.
Similarly, consultants also need to make their thinking visible to their clients. Oftentimes, companies bring in consultants to work with existing teams or projects. The company's internal developers probably have their own ways of doing things and might be apprehensive about a group of strangers coming in and shaking things up. As a consultant, it's important to build trust with client stakeholders. Being explicit about communicating your plan - and the rationale for why it's the right one - can be a helpful way to convince people to buy into your ideas.
In a classroom, just like in a client engagement, things will go wrong. Sometimes, a student will be having a rough day and won't want to participate. Sometimes, a critical bug will come up and your team won't be able to deliver a feature in time for the client's deadline. Those events can have serious negative consequences. But at the end of the day, what's important in that moment is being able to identify the next step that will put your student or your team back on the right track.
Positive framing is a technique called out in Teach Like a Champion, a book by Doug Lemov that compiles several successful teaching strategies. Positive framing is about flipping feedback around and rewording it in a way that focuses less on placing blame and more on identifying the next positive step. For example, instead of telling a student, "Don't lie on your desk," you might say, "Make sure you're sitting up." In a professional setting, this might look like telling your teammates, "Let's make sure we start meetings promptly at the scheduled time," as opposed to saying, "Let's stop being late to meetings." Both versions address the same root problem - meetings not starting on time - but the positively framed one focuses on the action you want people to take.
An important element of positive framing is "living in the now." This means letting go of things that can't be fixed. If a student missed a homework assignment, don't hang that over their head for the rest of the year. Instead, focus on the next positive step that the student can take to fix their behavior. Similarly, if something goes wrong on a client project, don't spend your team retrospective pointing fingers and trying to decide whose fault it was. Instead, work together to identify the next positive step that the team can take to correct the mistake. To help reinforce this mindset, my team has someone read out the Prime Directive before each retrospective: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what was known at the time, their skills and abilities, the resources available, and the situation at hand."
One quick callout: positive framing is not about ignoring mistakes. It's about talking about mistakes in a positive, action-oriented way. There may be times when it doesn't make sense to use positive framing - for example, instances of harrassment, violence, or theft, which require swift and absolute repercussions. But for most situations, using positive framing helps focus the conversation on ways to improve behavior in the future.
These were just three of many parallels that I noticed between teaching and consulting. What other teaching techniques do you use at work? Let me know what other advice you have for software consultants.
This post was adapted from a PechaKucha talk I gave at ThoughtWorks University in 2018.