I have a confession to make: I love reading business fiction. ❤️ ✨ 😄 Business fiction is a term that I’m inventing to describe a niche sub-genre of business books that have a very distinct plot, purpose, and style of writing. Sometimes people call the books in this genre business novels, but the authors of books in this genre don’t always describe their books this way and that term isn’t widespread enough to be recognizable as a genre yet. That’s why I’m coining a new term for it.

By my definition, business fiction is a genre of novels about characters who work for a fictional company and apply a set of strategies or techniques to solve a business crisis that threatens the company, often existentially. That might sound like a strange or boring premise, but these books are actually quite entertaining—and many of the books in this niche sub-genre have all become best-sellers. (You may have heard of The Phoenix Project, for example.)

In this post, I’ll describe the genre in more detail, highlight some of the most significant novels in this genre (all of which I enjoyed reading), and discuss the genre’s strengths and weaknesses in general.

In the final section of this blog, I’ll give some of my thoughts about what kinds of best practices or insights the field of technical writing can borrow from the business fiction genre.

Business fiction plot structures

Novels in the business fiction genre often have similar plot structures, roughly modeled after a three-act hero’s journey.

Act one: the challenge

The story is typically told from the perspective a single protagonist (our hero) who is promoted or forced by the circumstances into a new role at their place of employment, often against their will. The hero must overcome a significant problem that threatens their company.

The first act explores the nature of the problem by depicting the hero and their team failing (sometimes spectacularly) as they grapple with the worst effects of the business challenge.

Usually, the first act establishes the obstacles that need to be overcome and the first act raises the stakes of the novel by showing just how dire the problem really is. The storm is brewing, and the walls are closing in.

Act two: the insights

At some point, our hero usually stumbles into a chance encounter with a wise counselor who seems to possess key insights into the nature of the business problem, often through extensive personal experience. The counselor is highly confident about the solution to the problem, but they don’t share the solution directly with the hero. Instead, they offer some cryptic hints to subtly point the hero in the right direction.

At first, the hero rejects the counselor’s advice because it is counter-intuitive or nonsensical in some way. But something the counselor said lingers in their mind, and the hero puzzles over the advice long after the encounter.

Eventually, the hero has an epiphany and realizes what the counselor meant and how it was the right advice for the situation. After this turning point, the hero pleads with the counselor to give them more information. Much to the hero’s chagrin, the counselor doesn’t give them the answers outright, instead providing small hints or snippets of insights to nudge them in the right direction at different points in the story.

The hero shares their epiphany and the counselor’s insights with their team at the company, leading the team to discover new insights and gain a deeper understanding of the problem. As they discuss, analyze, and experiment with the problem together, their positive learning cycle continues.

Act three: the solution

Eventually everyone on the team commits to the solution and they implement it wholeheartedly. The third act of the novel often explores some of the hurdles or logistical challenges the team faces during implementation.

They might encounter an antagonist who tries to stop them along the way. The antagonist often represents a negative quality of the system or outdated attitudes that impede progress and need to be removed. The heroes eventually prevail in the end by winning over key allies with their sound logic and impressive results.

The novel’s concluding chapter almost always fast-forwards to a few months into the future and shows the dramatic change at the company since they implemented the counselor’s advice. All the problems are solved, the company is saved, their customers are happy, and the company has become a great place to work. Sometimes the hero is rewarded by getting a promotion or their team throws a celebration party in their honor.

The appendix

Almost all the books feature an appendix section after the main fictional portion of the novel. The appendix of the book usually contains an article or a few chapters explaining the business principles illustrated in the novel. This section of the book is written in the typical expository style of traditional business books.

For me, reading the appendix section can feel like a chore after reading the fictional portion of the book. I often skim it only for the general gist. The most effective appendices are brief and outline the main insights for easy reference.

Key examples of the business fiction genre

Docs for Developers (my entry point to the genre)

The way I first discovered the business fiction genre was by reading the book Docs for Developers by Jared Bhatti, et. al. This book is primarily a non-fiction book describing general principles that developers should follow when creating product documentation from scratch.

