Previously I wrote on what it's like to write a tech book. In that article I deliberately glossed over the process of getting to the agreement to write the book. Let's talk about that process.
There are a very limited number of scenarios in which people talk to a publisher about a book project:
- They have a book idea and want to write it through a publisher
- The publisher has a book idea and thinks they might be good to write it
- The publisher has a book and wants to revise it or complete it
The first case is what people frequently think of, and what I recently went through this fall as I successfully pitched a book idea (more on this soon). In this scenario, you have an idea, you think people will like it, you've decided you don't want to self-publish, and you now want a publisher to work with you.
The second and third cases involve an acquisition editor reaching out to you about an opportunity they believe exists in the market that you might be able to write about. This is how I got to write my first technical book, Refactoring with C#.
Even if a publisher reaches out to you, you usually will have to fill out a formal book proposal.
In a future article I may expound on cases 2 and 3 more (or self-publishing for those who have interest in what I've found there), but for now, let's focus on pitching an idea to a publisher who isn't expecting you to do so.
Identifying Publishers
The first step in pitching a book is to figure out who you want to pitch it to.
As many other writers have pointed out, take a look at the books on your bookshelf (or in your e-reader) and see who is publishing them. There's a good chance that publisher would be interested in your idea.
If you want to see your book on shelves in a bookstore, your list of publishers decreases significantly as most tech sections of bookstores focus either on mass audience tech books (non-programmers) or only shelf established hits from certain publishers.
Once you've identified 3 or so key publishers, I recommend you look over their website for a "become an author" link. From there, you can reach out and pitch your idea. Often times this will be a simple contact form where you can briefly identify yourself and your idea and ask if they'd like to hear more. Other times publishers will request you fill out a full proposal and submit that for review.
If you are connected in the tech industry, you may know authors who have published with the publisher before. For example, I speak at a number of regional and local conferences and have gotten to know many speakers as a result. I also am active in technical circles online, which further develops these relationships. If you have enough trust and familiarity between you and an established author, you can ask them if they'd be willing to connect you to an acquisitions editor at the publisher they worked with. This can give you another avenue to get established and get additional information before submitting a formal proposal.
My general message when reaching out to publishers was something like the following:
Hi [Acquisitions editor name], I'm Matt Eland, an AI Specialist and consultant with several decades of experience in the industry and an established presence in the industry. I'm just finishing up my first technical book, Refactoring with C#, and I have a strong urge to do this again and was wondering if my interest areas might align with your needs.
I'm currently exploring options for my next project and would like to know if [publisher] has interest in discussing partnering on a book on X, Y, or Z in the near future.
This was friendly enough, gave them enough information without overwhelming them, and showed them my qualifications by giving them a set of areas I was focused in.
This in turn helped me identify needs that the acquisition editor was most interested in, which helped me craft the right book proposal to send to that publisher.
Writing a Tech Book Proposal
The tech book proposal differs from publisher to publisher but addresses the following key points:
- What's the title, subtitle, and brief description of the book?
- Who are you? Why are you the person who should write this book?
- What type of person is reading this book? What do they already know?
- What other books are out there on this or related things? How is this book different?
- How does this book complement our existing offerings?
- How is the book structured? What are the chapters? What is each about?
The exact template and format of this will vary from publisher to publisher, but these are the major points you'll need to cover.
Keep in mind that publishers know what they've published before, what other publishers have published, and what projects are currently underway. If you pitch a project to a publisher that they published a few years ago, it will not go well unless you have a compelling reason why your project is different from that project.
The process of filling out this document will take you a significant amount of time, and the finished proposal will probably be 6 - 10 pages long or so, depending on the level of detail the publisher requests. Do not cut corners here or copy / paste from other documents you've filled out. Publishers will be able to recognize the competing format and it doesn't inspire confidence (I've heard horror stories from publishers at conferences before).
Some publishers will also ask for a writing sample, such as a link to blog posts you've written or even a sample chapter. I've personally not encountered the sample chapter requirement, so this may be a requirement that's going away, or this may be something that people ask for when they can't find any samples of your writing style online.
Once you've submitted a proposal, you'll need to wait some time before you hear back. This is part of why I recommend initially reaching out to a small handful of publishers, not just one; there's a lot of waiting in the process, and that's fine.
Book Proposal Feedback
When you ultimately do hear back from a publisher, the response may be a flat decline, a request for clarifying details, a request for modifications, or an approval.
The declines sting, particularly if you were invested in a publisher. I still vividly remember the not so nice phrases that entered my mind when I got a simple "No thanks" reply from a publisher in response to an 8 page document I created just for them.
More generous "no" replies will tell you why they're declining the project (typically because they have a competing title or its outside their focal areas), but you're not guaranteed to get this.
Sometimes a "no" will also come with a request for other ideas or, more frequently, an inquiry if you're able to write about a specific topic of interest to the publisher. I even had a no come in the form of a rejection of the target audience for the book and a request to retool the book for a different audience. That project was promising, but I ultimately decided that my ability to write at that level of expertise on an advanced topic wasn't a good fit for me at that time and decided to pursue things more likely to yield a good result.
When acquisition editors ask for more details it's usually because they didn't understand something in your proposal or because the proposal reminds them of a different book that struggled in a specific area or market.
If an acquisition editor doesn't ask you questions on your project, watch out! It could be that they don't care about it, aren't planning on offering you a fair contract, or are looking to get as many books out as possible.
Sometimes acquisition editors will ask you to add something to your proposal. This is either to increase search engine optimization (SEO) or stay competitive with other books on the topic. In either case, you are allowed to counter with reasons why you didn't include that or didn't feel it is relevant to your topic. Keep in mind that every chapter or section you add will be additional weeks or months writing, revising, and reviewing your content.
Most acquisition editors don't come from programming backgrounds, but these individuals know their areas well. Acquisition editors research things they see in book trends and in the industry, and they research things they encounter in book proposals. While your acquisition editor might not have written a line of code, they still deserve your respect as a researcher and SEO optimizer, but you may need to clarify misconceptions or assumptions they have about your areas of expertise.
On the topic of expertise, you do not need to know everything that is going to be in your book to submit the proposal. You need to know what is and isn't possible with technology, but you are allowed to deepen and broaden your knowledge while writing a book. I would propose that you should have somewhere between 85% and 98% of the knowledge you need to write the book during the proposal stage. The rest comes when you build out individual chapters and stretch into new areas.
For Refactoring with C#, I knew almost all of the material up front as it was from my own journeys as an engineer and engineering manager. However, I hadn't built a Roslyn Analyzer myself at the time of writing the book proposal. I'd studied a few and knew what they looked like and how they worked, but knew those chapters would be a learning journey for me. In this particular case, I wanted to learn this to develop my own skill and also fill a gap I saw in the market as someone who had searched for books on that topic before in the past.
Ultimately an acquisition editor is trying to find a market fit for your book and improve the proposal to the point where it can be approved during an editorial review meeting and green lit for production. Once that happens it moves on to the scheduling and contract phase.
The Scheduling and Contract Phase
Each publisher handles scheduling a little differently. Many publishers are interested in specific milestones such as when the first chapter will be done, when the first 3 chapters will be done, when the book reaches halfway, or when the book is fully complete.
Packt operates a little differently where they request page estimates during the proposal process and then extrapolate your writing speed based on the page count and hours per week to build a candidate schedule. They ask you to factor in work, vacation, travel, and other commitments, and that helps determine how long each specific chapter will take to reach draft phase and accepted phases at a per-chapter level.
Whatever you and your publisher determine, this will go into your contract. This sounds scary (and is a little scary), but the clauses it sits next to are generally related to reducing your advances on royalties if you're over 30 days late or potentially giving them the ability to cancel the project entirely if you're not making progress. Usually your publisher is more interested in maintaining active communication with you than strictly adhering to a plan.
It's important to note that each contract is different and I cannot offer you legal advice, so it is important to seek out someone who can.
Most book contracts will include a post sales percentage that you are awarded, an advance upon royalties awarded and a schedule for when that money is distributed. Your percentage is likely to be between 10 and 20% from what I've observed. Some publishers also do sliding windows of percentages based on sales so books that don't sell in high volume net you lower percentage rates than ones that sell more.
Be wary of contracts on the lower scale of royalties and contracts that do not offer you much of an advance on sales. Having an advance not only guarantees a minimum income from the project, but it usually protects you from the publisher deciding to cancel the project without compensating you (they'll rarely want to do this if you're on schedule, but technology and markets change).
Watch out for clauses that talk about when they won't compensate you, such as if a book is bundled, heavily discounted, or used on another platform.
You have a right to have a lawyer look at your contract. You have a right to raise concerns with the publisher on clauses or overall compensation. You also have a right to walk away entirely.
This is a right I exercised a month ago when a publisher I previously respected offered me a contract starting at 10% royalty on a title without any advance and without compensation when bundling the book with others or discounting it. They also wanted to purchase the ability to sell the book through a subscription service without compensating me further for it.
I ultimately walked away from that deal, found another publisher, revised the abstract based on their feedback and based on new developments in the industry during that time period, and signed a much better deal with a publisher I trusted.
Ultimately, your book is going to take a lot of your time. You won't be fairly compensated for it at an hourly rate no matter what given the industry, but you should sign with a publisher you feel comfortable working with, because you'll be working with them for some time.
Keep in mind that self-publishing is entirely viable and doesn't carry the risks it once did with newer print-on-demand publishing models.
However, I've found that publishers are very valuable in terms of understanding the market and optimizing for it, providing valuable editing, proofreading, typesetting, and cover design services, and just generally being an accountability partner to make sure the book is progressing.
I know this was a longer post, but my hope is that it helps future authors out there. If you found something particularly interesting or have a question, please let me know and I'd love to chat with you.
The post Pitching a Tech Book to a Publisher appeared first on The New Dev's Guide.
