As someone who writes books, I am continually grateful to the fact that there are people who buy a book, and then actually read that book. It’s equally clear to me that there’s a second, large group who like the idea of books, but would much prefer a project-based approach to learning the book’s content.

As the technology sector applies Large Language Models (LLMs) to everything, one very valid reaction for authors is to be concerned. Those concerns are merited: it is possible that fewer people will be reading book a decade from now than they do today. However, I also think that LLMs are a powerful tool for supporting project-based leaders.

There are many things that LLMs are not particularly good at, and generating a great engineering strategy is one of them. If you ask an LLM to generate your company’s engineering strategy, I’m quite confident you are going to be disappointed with what it generates.

However, I am extremely confident that an LLM is already an excellent companion to help you develop an effective engineering strategy. Used thoughtfully, an LLM can generate and analyze systems models, help you in each step of writing, and point out the areas your strategy needs to be reinforced. This companion will walk you through the techniques to accomplish each of those things, starting with this chapter which walks through configuring an environment to collaborate with Crafting Engineering Strategy and an LLM of your choice.

With your environment working, the obvious task to start with is co-writing a strategy document with an LLM. A good strategy document is not just readable, but has a clear view of your current challenge and how to address it.

This chapter will cover:

• Using meta prompting to optimize our initial prompt for writing a strategy
• Incrementally building a strategy document by prompting each step with our meta prompted prompt, and the outputs of prior steps
• Cleaning up our generated strategy into something well-formatted
• Remembering that the quality of a strategy rests in your thinking, and that quickly generating bad reasoning won’t solve real problems

By the end of the chapter, we’ll have written a reasonably good strategy document in a surprisingly short period of time.

In the last chapter, we co-wrote a strategy with an LLM. Now, we’re going to review that strategy, looking for areas that we can improve. Ideally, every organization would have someone ready to provide feedback on your documents quickly, but that’s often not the case whether they’re busy or simply don’t exist, and these techniques are a useful stand-in during those cases.

In this chapter we’ll cover:

• Identifying weaknesses in a strategy document using an LLM
• Using an LLM to summarize and narrow feedback to provide to the strategy’s author
• Advising an LLM on how to address raised feedback to rewrite an existing strategy based on your evaluation of the flagged concerns

By the chapter’s end, you’ll have identified issues in the last chapter’s strategy, communicated those issues concisely, and rewritten the strategy to address that feedback.

Crafting Engineering Strategy has a chapter on systems modeling along with a number of examples. Those examples focus on using the lethain/systems python library to generate models using a Jupyter notebook, with examples in lethain/eng-strategy-models. That is a reasonable approach, but it also requires learning the systems library’s syntax for modeling.

This chapter looks at how to use an LLM to write the system model syntax for you, without requiring learning how to use that syntax in great detail. In addition to being specific instructions for working with the systems library, this is also a generalizable pattern for using LLMs to work with domain-specific languages.

When I was drafting the first chapters of Crafting Engineering Strategy, I thought I might write a chapter on GitLab’s strategy. GitLab is interesting because it has publicly shared so much of how they operate, that I figured it might be possible to write an interesting strategy document about them despite never having worked there.

In the end, I decided not to write that chapter, but I did create a Wardley map exploring GitLab’s strategy. That Wardley map was not included in the final edition of the book, including not being in the LLM-optimized format either, making it a perfect test case for whether an LLM can help us generate an effective wardley map.

In order to reach this final chapter of the AI Companion to Crafting Engineering Strategy, you’ve co-written and revised a strategy with an LLM. We’ve also used both in-context learning examples and Model Context Protocol servers to prime an LLM to work on complex, domain-specific problems such as creating a systems model or Wardley map.

The two biggest remaining questions to engage with at this point are:

1. How should you actually use the LLM-optimized edition of Crafting Engineering Strategy going forward?
2. Is the concept of an LLM-optimized book actually a valuable one?

These two questions are really the key questions when it comes to evaluating this project, and will help determine whether this format represents a meaningful advance in how books are released, or whether it’s merely a hacky concept to be forgotten.