Although it isn’t a novel, it includes a few elements of the business fiction genre, specifically in each chapter’s introduction. Each chapter opens with a story about Charlotte, the lead engineer for the fictional service named Corg.ly, which translates dog barks into human language. Tasked with launching the service in one month, Charlotte struggles to create the accompanying developer documentation. The running narrative provides context for the technical writing principles discussed in each chapter. Charlotte’s documentation challenges ground the principles in a practical, real-world context that developers can understand and relate with.

Although I wouldn’t consider Docs for Developers to be a standard example of the business fiction genre per se, the opening vignettes in each chapter are very similar to the business fiction style. That might be why Anne Gentle compared Docs for Developers to The Phoenix Project in her review of the book. Anne Gentle is a notable figure in the field of technical writing, so when she talked about The Phoenix Project in her review, it made me curious to read Phoenix and understand why she considered it to be so influential.

The Phoenix Project

The Phoenix Project by Gene Kim, et. al. is perhaps the most famous and is one of the best-selling entries in the business fiction genre. Considered a must-read for people working in the IT space, it tells the story of Bill, an IT manager who gets promoted to VP of IT Operations at the fictional Parts Unlimited company, an auto parts manufacturer and retailer.

After Bill’s superiors are suddenly fired for their failed performance, the CEO puts Bill in charge of the business critical Phoenix Project, on which Parts Unlimited has staked its future. Unfortunately, the project is clearly doomed to fail spectacularly, threatening to take down the company and Bill’s career with it. But when a mysterious prospective board member named Erik meets Bill and points him in the right direction, Bill begins to implement DevOps best practices with his team. These principles empower the team and they are miraculously able turn the project around just in time to save the company.

Although it is not the first of its kind, this book is a major entry in the business fiction genre. It’s a fun, well-written novel that feels pretty believable. Many DevOps professionals say that this novel made them “feel seen” because it felt very much like the company they worked for and the challenges they experienced personally at work. I’ve read Phoenix twice and I frequently recommend it to new technical writers who want to better understand the IT and DevOps space a little better.

I’ve also read The Unicorn Project twice, which is the sequel to Phoenix (this time authored by Gene Kim alone). It tells the story of the same timeline as Phoenix at Parts Unlimited, this time from the development side of the company rather than the operations side. Unicorn is about Maxine, a software engineer who is forced to join the Phoenix Project. Maxine is deeply frustrated by how difficult it is to build a working development environment and by all the bureaucratic red tape she faces as she tries to get the resources she needs to do her job. She eventually joins a clandestine team of co-workers who meet in secret and call themselves “The Rebellion.” The Rebels work to implement DevOps principles in the development arm of Parts Unlimited. They help build a new system of workflows and processes that empower developers to innovate and do their best work. Unicorn is an equally fun and enjoyable read, even though the final act sometimes drags a little bit for me.

Sidebar: I don’t feel like I’m giving spoilers to any of these novels because the main joy of reading them comes the insights the characters gain and the challenges they have to overcome. It’s the experience of seeing them solve the challenges in a practical setting that makes these books enjoyable. So, I’m not “spoiling” it for you because I’m leaving those joys for you to discover on your own if you decide to read them.

The Goal

The authors of The Phoenix Project cite Eliyahu Goldratt’s The Goal as an inspiration for their novel, both as an example of the type of novel they wanted to write, but also as inspiration for the DevOps principles illustrated in their own book, which are based on the Lean methodology. As far as I can tell, The Goal was the first entry in this business fiction genre. It’s arguably even more best-selling than Phoenix as it has sold more than 10 million copies since its first publication in 1984.

This novel tells the story of Alex, a factory manager at UniCo. Facing a high-profile customer complaint and poor financial performance, Alex’s boss threatens to close down the entire plant in three months unless there is a dramatic turnaround. So, Alex has three months to improve efficiencies, cut down on throughput times, and to achieve profitability.

As luck would have it, Alex is at the airport and bumps into Jonah, his old physics professor. Jonah offers some cryptic advice that Alex continues to think about. After an epiphany in which he realizes Jonah was right all along, he puts Jonah’s advice into practice at his plant. Alex later tracks Jonah down and asks for additional advice. Over time, Jonah teaches him about the theories of constraints and Alex shares the theory with the other leaders at his factory.

