Computers since 1980, programming, games, and now for almost 18 years incident response/investigation of computer crimes.
I am retired LEO, that now works for a security company (easy to figure out, not many folks named Vern) doing DFIR work in the OT space, including Incident Response Plan development and Tabletop Exercise design and execution. I taught DFIR at the college level for over a decade, but am on a break from that.
I went into management/leadership, but I stepped back to individual contributor about 15 years ago and it was the right choice for me. I love the zeros and ones, solving puzzles, and helping folks that are in a crisis.
Proving I am in DFIR with my initial response "It depends"
I have done both, and even when doing work internally, I have identified who the report is actually designed for. Is this something the Dir of Sec wants to use as leverage with the CISO for budget? Is this report going to be parsed out to security engineers to harden systems and networks? Is this report going to be used by lawyers and insurance companies to understand what happened so they can inform shareholders, regulators, or underwriters?
Typically all my reports are narrative stories, even when doing threat hunts or security assessments. This may sound awkward, but a class on fictional writing helps for building the narration (not the content, I am still camp "The Evidence Speaks")
I use pictures and tables to emphasize points I am making in the narration, not replace it. So I will say something, then reference a figure on the same page that will help the reader understand or get a point across to them.
I try to keep the raw tech in appendices or specific chapters like, "Forensics Analysis of Host $HOSTNAME". The narration is always in time order, even for proactive assessments. So "This is what we are going to do, this is how we are going to do it, this is what we collected, this is what we did, this is what we observed, this is our analysis, this is our conclusions"
Final report goes out to to the customer I identified during scoping. I have found that report readouts are common enough in the service provider space that as I write the report, I will make notes for "If asked to do a report readout, this will be a slide" I don't make the slides until the read out is requested, but it helps to have those notes.
Last, no matter what you are writing, take a 24 break, then have your computer read it out loud to you while you read through the text. You will be amazed how many small problems like a change in verb tense, that you will pick up on. It also helps make sure your narrative flows and you can also realize where you may have repeated narrative (happens on multiple author reports often) or realize you missed something.