Blueprint or building blocks
When writing a book, what comes first: Structure or content?
About a year ago, when we set out to write our book, we had a feeling that the process would look like this:
Very quickly we realized that the process is way more involved then we ever could have imagined.
What surprised us the most was how often we went back and forth between the Write and Structure phases but also how often we had to go back to re-write and restructure things.
In our previous article we talked about how we built our own tooling to help optimize our writing process.
In this article we will be talking about how we went about structuring the contents of the book.
Essentially the topics we wanted to write about haven’t changed all that much. But how we wanted to connect it all has changed drastically. We didn’t want our book to feel like you’re reading a collage of blogposts. Nor did we want it to feel like a fiction book where every article is crafted to support the story.
Throughout this whole process, we changed the structure of the book at least 6 times. In this article we will look into how things have evolved over time, how we’ve managed the chaos, and what we’ve learnt from it.
In the beginning
In the beginning, there was just an idea. The idea that many engineering managers around us had learnt about the intricacies of their craft purely by imitation and trial & error. We wanted to help solve this problem of having engineering managers employ a evolutionary approach1 to learning their craft. Instead, we want to be able to provide aspiring engineering managers with the basic information necessary to help them get started.
The information required to become competent in almost any other discipline on the planet; farming, cooking, engineering, architecting, etc. can be achieved essentially through a book. Yet there aren’t that many books on engineering management.
The architect
Since we both love analogies and have an interest in wood-working, we decided to pick the analogy of how a carpenter builds a table. The premise being that; similar to carpeting, engineering management can also be learnt.
As an architect, making a plan before actually building a building, we first decided on the structure of the book, then woven a narrative through the following topics:
The craft: What does engineering management entail
The craftsman: What are the qualities of an engineering manager
The material: How to manage people
The tools: What methodologies and best practices are there
The job: What are the responsibilities of an engineering manger
The table: What does an engineering manager aim to achieve
We were happily following our outline and pieces and grouping those under the correct chapter. Until one day, we were about to tackle the infamous topic: Performance management. The piece we wrote became very difficult to classify under a single chapter. There were parts in there which, one could argue, would belong to ‘The craft’ since it is one of the core responsibilities of the role, but there were also bits which would fall under ‘The material’ but also under ‘The job’ and ‘The tools’.
There we were, having a moment of analysis paralysis2.
Then, the existential question dawned upon us: Were we doing it wrong all along? Should have we approach structuring of the book in a top-down manner or bottom-up one. Starting from the top would mean that we would first create the outline of the book and then to start working the chapters. Starting from the bottom would mean that were first write pieces which we then bond together, meaning that the structure of the book would come later.
Eventually, we understood that the structure which initially was the thing that gave us a great boost was starting to hamper us. This approach might have worked great if we were only to maintain a blog, but to create a cohesive book, we new we had to do better.
Papier-mâché
At this point in time, we decided to restructure the book. Since we had failed at the top-down approach; building the book in a bottom-up fashion.
We had already written quite some pieces. That gave us the impression that we could easily stitch these bits and pieces together and more or less, distill a book out of it. The only thing we would have to figure out was the order of the chapters. How difficult could it be (famous last words).
We quickly realized that we were trying to build a sculpture out of chewed paper thus we call this method the papier-mâché approach.
We were thinking that if we start tagging the chapters with the type of topics they contain, a grouping would emerge out of chaos, and would help us discover what the structure should be. So we fired up Notion and created a database3. In there, we put a list of the articles we already had written and the ones we still would like to write about. Then we started labelling the articles. As the labels quickly started going out of hand, we realized the four that we used more often than others:
Organizatoinal
Technical
Interpersonal
Managerial
So we got to work and tagged all of the topics we had using these labels:
Initially, it felt like we were lucky to have found a solution so elegant. Well, it turned out to be more difficult than we imagined. There were some chapters which could easily fall under both category. There were others (eg. performance) which definitely needed to have a place under more than one category.
Then we assumed that the categories that we picked were wrong so we tried different groupings. The next category was inspired by
‘s talk:
So we tried the 3X approach:
And again using the MoSCoW4 method:
And again, and again, and again…
Independent of the type of categorization we used, we always had the issue of not being able to have a 1 to 1 relation between the chapter and the topic. Furthermore, we realized that the content started feeling more and more like many blog posts appended to each other instead of a single story.
The sculptor
At the end, we gave in and decided to embrace the chaos. I guess, we were naive in thinking that we’d be able to extract a simple structure out of such a complicated and intertwined topic. That is when we understood that we need to approach the structure like a sculptor would. Knowing that we want to build a bust5 and slowly evolving to the end result where we iterate bit by bit.
We even took this analogy one step further and decided to have the book progress from the highest level and then zooming into the lower levels. The initial structure we came up with looks like the following:
Organizational
Inter-team
Team level
Personal
Once the high level shape was defined, we started grouping concepts/topics under these chapters. After that, we were able to add or subtract and bring it closer to the end form we’d like to have for the book.
Conclusion
It has been a humbling journey of trial, error, and discovery. Along the way, we’ve learned that structure isn’t something you simply impose—it’s something you uncover, layer by layer, through iteration and persistence.
Our initial attempts to define a structure were like trying to paint a landscape before understanding the terrain. We started with frameworks that seemed logical but quickly discovered their limitations when applied to the messy, multifaceted reality of engineering management. Each false start brought us closer to the realization that what we were building wasn’t a linear roadmap but a nuanced sculpture.
By embracing the sculptor’s mindset, we shifted from trying to force rigid categories to letting the narrative take shape organically. This shift allowed us to create a structure that feels natural and cohesive, one that guides readers through the complexities of engineering management while leaving room for interpretation and personal growth.
To anyone embarking on a similarly daunting project: embrace the chaos, trust the process, and know that clarity often emerges from unexpected places. As you chip away at the excess, what remains will be the essence of your story—a story worth telling.