Storytelling seems to have a bit of a PR problem in the tech industry: it sounds just like the soft skill stuff that is limited to marketing/communication people. But storytelling is more useful than you’d think. Here are five ordinary moments in an IT professional’s working week when it earns its place, without anyone having to call it storytelling.

Here’s an experiment. Go to any tech forum, Reddit or Blind or Hacker News, pick one, and search for a thread about storytelling, or communication, or “soft skills”. Give it ten minutes. Somewhere in the replies, usually with a healthy number of upvotes, you’ll find a developer who is asking if the whole thing is overrated and whether it does anything at all for their career.

I have a lot of sympathy for that developer, I really do. Their time is limited and their backlog is full. Probably, nobody has ever made the case to them in terms they care about. So underneath the dismissal I sense a reasonable question: what’s in it for me?

This reminds me of the scene from Monty Python’s 1979 film Life of Brian where Reg, leader of the People’s Front of Judea, demands to know “what have the Romans ever done for us?” and his own followers keep ruining the rhetorical question with practical, rational answers. The aqueduct. Sanitation. Medicine. Roads. Wine. By the end the poor man has almost lost the plot.

So: consider this my list of aqueducts.

I’ve written before about why your brain is built for stories and how storytelling fits into an Agile sprint. Both lean a little on the theoretical side, true. This one doesn’t. This is the practical, what’s-in-it-for-me edition: five specific situations in a normal IT week where telling a story deliberately, with a goal, can save you time, spare you a headache, or get you the thing you were after.

No narrative theory exam required. You have my word.

1. You’ll write documentation people actually read

Raise your hand if you love writing documentation. Yeah, I thought so. But you’ve all written the page that lists every config field in alphabetical order and explains precisely nothing about why anyone would touch them. And you’ve all abandoned someone else’s version of that page just a few lines in.

It isn’t a small tax, either. McKinsey once estimated that knowledge workers spend close to a fifth of the working week just hunting for information, and a fair slice of that is people lost in product docs that never made it clear what they were looking at.

Adding on more detail won’t save it, but a bit of storytelling might.

Good documentation answers the same questions a story does, in roughly the same order. Who is this for? What are they trying to do? What goes wrong without it?

A README that opens with “this service exists because checkout used to crash every time traffic spiked on a Monday” tells you more in one sentence than a feature list does in a page. You already know the villain (the Monday spike), the stakes (checkout, i.e. money), and why it’s worth reading on.

Think about who’s really on the other end of your docs. Often it’s future-you, at 2am, mid-incident, trying to remember how this bloody thing works while a dashboard glows an unfriendly red.

That person is the hero of your documentation. Write for them, hand them the problem before the parameters, and they’ll read to the end, because for once it makes sense that they would do that.

2. You can get your point across in half the time

I know the objection before you say it, because I’ve heard it many times: we don’t have time for stories, we have a release on Thursday (no, we still don’t do releases on Fridays). Engineers, as a species, hate watching time get wasted away in a meeting room, and I respect that enormously.

So here’s how I would phrase that to make IT people interested: a story is the most compressed format you have, far closer to a shortcut than to the long way round.

Picture the meeting where you need a yes from a skeptical stakeholder; let’s call him Patrick, since Patrick the project manager has been my favourite character in these articles for a while now. You could give Patrick ten bullet points on why the team needs two sprints to focus on technical debt. He’ll nod, remember none of it, and ask you to “table this for later” and “circle back” when it’s more convenient. You’ll nod, try again a few weeks later, with the same result.

Or you could tell him about the night the database migration failed because nobody had touched that corner of the code in two years; the four hours the entire team spent fixing it until dawn; the apologetic customer email that went out the next morning.

Then follow up with: “That’s the thing this refactoring prevents.” One short story, one clear ask. Patrick now feels the cost, which is a lot more persuasive than being told what it is.

Fewer meetings, clearer message, and a faster yes. Here you go. The story did the compressing for you.

3. You can bring a new joiner up to speed without drowning them

Onboarding is brutal, and we tend to make it worse with sheer volume. The new developer arrives and we hand them the link to the company’s wiki, a complex diagram of microservices (that somehow is still incomplete), and our sincere best wishes. They spend their first week memorising fancy words with no clue how any of it works together.

And the clock is not on our side: Gallup reckons it takes a new hire around twelve months to reach full performance in a typical role, and other industry estimates put software developers specifically somewhere in the six-to-twelve-month range.

They have plenty of information. What they lack is the story that ties it together.

