Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Communication Mechanics Episode 4: Writing Effective Technical Reports - Beyond Chronological Narratives
444 Plays8 months ago
In this episode Dr. Jill Fennell speaks with Dr. David MacNair, Director of Laboratory Development at Georgia Tech, about technical reports and the importance of moving beyond chronological narratives in engineering communication.
Show Notes and Timestamps:
- Introduction to topic and guest 00:54
- Technical Reports and their role in Engineering 04:28
- Communication challenges for novice report writers 05:48
- Significance of organization in avoiding pitfalls 07:07
- Importance of organization in relation to pre-determined formats 10:34
- Why writing chronologically is not the best option 12:47
- Impact of poorly written reports on decision making 15:40
- Importance of considering specific clients in teaching report writing 16:25
- Why choosing an organizational strategy is the Engineer’s job 20:58
- Examples of prioritizing client needs and the impact on report organization 22:48
- Guiding students towards making effective organization decisions 26:08
- Specific Organizational Strategies, importance of considering audience 28:54
- When chronological IS appropriate or best 31:03
- Results and Discussion sections and importance of organization within them 34:42
- Actionable advice and tips for students to improve their organizational skills 40:14
- Wrap up 42:09
Recommended
Transcript
Introduction to Communication Mechanics
00:00:10
Speaker
Welcome to Communication Mechanics. I'm Jill Fennell, the Frank K. Webb Chair in Communication Skills at Georgia Tech's Woodruff School of Mechanical Engineering. In each episode, we'll explore how communication shapes the success of engineers, researchers, and industry professionals. Join us as we share stories of triumphs, challenges, and the strategies that fuel success.
00:00:33
Speaker
Whether you're a seasoned pro, an aspiring student, or simply passionate about engineering, listen as we demystify compelling communication in the world of mechanical engineering.
Challenges in Chronological Writing
00:00:54
Speaker
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.
00:01:16
Speaker
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.
00:01:37
Speaker
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.
00:01:53
Speaker
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.
Expert Insights: Dr. David McNair on Communication
00:02:12
Speaker
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?
00:02:55
Speaker
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 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.
00:03:17
Speaker
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. um Once we started trying to redesign a lot of our laboratory 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.
00:03:48
Speaker
Through that, we were also finding that there's this issue where, all right, I have something I need to convey to you.
Tailoring Technical Reports to Audience Needs
00:03:54
Speaker
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. Because 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.
00:04:16
Speaker
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. 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.
00:04:45
Speaker
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.
00:05:08
Speaker
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.
00:05:26
Speaker
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 specialists 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.
00:05:48
Speaker
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.
00:06:15
Speaker
and then hopefully that will help you answer the question that you have. And so instead of having them thinking 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.
00:06:41
Speaker
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?
00:07:07
Speaker
Thinking about this, then, why is organization so significant to avoiding these pitfalls? um 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.
00:07:22
Speaker
and a 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 a design. Whatever that might look like, I have a limited amount of time before I need to go do whatever it is my job is they to digest the information that you're giving to me.
00:07:48
Speaker
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, I 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 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
00:08:38
Speaker
And then that's also the recognition of what 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.
Building Trust and Clarity in Reports
00:09:00
Speaker
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, they can move on. The other piece that really comes into a lot of this is making sure that the audience has a lot of trust in whatever the conclusion is.
00:09:20
Speaker
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 that I recognize that I trust that justification. I'm gonna trust the conclusion I can make the decision I need to make.
00:09:50
Speaker
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 yeah 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 actually critical to your audience, you're not effectively communicating to that audience. you One of the things you mentioned a heck of a lot for my students, and i 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.
00:10:33
Speaker
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?
00:10:52
Speaker
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 and 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, the way that that is being presented, the information is being presented,
00:11:33
Speaker
then I can understand that information more quickly, I can do my job more effectively. However, even inside of that, no format is 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?
00:12:19
Speaker
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 for 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. and Okay, great.
00:12:47
Speaker
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?
00:13:02
Speaker
Yeah, absolutely. And again, it's not to say that chronological doesn't ever have its place. I think one of the biggest challenges the students go through is, again, they have been through whatever experience they experienced to get the information in the first place.
00:13:17
Speaker
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.
00:13:41
Speaker
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.
00:13:57
Speaker
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 appropriately. Okay, yeah. So it sounds like this has a lot to do with cognitive load. Yes. That writing chronologically can oftentimes heighten the cognitive load on the reader.
00:14:44
Speaker
Yes, absolutely. um it 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. ah 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.
00:15:07
Speaker
Or they could read it and again they 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? It's 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.
00:15:39
Speaker
I think that really ties in with the next question and perhaps 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 for 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.
00:16:25
Speaker
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
Real-World Applications and Student Learning
00:16:40
Speaker
honestly, I have to give you a lot of the credit on this one is bringing forward the idea of a client, allow the students to really understand and question what is it that that client would need.
00:16:51
Speaker
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 oh 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.
00:17:30
Speaker
Now you take that to a next step it 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 a canned type of experience for that student that it's hard for them to understand the applicability into the real world. So we've tried to do is take another step back even from there to add some of the 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.
00:18:16
Speaker
And so it requires the students 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.
00:18:42
Speaker
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? How can I use each of these tools in my tool belt?
00:19:08
Speaker
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.
00:19:32
Speaker
Maybe they were 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 a 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 toolkit 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, 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.
00:20:27
Speaker
make 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. They 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.
00:20:57
Speaker
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?
00:21:18
Speaker
Yeah. So again, it comes back to the engineer is not only responsible for generating whatever the conclusion is, whether 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.
00:21:36
Speaker
And so if i 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 is going to misunderstand those and then make an inappropriate decision. write thy the What I needed somebody to understand was that the beams on this bridge needed to be bigger.
00:21:56
Speaker
But because I gave them a, you know, 50 page ah 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 beam 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.
00:22:21
Speaker
I mean, it's ah hopefully that's not going to happen, but me being able to effectively communicate that, have the 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.
00:22:46
Speaker
Okay. Can you provide some examples of how prioritizing the client's needs can impact report organization? ah 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.
00:23:12
Speaker
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 the best. um and so you know 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. ah 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,
00:23:38
Speaker
i 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 30 kilonewtons of force. And if I do that and and 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 control out the proper conclusion.
00:24:05
Speaker
Or maybe they go through and say, hey, look, one of those climbing slings held enough to 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. And 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.
00:24:26
Speaker
So when I'm structuring, that would be another example. Maybe I don't need to be by driving everything based on a chronological. I don't need to be providing literally just all of the evidence. um 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.
00:25:12
Speaker
right So maybe there's a way that I need to structure based on what was the 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 lab.
00:25:37
Speaker
Right, it almost seems as if 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.
00:26:08
Speaker
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?
00:26:24
Speaker
So a lot of the challenge that we have for the students is we're prompting them, we're we're giving them as if they're working for this fictional 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. um When the students are placed into that sort of a scenario, ah they're having to meet that client's need, but they forget that that's what they're doing.
Guiding Students to Audience-Focused Writing
00:26:54
Speaker
They're just, as a you know 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 problems that we're giving to the students.
00:27:22
Speaker
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?
00:27:50
Speaker
And a lot of this, it's 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 needed 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 to kind of bring some of those skills forward.
00:28:31
Speaker
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.
00:28:53
Speaker
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, um 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.
00:29:21
Speaker
Right? I do my analysis. ah 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 either worst outcomes really helping them to understand that uncertainty.
00:29:38
Speaker
um 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.
00:29:55
Speaker
So in that case, maybe a simple a too complex type of structure makes sense. I need to start out with something that's easily digestible, much more intuitive, and 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.
00:30:19
Speaker
yeah 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.
00:30:47
Speaker
So it seems like to answer the question, why organizational strategy should I use? You have to consider the audience. Yeah, absolutely. If you're trying to write technical 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.
00:31:03
Speaker
We talked about why 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.
00:31:19
Speaker
But, as we've been talking about, it's generally not the best option. Is it ever the best option?
When Chronological Writing Works
00:31:25
Speaker
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.
00:31:45
Speaker
Now, on the flip side, let's say I'm doing an accident investigation and I need to really show, A, what happened as i 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 there's the whole reason that we're investigating this in the first place.
00:32:10
Speaker
Maybe there's a chain of custody elements, maybe there's evidence that's part of the this accident investigation that I need to show that we did a test in order to recognize that the failure was the size of a screw that was used or i you know the hatch of an aircraft that just blew off of an aircraft of an airplane.
00:32:29
Speaker
um 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.
00:32:50
Speaker
is very critical. If I do some stress testing and then I put it to the side and I came back to that 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.
00:33:20
Speaker
You refer 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 intentionally. You wouldn't walk into the idea lab downstairs and pick up a drill when a saw would do a better job. yeah 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. Exactly. And a lot of that is how do you establish to where you have multiple tools to use from in the first place?
00:33:56
Speaker
ah 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 gonna just give you a string of consciousness for every document that I create, and it's now gonna 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.
00:34:23
Speaker
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 best in the right situations. Exactly.
00:34:42
Speaker
Can you dive in a little bit about specifically the results and discussion sections 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. yes So can you talk about that a little bit more? Sure. um So I guess just to give a little bit bit of background, the kind of structure, and again, I want to emphasize is 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, two thousand, three thousand words, typically as a technical report, as an output, um that usually maps over to something that's around three to four pages, written pages.
00:36:10
Speaker
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.
00:36:37
Speaker
right It's not helpful for them making the decision that they need to make. If instead we can structure that effectively. So if there's, 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 we were able to draw.
00:36:58
Speaker
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 i'll have topic sentences that are kind of referring to, you know, maybe here's evidence that proves sub conclusion one, here's evidence that proves sub conclusion two that are then the topic sentences of the paragraphs 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 references referenced within those paragraphs.
00:37:28
Speaker
that are relevant to what that paragraph is discussing. It's relevant to the topic sentence, relevant to the conclusion, concluding sentence of that particular paragraph. So when somebody's reading through this discussion section, the the topic sentences, conclusion sentences, those are providing a guidance for how this fits into this structure that I already provided them in my introduction to my methodology, right? The logical progression or the outline that they're already structuring 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.
00:38:26
Speaker
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 grab you know grasp it. 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.
00:38:54
Speaker
Okay, yeah, so it sounds like while you're breaking down the results and discussions section to one of the organizational strategies that we talked about, probably not chronological, could be topic, function, compare, contrast, um simple, complex, to best, worst case scenario, and that is how you have divided your subsections of the results and discussions section.
00:39:19
Speaker
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 information is going to be formatted for the audience to understand it. yes And because of that,
00:39:36
Speaker
Here is the information about the experimental setup that I'm going to give you. problem If it's a short report, probably not all of it. um 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 the best case in um comparison to the other sections that were just kind of completely segmented off. Yes, yeah exactly.
00:40:14
Speaker
What actionable advice and tips would you give to students to improve their report organization skills?
Ensuring Usable and Trustworthy Communication
00:40:20
Speaker
um 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.
00:40:42
Speaker
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.
00:41:05
Speaker
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 experience that you had in lab.
00:41:17
Speaker
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 to least important? how 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 and understand that information.
00:41:42
Speaker
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. And 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.
00:42:08
Speaker
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.
00:42:31
Speaker
Yeah, thank you. Yeah, and hopefully we're we're serving those alumni well. And if we're not, hopefully you guys will all let us know. Yeah. And we'll continue to update our process. it's ah It's ongoing. We're trying to make it the best that we can. Thank you, David. Yeah, thank you.