Share stories, not advice.

A few years ago I was trying to figure out how to incorporate product management techniques into infrastructure engineering, and I had the very good fortune of having Astrid Atkinson answer a few of my questions. I explained a challenge I was having and asked for her advice, and was surprised when instead of answering Astrid asked, “May I share a story?”

While I was surprised by that response, I’ve spent a lot of time reflecting on it, and have tried to copy it. These days I try to share stories instead of giving advice, especially in circumstances where I’m missing most of the context. It seems like a simple adjustment, but sharing stories is much more impactful than giving advice.

When you give advice, you’re sharing the output of your experience-trained mental model. This is helpful, but at a certain point in one’s career, folks learn to be justifiably suspicious of answers that don’t “show their work.” It’s great that you solved the problem that way, but why? Stories focus on the why, sharing the experience and context around the decision and results.

Stories also eliminate most of the least productive follow-up conversations after giving advice, where the advice-requester then argues against the advice. Stories relieve the advice-giver from the obligation to defend their advice. There’s nothing to agree or disagree with, just a recounting of past events.

This technique can be applied beyond the narrow context of giving one-on-one advice, and I’ve found it particularly useful in larger group discussions (caveat: must be able to tell concise stories), allowing you to introduce your experience with less chance of derailing into argument or running afoul of folks’ mental filters that weed out statement in the format “when I was at $PREVIOUS_COMPANY, we…”.

It can, of course, also work to tell the story first and then segue into some advice.