At first, Alex’s team applies the theory of constraints and begin to immediately see promising results. But the new system simultaneously introduces additional logistical and organizational challenges that the team has to grapple with. With more coaching from Jonah, they are able to solve the problems and they begin to see dramatic improvements in their throughput and customer order delivery times. By the end of the book, their profits are skyrocketing and Alex is eventually promoted to regional manager.

Like Phoenix, Goldratt’s The Goal is an enjoyable read. Because of my previous background working in factory simulation software, I always enjoy learning more about Lean Manufacturing principles. The Goal illustrates the principles of the theory of constraints from Lean Manufacturing in a way that is accessible and easy to visualize working in a real factory. This novel is one of the key reasons why the Lean Manufacturing method became so widely adopted throughout factories in the US during the 1980s and beyond.

The Five Dysfunctions of a Team

The authors of The Phoenix Project also name-check Patrick Lencioni’s The Five Dysfunctions of a Team as inspiration for their novel. Written in 2002 by Lencioni in collaboration with other members of his consulting firm, this book is also a best-seller. Lencioni wrote the book to provide a concrete story illustrating best practices for building effective business teams, especially executive teams.

This novel tells the story of Kathryn Petersen, the brand new CEO of DecisionTech who has been installed by the corporate board to fix their dysfunctional executive team and improve the company’s performance. Unlike the other heroes from the other books in this genre, Kathryn doesn’t need a counselor to guide her; she already has a clear insights and an intuitive working model of how executive teams can work effectively with each other. The story unfolds over a week-long offsite retreat involving a lot of team drama. But Kathryn is able to teach them her new model and way of working together.

She eventually gets buy-in from most of the executive team, although, (spoiler alert!) a few team members don’t last until the end of the week. With the new team dynamics firmly established, the team is poised to implement effective decisions and strategies that lead to company success by the end of the book.

I enjoyed Five Dysfunctions as well, and it’s also a quick read. Patrick Lencioni is one of the most prolific authors in the business fiction genre (although he prefers to call his books leadership fables). He’s written three other leadership fables: The Ideal Team Player (which I’ve read), The Five Temptations of a CEO, and The Four Obsessions of an Extraordinary Executive. The latter two don’t interest me as much since I don’t have any executive aspirations at this point in my career and so I haven’t read them. But I did enjoy The Ideal Team Player. It’s also a very quick read, which I always appreciate.

What I like about this genre

So, truthfully, I must admit that a big part of why I enjoy reading business fiction novels offer a kind of fantasy wish fulfillment for me. It’s really fun to imagine myself in the place of the hero who is struggling with business challenges and team incompetencies, many of which I can personally relate to. And I am a sucker for stories where a protagonist gets access to gnosis (secret knowledge) that seems to magically unlock productivity, happiness, and success. It’s just fun to vicariously live out a make-believe fantasy of working for a great company with a great product and team, even if it doesn’t start out that way in the beginning. It makes me feel hopeful, as though I am just one epiphany away from solving all my problems at work.

Notice that I’ve mentioned multiple times that these books were major bestsellers and often lead certain industries to adopt the principles espoused in the novels. That’s what I think is the key strength of books in this genre: these books take concepts that would be incredibly boring in a traditional business book and then galvanize these concepts into an interesting story with real stakes and meaningful consequences. It makes it easy to see how you could apply those principles in your own company and hopefully see the same benefits.

