Crafting Engineering Strategy!

On November 3rd, 2023, I posted Thoughts on writing and publishing Primer to celebrate the completion of my work on my prior book, The Engineering Executive’s Primer. Three weeks later, I posted Engineering strategy notes on November 21st, 2023, as I started to pull together thoughts to write my upcoming book, Crafting Engineering Strategy.

Those initial thoughts turned into my first chapter draft, How should you adopt LLMs? on May 14th, 2024. Writing continued all the way through the Stripe API deprecation strategy, which was my final draft, completed the afternoon of April 5th, 2025. In between there were another 35 chapters: two of which were Wardley maps, four of which are systems models, and two of which are short section introductions.

This post is a collection of notes on writing Crafting Engineering Strategy, how I decided to publish it, ways that I did and did not use foundational models in writing it, and so on.

Why write this book?

One of my decade goals for the 2020s, last updated in my 2024 year in review, is to write three books on some aspect of engineering. I published An Elegant Puzzle in 2019, so that one doesn’t count, but have two other books published in the 2020s: Staff Engineer in 2021, and The Engineering Executive’s Primer in 2024. So I knew I needed one more to complete this decade goal. At one point, I was planning on finishing Infrastructure Engineering as my fourth book, but honestly I’ve lost traction on that topic a bit over the past few years.

Instead, the thing I’d been thinking about a lot instead was engineering strategy. I’ve written chapters on this topic in my last two books, and each of those chapter was tortured by the sheer volume of things I wanted to write. By the end of 2024, I’d done enough strategy work myself that I was pretty confident I could take the best ideas from Staff Engineer–anchoring the essays in amazing stories–and the topic I’d spent so much time on over the past there years, and turn it into a pretty good book.

It’s also a topic that, like Staff Engineer in 2020 when I started writing it, was missing an anchor book pulling the ideas together for discussion. There are so many great books about strategy out there. There are some great books on engineering strategy, but few of them are widely read. My aspiration in writing this book was to potentially write that anchor book. It’ll take a decade or two to determine whether or not I’ve succeeded. At the minimum I think this book will either become that anchor or annoy someone enough that they write a better anchor instead. Either way, I’ll mark it as a win for advancing the industry’s discussion a bit.

LLM-optimized edition

While I was writing this book, I was also increasingly using foundational models at work. Then I was using them to write tools for managing this book. Over time, I became increasingly fascinated with the idea of having a version of this book optimized for usage with large language models.

For this book in particular, the idea that you could collaborate with it on creating your own engineering strategy was a very appealing idea. I’m excited that this ultimately translated into an LLM-optimized edition that you can also purchase on Amazon, or you can read the AI companion’s text on craftingengineeringstrategy.com, although you’ll have to buy the actual book to get the foundational model optimized file itself (e.g. a markdown version of the book that plays well with foundational models).

This is the culmination of my thinking about the advantage of authors in the age of LLMs, where I see a path to book turning into things that are both read and also collaborated with.

Regarding the foundational model optimized-version, at its core, this is just running repomix against the repository of Markdown files, but there are a number of interesting optimizations for a better product. For example, it’s adding absolute paths to every referenced file and link, including adding a link to each chapter at its beginning to help models detect to them as references.

It’s also translating images into text descriptions. For example, here’s an image from one of the chapters.

Then here is the representation after I wrote a script to pull out every image and replace it with a description.

My guess is that many books are going to move in the direction of having an LLM-optimized edition, and I’m quite excited to see where this goes. I’ll likely work on an LLM-optimized edition of Staff Engineer at some point in the near-ish future as well.

Role of LLMs

When non-authors talk about LLMs making it easier to write books, they often think about LLMs literally writing books. As a fairly experienced author, I have absolutely no interest in an LLM writing any part of my book. If I don’t bring something unique to the book, the sort of thing that an LLM would not bring, then generally either it isn’t a book worth writing or I am the wrong author to write it. As a result, I wrote every word in this book. I didn’t use LLMs to expand bullets into paragraphs. I didn’t use LLMs to outline or assemble topics. I didn’t use LLMs to find examples to substantiate my approach. Again, this is what I know how to do fairly well at this point.

