Hey, readers. Week-before-last, I wrote the first question (Who benefits?) in what I was hoping would be a series of posts about questions I turn to frequently.

But last week, I didn’t write to you at all. The inspiration to write that second post in the series just wasn’t there. I also had a bit of a time-and-energy-depletion situation. Let’s just say that my best words of wisdom for you last week were to avoid ever needing a root canal.

This week, I wrote a post for you in that questions series. The post just wasn’t interesting enough with one question, so I included two. However, it also wasn’t interesting enough with two questions.

Fortunately, at least once or twice a week, something I read on Slack (here or here for example) motivates me to write a reply just long enough that I think “you know, this is getting to be more like a blog post than a Slack message.” Instead of posting it, I send it to myself in an email to remind me to share it with you.

Like this:

On “war stories” as skill-building

I just finished reading the book The Skill Code, by Matt Beane. He argues for the importance of experts and novices working together, and he outlines challenge, complexity, and connection as essential to skill development. We need to work just at the edge of our ability, we need to be able to see the bigger picture and not just our little piece, and we need the relationship with an expert who can guide us (and the experts likewise need novices).

Two people looking at a computer

Photo by Desola Lanre-Ologun on Unsplash

Along the way, he mentions “war stories” as a way of passing on knowledge to junior colleagues. Stories like: “when the customer inadvertently set their system date to 20007 instead of 2007,” for example.

Yes, that really happened. They noticed the error promptly, but the system noticed it immediately and had an unpleasant reaction in the time it took for them to get back in and change it.

I hadn’t really considered that sort of storytelling as having a skill-building purpose before. Relationship-building, sure. But now I’m intrigued by that as an opportunity for learning.

For example: What were the repercussions? (The system immediately started to try to get “caught up” because a whole bunch of medication orders suddenly appeared to be 18,000 years overdue.) How was the mess cleaned up once the date was corrected? Did a developer need to get involved, or could customer service handle the fix?

Why is a five digit year even possible? Maybe most importantly: What will we do to keep that from happening again?

Newer people can learn quite a bit about how the software works and fails, and how the company works to handle a problem like that. They’re gaining a little institutional knowledge and building the relationship with the person telling the story.

Footnote about that story: the customer asked the service specialist if they would have a problem because of this mishap when they reached that date in 20007. It’s fun to think of answers to that question…

Drop me a note

This blog might be shorter, or not quite weekly, for a while. I need to spend more time on writing draft book content, and less time on writing polished blog posts. Once I get to a point where I have enough book content written, I will share sneak peeks of that with you.

I would love to hear from you. Hit reply and let me know what’s on your mind and how this week’s message landed with you.

I read every message and reply when I can!