Before explaining the architecture, tell them the product story: who this thing is for, what life was like for those people before it existed, and what we’re actually trying to help them achieve.

Once a new joiner knows the whole sprawling system exists to get a particular kind of user out of a particular kind of misery, those microservices now have a cast and a plot. Each one has a job to do in the story, and they can see how it fits.

This, by the way, is why I lobbied for a proper “product story” session in the first week of every new hire’s induction, which was appreciated by all my fresh colleagues. One hour of storytelling can save weeks of confusion.

The new joiner is the hero here, and you’re the guide handing over the map. Give them the map’s legend first – what everything is for – and the territory makes sense a lot faster.

4. You’ll mentor without sounding like a lecture

Nobody likes being lectured, and juniors least of all, because a lecture tends to be perceived as “here is a list of everything you did wrong”. Storytelling is how you pass on hard-won experience without pushing anyone’s buttons.

Some time ago a colleague of mine, a very talented front-end developer, came out of a project convinced he’d failed. It was the first time he’d led the end-to-end implementation of a content management system that ended up shipping about three months late, with numerous reconfigurations of the initial information architecture. He’d filed the whole experience under “personal failure” and tried not to think about it again.

What actually helped was retelling it. We sat down and walked through the whole thing as a story: where it began, the forks in the road where the timeline slipped, what the team knew at each point and what they couldn’t have known yet, how they fixed it, and how it ended: shipped, used, and running perfectly fine to this day.

Laid out with a beginning, a middle, and an end, it turned back into what it always had been: a string of reasonable decisions, most of them sound, one or two worth learning from. The lessons were sitting right there once the shape of the story was visible.

There’s an old truth that you only really understand something once you’ve had to explain it to someone else, appropriately called “the protégé effect”. Telling the story of a project (yours or a junior’s) is how the lessons get pulled out of the rubble. You become the wise mentor not by dispensing wisdom from a pedestal, but by helping someone narrate their own experience until the wisdom surfaces on its own like a freshwater wellspring.

The junior is the real hero. You’re just the one holding the lamp.

5. You’ll attract people who actually want to do the job

Most job ads are interchangeable. “We’re looking for a rockstar engineer to join our fast-paced team and own the full stack.” It tells a candidate exactly nothing, because every other ad on the page says the same words in the same order.

Try telling the job description as a story instead. Here’s the system you’d inherit; here’s the corner of it currently held together with tape and prayers; here’s the user waiting for someone to fix it, and here’s what their Monday looks like once you do.

A candidate reading that can picture themselves in the role and see the actual problem they’d get to solve; and the people who light up at exactly that problem are the people you want applying.

A vague ad pulls in everyone and no one; a specific story pulls in the right few. And the right few matter, because replacing the wrong one is pricy: SHRM puts the cost of replacing an employee at anywhere from 50% to 200% of their annual salary, depending on the role, and a generic advert is a dependable way to start down that road.

The same goes for the times you find yourself in front of a university room full of students. Don’t read them your tech stack. Tell them what your team is building and who it’s for, the messy thing at the centre of it, the part that’s genuinely hard and genuinely interesting. Students have heard “great learning opportunity” enough times for the phrase to mean nothing. They have not yet heard your story.

In a hiring story, the candidate is the hero you’re casting. Show them the quest honestly, and the right ones will put their hand up.

So, what has storytelling ever done for you?

Let me line up the aqueducts. Documentation that your engineer reads to the end. Meetings that finish early because you made your point clearly. New joiners who grasp the why before the what. Juniors who walk away from a rough project with lessons instead of bruises. Job ads that pull in the people you were hoping would apply.

Not bad for the soft, mushy stuff.

Here’s what I’d leave you with, though. None of this is a new skill you have to go and install. You already tell stories all day: you do it when you explain to your partner why the release ran late, when you recount the outage over lunch, when you talk a friend into a restaurant they weren’t interested in.

It’s about the most human thing you do. The only difference between that and what I’ve described is aim: doing it on purpose, for a particular person, toward a particular goal.

And if you look back across all five, there’s a single thread holding them together. In every case, the hero was someone other than you: the engineer reading your docs, the stakeholder in the meeting, the new joiner, the junior, the candidate. That’s the basics of storytelling.

I’ll never get tired of saying it: a product is a story, and the user is always the hero. As it turns out, the same is true of nearly everything else we build, teams included.

So this week, catch yourself in one of these five moments and tell the story on purpose, just for once. See what happens. Or wander through the rest of the storytelling-in-tech series if you fancy a few more aqueducts.