Teaching within our team
TL;DR — There are a many ways to make ongoing education a part of your org. Here are a few things we’ve tried…
Olark co-founder and advisor Zach Steindler wrote this article in late 2015 about the different ways we’ve tried to encourage ongoing learning within our team.
One of my first jobs was working at a math and science day camp. My first week I was assigned to be a teacher’s assistant for two classes: help 6-year-olds with math activities, and build rockets with 12 year olds. In both cases the primary teacher was a public school veteran with 10+ years of teaching experience. “I love rockets and math…piece of cake” I thought.
Boy was I wrong.
I completely overestimated the importance of loving the subject matter and completely underestimated the importance of understanding the people you are trying to teach. It turns out in a classroom there’s a bunch of different ways to teach something — lecture, hands on activity, worksheets, reading, and many others — and it’s a skill unto itself to figure out what teaching methods to apply depending on the topic, the students’ learning style, their prior knowledge, their energy level, and a host of other factors.
At first I was baffled, but after a few weeks of struggling and some patient mentoring things were starting to click and I really enjoyed working there the rest of the summer.
All this came rushing back to me a year ago at Olark when we were in the process of adding 4 new people to our engineering team.
Everyone knows how to write code, but there’s a bunch of things specific to your organization you probably need to teach new hires, regardless of how long they’ve been in industry.
There are simple things, like:
- What technology / tools make up the stack?
- How do you know what you’re supposed to be working on?
- How do you test your changes?
- How do you deploy code?
And more complex things like:
- How is the codebase organized?
- What’s the system architecture?
- When you’re not sure how something works who do you ask?
- If you see something you want to change do you just do it? Or do you need to talk to someone first?
Nothing here is impossibly hard, but the answers usually vary organization to organization and you need some way to get everyone on the same page. The holy grail is to find teaching methods that “scale” (i.e. one person teaching many, or people learning without needing someone else’s time).
Here are some of the things we’ve tried (and some aspirational ideas to work towards):
Very popular, very ineffective. The idea is your new hires need to know information, so you sit them down and tell them what they need to know.
In practice, people learn best when engaging with the material, and sitting and listening is the lowest form of engagement. You can make this marginally better by drawing diagrams or having them take notes but there’s another subtle problem here.
People often learn by connecting new information to existing things they understand, and by the time you’re describing how the fifth wiz-bang connects to foo-sprocket your new hire is likely glassy-eyed and nodding politely.
Much better, but time consuming. Here you have a new hire and a mentor do something together — usually ship a small feature or debug a problem.
This works especially well if you give a brief overview and then let the new hire “drive” the process, so they can ask questions and you can discover misconceptions. Of course, this requires the mentor to be available to answer questions and can take a while.
Private Investigator Reports (aka Book Reports)
Say you want someone to learn something, but you don’t have any work to pair on, and you know that a lecture won’t stick.
One option is to have your new hire research the topic and then give a short presentation about it to the team. These don’t have to be anything fancy: a 15 minute presentation after team lunch or on Fridays works fine, but the act of organizing the information to present to others will help the new hire understand the material and make it stick. Plus now you have an artifact that you can share with other teammates.
We used to call these Book Reports (that was the initial inspiration), but we wanted people to really dig in with their investigation and not remind people of middle school.
This is a great way to get a team up to speed on a new tool or library. My favorite way to kick this off is to have someone give a quick overview to teach the basic concepts and then let the team dig in and make something.
You can do this in an hour or an afternoon depending on how complicated the topic is and how much time you have set aside. A fun way to conclude is to let people share what they created. These hacks don’t have to be practical — in fact the sillier the better — but having everyone share what they learned helps everyone solidify the new concepts and root out misconceptions.
Show ‘N Tells
Most Fridays someone at Olark gives a 10–30 minute presentation about something they are passionate about. Sometimes it’s about a work project, sometimes it’s about a hobby, sometimes it’s about an idea to explore. (Recently it was an original song someone had composed.)
Regardless of the content, it’s a great way for your team to deepen their understanding of the presenter, and it helps encourage a culture of learning and sharing in your organization.
Provide Materials for Self-Instruction
If you want to learn Python or Ruby on Rails, there are tons of tutorials online. But if you want to learn about how Olark’s Erlang ejabberd patches you basically have two options: read the code or talk to the organizational expert.
Documenting your organization knowledge and keeping that documentation up to date is always hard, but if you have artifacts from Private Investigator Reports (or other learning exercises) and can figure out some way to make them discoverable, this method can really scale learning in your organization.
Teaching People to Teach Themselves
Arguably the most difficult, arguably the most important. As teammates ask questions, be sure that you’re not just answering their question but also explaining the process you are using to answer their question.
If you’re helping some debug, list out all the things you think you should check, how to check them, and what the result is so they can follow along. This definitely takes more time, and it isn’t always easy to articulate your thought process, but over time it’s incredible how this can really multiply the impact your team as people get more and more skilled at independently solving organization-specific problems.
So has Olark completely solved the problem of spreading knowledge through an organization? No way! We still continue to iterate and experiment.
We aren’t always successful at all these different methods of teaching inside our organization, but even partial effort can have a big impact on your organization. This definitely isn’t a checklist — I would recommend thinking through the teaching issues in your organization and pick and choose what things you think would work best in your environment.
Don’t just model typical high school or college classroom experiences — if your culture says work should be fun figure out some way to include that value. Rapid organizational change is almost guaranteed to fail, so go slow, experiment, and stay curious!