Writing Effective Technical Reports: Beyond Chronological Narratives w/ David MacNair

Writing chronologically in professional engineering reports can hinder clarity and usability. When presenting information, it's important to consider how readers want to use it. A common pitfall is the misconception that chronological narratives always lead to understanding. Dr. David McNair from Georgia Tech emphasizes the need for engaging and applicable learning experiences in engineering education. Technical report writing plays a crucial role in engineering and professional settings, as it communicates analysis, design, and decision-making. Novice report writers often struggle with organizing their reports to meet the audience's needs. Organizational structure is significant in avoiding pitfalls because it helps convey important information efficiently. It allows readers to grasp the main points and make informed decisions. Trust is also built when the report provides a clear structure and justifies its conclusions. In this episode, we'll explore why writing chronologically often falls short in professional engineering reports, and how students can elevate their writing by prioritizing clarity and usability. Ultimately, when making organizational decisions, it's important to understand how intended readers want to act upon the information being conveyed. Imagine this scenario. You're a young engineer, fresh out of university, tasked with analyzing data from a recent experiment and drafting a technical report for your team. Eager to impress, you meticulously detail every step of the experiment in chronological order, from setting up the experiment to recording your observations. However, when you present your report to your colleagues, you're met with confusion and frustration. It turns out, while your report may be thorough, its organization makes it challenging for your team to exact the crucial insights they need to make informed decisions. This scenario highlights a common pitfall in technical report writing, the misconception that chronological narratives always lead to clarity and understanding. Today, we'll delve into why this approach often falls short, and how we can elevate our writing to better serve our intended audience. I'm joined by Dr. David McNair, who is the Director of Laboratory Development at the Woodruff School of Mechanical Engineering at Georgia Tech. David develops innovative laboratory experiences based on lessons learned from the maker movement and real-world industrial challenges, and is building an ecosystem of academic laboratory equipment and curriculum resources, which allows universities to collaborate on the development and execution of effective undergraduate laboratory experiences. Hi, David. Hi. Thank you for having me. And I apologize in advance to everybody. I do have a little bit of a head cold I'm still getting off of. No worries. Thank you for coming in, regardless. Do you want to talk just a little bit more about your role here at Georgia Tech? Yeah, of course. A lot of what I was brought in for was taking a look at how do you make the learning process a lot more engaging for students, and a lot more applicable to the real world? So at Georgia Tech, we have a lot of really great progressions that are focused on the theory, trying to understand, say, fluid dynamics, or thermal dynamics, or heat transfer, all of these different topic areas, but oftentimes it's when you actually start playing with the equipment, when you really start trying to understand how the theory is applicable to what you're seeing from the real world, that that becomes useful. Once we started trying to redesign a lot of our laboratory progression in order to allow students to kind of delve in, get their hands dirty with the topic areas, explore not only to see a demonstration of something happening, but to be given a task, that you need to achieve something, you need to understand something, and provide some sort of output. Through that, we were also finding that there's this issue where, all right, I have something I need to convey to you. How do I do that effectively? I've come to a conclusion, but you don't need to see everything that I went through from my own understanding. You need to understand what decision that you need to be making. So that kind of led us to another pivot point, which is a lot of what we can talk about is how do I converse very effectively with an audience in a technical way, but in a way that's very useful for whoever that audience is. Right. It sounds like utility is a really big part of how you design these courses. It's as if we're trying to teach students how to turn knowledge into usable skill. Yes, exactly. Nice. So, focusing in on technical report writing, can you talk a little bit about why technical reports serve an important role in engineering and professional settings? Yeah, absolutely. So, a lot of engineering, a lot of times when students especially go through, they're thinking, as long as I can get the right answer to my problem, I'm good. That's all that I really need. Or, if I can create a set of drawings, and as long as the dimensions are somewhere on this drawing, I'm good. Somebody else will kind of figure out the details of this, whereas the reality is people will hire an engineer to help them make decisions or to help them understand what a challenge that they're facing, how to make a decision around that challenge, or to design a product but then understand what that product is to know that it's going to meet some kind of need. And so, a lot of the job of an engineer is not only coming up with what is the conclusion of analysis or what is the design that you're trying to create, but how do I communicate that very effectively to whoever either needs to understand the analysis to make a design change or to understand the design to know that it's going to meet their market need. Yeah, I think a lot of the times, because we're so surrounded by people who are studying the same thing that we're studying, we forget that a lot of the purpose of getting this specialized information is that when we go out into the world, we're the only specialist in the room and we're not going to be talking to people who know the same things that we do because the fact that we're different is what makes us valuable. Yeah, exactly. So in your experience, what are the common challenges novice report writers face in writing technical reports effectively? Probably one of the biggest ones that we face is students will come in thinking about the mindset of where they are in trying to get that information. So if it's an experimental capacity, they come in thinking, I'm just going to walk you through all of the steps of this experiment that I did so that you can see exactly how I reached the conclusion that I reached, and then hopefully that will help you answer the questions that you have. And so instead of having them think about that chronologically and walking through their own process, getting them to restructure it so that it's really focused on the audience's need. So instead of me telling you about the experience that I just went through, let me find out what experience you're needing and to create some kind of piece, technical piece that's really able to address that need. Yeah, it sounds like a really difficult time point in the student's learning process is because up until this point, they've just been learning about how they should be behaving in labs and what they should be doing to labs. So now they have to take a different perspective to talk about not just the stuff that they found fun and interesting because they're getting to practice what they learned in other classes, but what would someone else want to know? Yeah, why am I paying you to come up with this? So thinking about this then, why is organization so significant to avoiding these pitfalls? So a lot of that comes down, there's a couple different reasons, but a lot of that comes down to whoever is going to be reading this technical report has limited amounts of time, and time or attention, whichever it may be. And so you need to be able to convey to them whatever is important for them making their next decision, that could be a go-no-go on a project, that could be recognizing what was most important that we came from an analysis that I need to change its design, whatever that might look like, I have a limited amount of time before I need to go do whatever my job is to digest the information that you're giving to me. So if you present something, let's say chronologically, and you walk me through all of the details of exactly what you did to get to the conclusion that you derived, well, maybe I didn't need to know all of that information, and perhaps even worse, there was a lot of that detail that I didn't know what was important or what wasn't important, you didn't clarify to me what the conclusion was, that then I took away something that you didn't actually intend me to take away. And so if something's communicated to me, you know, the term, you lose the forest because you're seeing the trees, if all I'm seeing are all of the individual details, maybe one of those details sticks in my mind, and I start making inappropriate decisions at a higher level because that's all that's stuck in my mind, versus having that broken down to say, hey, this is the most critical element, pay attention to this, this is my final conclusion, now let me provide you some evidence that backs it up. And then that's also the recognition of where that audience is, what that audience needs, allows you to recognize, all right, how much do I need to back up that conclusion? Is it somebody that has a lot of technical depth that really wants to challenge that conclusion or needs to understand a lot more depth? That's going to be a longer format, I'm going to have a lot more structure behind how I'm proving out that that conclusion is true, versus I may have an audience that really doesn't care, they need to make a snap judgment, they need to really understand that conclusion at the very base level, I'm going to give that conclusion up front and then I'm going to justify that conclusion very quickly and succinctly so that they can make their decision and they can move on. The other piece that really comes into a lot of this is making sure that that audience has a lot of trust in whatever the conclusion is, and so if all you're doing is throwing a lot of data at them, and especially if there's elements of that data that don't match their intuition right off the bat, well, then do I trust it, do I not trust it? I don't really know, I wasn't given any guidance, I don't know what's actually relevant to you drawing the conclusion you're trying to draw, versus if I'm provided that as a very nice outline, a very nice structure that leads into the conclusion, I know exactly why the conclusion's made, what's justifying the conclusion, and then I recognize that I trust that justification, I'm going to trust the conclusion, I can make the decision I need to make. It seems as if then the first step here might be make some assumptions about the kinds of decisions your audience might be making based on what you've been asked to do, and use that to help inform your organization. Yeah, exactly. If you're not asking questions of who is your audience, what is it that's actually critical to your audience, you're not effectively communicating to that audience. One of the things you mentioned a heck of a lot for my students, and I hope they really take it home, is there is no single perfect technical document that's being written, rather there's a document that's written that's for a particular audience well, but then if you needed to take that and give it to a different audience, even about the same topic, it might be terribly written. It doesn't meet their needs whatsoever. Okay, yeah. So thinking from the perspective of the student then, reports tend to have a really expected format, right? Introduction, methods, data, analysis, you know, depending on the format that you're given, but there's always a format. So given that there is a format, why is making organizational decisions really something worth focusing on? Yeah, and you know, kind of to that point, one of the things that I also want to throw out there is, you know, we will oftentimes, whatever organization, so we at Georgia Tech have a format that might match our laboratories, but we never tell somebody this is the absolute format. There is a good format, you know, many organizations will have formats that are adjusted for different ways. And kind of to answer the question, it's so, because there's an expectation that's created around that format so that I know what I'm looking for, I know where I need to go to search for that information so that it's effectively conveyed. If I'm reading 20 reports every single day, at least if there's some kind of normalization in the way that that is being presented, the information that's being presented, then I can understand that information more quickly, I can do my job more effectively. However, even inside of that, no format's going to be perfect for every scenario that you're going to be seeing. That's where we have to think critically about what was the need. So I need to back up the evidence for a conclusion that I have. I have a format that's being given to me, but what needs to fit in, say, a methods or methodology section versus what is considered to just be data? Where do I need to present the initial conclusions? Is that the very beginning? Is that near the end? Do I need to explain to somebody some of the background knowledge prior to giving them a conclusion they can understand? Or can I give the conclusion up front because they're already fairly knowledgeable about the subject area, and then they're just looking for a little justification? A lot of that's really going to come into who is that audience? Where are they starting from? Are they going to be, say, trying to make some snap judgments if I give them a conclusion up front and they say, I don't agree with that, and then they completely turn off of the rest of the technical communication versus if I'm working with an audience that really does know what's going on in this area, I can provide the conclusion up front. They can kind of in their head be making that decision, but then they can back that out through all of the rest of the evidence that I'm providing to say, look, I'm building additional trust behind that conclusion. Okay, great. So can you talk a little bit about why writing chronologically... All right, I'm restarting that sentence. So we've done a lot of team teaching, and I know that one of your pet peeves is getting reports where it is just totally written chronologically. So can you talk a little bit about why writing chronologically is likely not the best option in technical reports? Yeah, absolutely. And again, it's not to say that chronological doesn't ever have its place. I think one of the biggest challenges that students go through is, again, they have been through whatever experience they experienced to get the information in the first place, and so the natural point that they turn to is to explain, well, I learned this fact, then I learned this fact, then I learned this fact, which then allows them to more or less just avoid having to provide any sort of structure that's focused on their audience. And so when we're teaching, we tell them basically you can't use chronological largely as a device to force them to have to think about what the audience need is. And so why would I tell somebody the steps of exactly how I collected the data if that has no relevance to them making the decision or the conclusion that they need? Now, it might be useful if the process that I went to was critical to understanding a conclusion, then great. Give that as chronological evidence. Oftentimes if I can lead with, say, what the topic is, and then I can back up what that topic is with the evidence that I'm needing to provide, and it doesn't matter if I collected a set of evidence from that first or I collected a set of evidence for that last. It matters for you to understand this conclusion, I need to know this bit of information first. That helps me prove it out. And then I need to fill in this bit of information, then I need to fill in this bit of information. And if I can think about the process the reader needs to experience versus the process that I went through to get the information, I'm going to be able to convey those facts a lot more interesting. I'm going to be able to convey those facts a lot more appropriately. Okay, yeah. So it sounds like this has a lot to do with cognitive load, that writing chronologically can oftentimes heighten the cognitive load on the reader. Yes, absolutely. It goes into that idea that if I'm not providing the appropriate kind of structure, I'm making the reader have to sift through all of this additional information, and most of it is not going to be relevant to what they're actually trying to understand from my technical document. And in that point, they either get frustrated, they give up on it, and they don't want to really have me as a worker. Or they could read it, and again, through all of this detail, they actually glean the wrong pieces of information from it, or they glean details that don't really seem to reinforce a conclusion because it was just steps that I went through that might have seemed contradictory, but later on, I actually proved that they were irrelevant, at which point, why were they even in my documentation? You're just putting the reader in this point of having to sift through everything themselves to determine a conclusion versus you being able to do that effort and allow them to do whatever job they're needing to do. I think that really ties in with the next question. I don't know if that answers the next question, or you want to expound upon it some more, but how do poorly written reports impact decision making in professional engineering settings? At the very least, it's going to make me have to take a lot longer period of time to understand what I was provided to make the decision that I need to make. That can lead to frustration, that can lead to delays on jobs, that can lead to all of these other elements. Poor performance, evaluation. Exactly, exactly. You want to get that raise? Well, maybe you're not as effective to me as an organization. Now, on the flip side, if I can structure that effectively, I can allow whoever's reading my documentation to do the job that they need to do because I did my job in delivering that information as effectively as possible. I know you've done a lot of work here at Georgia Tech, redesigning the labs and the lab course sequence. Why was including the concept of considering a client important for teaching engineers technical experimentation and report writing? Well, and honestly, I have to give you a lot of the credit on this one, is bringing forward the idea of a client allowed the students to really understand and question what is it that that client would need. Well, I guess we could even back up that a little bit more because I helped you guys really flesh out the client, but you had this idea of a scenario of someone who wants something done, and you are then reporting back to that person who has commissioned the experiment. Yeah, and yeah, thank you. And a lot of it is if I tell somebody to just take a couple of actions in a laboratory, you know, turn this dial to five, turn that dial to four, now look at what this indicator is showing, write that number down in a lab notebook and go home, I really haven't understood what was happening inside of that experience. I just sort of witnessed something happening in front of me. Now you take that to a next step, is at least I can ask a question about what this device may be doing, I can try to tie it to some kind of theory, but even then, I'm providing something that's such a canned type of experience for that student that it's hard for them to understand the applicability into the real world. So what we've tried to do is take another step back even from there to add some of the recognition of not only am I going to go through an experimental process, I'm going to get a level of data, I'm going to tie that through the theory to answer a question, I need to understand what was the purpose of this piece of equipment in the first place, right? Why am I being handed it? What is it that the customer thinks it's going to be able to do? And then I can start trying to determine what is it that the customer needs me to answer for them to do their work effectively. And so it requires the students to kind of put themselves into the customer's shoes to answer whatever the questions are that they think the customer is going to need to draw their conclusions based on that. And then when it comes to the communications, to then make sure that they're creating communications focused around that need rather than just sort of, again, giving us that chronological accounting of all of the actions that they took, which really doesn't require much depth of understanding of what they did. Okay. So it sounds like you're really helping students see how the concepts that they learn and maybe in some of the more lecture-based classes are going to be put to work in a technical engineering setting. Yes. Yeah, exactly. And a lot of that is, you know, the technical classes, they absolutely have their place. You have to understand what is the formula, what are all of the different variables that are feeding into that formula, what kind of, how can I use each of these tools in my tool belt? Well, the challenge then becomes now if I just give you a problem, which tools are applicable? How do I make the determinations or make decisions about which of those tools are applicable to this particular problem? There's a level there. Then once I know how to apply those tools, how do they work together? Like I've got a whole bunch of different equations, but maybe some of those equations are more applicable to this particular challenge and other equations aren't as applicable. Maybe they would, a bunch of different ways that I could go with my analysis, maybe even lead to different conclusions, but I trust one more than I would trust another. And so we want students to have to deal with that kind of uncertainty. We want them to have to recognize the client has a particular need. Maybe there's different ways I could simplify this problem, and because of the way that I choose, the assumptions that I'm making, allows me to then reach into my tool kit, apply the right tool to do some analysis to understand how I'm going to draw a conclusion, and then to, again, explain that result. And one of the things that students really miss a lot of times is going through that logical process themselves for the client. It's, you know, hey client, you need this question answered. To answer that question, I didn't need to analyze all of these other 50 things that I could have analyzed. I only need to analyze this one element. For that, I can make all of these different assumptions. Let me make sure that I'm telling you which of those assumptions are relevant, or maybe if you're needing to ask a deeper question, you can relax some of those assumptions. But I need to communicate that kind of stuff. That is actually really important to what the client needs to know. Maybe the client doesn't need to know that I did 50 trials, and 40 of those trials weren't relevant to answering their question. It was just taking me off in different directions, and I learned something from it. But what I learned was this was not relevant for my client. It was still useful work for me to have gone through, but it's not necessarily useful for me to convey. So, it seems as if, in this class, you're showing students how they can take the technical information that they know, and make decisions about what needs to be applied in particular situations. So, then, on the communication side, why is choosing an effective organizational strategy a part of the job of the engineer? Yeah. So, again, it comes back to the engineer is not only responsible for generating whatever the conclusion is, whatever the data is that they need to convey. We have to do that. We have to do that effectively. We also need to convey that in such a way that somebody who's reading our results doesn't misinterpret those results, or misunderstand them. And so, if I am not thinking about the way that I'm going to present those results as part of my technical reports, there's a much stronger likelihood that somebody's going to misunderstand those, and then make an inappropriate decision, right? What I needed somebody to understand was that the beams on this bridge needed to be bigger. But because I gave them a, you know, 50-page process where I walked them through every single little detailed step that I did for testing, for me to reach that conclusion, what they saw in there was that I tested small beams, and I tested big beams, and in this one particular case, the small beams seemed to do okay. Well, I liked that result. I'm going to decide to build my bridge with tiny beams, and the whole thing falls over. I mean, it's, hopefully, that's not going to happen. But me being able to effectively communicate that, have a focus on the result. You need bigger beams. You need to have something that's robust enough for this application, and then reinforcing that is a part of my job as an engineer to make sure that somebody else is going to be making the decision that they need to be making, that's reinforced by the data and the analysis that I've been able to provide. Okay. So, can you then provide some examples on how prioritizing the client's needs can impact the report organization? Do you have, like, a particular anecdote or scenario that you've taught in the past where you develop this scenario, you realize that the students are really going to need to use this organization because of the decisions that the client, obviously, is going to need to make? Yeah. So, an example of that from the teaching standpoint is we have, like, an internal combustion engine that we have the students work with. So, it's got a motor. It's got an electric motor, you know, connected through a battery that's essentially acting like a starter motor that's spinning this engine. Then we've got the engine itself that we're, you know, EH&S doesn't necessarily like us having big things exploding right in front of students' faces. So, we have stuff that's powered by pneumatics that's emulating the functionality of the combustion engine. The students will come in, and we'll ask them several questions about that. We'll ask them, what are all of the friction properties inside of this? What is the way that you would model this system, inertial properties? How much energy can I get from this system that maybe I can pass through a motor and I can charge? Again, they want to then walk through everything that we've asked them to do and whatever process they did it. The reality is that at the end of the day, our customer would like to know, A, I want to use this engine as a generator. How much energy can I generate? Well, I should lead with something like that. If that's what the customer really wants to know, I need to lead with an answering their question. Then I need to reinforce that. I need to show them evidence that, you know, I'm saying you can generate this number of joules of power, right, or, yeah, energy. So when I'm doing that, let me back that up, sorry, I have to think, I got ahead of myself. That's all right, we'll just cut this. Yeah, we might have to cut that section and restart it, sorry. We also don't have to answer this question if you don't like it. No, I like the question. I'm trying to think of the best way to structure an answer. Actually, I think I have a better way to go with it. Okay. Do you want to ask again? Sure. So can you provide some examples of how prioritizing the client's needs can impact report organizations? Sure. And especially kind of in our teaching capacity, we've got these labs that we have the students doing. One of those labs is actually a stress-strain lab. So we're having the students test all of these different materials. And what the client would like to know is, when is this device going to fail? Let's say a climbing sling. I would really like, as I'm climbing up a rock wall, I'd really like my climbing sling not to break and drop me to the ground. That would be next. And so, as an example, we'll have the students walk through this experimental process where they're testing these climbing slings. And through that, they're going to have a certain level of trust in the result that they are working through. There's going to be factors of safety involved. There's going to be a lot of this. Well, when I'm delivering a conclusion, I need to not structure it purely on the, well, I tested climbing sling number one. Climbing sling number one held 27 kilonewtons worth of force. Climbing sling number two held 36 kilonewtons of force. Climbing sling number three held, you know, 30 kilonewtons of force. And if I do that and then I give people, all I did was I provided, say, 50 tests of all of these, maybe they go through and they know something about statistics or they know whatever and they can draw out the proper conclusion. Or maybe they go through and say, hey, look, one of those climbing slings held enough that was like double the capacity of all the others. I'm going to make a decision that I like these climbing slings and I'm going to use up to a force capacity that's that high. Now I've misjudged a product and I have climbing slings breaking and it's becoming a major safety concern, right? That could drive me out of business. So when I'm structuring, that would be another example. Maybe I don't need to be driving everything based on a chronological. I don't need to be providing literally just all of the evidence. What I need to be doing is showing, let's say, best case, worst case might be a good structure there. I can say all of these climbing slings that were tested, there was an upper range to what they were able to do performance-wise and there was a lower range for performance-wise. Well, and in this particular case, I can even break that down for my customer to say, you know, maybe we don't need to pay attention purely to that upper range. It's nice that it was stronger than the rest of the climbing slings, but being stronger than the rest of the climbing slings doesn't end up with somebody injured. But the lower range, that could lead to issues. So I need to focus my analysis and make sure my reader is recognizing it was the lower range that I really care about, right? So maybe there's a way that I need to structure based on what was the question that was being asked. Here's the topic that we really care about or the function of the device that we're working through. Here's the conclusion. Here's how I'm backing up that evidence. I'm going to give some of the data points, but I'm going to focus that really on maybe what was the worst case of what my structure was able to do. I'm not going to give that chronological accounting of everything that I did in the lab. It almost seems as if you knew that your client needed to make an important decision like this, that writing a report in a chronological organization would almost be shirking the responsibility that you were asked to take on when you took on this project. Yeah, exactly. I'm hired in order to answer a question based on what the client's needs are, not for me to go through some kind of exploration process just for my own reasons. Right. So when you're in the thick of it in class and helping a lot of these new engineers figure out how experiments work in real world settings and writing, how do you guide them to make effective organization decisions in these reports? So a lot of this is challenging them to put themselves in the customer's shoes. So by having them essentially have to go back and reread the kinds of prompts or the questions So a lot of our laboratories are structured around, you know, in our case we're saying you work for Burdell Incorporated. It's this fictional organization that does consulting, and in our case, experimental consulting. You're being provided a product and we're asking something about the functionality of that product. We're either validating it, we're doing a Q&A on it, or, you know, we're trying to give the capabilities or we're just trying to model what this thing is. You know, how would I represent it theoretically? And so inside of, and now I've blanked on the question, I'm sorry. I lost my train of thought. How do you guide students to make effective organizational decisions? Okay, so picking back up. So they're working for this fictitional organization, Burdell Incorporated, and they're being challenged to answer these different questions. How do they... Crap, I lost it again. Ah! My brain is not here. It's okay. Alright, what was the question again? We can cut this. We're on question 4.1. 4.1, okay. How do you guide students to make... That's what I kept missing. I was going down a different rabbit hole. Alright, and you can just restart your answer whenever you're ready. Okay. So a lot of the challenge that we have for the students is we're prompting them. We're giving them as if they're working for this fictitional organization, Burdell Incorporated. It's a consulting organization. We're being given products. We have to either tie that to the theory. We have to answer some kind of question. We have to do quality analysis on it, whatever the case may be. When the students are placed into that sort of a scenario, they're having to meet that client's need, but they forget that that's what they're doing. They're just... As a student, I'm in a three hours long lab block, and I'm giving a whole bunch of tests that I need to make sure that I do in order to meet this question. Their natural response is I'm going to turn to something that's more chronological. Right, and maybe even in their physics labs, they're expected to write chronologically. Yeah, exactly. It's more important that I'm stepping through exactly what steps that I took, exactly what equipment that I did. That's very important to that context, but maybe not so much for the types of products that we're giving to the students. So then what we do is we step in when they try to give us more of this chronological accounting, we step in and say, yeah, but think of yourself as needing to make a decision about this product. Is the product good enough? Do I need to put additional investment into this product? Where might I need to put that additional investment? How do you answer that sort of question? And so that forces the students again into what type of conclusion do they need to be able to draw? What kind of information is most critical to that client? And a lot of this is very much a back and forth process with the students. We're having to challenge them to say, you know, okay, what you just told me has a lot of the information in it, but I might have misunderstood it. Or you made me go through this entire process of whittling down and doing all of the thinking for you instead of you just telling me the answer that I need to understand. And so all of that back and forth with the students is what really gets them to a point where now they can put themselves in somebody else's mindset in understanding how they would like the information conveyed to them. That then allows them to write much more effectively. And hopefully doing that here at Georgia Tech, then when they get out into the work world, they're able to kind of bring some of those skills forward. Yeah. So it sounds like you're asking students to sympathize with the client and sympathize with the cognitive load that might be needed in order to understand and act upon this report and be as kind as you can in still maintaining a degree of trustworthiness, but lowering that cognitive load. Yeah, exactly. So in your classes then, what kind of organizational strategies do you emphasize? So a lot of them are things like if I'm doing experimental tests, what kind of situations, like I have a lot of decision uncertainty. My client needs to understand what's going on with this, but maybe there's a little bit of uncertainty around what my conclusion is. I need to show things as being like what is the best versus the worst case scenario that could exist. Right? I do my analysis. This may have been a conclusion on one side of that uncertainty band. This could be a conclusion on another side of uncertainty band. I need to start comparing and contrasting that. Or if you make a decision in a particular way, this is the best outcomes that could come from this. These are the worst outcomes, really helping them to understand that uncertainty. Oftentimes, and we don't deal with this as much for what we're doing, but oftentimes one of the structures that's needed is that I need to teach somebody something to really understand the conclusion that I'm trying to convey. Maybe I have a level of expertise that the person I'm trying to write the technical report for doesn't understand. So in that case, maybe a simple to complex type of structure makes sense. I need to start out with something that's easily digestible, much more intuitive. Then I'm going to, as I'm providing that kind of evidence up front, I can build onto it. I can start getting more and more nuanced in the kind of answer so that when they eventually make the decision, they're making it from a very informed capacity, but they learned as they went through that technical document. Nice. Which definitely lowers the cognitive load. Yeah, absolutely. But then maybe I'm going to tick off my boss if I give them that document and they already are a technical expert and I just wasted their time through three pages of explaining something to them. So maybe in a case like that, I need to really have more of a topic function type of structure or again, like a compare and contrast or that best worst case. So there's a lot of these kinds of structures that you can put together that are really focused on what the need of that audience is. So it seems like to answer the question, what organizational strategy should I use, you have to consider the audience. Yeah, absolutely. If you're trying to write technical documentations, you're not thinking about or putting yourself in the shoes of the reader, you're probably not doing a very good job of it. So we thought really this entire episode is pretty much about why a chronological organization is generally not the best choice for technical reports. And we're talking about this because it's very understandable why students might want to write chronologically, especially given their trajectory and where they are in their education. But as we've been talking about, it's generally not the best option. Is it ever the best option? Oh yeah, absolutely. And so, and this is again to say, you know, use the right tool for the right job. One of the reasons that we stress so heavily that students shouldn't be using chronological narrative is not because you shouldn't just ever use them. It's because that's what they will naturally gravitate towards because of the way that they do an educational process inside of our labs. Now, on the flip side, let's say I'm doing an accident investigation and I need to really show, A, what happened as this accident was progressing. Well, it probably makes sense to understand that chronologically. First, this thing went wrong. That led to this next thing going wrong. That led to this next thing that went wrong. That led to maybe the critical failure that caused the big issue and is the whole reason that we're investigating this in the first place. Maybe there's a chain of custody element. Maybe there's evidence that's part of this accident investigation that I need to show that, all right, we did a test in order to recognize that the failure was the size of a screw that was used or, you know, the hatch of an aircraft that just blew off of an airplane. Why was it that that led to it? Well, we found some piece of evidence and then we went and we did laboratory testing on that piece of evidence. Maybe I need to show all of the chain of custody for getting that to my laboratory to make sure that that actually was the right part that I was testing. Then I need to show what the chain was of how I did the testing is very critical. If I do some stress testing and then I put it to the side, that came back to the same part and stress tested again, I would get a very different result the second time versus the first time. And if I just presented the second time's results and I didn't tell you anything about what I did the first time, you're going to draw a completely inappropriate conclusion. And so there are times that a chronological approach could really make sense. It's just we want people to be very intentional about choosing whatever the right approach is for their application and for their audience. You referred to it as a tool, which I think is particularly relevant and we're talking about engineering that you want to make sure that you choose your tool on purpose, intentional. You wouldn't walk into the idea lab downstairs and pick up a drill when a saw would do a better job. So when you sit down to write, you want to be intentional. You don't want to just write chronologically because that happened to be the first thing that popped into your mind. You want to be more intentional about choosing what tool to use for this particular job. Exactly. And a lot of that is how do you establish to where you have multiple tools to use in the first place. Even having a level of recognition of what kind of options could I choose in order to match my audience. If all I do is I never think about this, I never really think about putting myself in the audience's shoes, then I'm always going to just give you a string of consciousness for every document that I create and it's now going to be your job to try to figure out from that string of consciousness what was actually important. What conclusion should I draw? How should I make a decision that I need to make? And that's not fair to you. Right. And really that seems to be what our job as a part of the communication curriculum at the Mechanical Engineering School of Georgia Tech here is trying to do is show students the diversity of options that are available to them and coach them how to make the best choices in the right situation. Exactly. So, can you dive in a little bit about specifically the results and discussion section and why ideal organization within these particular sections are crucial? Because we talked a little bit about how reports have a particular format, particular sections that you probably need to have, especially depending upon what your job requires. But I think a lot of this that we're talking about happens within a particular section most importantly. So, can you talk about that a little bit more? Sure. So, I guess just to give a little bit of background, the kind of structure, and again I want to emphasize, it's not to say that the structure we use should be the structure that's used externally. It's a very good teaching tool to have students to work through a structure that we're providing. The structure that we've chosen, it starts with providing an introduction and then diving into a methodology. And between the introduction and the methodology, you're defining your problem, you're defining what kinds of conclusions are going to be drawn, and then you're providing that logical progression for how you're going to prove out those conclusions. What kind of evidence is going to be presented to the reader so that they have an outline or a framework in their mind before they even start diving into the actual core data, the core analysis. Right? So, that portion for us, we're doing something that's, you know, 2,000, 3,000 words, typically as a technical report, as an output, that usually maps over to something that's around three to four pages, written pages. And usually those first two elements, that's going to be half to three quarters of a page of that. It's providing the structure to the reader. From there, the real important part is that data and analysis section. One of the main reasons is that's where you get everybody lost. If I just start dumping data on you, I just give you charts, and here's all of the data that I've generated through my 30,000 data points and whatever experiments that I did, the reader just looks at that and just goes blind. Right? It's not helpful for them making the decision that they need to make. If instead, we can structure that effectively. So, if I'm walking through an analysis piece, maybe there's sub-conclusions that directly prove the overarching conclusion that I want, that I can show first. I can say, look, these are the sub-conclusions that we were able to draw that reinforces the main conclusion. Now, why did we draw those sub-conclusions? Well, I have it kind of structurally in my document attached, and I'll use consistent keywords between them. I'll have topic sentences that are kind of referring to, you know, maybe here's evidence approved sub-conclusion one, here's evidence approved sub-conclusion two, that are then the topic sentences of the paragraph that give that amount of evidence. And then I'm going to have formulas or I'm going to have figures or charts inside of those paragraphs, or at least referenced within those paragraphs, that are relevant to what that paragraph is discussing. It's relevant to the topic sentence, relevant to the concluding sentence of that particular paragraph. So, when somebody's reading through this discussion section, the topic sentences, conclusion sentences, those are providing a guidance for how this fits into the structure that I already provided them in my introduction to my methodology, right, the logical progression or the outline that they're already structuring in their mind. So the idea is I'm creating these places where I can hang knowledge early on. Then when I'm coming through this data analysis section, I'm going to remind you of what knowledge I needed to give you at these different times and why it's relevant to trying to show this overall structure. Then I'm going to provide you the knowledge that you needed, right? Then from there, once I've done that for all of the different elements that I needed to prove out, that's where I bring everything back together with the conclusion, right? This is where oftentimes they get an audience member, a reader, gets to the end of discussion and analysis section and they're just sort of swimming. You know, even though we try to do our best job of providing as much structure as possible, they're still just swimming, trying to grasp at, okay, what was it that I just learned? What was the most important part? We wrap that up with the conclusion. We reaffirm what was the overall reason we were doing this, what was the overall conclusion that was drawn, and what were the most pressing or most relevant argument pieces that were reinforcing that conclusion, right? And then that wraps up the overall report. Okay, yeah. So it sounds like while you're breaking down the results and discussion section to one of the organizational strategies that we talked about, probably not chronological, could be topic, function, compare, contrast, simple, complex, to best, worst case scenario, and that is how you have divided your subsections of the results and discussion section. You should be giving your audience a roadmap of the fact that that's going to happen in every section. So you're in your introduction. It should be clear the way in which this, sorry, the way in which this information is going to be formatted for the audience to understand it. And because of that, here is the information about the experimental setup that I'm going to give you. If it's a short report, probably not all of it. Just the part that is most pertinent to the way everything else is set up. Then whenever you get to your results and discussion, it very clearly has subsections that are guiding us through best or worst case scenario. And then the conclusions job is really to bring that back together to give us the bigger bird's eye view of why this is best case in comparison to the other sections that were just kind of completely segmented off. Yes. Yeah, exactly. All right. Should we skip all of six? It seems as if we already answered all of those. Yeah, I think we did. Okay. So thinking, you know, if we have any students listening now, what actionable advice and tips would you give to students to improve their report organization skills? Again, not to sound like a bit of a broken record here, but put yourself in the shoes of the reader. Like, if you're the person that needs to be able to read this, you know, where are you coming from from that level of knowledge and what information or what structure to the information would be most relevant so you don't have to think as hard in order to not only understand what conclusion was being drawn but to trust that conclusion. And so if you put yourself in the shoes of the reader, whatever their case may be, they may be a technical expert, they may be somebody who doesn't have much technical expertise but needs to make an important decision that has millions of dollars riding on it. Put yourself in their shoes to recognize what would you like to have conveyed to you to effectively understand this so that you can then structure it for them. So one of the things I like to tell students is think about the scenario that you were given, the decisions that your client likely wants to make. Think about the experiment, sorry, think about the experience that you had in lab. What is the ideal way for your client to understand the information? How would you, if you got to map it in their mind, would you map it like a web diagram? Would you map it from priority to least important? If you got to design the way they understood that information, how would you design it? Because guess what, you do get to design how they understand that information. When you're in the lab and you're producing information no one has produced before, that newness ends with you unless you can convey it to others. The exciting part is that you get to completely control the dispersal of that information. But that's also a responsibility. Yeah, exactly. Do this effectively, you tend to get promoted. Do this poorly, you tend to need to find another position. So are there any other points you'd like to make or any anecdotes you'd like to give, things you want to tell students to remember? Nothing I can think of right now. Sorry. Thank you so much for coming in and being a part of the podcast. I know this is a really important part of being an engineer because I spent a lot of time since I was hired here interviewing alumni. And one of the things that they tell me the most is how important it is to package information in a usable, actionable way. Yeah, thank you. Hopefully we're serving those alumni well and if we're not, hopefully you guys will all let us know and we'll continue to update our process. It's ongoing, we're trying to make it the best that we can. Thank you, David. Thank you.