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.