engineering

There are 3 posts filed in engineering (this is page 1 of 1).

Consider your (multiple!) audiences

I’ve been spending a lot of time helping colleagues with communications lately, and one of the refrains I keep repeating is “consider your audience!”

For any given project you’ve worked on, you may need to be able to talk about your work in many different formats. Non-exhaustively, these might include:

  • Working documentation for colleagues within your team, familiar with all the context and able to find and integrate other documentation
  • A detailed report for other experts outside your team, showing all your work
  • A short technical report, also for other experts, but without all the steps shown
  • A one-page executive summary, geared towards decision-makers who are in that fuzzy “informed but not fully expert” zone
  • A less-technical essay in more informal language, i.e. the “blog post” format
  • A single paragraph summarizing key results
  • A 30-60 minute presentation
  • A 5-minute presentation
  • A single bullet point that can go in your resume

Each of these formats is pitched at different audiences — people who have different levels of background knowledge, need different information about the project, and who are willing to spend different amounts of time reading your work. Some formats might work for multiple audiences, but a lot of the time you need to use a different format when the audience changes. IMO there is no such thing as a format that works for everyone!

A common trap I see engineers fall into is thinking that the first version, the detailed technical report, is the only document they need. And that all the others can be produced by just copy-pasting from the detailed report. To some extent that can be a starting point, but each of these different communication formats does need to be tailored to the people you expect to read it!

I also see folks forget that some audiences will not have time for a detailed report. If you’re communicating with a less expert audience, they are almost always going to be unwilling or unable to read a 20 page doc… or even a 5 page doc. These audiences need their own format because you need to be able to provide information at the right page.

Over time, and especially as you get more senior, you will likely need to be at least reasonably good at all of these. In my current role, managing a fairly high-level engineering team, I often need to be able to write all of these for any given project.

Because it’s 2025, many folks will suggest “just use an LLM translate between formats!” That’s not necessarily a bad approach, at least when you’re going from a more detailed document to a less detailed one. I’ve seen LLMs produce some decent executive summaries. But it’s really important to remember that LLMs are just text generators, not experts — you are the one who actually understands your project!

LLMs will also cheerfully invent information, so you can’t trust them to fill in details starting from a summary. (This seems like it should be obvious, but I have absolutely seen people try to use an LLM to produce a detailed doc from a summary — that direction doesn’t work!)

Quick review: “Built”, by Roma Agrawal

Built: The Hidden Stories Behind Our Structures was a pleasure to read. Authored by Roma Agrawal, a structural engineer who worked on the the “Shard” skyscraper in London, it’s truly a love letter to her profession, and to the structures it involves.

Throughout the book, Agrawal describes a wide variety of engineered structures around the world. From skyscrapers to bridges; from clay bricks to steel; Agrawal’s writing goes into detail on the materials and techniques used to build the constructed world we all walk through.

In each case, Agrawal finds fascinating stories to tell about the cultures and individuals who pioneered various techniques. And throughout the book, it’s clear how much enthusiasm and love she brings to her work.

As someone trained in physics and materials science, I was especially happy to find such an engaging read that talks about such properties as ductility, elasticity, toughness, compression and tension. It’s a rare thing to find someone who can describe how fun these topics can be.

While Agrawal occasionally touches on her difficulties working in structural engineering, as someone who isn’t “traditionally” white and male, she doesn’t dwell on these concerns. To the extent I have a criticism of this work, it’s that she doesn’t spend more time on how she experiences being a professional engineer — including both the positive and negative aspects of the profession.

However, that’s a mild criticism, as that’s clearly not what the book is about. As I said above — this isn’t a memoir, it’s a love letter to her work. And to the extent it is that, it succeeds very well.

Some thoughts after reading Vincenti’s “What Engineers Know and How They Know It”

A few weeks ago I watched Hillel Wayne’s recent talk “Are we really engineers?”, where he looked at the idea of whether software engineers get to call themselves “engineers” or not. (Spoiler: the answer is yes!)

During the Q&A, Wayne mentioned that while he had seen a lot of “philosophy of science”, there didn’t seem to be much “philosophy of engineering” out there. I remembered noticing the same thing, and on Twitter I asked for book recommendations on the topic. The always-reliable Lorin Hochstein obliged, and a week later I had some reading to do!

Just as a disclaimer: this post is very much in theme of “thinking out loud”, and got a little long. 🙂 This is mostly me discussing my experience of reading the book and some thoughts on software engineering I had after reading it. Very likely nothing here is at all original, and I am not an expert, but I wanted to get my ideas down in text after finishing the read. And having done so, I thought it might be worthwhile to share.

Ok, let’s dive in.

Continue reading →