Editor’s Corner: How to Write a Book Introduction

One of the most important elements in a book is the introduction. This is your first and, perhaps, only chance to hook your reader and convince them that they should devote 8-12 hours of their valuable time to reading your book instead of the stack of unread books on their bedside, the endless checklists on their computers at work, or the queue of shows on their streaming accounts. 

It can also be the best place to start if you’re looking to sit down and write your first book. Why? Because this is a great opportunity to hone your idea and focus on it. If you have too many or too few ideas, a well-crafted introduction will help you determine the scope of your book.

A good introduction should contain a (1) hook, a (2) problem statement and solution statement, and (3) supporting evidence. It will also often identify who the audience for the book is and establish the authority of the author (why the reader should listen to them).

Next, we’ll walk through these elements in a little more detail and use examples from the introduction to the second edition of The DevOps Handbook to illustrate.

Hook

The Introduction should start with a hook. The hook…well…hooks your reader. It is usually a story, fact, or example that illustrates the pain point that your book is looking to solve. It should be provocative or funny or somehow challenge your reader’s assumptions.

In The DevOps Handbook, the hook starts by painting a picture of a different world:

“Imagine a world where Product Owners, Development, QA, IT Operations, and Infosec work together, not only to help each other, but also to ensure that the overall organization succeeds.”

The initial hook is then reinforced by showing readers the potential benefits that could be achieved in this new world. The authors will point out many of the common pain points they know their readers are experiencing.

“By working toward a common goal, they enable the fast flow of planned work into production (e.g., performing tens, hundreds, or even thousands of code deploys per day), while achieving world-class stability, reliability, availability, and security.

In this world, cross-functional teams rigorously test their hypotheses of which features will most delight users and advance the organizational goals. They care not just about implementing user features, but also actively ensure their work flows smoothly and frequently through the entire value stream without causing chaos and disruption to IT Operations or any other internal or external customer.

Simultaneously, QA, IT Operations, and Infosec are always working on ways to reduce friction for the team, creating the work systems that enable developers to be more productive and get better outcomes. By adding the expertise of QA, IT Operations, and Infosec into delivery teams and automated self-service tools and platforms, teams are able to use that expertise in their daily work without being dependent on other teams.

This enables organizations to create a safe system of work, where small teams are able to quickly and independently develop, test, and deploy code and value quickly, safely, securely, and reliably to customers. This allows organizations to maximize developer productivity, enable organizational learning, create high employee satisfaction, and win in the marketplace.

These are the outcomes that result from DevOps.”

By the end of the hook, any reader who has been feeling the pain of a siloed organization is intrigued by the possibility that there could be a different world. A better world. They are, at the very least, intrigued to read on.

Problem and Solution

In the business nonfiction realm, an important step is to craft your problem statement and your solution statement. This is the core purpose of your book. What pain point are you addressing, and what is your solution?

It sounds simple, but this is usually the number one problem we see with early drafts of books: they lack a clear problem and solution statement. Without this, there is no clear purpose to your book, and there’s no clear reason why a reader should pick it up and devote hours of their time to it. 

Start here and post your problem and solution statements somewhere you can easily see them. Refer back to them often throughout your writing to keep your ideas focused.

In The DevOps Handbook, they present the problem statement thus: 

“For most of us, this is not the world we live in. More often than not, the system we work in is broken, resulting in extremely poor outcomes that fall well short of our true potential. In our world, Development and IT Operations are adversaries; testing and Infosec activities happen only at the end of a project, too late to correct any problems found; and almost any critical activity requires too much manual effort and too many handoffs, leaving us always waiting. Not only does this contribute to extremely long lead times to get anything done, but the quality of our work, especially production deployments, is also problematic and chaotic, resulting in negative impacts to our customers and our business.

As a result, we fall far short of our goals, and the whole organization is dissatisfied with the performance of IT, resulting in budget reductions and frustrated, unhappy employees who feel powerless to change the process and its outcomes.”

The problem is clear and concrete. Dev and Ops are adversaries, which makes life…well, suck. It’s easy to identify with the problem and hard to argue against it.

Next, the authors provide their solution statement:

The solution? We need to change how we work; DevOps shows us the best way forward.

Pretty simple. The solution is to change the way we work. That’s clear to understand and identifies exactly what the reader will learn about in the rest of the book: how to work better.

But the authors don’t leave it there. Afterall, we can’t just take their word for it. So this is where we need to provide the reader with supporting evidence. This could be in data, case studies, personal stories, etc. 

Here’s the supporting evidence from The DevOps Handbook:

