Last December, Sam posted the following in our “37signals Newsroom” Basecamp project:
I’ve been trying out an experiment over the past few workdays: when someone asks me for help with something, I show them how it’s done.
In an on-call case, it means copying and pasting the console transcript, cleaning it up a bit, and adding some descriptive comments. ... Other situations call for a different approach. Jamie came to me with a JavaScript problem this afternoon, so we took an hour and paired together on a solution via screen sharing.
Now, the other party might not fully understand the explanation, but I think it’s a positive change to assume that everyone is curious to learn how things work rather than too busy to care. Repeated exposure to these explanations might spark an interest that would otherwise go unexplored.
And obviously there is a practical limit to the amount of time and effort we can put into such explanations. In theory, though, spreading the knowledge means the people who ask you for help are more likely to be able to solve those problems themselves.
So I invite you to try the experiment with me. The next time someone asks you to do something, walk them through your process, or write it up for them to read.
Jason chimed in:
Yes please. This is a great initiative. Whenever someone does something for someone else, let’s make sure it’s taught, too. It’ll be slower in the short term, but faster and better in the long term.
Since then, we’ve all gotten a little more conscious about teaching one another to fish. Recently, I was frustrated I lacked the skills to update basecamp.com. Mig jumped in and offered to show me some HTML and CSS basics. It’s “one of the most empowering things anyone here at the company could learn,” he told me. “I’d be more than happy to show you the ways.” Rad. Thanks, Mig.
Everyone in the company works at least one day a month answering support tickets, and the support team buddies up with non-support folks to share solutions for the more complex cases. Programmers often share the code they used to solve a problem with support, which encourages support to try to solve similar issues themselves next time. Designers and programmers swap intel all the time. Here’s what Jonas has to say about working with Trevor:
He’s continually helping me get better at programming, and has been super patient and encouraging. He frequently suggests that I tackle certain problems, takes time to help me out when I have questions, and reviews my code when I’m done.
I’ve tried to return the favor a bit by helping him work through some design problems and CSS.
I think this mutual learning approach and easy back-and-forth has had real benefits to the app, too. Even though it seems like it would be counterproductive to take the extra time, I think we’re ultimately more productive because we can work on different projects simultaneously, then chat a few times a day to figure out the remaining tricky stuff.
We weren’t not working this way before, but it wasn’t an institutionalized value or anything. Making a conscious, enthusiastic effort to work with, not for, each other, has expanded our horizons, empowered us with new skills, and made us a more well-rounded company.
Devan
on 10 Sep 13Interesting and inspirational. It’s the absolute reverse of building ‘information silos’ and ‘power kingdoms’ within a workplace. Thanks for the progress report on how this is working out, and looking forward to future feedback on this initiative.
Anonymous Coward
on 10 Sep 13This is called a Learning Management System (LMS) and it sound like 37signals is beginning to have “big company” problems … cough, cough.
Georges Jentgen
on 10 Sep 13I made a similar experience a few weeks ago while trying to teach my boss some ruby code and going through the cucumber tests. He will not be able to code, but he might grow an understanding for my work and the value I bring to the company.
Brian Shea
on 10 Sep 13Hi Emily, Get post as always. One of the things that really stands out from your post is a real egalitarian culture. In more hierarchical organizations there seems to be a subtle message that education goes in one direction: from top down. Senior people “train” more junior people.
Within 37Signals there seems to be an understanding that everyone has something to teach and everyone has something to learn. Seems obvious, but again, that’s an idea that’s not embraced at a lot of organizations.
@Anonymous Coward: what I got from the post is not that 37Signals is going in the direction of institutionalizing a formal LMS. But rather that they’re organically growing some internal best practices, based on their culture and their needs.
GeeIWonder
on 10 Sep 13Agree with most of the previous posts—and certainly communication is about telling and seeking to find time to teach, but also about listening and seeking to find time to learn.
I think that Devans/AC/Brian’s comments together with this particular case are instructive—even if very small organizations, silos can emerge and become well established (feeling the need to break them confirms their existence!)
Emily
on 10 Sep 13@Anonymous Coward, our growing pains are hardly a secret! ;) https://knowyourcompany.com
@Emily
on 10 Sep 13I would argue its a secret.
If it wasnt, then you’d link your new product KnowYourConpany at 37signals.com
(See weird to me you aren’t promoting KYC at 37signals.com)
Matt
on 12 Sep 13Teaching other people has an interesting side effect that didn’t come through in your article.
Firstly, talented people are hungry for knowledge and very prone to boredom and burnout if they aren’t learning quickly enough. Giving them an opportunity to learn new skills is a great way to keep them motivated.
Secondly, teaching is one of the best ways to hone your own skills. It forces you to distill your knowledge to its essence to be able to effectively explain it to someone less experienced. This is another great way to challenge yourself once you’ve reached personal ‘mastery’.
This discussion is closed.