Understanding the Audience

[00:00:00]
>> So we are on to communication, and we're about to spend about half the rest of the course talking about communication, because that is most of this job. I'm gonna talk about general principles of communication. And then I'm gonna apply these principles talked about here in communication and technical writing.

[00:00:17]
And then I'm gonna talk about them in conjunction with the meetings cuz these principles here apply to both of them. So I wanted to kinda get the general ones out of the way first, and then we'll apply them. So people, you're probably unsurprised I'm saying this again, but the most important part about whatever communication you're doing is who the hell is listening to you?

[00:00:41]
And what are you trying to get them to do, and what are you trying to get out of them? So just whenever you're writing a doc, the extremely first question is what stakeholders am I looking at here? Who is going to be reading this? Know your audience. The way you write a memo to be consumed at a company with 10,000 people is going to be wildly different than an abbreviated executive summary that you're gonna send to senior leadership of that company, right?

[00:01:13]
So know who you're talking to and know what you want from them. Have a damn point. I've read too many docs that just have no point whatsoever. It's like, why did I spend a bunch of time reading this? This is a bunch of context that leads me nowhere.

[00:01:28]
Sometimes, rarely, context sharing can be the exact point of that. But usually, you're trying to inspire action or you're trying to inspire something to get done from other people. Being informational is typically not enough, so be intentional. You can want sponsorship of your project, you can want investment, you can want additional resources, whatever that is, but just ask yourself, who am I talking to?

[00:01:55]
Why am I talking to them, and what am I trying to get out of them? What is success, and what is failure? So please, where possible, be explicit of what you want, and where not possible to be explicit, be tactical about it. Yeah, and lead your audience to the conclusion that you are hoping to get out of them.

[00:02:17]
And then sometimes I do find that there are some opportunities for discovery, so I'll kind of put hooks in there for people like, okay, I'm wondering if I tell you these kinds of things that I'm gonna get inbound information that I'm looking for. So you acquiring additional context can also be a point of whatever communication that you're engaging in.

[00:02:37]
So an example I put in here is, we are working on feature X, but we don't yet know what the technical problems are, and then if you send that out as a draft to a technical organization. You better believe that all of those folks in that organization are going to tell you exactly what's technically wrong with your project, cuz people love to tell you what's wrong with things, right?

[00:02:57]
So highlighting points of uncertainty can also lead to opportunities for discovery. So people, people, people, know your audience and know who you're talking to, and know what you want to get from them.
>> What, and maybe you'll get to this, is your advice or your strategy for handling what eventually becomes a kind of a recursive cycle?

[00:03:27]
Because we're gonna sit down and we're gonna write our plan, we're gonna move forward with that plan a little bit, we'll definitely have to go back and make edits, corrections. Do you have a way of thinking about that? Or somewhat, maybe put it tersely, how do you got to press 80% complete, knowing that more than that is probably too much?

[00:03:49]
>> It depends [LAUGH].
>> I think that's a good answer.
>> It's a sign of a good learning organization, or to borrow the Microsoft terminology that I heard way too much, a growth mindset, right? If I never hear that again, I'd be too soon. To know that whatever your specifications are or whatever your vision for something deserves to be revised and revised frequently.

[00:04:22]
So having a culture of revision and a culture of learning and a culture of applying new context to old ideas allows for you to kind of have that sort of flexibility. I think software has gotten to a much different place than it has years ago, and I, unfortunately, only can speak in the context of software cuz that's all I've ever worked on.

[00:04:49]
But we expect to kind of have those revisions that we don't, we're not sending things off to the manufacturer. It's a whole different process where you have to be really sure about what you're doing before you send things off. But having a single source of truth helps that a lot.

[00:05:05]
Rather than having ten documents that all talk about the same thing, it's better to have one doc that is the plan, and then a bunch of other docs that refer to the plan, and that you continually modify the plan over time. And having a good culture of marking docs as deprecated as soon as they are not applicable anymore.

[00:05:24]
That was a big problem at Stripe, because Stripe is such a writing culture. Stripe writes everything down. Sometimes you'd be looking at docs and it was like, you would not know that this has actually been deprecated and there was new thinking on it. They got better at it towards the end of my tenure there, but, yeah, kind of like the idea of a living document is my best idea of how to handle that.

[00:05:47]
Hopefully, that will get explored more as we keep talking about it, too.