“To better understand the potential of the DevOps revolution, let us look at the Manufacturing Revolution of the 1980s. By adopting Lean principles and practices, manufacturing organizations dramatically improved plant productivity, customer lead times, product quality, and customer satisfaction, enabling them to win in the marketplace. 

Before the revolution, average manufacturing plant order lead times were six weeks, with fewer than 70% of orders being shipped on time. By 2005, with the widespread implementation of Lean practices, average product lead times had dropped to less than three weeks, and more than 95% of orders were being shipped on time. Organizations that did not implement Lean practices lost market share, and many went out of business entirely.

Similarly, the bar has been raised for delivering technology products and services—what was good enough in previous decades is not good enough now. For each of the last four decades, the cost and time required to develop and deploy strategic business capabilities and features has dropped by orders of magnitude. During the 1970s and 1980s, most new features required one to five years to develop and deploy, often costing tens of millions of dollars. 

By the 2000’s, because of advances in technology and the adoption of Agile principles and practices, the time required to develop new functionality had dropped to weeks or months, but deploying into production would still require weeks or months, often with catastrophic outcomes.

And by 2010, with the introduction of DevOps and the neverending commoditization of hardware, software, and now the cloud, features (and even entire startup companies) could be created in weeks, quickly being deployed into production in just hours or minutes—for these organizations, deployment finally became routine and low risk. These organizations are able to perform experiments to test business ideas, discovering which ideas create the most value for customers and the organization as a whole, and which are then further developed into features that can be rapidly and safely deployed into production.”

Urgency

A secondary element of your problem and solution statement should be to give your reader a sense of urgency. Why do we need to solve this problem today? Afterall, if it’s a problem but not necessary to solve any time soon, then I don’t need to read your book, right?

In The DevOps Handbook, they frame the urgency of the problem clearly with:

“Today, organizations adopting DevOps principles and practices often deploy changes hundreds or even thousands of times per day. In an age where competitive advantage requires fast time to market and relentless experimentation, organizations that are unable to replicate these outcomes are destined to lose in the marketplace to more nimble competitors and could potentially go out of business entirely, much like the manufacturing organizations that did not adopt Lean principles.”

The implications of not solving the problem quickly are clear; you could be left behind in the dust. Better to invest a few hours of my life reading this book and see if it can help me solve this problem as it promises.

Once again, the authors support this statement of urgency with supportive evidence. Don’t assume that your reader should take your word for it. Reinforce the information you present with independent data, research, stories, etc.

“These days, regardless of what industry we are competing in, the way we acquire customers and deliver value to them is dependent on the technology value stream. Put even more succinctly, as Jeffrey Immelt, CEO of General Electric, stated, “Every industry and company that is not bringing software to the core of their business will be disrupted.” Or as Jeffrey Snover, Technical Fellow at Microsoft, said, “In previous economic eras, businesses created value by moving atoms. Now they create value by moving bits.”

It’s difficult to overstate the enormity of this problem—it affects every organization, independent of the industry we operate in, the size of our organization, whether we are profit or non-profit. Now more than ever, how technology work is managed and performed predicts whether our organizations will win in the marketplace, or even survive. In many cases, we will need to adopt principles and practices that look very different from those that have successfully guided us over the past decades.”

At this point in the introduction, you have two choices. You can move on to the next section of the Introduction, or you can dive deeper into the problem and solution. It depends. You want to keep the first part of your Introduction short and to the point to hook readers in. But once they’re hooked, they ask questions and try to poke holes in your theory. This is where you can elaborate more on the problem and solution to reinforce what you’ve presented or leave that reinforcement for the first chapters of your book.

In The DevOps Handbook, they dive deeper into the problem and the solution in two large sections full of concrete examples and statistics.

Authority & Audience

Unless you’re already a well-known authority to your readers, you need to take a moment to talk to your reader about why they should listen to you. Why do you have the answers? You can address this in one of two ways, either in a Preface that comes before the Introduction and generally outlines a bit about yourself and how you came to write this book. Or in the Introduction. 

But remember, this isn’t a place to give readers your CV or resume. If you want to think about it like applying for a job, then approach this section more like a cover letter. It can include personal stories and experiences that establish how you came to the solutions you’ll present in the book.

The second thing you may want to do at this stage is to identify exactly who the book’s audience is. In the business world, this can help identify if this is a book written for managers or team members or if it is for technologists, or perhaps for those in Marketing. 

Be careful not to be too broad at this stage. While it’s understandable that you don’t want to limit your audience, it’s also true that only the rarest of books are written for everyone. Remember, not even everyone likes chocolate.

How to Read This Book

