Shownotes Transcript
Welcome to Kodish, an exploration into the lives of modern developers. Join us as we dive into topics like languages and frameworks, software architecture practices, and individual and team productivity, all tailored to developers and engineering leaders. Hello, my name is Ian Barley. I'm a principal architect at Salesforce, and I've got a couple of guests with me today to talk about communication skills. So Laura and Wes, why don't you guys introduce yourselves?
My name is Laura Fletcher. I'm a Senior Program Manager for Leadership Development at Salesforce. And speaking of clear communication, I should point out that I am not an engineer of any kind, but have been an instructional designer for 15 years and
My thoughts on clear communication are that no matter what kind of technical topic you're explaining, we're trying to move people towards a desired behavior. Right. And so this tie in between instructional design and technical writing have a very close connection that way.
Yeah, awesome. And I'm sure we will get deep into the weeds on all of that. So I'm looking forward to this conversation a lot. And Wes, why don't you introduce yourself as well? My name is Wesley Berry. I am also at Salesforce as an architect of engineering culture and practices and have
Have more of an engineering background than Laura, certainly, but less and less engineering over time. And communications has become more and more central to getting my work done. So it's definitely something that I think about, especially as I communicate with the engineers that I used to work with more closely as to how maybe we can go about doing our jobs better, how we can collaborate more effectively, all those kinds of things. Yeah. And I think that's a thing we'll probably come back to repeatedly today is the
I think that is true for any kind of technical person doing any kind of technical stuff that over time you discover that more and more of what you're doing really hinges on communication rather than the deeper technical details of what you're doing. Obviously,
whether you're a software engineer or a rocket scientist, first and foremost, you have to know what you're doing, right? You have to be able to do computer science or rocket science. But at least in my experience, and tell me if y'all have had the same experience,
It seems like when things really go well overall, a huge component of that is the communication angle that you have to work with other people. And in order to work with other people, you have to have some shared mind share, right, about what you're working on and what your goals are and what problems you're encountering are.
And if you're not communicating well, that stuff will quickly become the dominant problem. Absolutely agree. I think that what you said about having that shared mind share or mindset, it's that's like the only way to get there is to verbalize clearly what my position is and double check. Is that the same perception that everyone else has or is there an incongruence somewhere? So that's that would definitely be true for me.
Yeah, and I know in working on culture and practices, I spend a lot of time just checking in with engineers to see how they're doing and how things are going. And one of the things that has come up over and over again is that one of the things that people reach to when they think about their favorite times at work, it's almost always when they feel like they're working on something that tied into a broader narrative, right? That they understood what it is that they were doing, why it was important, how what they were doing was going to...
lead ultimately to that important thing. And, you know, it can be easy to lose that even in the broader context of work. And so, you know, I think it really goes back to this notion that like, if you can communicate effectively and help people to understand what it is they're doing, the impact it will have, why it's important, why you're doing it the particular way you're doing it will just lead to people being more satisfied with their work and more happy. So that's also really important.
I think that's so interesting. And it's funny, my experience at Salesforce has really mirrored that in that when I started, I was an engineer working on teams delivering software. And I kind of quickly noticed that exact effect that you're talking about the fact that when everybody is kind of on the same page, when everybody is, I guess, working towards a common goal that they believe in, and that they agree on, things go great, things move really fast.
And when there's any kind of friction in that, when there's any kind of sand in the gears there about, oh, you have a slightly different perception of why we're doing this than I do, or, you know, you think that our goal is X and I think that our goal is Y, that really just slows everything down. That makes everybody more hesitant and you end up, you know, the amount of overhead in communication that you're spending just grows and grows and grows until it becomes the dominant, you know, factor in the equation.
And so that's why I actually kind of went down the path that I did here at Salesforce. I, you know, sort of moved from an engineering specific role to a role where most of the time I was trying to help people see eye to eye and communicate better about what it is that they're doing to clarify, to simplify and to really get down to the heart of the matter.
And so I've been doing that job here at Salesforce for about six years. And my team's called architecture strategy. And that's exactly what we do. We say, okay, well, here's, here's the architecture and let's see if we can agree on it, see it clearly. And of course, in practice, most of the time that's, that's writing, right? That's what I'm doing is writing, not code, but pros. And it does play a really important role is having that, those lines of communication, those lines of clarification open. Yeah.
Well, and I see you also curating a lot of communication, trying to highlight the
messages that should be seen across teams. And for the size of a company like Salesforce, even though teams are doing a lot of similar work and probably making a lot of similar mistakes, if we can highlight some of those mistakes or decisions, not necessarily mistakes, but decisions that have turned out to work really well or work really not well, so that we can save other teams the time of trying and failing or trying and succeeding, then
Weeding out the try phase is a major benefit of kind of sharing this amount of information and being able to curate the right messages that are already clear enough on their own to have legs. So I know that there are a bunch of different purposes that you can have in terms of like if you're in a technical setting, you can be writing for a number of reasons. And there's lots of different styles, lots of nuance there.
You know, Wes, from your perspective, what are some of the kind of dominant purposes that you think about when you think about communication and the styles that go along with that? Sure. I mean, I think a really common one in the technical setting is basically to educate. You want to make sure that someone understands something, right? But oftentimes, I think communication
What can be sort of intermingled with that, I guess, is when you're actually trying to convince somebody of something, not just that you're trying to provide context and help them be on the same page as you, but that there could be a difference of opinions and you're trying to convince them not only that they would understand what the different options are, but that they would agree with you that the option you have chosen is the correct.
One tricky part with a lot of communications is those times when those sorts of things get intermingled. It's a lot easier to have an effective communication when there is a single goal that you can direct the entire communication towards instead of one where you're doing a little bit of this and a little bit of that. And I think that's one place where we can sometimes go awry a little bit. Yeah, agreed. And I think there's something we've been working on and you and I have been talking about it a lot here, Wes, is
is trying to up our game in terms of when it comes time to make a decision about something, how good can we get about clarifying the lead up to that decision and the ramifications of that decision so everybody's making that decision in a clear-headed way. And so there have been a few practices that we've actually been starting to adopt pretty heavily inside of Salesforce around that. And one of them is fairly simple, and it's something called a decision record. And a decision record is basically, hey, when you have decided something, just
Write it down. I know it sounds so simple, but just write it down. Write down what you decided and maybe what were your reasons for making the decision that way as opposed to another way. This is useful for a huge number of reasons, right? One of which being if you come back later and things are not going right,
you can at least introspect why the decision was made a certain way and maybe change your mind at that point if the facts have changed or if you realized you got something wrong. But at least you have a record of it. And I can count tons of times, at least in my own career,
Where I've done that, I've written down why I made a decision. And then some facts of the matter did change. Either something changed in the real world, like, oh, you know what? The customer doesn't want that anymore. They want this other thing. Or some other kind of constraints have changed. Like, oh, you know what? Disk space is cheaper than it used to be. Or computers are faster than they used to be. And when we look at the decision in light of those changed constraints, we might say,
It wasn't a bad decision then, but it's a bad decision now and we can change it. And so I think just that practice is hugely important. We've also had a lot of success with using an RFC process. And Wes, you know, you've spent more much more time than I have on that. Maybe you could describe that a little bit.
Sure. Yeah, I think the key distinction relay between decision records and RFCs, at least in most cases, is they contain a lot of similar things, right? They're both documents that capture what it is that you're trying to decide about, maybe some of the alternatives you considered, what you talked through, how you thought about it, what decision you ultimately reached.
The big difference really is a process one. So with the decision record, it's really like almost like a journal or something. Like I just want to capture what it is that I thought about and what I did in my small group or on my team so that it's there for posterity so we can refer back to it so that it's clear, so it's explicit. With an RFC, there's usually tied in some amount of seeking approval or at least sign off kind of from a broader group.
So once you've kind of gotten to the point of writing things out, you actually bring in a much bigger group and get them to provide feedback and try to make sure that you're all kind of on the same page. So it becomes important in places where it's really important that the decision is coordinated because there's a broader group of stakeholders. There's a larger impact, that sort of thing. Yeah. And I should have said RFC stands for request for comments. I didn't mention that. Yeah. And of course, then the process things get more complicated. And in some ways, like
the effectiveness of the communication becomes much greater because now there's a lot bigger group of people who are coming from different contexts that have different ideas about what is right and wrong. And you're really then getting more into the area of influence and trying to get everybody on the same page to agree really that among the things that you could have decided that this is the reasonable thing to decide in the current context. I think another important part of
recording decisions like that is just that it gives you the opportunity to learn how to become a better decision maker, which is also sometimes I feel like non-obvious that like decision making in and of itself is a skill. I think most of us just sort of like do it and don't really think about it as something that we could grow better at. But in many cases, I think in reviewing an old decision, it's not really about whether or not that decision was right. In many cases, it's
Did I go about making that decision in a skillful way? Did I bring in all the right stakeholders? Were there other perspectives that I should have brought to the table as I thought about this or other factors that I left out? Like maybe I just didn't think about security that day for some reason. I was having a bad day in terms of my security stance, right? And so coming forward into a new decision, I could say, oh, right, that other time I really didn't think about security as much as I should have. I should make sure to be on that this time.
So little things like that can really make it so that the next time you make a decision, even if it's a totally unrelated decision, that you will be able to do it more skillfully, which I think is also a really important thing. That's really interesting. I like the idea of having like a personal gain from really strong communication in the first place. I'm curious, you've talked about that being able to reflect on the quality of your decision making as kind of after the fact. Is it always after the fact reflection time?
or just by virtue of documenting it, can you review your decision making in the moment? And is there value just to the act of writing it down? - I mean, I've certainly found value just to the act of writing it down. In a lot of cases when I've done it, I've used a template for instance. So even just that by itself,
means that my process of making decisions is more consistent than it would be if I just sort of like went off on a little walk and thought about it and came to a conclusion. Like, you know, doing that, you're going to probably not be nearly as consistent about what different factors you consider, what order you consider them in, maybe even like how you write it down or not, all those kinds of things. So I think that has been helpful.
In general, I have tended to find it helpful, but I've also found it difficult to sell that to other people, I guess is kind of where I land. So that makes me question whether or not it's broadly useful or not. Like, I think in a lot of cases, people are like, yeah, but this seems like a lot of work. I've just made decisions historically, and it's worked out well enough. So can't I just continue to do that? And of course, the answer is yes, you can just continue to do that. But
your mileage may vary, so to speak. You'll probably have some good decisions and some bad decisions, and it may be very difficult to suss out what made them good or bad.
Did you just get unlucky? Did you just get really lucky? Or is there something underpinning that? And so I think if you work on it as a skill, the nice thing is that in aggregate, you should tend towards better and better decisions over time. And so, yeah, you'll still have some bad decisions every once in a while, but there should be fewer of them and they shouldn't be as bad. And you'll have more good decisions and decisions that trend towards even better than your decisions have been in the past.
you're still going to have good times and bad times, but overall, like the, the average level should increase if you're making that investment. Yeah. And I think that generalizes actually when we think about, you know, the importance of explaining a decision and how that influences your thought while you're making it. I personally find that to be true about every aspect of thinking. Like,
And maybe that's just me because I write a lot. But for me, writing is a way of thinking. Writing is a way of getting my thoughts crystallized to a degree of, I guess, formality or explicitness that they don't have to be when they're just in my head. So there's this really famous paper from, I think it was from the 1980s, by Peter Narr, who is a computer scientist.
And the paper was called Programming as Theory Building. So the context at the time was a lot of people back in the 70s and 80s sort of viewed programming as essentially typing. If you were writing a program, it was like, well, you know what you need to do. Just type in the program.
And what he said in this paper, and he made a very good case for it, was no, the essential activity of programming is actually building a representation. He called it your theory, building a theory of correspondence between some problem in the real world you're trying to solve and the solution over here in the program. Right. And the richness of that theory and the correctness of that theory is what's at stake in software engineering. Right.
It is certainly possible to build lots of complicated engineering artifacts without writing any prose at all. But if you don't do that, you're missing a huge opportunity to capture and crystallize those theories that are in your head at that time. And you know what? It's not just for other people who might be reading it. It's for you because you're not going to necessarily remember your mental state, this very complicated mental state that you had while you're while you're creating some complex engineering artifact.
So I think this act of communicating and writing is just such an essential part of the process of engineering in the first place. Yeah, I mean, I think it reminds me of the notion of the cognitive bias. It's called the illusion of explanatory depth, actually, which I feel like in some ways, like that is programming writ large is the way it feels sometimes where the notion is sort of like if
If you ask somebody how well they understand something, they will often give you a relatively confident answer. But then if you ask them to explain in depth that thing, things kind of go off the rails. So the classic example is probably there are two really. One is a toilet, right? How well do you understand the way that a toilet actually works? Most people will say, I don't know, like seven out of 10. And you're like, okay, like write a like ordered numbered list of the steps that happen as you flush a toilet.
And they'll get to like one, like press, press the handle down. Right. And two, oh no, maybe I don't actually know how this works at all. Like, you know, like there's, there's more going on to this than I realized. Yeah. And I feel like programming comes into a very similar space where we think we know what's going on and we just sort of like wade in and try to make the best of it. But we actually like get to, you know, step one, step two, and then kind of say, oh no, oh no.
Maybe I didn't really understand what it was that I was trying to solve for here or how I was going to do it. And so, yeah, I think, you know, what Ian's saying here of like taking the time to actually write it out gets you out of that, right? You get to the point of realizing how much you really do or don't know. Yeah, there's so many factors that make writing absolutely critical as a part of what you're doing from an engineering perspective. And yet...
many of us are so terrible at it, right? And it turns out that writing and communicating well is actually quite a bit harder than it seems. Laura, maybe could you take us through some of the kind of basic ideas around how to communicate well so that we're not just flailing out here? Yeah. And this is where I mentioned at the very start, this idea of
driving a particular behavior. And Wes echoed that talking about, you know, two of the major reasons why we write are to educate or to persuade. And so when it comes to, you know, if we're all aligned on we're trying to drive a particular behavior or prevent a particular behavior, then there are some research based techniques that work particularly well. One of the things that we have talked about
And I think we have some varying opinions. So I'll be interested to hear what you guys think. We've talked about context and how providing a certain level of context is really critical for explaining a concept. In learning and development,
context is recognized as really critical for making the jump between the classroom learning or reading or however you obtain the knowledge and then transferring that into however you're actually going to use it, the context in which you're going to use it. And so while something can make perfect sense when you read it on paper, kind of like the toilet flushing example, makes perfect sense when I read it, it doesn't mean that I'm ready to get in there and make the repair.
if I notice that it's not happening correctly. So giving that context of, okay, when I get into that situation, give me the specifics of, you know, what I'm going to see or what you saw when you were in that situation, things like that, that are really helpful. I wonder, um,
if you guys have strong opinions about the level of context, because of course you can take that to an extreme. Yeah. You know, it's really actually quite difficult to get right. Cause I was going to say on, you know, for most of the time people don't give enough context and I think it's useful to
it's useful to distinguish between context and details. Because one thing that I see really often with engineers when they're trying to write something is they will go into such excruciating detail that it's impossible if you're not actually
actually working on the system side by side with them to even follow what they're saying. You know, they'll paste in, you know, reams of code and stack traces and all kinds of other stuff into this explanation. And that can kind of make sense if you're the one working on a particular problem. But for an outsider, it's just...
way, way too much detail, right? All you needed to know was this function does X. And yet here you have 16 examples of it doing X right now on the flip side. What I think people don't give enough of is the kind of context that you're talking about. Why does this thing exist? Who built it? How long has it been here?
What kinds of problems have we seen with it in the past? What's the basic situation here? You know, all of this stuff that you're basically blind to because of something called the curse of knowledge, which is it's very difficult for you to remember that somebody else doesn't know a thing that you know.
And so you skip all the stuff they really need and then give them all the stuff they really don't need. And that's sort of classic bad context in my experience. I think there's a real paradox in that. I think in many cases, people do lean into the more and more detailed side of things, as you described.
And in many cases, the more detail that you get into in that way, the more context you would actually need to provide in order for the person to understand what's happening. Right. So it goes like in the exact opposite direction of what you would want. So really, yeah.
When we say context, what we mean, as I think both of you alluded to, is this notion of like, why does this matter to me? What's in it for me? Why should I care? Right. That's really what you want to make sure that you get to the heart of. It's not about going deeper and deeper into the nitty gritty of what it is that you're trying to talk about. Like sometimes you might need to do that as well. But the more that you need to do that, the more you probably also need to understand why that nitty gritty is also important to the person that might be reading it and understand how it relates to them.
Which can be really hard because one of the other things we've sometimes talked about is this notion that what matters to person A and what matters to person B might be quite distinct. And so now you're in this place of, is there some way that I can structure and frame this document that will matter to both of them? Or maybe am I even getting into the space that I need to write two separate documents or two separate sections in this document where each section addresses one set of concerns? Because sometimes it can be really hard to...
squish all of those different concerns and, you know, where they're coming from and everything else into one thing and really have it remain coherent and sensible. I really like the distinction between details and context, kind of separating those two and
And it reminds me of another communication best practice that we've talked about, which is this avoidance of jargon and complex language. You know, when you talk about having 16 examples of how X does Y and that being in the instructional world, we talk about cognitive overload. It's like you're already explaining something that is a complex idea. And then on top of that, you're forcing me to process things
complex language and lots of technical terminology that even if I know it, the additional cognitive lift, it makes it more difficult. And so we talk about a concept called scaffolding, which is, you know, building on a most basic foundation, you starting with the common denominator of like, okay, here's what we all know.
And this is why you see analogies be really, really helpful, not just for the storytelling component, but an analogy builds on a concept that you already know. So if you liken the toilet flushing to how a dam works, this idea of building on the most basic. And so in order to do that, you're thinking about every word that you're writing. And that seems like such a tall order, but
The fact is a normal adult reads at a ninth grade reading level. You know, that's the level where you're not having to look up lots of words, every other sentence and everything. You're processing things fairly easily, fluently. So they read at that level, but their preferred reading level is actually about two levels under that. That's where it's just really comfortable. And so that's, you'll see popular novels being written at the seventh grade reading level for that reason, right?
And so just like, you know, with any complex topic, if we can strip out any additional brain lifting that we're asking our reader to do, it ensures more and more that they're
going to comprehend, that they're going to remember what it is we were trying to get across in the first place. I think that's so true and makes me so sad. But for me, the important part of this is this idea of streamlining, of really thinking about what is the mental load of my reader going to be as they're reading this. And Steven Pinker actually talks about this in his book, The Sense of Style,
where he says, actually, as you're reading a sentence, you're having to maintain in memory some structure that is the parsing of the sentence and the sense of the sentence. And there are ways you can construct a sentence where you keep that memory load low as they're going, right? So they don't have to stack up a whole bunch of stuff before they get to the payoff. Or you can structure a sentence the opposite way where, you know, you have comma after comma, all of these clauses, but you're not really saying that the thing they need to know until the very end
And so they have 50 words stacked up in memory, trying to hold that on their head before they understand what you're even trying to say. So there are ways you can construct language. But the important part there is not so much how you do it is that you do it. In other words, that you are actually paying attention to what is going to be the experience of the reader here. Right. And that's that can be really hard to do when you're looking at a piece of prose.
because you're so used to it. You've already read this paragraph 12 times. You know what it's saying. You know what you're trying to get across. It's very clear. So, you know, one trick that I sometimes use in that respect is multiple. There's a reason people say, oh, you should have multiple drafts and multiple revisions. At least for me, the reason is freshness. The reason is so that I can come back to that piece of writing with fresh eyes the next day and go, oh, that kind of made sense to me yesterday, but it's so laborious the way that I say it. I could say that so much more simply with X.
Right. And then you're doing all of that kind of work. And in the process, you'll notice you'll notice those cases where you used a word like utilize. Right. And, you know, you have to utilize such and such and utilize is essentially a pointless word because you can it is 100 percent substitutable with use. Right. So you'll just you'll notice those things where you've done that and you'll fix it. I don't know if it's a misperception or I don't know how to label it.
But especially in academia, I see a completely different language pattern. My perception is that it's used to drive credibility, that we're writing like this to show you that we know this topic.
And when we're trying to explain, educate, persuade, I don't think that kind of use of complicated language does us any favors. You're right, Ian. Sometimes the right word is the right word and it happens to be three syllables or more. But I think a lot of times that's not the case. And there's an easily substituted word that...
levels the playing field across your audience. Because not everybody, like you said, curse of knowledge, not everybody knows exactly the same things that you know. That kind of drives me nuts a little sometimes with academic writing, actually, that you get this notion that if you
We're to consider what the goal of the writing was. It seems like the goal of the writing was to demonstrate intelligence or something, not really to, you know, make a point or communicate something to someone else. Right. It was just like it's sort of grandstanding or something. Right. Just sort of like, look at me. How great and smart am I? But at the same time, like, I'm not sure that I can blame them that much because that's the example that they see in other academic writing. And so there's a certain amount of like trying to match that context there.
Still drives me nuts, though. Well, and, you know, in the sense of style, Pinker actually has another way of describing academic writing. And it's that it's just bad. It's just bad writing. But, you know, another thing that I find missing in academic writing and a lot of technical writing, and this is something that you really opened my eyes to, Wes, is the absence of any kind of what you might call storytelling. Right.
Right. Any sort of narrative arc, any sort of concrete details. Talk a little bit about that, Wes. Like, what is the point of using story as a part of your communication?
I think there's a couple of key aspects. One relates back to the notion that Laura was talking about of scaffolding, right? So in a lot of cases like that can provide some common foundation for the conversation where everybody's kind of on the same page, right? You don't have to know this particular jargon or whatever. You don't have to have necessarily been in the room at the right time to have seen this thing unfold that would give you the context that you need. Like you tell the story so that everyone is brought to the same page.
Stories are just something that like we grow up with, right? From storybooks as kids up through movies, TV, whatever that we consume now. Like it's just a very familiar form of interacting with the communications and receiving messages that helps to sort of bring us along and give us more of an opportunity to see ourselves in the communication, which I think that doesn't necessarily happen if it's like very normal.
strictly technical and detail oriented. Like you don't see yourself in that. You're just like, Oh, this is information that is like being pressed upon me. I don't see myself as a part of this. That is the power of stories in many ways, right? That we can see ourselves in that story in some way, shape or form. Um, and so they tend to, when used well, at least, um,
be much more memorable and really help to drive things home. And if you, for instance, go and watch two presentations and one has like no narrative element at all, it's very detail oriented. And another one has a narrative element. If you asked people who watch those presentations, like even an hour later, people will probably be able to tell you about that narrative one. And, you know, the number of people that are going to be able to tell you about the detail oriented one is going to be pretty hit or miss. A week later, probably nobody's going to remember the detail oriented one like at all.
I think that memory piece, for me, that is the big selling point. And this was news to me that there are actually like giant memory competitions online.
people who compete to see how many things, random things they can remember in a row. And so I listened to somebody talk about how they do this and they literally are creating a landscape in their mind. So like a place they're familiar with and associating the random things they're supposed to remember within that physical space. And,
And so to me, that is what we're doing when we're telling a story. We're giving people, I think of it as a Christmas tree. We provide the Christmas tree and then we're hanging these ornaments on it so that they can have that spatial relationship to have in their mind. There's an oft cited statistic about
about stories making things up to 22 times easier to remember, which sounds very dramatic. But then you see it in practice and it's like, oh yes, well I did remember the color of the car and I did remember the perpetrator's height or the shade of the sunset on the beach. So when you see it in action it's pretty eye-opening how
valuable storytelling is for retention. And it can be tricky in a technical setting, right? To actually do that. If, you know, I need to tell you about a new database partitioning technique that we are pioneering. And let me tell you a story about some rabbits that had to, I don't know, right? It's like,
Sometimes it can be a real reach. And actually, so for me, I actually kind of embrace that absurdity sometimes a little bit, because I think that ties into another aspect of good communication that I really lean into heavily, which is humor. What's the value of some level of humor or levity in our writing?
Well, I think humor is something that sets something apart from just a landscape of facts. So principle of difference, humor sets things apart in a way that makes me remember it. So Ian, in your presentations, you incorporate a lot of surprising gifs and images as you kind of weave your story of your concept together.
And I can still remember some of those from presentations of yours that I've seen. So because they're unexpected, they stand out and those are things that we remember.
And you can use this for good and for evil, right? So if you're highlighting things that don't matter, if you're using principle of difference to highlight ideas that really aren't supposed to stick with people, you're taking up memory space in your reader's mind. But if you can use it really strategically, like I think that you do, it really helps to submit certain topics.
And, you know, the other kind of piece that I think fits in there for me is there's a kind of signaling that happens when you add a little bit of interest or humor or something unexpected in a piece of writing. The other thing that it does is it telegraphs to the reader, hey, I cared about this. You should care about it, too. I cared enough to put a little extra into this. I'm not just, you know, doing the rote thing that I have to do. And so
And so you might actually want to pay attention to this because you might find other things that are interesting to you. It's like a signal between two human brains of like, hey, open your eyes. This is real. I'm here. I'm talking to you. And so I think that personalness and that personality actually is I think it's a thing that that really can help and can can give that like extra push to make the thing that you're writing or communicating really get across.
So there's one more concept that I think we would be remiss not to discuss as part of thinking about what makes communication really effective, and that is repetition. And I think this is...
It's delicate to some extent because it has the evil brother of redundancy. And people are really, you know, especially as we think about the importance of concision, redundancy is something that should be stripped out every time. But repetition is essential for getting people to remember something. That's the only way that we form memories is by hearing something more than once and having to like consciously think about a concept. Otherwise your brain stops.
deletes it when you go to sleep, that's making more space. And so within a document or within some kind of communication message, this can look like, you know, when you talk about a presentation and you say, you're going to tell them what you're going to tell them, you're going to tell them about it, and then you're going to tell them what you told them. I think that's an easy way to incorporate repetition into
to really drive home what your main point was. Because as much to your point, Ian, having non-fresh eyes, I think it's easy to think this is crystal clear and somebody reads your paper and take away the completely wrong message from that. Internally, there've been some really good examples of recent initiatives, especially around
creating team agreements. I feel like we've been seeing information about team agreements in lots of different channels. And that repetition starts to make you think, this isn't the passing fad. Like, I understand what they are. I understand I'm supposed to work on those with my team. I thought that was a great example of using repetition across channels really, really well.
Ian and I come at this a little bit differently. I know when we work on documents together, especially this becomes apparent where Ian leans much more strongly on repetition than I do. And I think I like try to be concise to a fault, to be honest. So I know that that is like my predilection. Beyond that, I think in many cases, my preference maybe actually is the
to think about kind of more what Laura was talking about, right? This notion of repetition across channels and across messages rather than within a message. Like, I think there's a lot of value to spacing out the repetition, basically. Like, yes, I do want to repeat myself. I want to make sure that that message is clear. But if I say this 10 times in one document, I'm not sure that it's going to be that much better than saying it eight times or maybe five times or maybe only three times. Like, because within the context of that document, there's only so many times that
it's going to stick out. There will be different enough or surprising enough or interesting enough for people to think about it more versus if I repeat it across 10 different channels, 10 different documents, I feel like that lands probably much stronger, but it just depends because there's some things where you just don't have that opportunity. You're not going to have 10 opportunities to communicate about this thing. You're going to have one opportunity to do it. So of course, as in all things, there's some balance that you have to seek out here.
You know, for me, the idea here of repetition, like there's another subtle related idea here, which is redundancy for error correction. You know, if you think about, you know, information transmission, there's a sort of fundamental principle of information transmission that you can reduce errors in transmission by adding redundancy.
So in writing and in communicating ideas, for me, the way that this manifests is trying to say, okay, well, here's the sentence that perfectly encapsulates my point and what I'm trying to say. Then assuming like, okay, now what if somebody just didn't get that? What if for whatever reason it didn't land for them? What would I add to this? You know, maybe, you know, a paragraph later.
That says something like, so in other words, and say it a different way, right? Because if you're just repeating the same thing, it's not necessarily going to make a difference. Like we're not talking about information transmission over lossy wires here. We're talking about something not landing in somebody's brain for whatever reason. Now, you know, we're talking about all this as if, you know, writing here is this thing that you just sit down and you do. And, you know, as long as you understand the stuff we're talking about, you're going to do it well. And that just could not be further from the truth, could it?
Reminds me of the old joke, how do I get to Carnegie Hall? And the guy says, practice, practice, practice. It's kind of the same idea. Yes, yes. I mean, certainly in the way that I've experienced writing over my career, yes.
It's not like some particular thing transpired to make me into a great writer. It was practice. It was that I write all the time. And, you know, I think it is a bit like playing the violin in that, you know, being told what to do can only get you so far. It's just a matter of you doing it, you getting out there and doing it over and over and over again and learning from your mistakes in a sort of deliberate practice kind of way.
I think one important sort of follow on to that is the notion, at least for me, of how important it is to get feedback on that writing. Like, I think all too often, especially earlier in my career in life, I would write up this wonderful thing and like hit send, hit publish. And that was that. I was done. Right. And that's,
I've just learned so much from taking that thing before it goes out to the broader audience and asking, you know, a few key people to just say, what did you get out of this when you read it? Did it make sense to you? Did the points that I was trying to make come across to you? Did you take from it what I was trying to send from it? That is just like really, really valuable. And in the same way, you know, like I find myself now in a place where I often am asked to edit other people's documents. And, you know, I often, um,
learn a lot from what it is that they said, how they said it, how it's different and how helping them to make their writing more effective also gives me a new perspective on how I can make my own writing more effective.
Yeah, having a good editor is invaluable. I'd say the other thing that wasn't necessarily obvious to me, especially as I got into instructional writing, is what drastically different styles of writing exist out there. And adopting a very different voice for different purposes is useful. So when I started to do instructional writing, I came from a job where I had been doing very formal writing. And then I started to do instructional writing,
And then we got into writing instruction and this paragraph style did not work, nor did that voice of authority. And so being able to have a little bit of fluency in the voice that you use, depending on who your audience is and what your purpose is, goes a long way. And so verifying that too with a reader and editor can be really helpful to make sure you're striking that right balance for who you're trying to communicate with.
Yeah, yeah, I could not agree more. And I think you can write just for yourself to enjoy it. But most of the time, writing is communication. Writing is interpersonal.
Right. And so a lot of getting better at writing is just getting better at vibing with people and understanding them and understanding how other human brains work and how it works to share thoughts with another human brain. And so, you know, I know we're just about out of time here, but actually maybe that would be an interesting note to end on. Do you have any resources that people could lean on as far as getting better at writing and getting better communication? One of the books that I read,
really liked. It's extremely practical, really almost a handbook. It's a book by an author called or named Patty Shank. And the book's called Write and Organize for Deeper Learning. And it's all about ways to not just write language, but then format it in ways that are really easy to process and understand. So really communicating to drive that call to action or behavior change.
That's a great one, and I have not read one. I'll put that one on my list. I know I referenced before Steven Pinker's Sense of Style earlier.
And I do highly recommend that I have had people tell me that it's nerdier than they were ready for. And it is it's like he's a linguist and he's really talking about, you know, how we actually process language. But if you really want to get into it, I think it's it's a great one. And I'll throw one more in there, which is there is a technical writing class that is people speak very highly of. I haven't gone through it myself, but from from Google and if you search and in fact, we'll put these in the show notes so you don't have to search for these.
This class actually really takes you through all the nuts and bolts of just proper powerful English prose in a technology context.
And so, you know, I think that's also just a great way to walk you through things. Yeah. And I don't have a particular book or something to point to, but I think a big thing that I would point to is more about sort of like a process or practice of how you would get better. And I think a really valuable thing to do is to see if you can find something that you can sort of anchor to that's already happening on a consistent basis that some good writing might really benefit and see if you can be the one that does that writing. So maybe your team needs to produce something
a newsletter on a regular basis, or maybe you just want somebody to be able to take the really raw meeting notes that came out of an important meeting and write it up into sort of a little report that other people can more easily digest. Like there's lots of opportunities that happen on regular basis for you to take on some technical writing. And if you don't find more regular opportunities to do it, it's going to be hard to get better.
better. So if you can find things that are already happening that will give you an excuse to do it, it's going to be a lot easier than just sort of this abstract notion of like, oh yeah, I really should work on my writing at some point when something like someday something will come up and I'll work on it. Like really tying it to something can be very helpful. I mean, you can also, for instance, commit to writing a weekly or monthly blog post, right? That's another great way to say, you know,
you know, I'm going to put my feet to the fire that this is something that I want to make sure that I actually am spending time practicing. So this is a way to make sure that it's actually happening. That's awesome. Well, I just want to say thank you to both of you, to Laura and to Wes for this really interesting conversation. And thanks to all of you for listening. And, you know, we'll share those references and some other stuff in the show notes and we'll see you next time.
Thanks for joining us for this episode of the Kodish Podcast. Kodish is produced by Salesforce, where our technology and product teams have built a platform that helps companies around the world connect with their customers. For show notes from this episode and all other episodes, visit heroku.com slash podcasts slash Kodish. To read more about software development at Salesforce, check out our blog at engineering.salesforce.com.