I think this is much more effective as a teaching or persuasive tool than your standard business book. I personally loathe reading standard business books. They’re one of my least favorite genres because they’re often written in a boring, pretentious, or patronizing tone. I dread these kinds of reading assignments at work and find myself angrily arguing with the writers because of their lack of scholarly rigor and academic discipline. (“Citation needed!") Business books are often poorly supported or badly argued, and, as such, they are wholly unconvincing—even when they espouse ideas that normally I would accept as common sense. I find myself feeling knee-jerk suspicious of them.

But put that same content in a story and add some humor or drama? Suddenly I’m all ears. For better or worse, all my defenses go down and I find myself nodding along or fist-pumping as I read. And clearly I’m not alone given the overall commercial success and industrial influence of these novels.

The weaknesses of this genre

While I really enjoy the business fiction genre of story-telling and find it very compelling, I’ve already hinted at its greatest potential weakness: at the end of the day, these novels are just elaborate versions of anecdotal evidence. As fiction, the novel writers can create perfect conditions for fictional companies where, in spite of meaningful challenges, the characters adopt the principles and get a happy ending. Not every real company that applies these principles will get a happy ending and the real world is often complicated, random, and luck-based. That’s why I caution that these books are a form of fantasy wish fulfillment.

Now, I only call this a potential weakness because although anecdotal evidence isn’t strong evidence, that doesn’t mean these novels aren’t backed by meaningful hard evidence or real-world experience. Eliyahu Goldratt developed the theory of constraints as a physics professor and it was based on genuine, peer-reviewed, scholarly evidence. He merely wrote The Goal in an effort to make his ideas more concrete and accessible to practitioners. And I’d say it worked.

Gene Kim and the other writers of The Phoenix Project similarly drew on their first-hand experience and deep industrial knowledge as early practitioners of the DevOps movement in the tech industry. Like Goldratt, they also wrote Phoenix to make their ideas accessible to practitioners in the field.

And Patrick Lencioni was a consultant for several years for a wide variety of executive teams. He drew on the principles he taught as a consultant to write his leadership fables in a relatable way for his clients. Admittedly, Lencioni’s work probably has the weakest evidence to support its conclusions, relying more on his consultant group’s first-hand experiences in the field rather than empirical evidence to back up their claims. However, I also feel that the unique challenge of explaining business principles using a long-form narrative is a good initial test for the theory because it forces the author to think about more concrete logistical details. So it lends the theories a little more rigor than the random, cherry-picked anecdotal accounts that are typical of standard business books.

Nevertheless, it’s easy to see how the business fiction genre could be abused by unscrupulous writers to spread untested, unfounded, and potentially harmful ideologies with an engaging narrative. It could easily tip into propaganda without a solid grounding in evidence-based reality.

My apologies to Ayn Rand fans, but she is the main cautionary tale that comes to mind as an example of the harmful abuse of the business fiction style. I personally feel that her philosophy of Objectivism is deeply problematic and unsupported by evidence. I also strongly disagree with her moral view of the world and of humanity and find that the way she lived her personal life is further evidence of her lack of moral ethics. But books like Atlas Shrugged and The Fountainhead win over young, impressionable minds all the time. In that way, her novels showcase the potentially corruptible power of an engaging narrative that can mask a potentially dangerous, anti-social ideology. Having read her books, I find them simultaneously engaging and disturbing at the same time. I can understand why people find them compelling, even as I strongly disagree with them.

Practical application: can technical writing benefit from the business fiction genre?

Despite the potential weaknesses of the genre, I still deeply love this genre and wish authors would add more new entries in this genre. Part of the reason why I’ve read so deeply into this genre is that I sometimes playfully consider whether I’d ever like to write this kind of book someday. I suppose it would all depend on whether I ever develop a grand business theory I’d like to evangelize to others and convert them into true believers. It helps to at least study the greatest examples in the genre before venturing out on my own, right?

But beyond these unlikely personal ambitions, I wonder if there are potential practical applications of the business fiction genre in technical writing. For example, I wonder if business fiction offers insights into how technical writers can make technical documentation more interesting to read.

On my darker days, I share Neil Postman’s worry from his book Amusing Ourselves to Death: Public Discourse in the Age of Show Business. I worry that with each passing generation, the written word will become less and less relevant as video and television becomes the dominant media, displacing print media. I worry that upcoming generations will be less literate and less interested in engaging with technical documentation. And that’s a shame because sometimes reading is the only viable pathway to learn about new technologies and unlock the benefits that come from using them. Technical documentation is also one of the cheapest ways of conveying and maintaining technical information at scale, which is why I’m still gainfully employed, I suppose.

But I would be a hypocrite if I didn’t admit that sometimes my own eyes glaze over when reading some kinds of technical documentation. I can’t force myself to pay attention to boring things, even when I am highly motivated to gain the knowledge it contains. It takes tremendous strength of will to slog through dry, arcane documentation to unlock the information you need to use technology.

In a blog entry entitled Pulling readers through long documents, Tom Johnson writes about this problem for conceptual documentation. He explores the paradox that people often profess to want documentation providing a high-level conceptual overview and yet, “long, high-level conceptual docs don’t command the same reading attention as task-based docs.” Johnson describes the problem this way:

• Complexity requires detail.
• Detail requires length.
• Length requires reading.
• Reading requires time and attention.
• Time and attention are scarce commodities.
• Without more readership, the motivation to write more high-level content fizzles.

He later mentions the potential for story to resolve this conflict:

For most long texts (for example, a 200-page book with no images), writers use story as the captivating structure that pulls readers in. If a story doesn’t emerge 50 pages into a book, readers lose interest. But … in documentation, providing a story is even harder. Presumably, the conflict in technical documentation is the focus on some task… and the protagonist overcoming that conflict is the reader. But for the in-depth overview,… there isn’t a concrete goal or task to ground the reader’s attention. The reader isn’t the protagonist either, but rather a bystander.

But perhaps Docs for Developers offers a potential solution to the problems of writing engaging, story-based conceptual documentation. As I mentioned in my summary of that book, each chapter of the book starts with an opening fictional vignette about the Corg.ly service. These introductory stories provide context about how the principles of technical writing illustrated in that chapter can help solve developer documentation challenges. (And it doesn’t hurt that each anecdote is accompanied by a super cute drawing of a Corgi to add visual interest.)

In that same vein, maybe a documentation set for a given product could regularly feature stories about a fictional product user or business team that uses the product to solve their problems. And stories featuring these characters could be woven throughout the entire docset. For example, these narratives could be:

• Aligned with user personas - The characters in the fictional story could be aligned with the personas that are used to develop the product features and user stories or journeys.
• Used for page introductions - The top of each page of documentation could illustrate the practical context for the tasks or concepts taught in that page of documentation from the perspective of the fictional characters (personas) and tie into the overall narrative. These narrative-based sections could be expandable/collapsible for readers who want to skip them and get to the main content. Or they could be offset visually in some way to make them easy to scan over quickly.
• Used for examples and illustrations - If the technical documentation could benefit from an example that illustrates the task or concept being taught, it could use an example featuring these same fictional characters with a believable task these characters might realistically try to solve.
• Write conceptual documents as stories instead - Perhaps technical writers could experiment with writing conceptual documentation in the more engaging narrative style of business fiction, teaching the concepts by telling a story about the real-world contexts in which the concepts would be applied. The end of the document could feature a summary of the concepts, similar to the appendix sections of these business fiction books.

The main advantage of this approach is that it would be a cohesive, consistent narrative that ties the product documentation together. I also think it would give the documentation a spark of personality that if often missing in corporate writing. The users could potentially find these characters relatable and see themselves in the story. And, well, this kind of technical documentation might just be more fun to write.

I imagine that the main disadvantage of this approach would be navigating reader’s mismatched expectations. Readers typically don’t expect to come to technical documentation for a narrative and they could feel frustrated or angry at documentation by the surprising shift in tone and content. They might also find the narratives patronizing, silly, or out of place in “serious” technical documentation. I think that would be a real risk of adopting this style, which is why I would feel hesitant to experiment with it myself without first heavy deliberating it with my team or running some A/B experiments.

At the same time, I think the idea might have some merit, and could possibly have practical applications for other kinds of dry technical content, such as work presentations. One time I gave a presentation at work about a guide my team had created about how technical writers can effectively work with UX. To make the presentation more engaging, I turned our guide into a story about Perry the Pineapple, a technical writer who needs to engage with Salem Strawberry to ask if the documentation team could be involved earlier in the product development lifecycle.

We were able to cover some of the main points we discussed in the guide in an engaging style that received good feedback from our audience and stakeholders. I personally think the presentation would have been much more snooze-inducing if it were presented in the normal bullet-points lecture mode. I must also admit that as I created the visuals for Perry’s story, I was often surprised by my own empathy for this cartoon pineapple’s feelings and my own odd sense of emotional attachment to the cast of characters. Perry’s distressed faces genuinely made me feel mildly sad every time I looked at it. I suppose it’s true that humans will pair-bond with anything.

So, let me know if you decide to experiment with incorporating the narrative form of business fiction in your writing and speaking events and feel free to share your feedback with me. In the meantime, consider reading some business fiction novels yourself. I hope you enjoy them as much as I do!