However, there are many things that I’m not that good at, where I relied heavily on an LLM. In particular, I used LLMs to copy-edit for typos, grammatical errors and hard-to-read sentences. I also used LLMs to write several scripts that I used in writing this book:

1. grammar.py which sent one or more chapters to an LLM for grammatical and spelling correction, returning the identified errors as regular expressions that I could individually accept or reject

2. import.py which translated from my blog post version of the posts into the craftingengstrategy.com optimized version

3. links.py which I used for standardizing format of chapter references, and balancing the frequency that strategies were referenced

4. Generated craftingengstrategy.com’s FAQ by attaching full LLM-optimized version to Anthropic Claude 3.7 thinking and running this prompt:

    I want to make a frequently asked questions featuring topics from this book. What are twenty good question and answer pairs based on this book, formatted as markdown (questions should be H2, and answers in paragraphs). Answers should include links to relevant chapters at the end of each answer.
    Some example questions that I think would be helpful are:
    1. Is engineering strategy a real thing?
    2. How is engineering strategy different from strategy in general?
    3. What are examples of engineering strategy?
    4. What template should I use to create an engineering strategy?
    5. Can engineers do engineering strategy? Is engineering strategy only for executives?
    6. How to get better at engineering strategy?
    7. Are there jobs in engineering strategy?
    8. What are other engineering strategy resources?
    Please directly answer those 8 questions, and then include another 10-15 question/answer pairs as well.
   

   This worked quite well, in my opinion. Generating a better FAQ than the one I created for Staff Engineer’s FAQ in a very small amount of time. SEO seems well and truly “cooked” based on this experience.

Just like I don’t see software engineers being replaced by LLMs, I don’t see authors being replaced either.

craftingengstrategy.com

For Staff Engineer, I put up staffeng.com. For The Engineering Executive’s Primer I just posted things on this blog, without making a dedicated, standalone site. For Crafting Engineering Strategy, I decided to put together a dedicated site again, which maybe deserves an explanation.

My writing over the past few years is anchored in my goal of advancing the industry, and I think that having a well-structured, referencable version of the book online is a valuable part of that. If people want to recommend someone read Staff Engineer, they can simply point them to staffeng.com, and they can read the whole book. They might also buy it, which is great, but it’s fine if they don’t. The Engineering Executive’s Primer is just much less referencable online, so someone ultimately has to decide to buy it before testing the content, which undermines its ability to advance the industry.

For the record, that wasn’t an O’Reilly limitation, just poor planning on my part. An Elegant Puzzle didn’t require a standalone site, so I thought that Primer wouldn’t either, but I think that’s more a reflection of An Elegant Puzzle being a collection of this blog’s writing in the 2010s rather than the best way to support the typical book.

At this point, my experience is that most books benefit from having a dedicated site, and that it doesn’t detract from sales numbers. Rather, if properly done with clear calls to action on the site, it supports sales very effectively.

Decision to publish vs self-publish

I worked with O’Reilly to publish this book, same as I did for my previous book, The Engineering Executive’s Primer. My continued experience is that it’s harder to create a book with a publisher, the financial outcomes are significantly muted, but the book itself is almost always a much better book than you would have created on your own.

For me, that was the right tradeoff for this book.

My last book of 2020s

I’m not at all sure this is the last book that I’ll ever write, but I’ve completed my decade writing goal for the 2020s, and I’m committed to this being my last book of the 2020s. For the past seven years I have been continually writing, editing or promoting a book, and I am exhausted with that process. I’ve loved getting to do it, and am grateful for having had the chance to do this four times. But, I’m still exhausted with it!

I could imagine eventually having another book to write, and that is definitely not now. Instead I want to spend more time with my family, my son, personally writing software professionally (rather than exclusively leading teams doing the writing), and other projects that are anything but writing another book.