Technical Argument and Structure

“Technical Argument and Structure” discusses the steps involved in constructing a report. For a technical story to be told coherently, the audience must be given the context they need to appreciate the work that has been done. The first part of this chapter covers a straightforward formula to achieve this. The argument starts by presenting the vision (goal) for the work and then narrows down to the reason why progress was needed, the specific technical problem or obstacle that needs to be tackled to make this progress, the prognosis, and the competing solutions (and why the status quo is not good enough in these particular circumstances). This then leads perfectly to a discussion of the new solution. The second part of the chapter talks about overlaying structure on top of that: specifically, how to think about introductions, titles, and conclusions in the context of the technical argument.

Epilogue

For any how-to book, a primary goal is to systematize the subject matter to make it as self-evident and straightforward as possible. However, some of the techniques described here are significantly more challenging to use in practice than they are to explain. So, if you’re attempting this kind of project for the first time, it’s really important that you ...

Credibility

“Credibility” focuses on all the things that will help to clear the path for the reader. Even a well-structured piece can be alienating if written if an illogical, confusing, or noncredible way. This chapter goes over some basic rules for making an argument convincing and ensuring the readers remain favorable. These include presenting the right kind of evidence, being honest, ensuring accuracy, writing (or speaking) with an authoritative voice, and preparing for common objections to a given argument. It also discusses ways to make an article easy to read, from breaking the text up into digestible paragraphs and sections, to providing topic sentences and subheadings, to signposting where the argument is heading, to avoiding repetition, to using the active voice. Finally, it discusses how to make the most of a very important set of readers: those being asked for feedback.

Analyze

Chapter 4 discusses the difficult, multilayered art of technical analysis. For those who haven’t yet developed their own methodology, it begins by considering different routes through the work, taking either the point of view of a problem looking for a solution, or that of a solution looking for a problem (looking for a solution). Using canvases (or spreadsheets) makes it possible to systematically evaluate technology features, application criteria, competitors, and timing—all of which were discussed in Chapter 1. Finally, the chapter discusses levels of confidence in the analysis presented, and the importance of coming to a conclusion of some kind, even if the conclusion is that more research is needed.

Finding Answers

“Finding Answers” addresses the information you need to answer questions. The chapter starts by suggesting a basic work flow for gathering material. It then moves on to consider where to look for that material; specifically, the information sources that can be accessed both virtually and by reaching out into the real world. These include everything from keywords, technical literature, patents, intellectual property, the trade press, annual reports, conferences, lab visits, industry roadmaps, industry blogger, books, and more. For each one, the chapter discusses not only what each source can offer and which questions they are most likely to answer but also their strengths, their weaknesses, and common pitfalls in using them.

Audience and Explanation

“Audience and Explanation,” which is the first of three chapters on communicating technical work, starts by focusing on the audience and how understanding their backgrounds and interests is critical to being able to report in a way that is meaningful to them. It consider their motivation for reading, what kinds of explanations will make sense to them, what kind of visualizations will be helpful, and the language that they will (or won’t) be able to follow. A section on jargon explains when to use a word without explanation, when to define, and when to avoid using a technical word altogether. There is also a discussion on the use of various kinds of figures (e.g. charts, photographs, and diagrams), how they are best used, captions, and how to avoid problems with copyright and plagiarism.

Key Questions

“Key Questions” works through the questions that come up when trying to evaluate a technology or think through how to solve a technical problem. It starts by looking at the technology itself and how to determine what it’s likely to be good for based on features such as performance or cost. Then it turns the question around to look at the problem being solved and what its requirements are: these criteria will help understand what success looks like. The effect of time is considered next. How will the demands of the technology and its application evolve? What difference will any start-up lag will make? Finally, it goes on to consider all the technologies competing to solve the given problem: how do they match up to the requirements of the application? Are there weaknesses that stop them being viable solutions?

Perspectives and Agendas

“Perspectives and Agendas” discusses why it’s important not to believe everything you read: even well-meaning experts often have specific perspectives based on their disciplines, their interests, and who their friends and rivals are. This chapter considers these agendas, where they come from, and why those who have negative things to say are often more useful than those who have a more positive outlook. It looks at trust, bias, competitive relationships, dependent relationships, expertise, disagreement, rivalry, and collaboration. It also considers the dangerous concept of “balance” and why it is too often used to avoid responsibility for making an informed judgment based on the available evidence.