Get Your Team Telling Stories

A few years ago, I gave a talk at the SFRails meetup. It was by far the largest group I've spoken to and a truly enjoyable experience. I titled the talk "Leveling Up Rails Developers," and it was geared towards helping engineers build a team which fosters learning and advancement of skills.

Fostering a learning culture

One of the major issues in the Bay I've been interested in lately has been getting more junior engineers into the industry. 

Our industry changes so rapidly that a constant state of learning is necessary in any team. Learning the toolchain, syntax, business, industry -- all of these topics and more. This is true just as much from a junior engineer as a senior engineer. Learning goes hand-in-hand with teaching. I personally value teaching ability over coding ability with any engineer. Learning a platform is also not necessarily a task performed by a manager, but by peers just as much.

We should be in a constant state of learning and educating. Storytelling is one method of fostering this culture.

Storytelling is natural

Narratives are a part of human culture. They cross every cultural boundary. If you go to a bar and look around, everyone is sitting around telling stories. It's the most natural method of communication we have.

"Evidence strongly suggests that humans in all cultures come to cast their own identity in some sort of narrative form. We are inveterate storytellers." -- Owen Flanagan

Dave Hoover, author of Apprenticeship Patterns, told me that he studied various organizations to get ideas of how they bring those less experienced up to speed. He told us about an interesting article studying the collective dynamics of aircraft carriers.

Dave told us aircraft carriers were a great group to parallel since they had younger recruits fresh on the boat as well as senior crew that have been there for decades. The accident rate on aircraft carriers is exceptionally low. What they didn't find was a heavy amount of documentation, rules, or mandatory meetings for new recruits. They found that information passed from the seniors to juniors simply by sitting around tables and telling stories.

I believe this is effective since it's simply so natural. Nobody has to tell the senior crew to prepare stories to tell. The junior crew listen intently since the stories are simply interesting to them. These stories are probably funny, but also have a moral subtext. A moral that might be complicated, but deep and effective.

Get your team telling stories, too!

Dave brought this onto his team at Obtiva (later sold to Groupon) through a weekly Geekfest. It's still happening at Groupon today. Each week, a member from a different team gets up to give a prepared story to the group. He said it was one of the most valuable practices on his team.

I wanted to take this a step further. I want to emphasize the natural ability of humans to give and receive narratives. On my team at Tapjoy, I started a similar practice called Alcotales. Every Friday we get together at 3:30, leave our laptops, grab a pint, and gather around a table. I try and keep the conversation around stories of failure.

Failure is a great place to start since it humanizes the senior engineers. It proves that they are not perfect. It also teaches valuable lessons to the new engineers and provides a natural "what would you have done differently" discussion. Failure stories are not often heard on a team, and usually really entertaining.

We've only had two alcotales sessions so far, so it's hard to say how effective it is. I can say that I and the rest of my team look forward to it every week. Our junior engineers have found it a valuable source of information as well.

Explain your product as a narrative

Another way to leverage the power of narratives is by using it to explain the codebase. Admittedly, Tapjoy doesn't have as easy to understand product as other companies might. This can make explaining the codebase a difficult task. One of our engineers mentioned that what helped him learn the product was to have a story to explain everything from.

Often, as engineers, we think about the component of a system and how they relate to each other. When we're learning, however, we need to think more holistically. We need to imagine what a user might be doing, and why certain code needs to be run.

If we used Hipmunk as an example, the story might be: "Molly is trying to book a plane on April 15th to Portland, Oregon." We can keep referring back to this example to make it clear how the code relates to the business.

Those are my two suggestions on how I plan on using narratives to increase the learning culture on my team. I'm curious if your team has any similar practices, definitely let me know!

Originally published February 2013

Further reading

How to Become a Continuous Learner

My 3 Step Process to Learn New Skills as a Software Developer

Storytelling in IT: Conversation Matters