How I work with someone who is learning

Image by Young Hahn

👋 I work on the Platform team at Mapbox, which is responsible for building and maintaining the infrastructure that powers all of our customers’ applications. Every day, members of our team are learning technical concepts — often javascript, AWS, or specific parts of the Mapbox stack. These are my rules for when I’m working with somebody who is learning, whether it’s a recruit, a new hire, or a teammate who is scaling into something new:

1. They do 100% of the driving, even if it’s slow-going. No matter how harmless it may seem to you, taking control of someone’s keyboard or mouse is disempowering to them. It says: You are not capable of solving this problem. Use your voice to dictate directions (even to spell out words or syntax). If the problem you’re running into is out-of-scope, explain why & how, and help them navigate to a landing place where you can do a hand-off via git. Similarly, be wary of explaining something via you doing it on your computer — this has a low success rate.
2. Start with tests. Most people are already familiar with articulating desired outcomes — do it in English and then turn those expectations into code, together. Starting with tests provides structure and continual guidance. Tests chart a clear path for your work — points of reference that are not ephemeral like voice.
3. Always respect the way they approach a problem, even if it is different from your approach, unusual, or likely won’t scale past the immediate need. If they are headed towards a dead-end, explain the challenges they may run into, and let them make their own conclusions. Again, starting with tests will ease the mechanics around this. If you really want them to do it “your way,” explain why your approach makes sense to you. Don’t frame this in terms of “right and wrong” or “best practices.” Don’t worry about optimizing or style until there is an explicit need.
4. Use exclusively positive language. If somebody mistypes or otherwise makes a mistake, try not to say no, not like that, that’s not going to work, or your parentheses are wrong. Instead, say whoops, I meant x, instead of y, let’s try z, or heads up, you may run into trouble with the parenthesis on line 34. Avoiding directly negative language creates a sense of we’re in it together rather than you’re on your own.
5. Let them fail. Even if your code eyes can see a syntax error, out of place callback, or unparsed object ahead of time, let them experience failure and the valuable debugging that comes after the fact — this is where learning happens. First let them try to debug, then offer tips on how to debug (I wonder what you’ll see if you console.log ‘data’ on line 52), then describe the problem generally — try to get them to find the solution via context instead of pointing to it directly. Don’t abandon them here to “tough it out,” but don’t swoop in and fix everything.
6. Be happy about errors. Model a positive attitude towards error messages and test failures. Mostly, code fails right up until it works, so it’s important to associate code failure with grit & opportunities for growth. Try to disassemble and reframe negative reactions.
7. Be vulnerable, too. They are already in an incredibly vulnerable place, and you’ll move faster if you can meet them there. Speak of mistakes you’ve made, your learning experiences, and things that are hard for you. You don’t need to know all the answers — you’re not an expert. Be upfront about the pieces that you’re still unsure of. When you need help, show them how you get assistance from others — set an example.
8. Explicitly give them positive feedback. This is the fuel on which learning and risk-taking runs. Push them and show them how to get even better, but don’t do this without a healthy dose of positive feedback. Some examples: by the way, you’re doing great, this is hard — and you’re picking it up quickly, thank you for working on this, it’s awesome, I’m really enjoying working with you. Prioritizing personal growth is a risk — you need to make it clear why they should continue taking that risk.
9. Find a work style that works for them, and gently scale that. Prioritize in-person, and err on the side of too much attention early on. Then slowly back off as you both get more comfortable with the arrangement. I’ll often start by writing up a very detailed gist or ticket about what we will be working on together — including as much detail, examples, and starter code as they may need. Be explicit about what success looks like and how you’ll know that you’re ready to move on to the next thing. Capture your thoughts really well once, and this will be a reference point they can use over and over again.
10. Check in early and often. Go grab a coffee after you’ve been working together for a couple days. Ask for feedback — what’s working, and what isn’t? Dig into their experience and what they want & need.
11. Be relentlessly positive, patient, and calm. Be an emotional rock — level out somewhere around these qualities and refuse to budge.

The Mapbox team has used this list to focus on actionable, concrete steps to help people learning technical concepts. How do you support team members who are learning?