Another option in an introduction is to provide your reader with a short roadmap to your book. If organized in parts, you can walk your reader through what they’ll learn in each part, etc. This can be especially helpful if you’re book is on the longer end.

The DevOps Handbook is broken into six parts and is over 400 pages long. So a little road map at the beginning can go a long way to help ease your readers into what’s ahead of them. The authors present their road map thus:

“In the remainder of this book, we will describe how to replicate the transformation described in The Phoenix Project, as well provide many case studies of how other organizations have used DevOps principles and practices to replicate those outcomes.

The purpose of The DevOps Handbook is to give you the theory, principles, and practices you need to successfully start your DevOps initiative and achieve your desired outcomes. This guidance is based on decades of sound management theory, the study of high performing technology organizations, work we have done helping organizations transform, and research that validates the effectiveness of the prescribed DevOps practices, as well as interviews with relevant subject matter experts and analyses of nearly one hundred case studies presented at the DevOps Enterprise Summit.

Broken into six parts, this book covers DevOps theories and principles using the Three Ways, a specific view of the underpinning theory originally introduced in The Phoenix Project. The DevOps Handbook is for everyone who performs or influences work in the technology value stream (which typically includes Product Management, Development, QA, IT Operations, and Information Security), as well as for business and marketing leadership, where most technology initiatives originate.

The reader is not expected to have extensive knowledge of any of these domains, or of DevOps, Agile, ITIL, Lean, or process improvement. Each of these topics is introduced and explained in the book as it becomes necessary.

Our intent is to create a working knowledge of the critical concepts in each of these domains, both to serve as a primer and to introduce the language necessary to help practitioners work with all their peers across the entire IT value stream, and to frame shared goals.

This book will be of value to business leaders and stakeholders who are increasingly reliant upon the technology organization for the achievement of their goals.

Furthermore, this book is intended for readers whose organizations might not be experiencing all the problems described in the book (e.g., long deployment lead times or painful deployments). Even readers in this fortunate position will benefit from understanding DevOps principles, especially those relating to shared goals, feedback, and continual learning.

In Part I, we present a brief history of DevOps and introduce the underpinning theory and key themes from relevant bodies of knowledge that span over decades. We then present the high level principles of the Three Ways: Flow, Feedback, and Continual Learning and Experimentation.

Part II describes how and where to start, and presents concepts such as value streams, organizational design principles and patterns, organizational adoption patterns, and case studies.

Part III describes how to accelerate Flow by building the foundations of our deployment pipeline: enabling fast and effective automated testing, continuous integration, continuous delivery, and architecting for low-risk releases.

Part IV discusses how to accelerate and amplify Feedback by creating effective production telemetry to see and solve problems, better anticipate problems and achieve goals, enable feedback so that Development and Operations can safely deploy changes, integrate A/B testing into our daily work, and create review and coordination processes to increase the quality of our work.

Part V describes how we accelerate Continual Learning by establishing a just culture, converting local discoveries into global improvements, and properly reserving time to create organizational learning and improvements.

Finally, in Part VI we describe how to properly integrate security and compliance into our daily work, by integrating preventative security controls into shared source code repositories and services, integrating security into our deployment pipeline, enhancing telemetry to better enable detection and recovery, protecting the deployment pipeline, and achieving change management objectives.

By codifying these practices, we hope to accelerate the adoption of DevOps practices, increase the success of DevOps initiatives, and lower the activation energy required for DevOps transformations.”

Conclusion

Last, a compelling conclusion helps transition your readers to the next chapter. It will often be similar to a hook, and should quickly restate the problem and the solution. Ideally, there should be an emotional appeal here that makes the reader want to turn the page.

So to conclude our post, here is a breakdown of a good introduction:

• Hook: (Between 1-3 paragraphs long)
  1. Tell an actual story/fact/figure that illustrates the pain point this book seeks to solve and hooks the reader. 
• Problem Statement (Between 3-10 paragraphs long)
  1. Detail the pain point 
  2. What is wrong in the industry?
  3. Why is that a bad thing?
• Detail the Solution (Between 3-10 paragraphs long)
  1. Identify the solution to the problem statement about
  2. Provide stories or context to help your reader understand
  3. What benefits will the reader gain from applying the solution
• What will the reader learn (between 1-5 paragraphs)
  1. Provide a brief outline of the book, focusing on what the readers will learn
• Establish Authority (between 2-5 paragraphs)
  1. Establish why you are equipped to solve the problem (your relevant experience)
• Identify Audience (between 3-6 paragraphs)
  1. Establish who the book is for and who it is not for
• Transition to Chapter 1 (between 1-2 paragraphs)
  1. Brief transition that leads readers into Chapter 1

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•