I was trying to describe to somebody what it is that I do in relatively specific terms—a task that proved to be immeasurably more difficult than it should be—and I was casting about trying to find some way to convey what it is that I actually accomplish. I know what I do, I’m there for pretty much all of it, why would it be so difficult to summarize in any meaningful way (or, more to the point I guess, in a way that is meaningful to people that don’t do the same thing). After a series of increasingly embarrassing false starts and fumbled trail-offs, I staggered into a description that I feel is pretty close.

I am a story teller.

When I teach, I teach through metaphor and anecdote. Facts are fun—I love them and they are necessary—but facts don’t teach, they inform. Building a connection to facts, that is how we learn. That is how everyone has always learned (give or take a few). So rather than spew a list of concepts, methods, or algorithms at my class, I teach by using stories to build those connections. I tell stories about how I used this function wrong and it yielded a comical result. I talk about how mis-application of some idea ended in tragedy. We, as a class, explore examples of certain algorithms in our daily lives. We weave stories in order to build context for the facts in our minds and so that we can retain them.

I’m no less a story teller when I develop software.

When developing software, I have to be a master storyteller if I want to do a great job. I can’t tell the story, I have to help the customer—the end user—tell their story. I have to elicit from them how they think they do work; then I have to dig deeper and get them to convey how they actually do work. Through anecdote and informal chatter, I draw out context for otherwise disjointed facts like “I want it to be busier” or “the old way was just too clustery.”

Once I’ve helped the user build their story, I build my complementary story. I take what they have taught me and spin it into my own tale using code and graphics and requirements documents. I deal it back to them like a serial novel—pieces at a time in a way that allows me to gauge their reaction and keep their interest engaged. By the time they have seen the story in total, there should be precious few surprises (and among those precious few, only good ones) but a great deal of satisfaction with the denouement.

This is why it pains me to see the artless, engineering way to do requirements analysis. I cannot do my best work as I slog through a checklist of context-less questions and categorized facts. I need connection, and so does the client. In my experience, we are all infinitely better off sitting down together and listening to one another’s story with a checklist as a backstop to ensure that all bases have been covered than to rigidly adhere to a few hours of discovery done in a conference room.

So I’m not a software developer. I’m not an educator, a father, a manager, or a leader. I’m a story teller; I suspect that your software developers are yearning to be one too. Do yourself a favor and help them get there.