 So this is Stop Speaking Laura Mipsum, how to improve project communications through vocabulary building. And I am Samantha Schreiber. Some of you may know me as Sam Elliott. I'm a Solutions Consultant at FFW. And over the course of my career with Drupal, it's been a little over seven years now. One of the things I realized was a recurring issue amongst a variety of my projects, no matter what role I was playing or how I was relating to my peers or my clients, there was basically this elephant in the room, this unspoken, unspoken but bursty issue that cropped up time and time again. And actually, Barry Long, a Australian spiritual master wrote about this topic in his book Knowing Yourself, The True and the False, when he said, we can rarely see things from the point of view of another person because we look at the facts through the screen of an impression or an interest which distorts our view. And then there are accusations, quarrels, and misunderstandings. Now, this quote's important to me because there's two key points here that brought me to this stage here today to reasons why I thought this was important to talk about. One is that from a very small age when we start understanding who we are as people, we realize that others are different than us. People have different experiences and different perspectives but somewhere along the way, we tend to forget that. I personally forget that all the time and what this does is lead to conflict. We see it all the time in our personal lives, our professional lives and I would like to stop the vicious cycle. So that's what we're talking about today. But first, story time. So if you don't mind bearing with me a little bit, put on your imagination cap so we're gonna go back in time to 2011. I am a team lead working with my development manager and we have joined a meeting with our stakeholders to talk about the project, the status of the project because they're a little bit nervous since we convinced them to switch from an unnamed terrible CMS to Drupal 7 and we've lost some time. There was some development work put into this other system that shall not be named and we're trying to gain back that ground. So they've asked us very directly to give them a status update, how's the project going? So the development manager, he's sitting right here to my right, he says with a very calm but proud grin, we actually have some really good news. The templates are almost complete. Now across from me kind of where you guys are sitting is the director of communications and her face lights up like it is Christmas morning and she's got a giant stack of presents. She is ecstatic. To my left is the web project manager on the client side and she looks a little confused and maybe perplexed about this news. Now I want you all to imagine again, maybe close your eyes if you must and picture what you think of when you hear the phrase, the templates are almost complete. What did you picture? Did you picture code in TPL files coming together very nicely on the back end because you have a development focused mind and you're picturing TPLs? Did you picture wireframes and the thought that the templates or page layouts are starting to come together in sketch form and we're starting to establish these patterns and they're almost complete? Or did you, to use a Southern turn of phrase, picture the whole hog and you went straight to, the designs are complete, the whole page layouts are done and we're raring to go. Now, ultimately no offense, it doesn't really matter what you pictured because my point is that it is very unlikely we all pictured the same thing. Now I'm not gonna leave the story there because I don't want you guys to go back to your hotels tossing and turning wondering what happened in 2011. So let me continue. The development manager to my right had just come off of a scrum meeting with me and our developers and he was referencing the TPLs. Our development team had very, very proudly figured out a way to move the development forward even though our designs were not yet complete. The communications director, our team here has had lit up so brightly because she thought we were about to deliver her a stack of completed designs that were way ahead of schedule because she was thinking the templates are almost complete means she's getting all these design files. And the web manager who'd been reviewing and approving our wireframes before they went on to the communications director in the form of designs was very confused because she knew she hadn't seen any designs yet. She'd only been looking at wireframes and what were we talking about with the templates being complete. And that's just one simple area in which having a lack of a common shared vocabulary can cause problems. There are many technical web related, I don't know what I'm doing, web related jargon that can come into play when you're talking about shared vocabulary in terms that can be tricky. Things like wireframes or content types or taxonomies can be sticky. I don't know how many times I have explained the concept of a site map to a client or to a non-web person. I don't know how many, it's been too many. There's a lot of times I've explained the concept of never really syncing. And that's just at the jargon level. And I think all of us can kind of understand why non-web professionals or others could have a challenge understanding some of these web concepts. It makes sense to us, we need to spend a little more time digging into these things. But I think what a lot of people skip if they even get to that level is going a little bit deeper to the project process and how we're talking about doing project work. Things like Agile or MVP or requirement and deadline. These concepts seem so straightforward to us. And maybe even you'll spend some time on things like Agile and MVP. But I would bet money. People have not spent time talking about the concept of a deadline. It seems straightforward. But how many times have you given someone a deadline only to have them come to you because they worked right up until that deadline before they finished their part of the work? And then you're stuck saying, wait a minute, did anyone else review this? Has it been code reviewed? Has a peer reviewed it? Has it been edited, copy edited? Is it ready to go? So if your understanding of what that deadline means is different than the person who's receiving the deadline, you're going to have conflict, you're going to run into trouble. All right, so we know that we need to focus on terminology and coming to a common understanding. It's pretty clear what the caveats can be. So your mission, should you choose to accept it, and you kind of all have by showing up today and being interested in this topic, is to do some reconnaissance. Gather some information and do some reporting. You really want to get good at identifying these sticky points and learning how to communicate about them and document them so that they don't repeat the same mistakes again and again. And I will say, in that room that day back in 2011, had someone not noticed the giant grin and the confused look, we could have just breezed past that simple comment that the templates were complete, it was factual. There was no reason to dig more into it, except we realized everyone was not talking about the same thing and it gave us an opportunity to educate one another and get on the same page. So in the future, when we were talking about templates, which we did, we were talking about page designs because that's what the most common understanding was of that term. And from then on, if we talked about TPLs, we called them TPLs. So when you're gathering information, what are you doing? Listening, it's pretty straightforward. But in the art of active listening, it's a very, I don't know if you guys have read too many communications or self-help type books, but it's a very deep, deep well. And so I just want to hit on a few concepts within active listening that can be very, very valuable for fact-checking vocabulary understanding and common vocabulary building. Paraphrasing, clarifying, and summarizing. Now, I've separated paraphrasing and summarizing spatially on the screen because it's very easy for people to conflate these two concepts. Basically, they think either they're interchangeable, either way you're just repeating back to someone what they just told you, but there's two reasons why I want to distinguish between them. First, with paraphrasing what you're doing is you're saying, you've just told me this information, I'm going to repeat it back to you in my words. We're going to take what you said and what I'm saying and we're going to try to make them meet. This is very valuable when we're talking about the fact-checking of definitions that I was referring to earlier with the templates. What do you mean when you say template? What do I mean? Okay, are we making them meet? How do we make them meet? Let's go on from there. But summarizing is different and I wanted to call attention to it because I think it's an underutilized aspect of communication. Summarizing is when you repeat back to someone, something that they've just told you, in their own words. I don't know if this happens to you guys as much as it happens to me, but sometimes I don't say the words I think I'm saying. My husband can vouch for this. And if someone were to repeat back to me or if I were to be recording this session, I might hear things that I don't think I said. And so if you take the time to repeat back to someone what they've just told you in their own words, it gives them an opportunity to self-fact-check, to look at what is going on in the situation and say, yes, that's what I intended to convey or wait a minute, did I really say that? That's not what I meant. And they can self-correct. So some of that onus isn't on you to paraphrase accurately and kind of guess what's in their mind. And if neither of these two options can really get you there, there is of course clarifying, which is as simple as saying, I need more information. Can you go a little bit deeper so that I can be sure that I understand what you mean when you're talking about this concept? But that's a lot about what you have to do and the purpose of this talk is to give you all tools, so that's fair. But it can also be very, very valuable to listen for these cues when someone else is speaking to you. Valuable for two reasons. First and foremost, if you hear some of this language reflected back at you, if you were to say to me, so what I hear you saying, Sam, is that active listening is important. Then I would be like, yay, you're engaged. You care what I'm saying. And that's great, it's a good feeling. But more importantly, if you're repeating this stuff back to me, it probably means that you think what I'm saying is important. And that fact can be very important if I don't think that what I'm saying is important. If I thought I've just delivered very mundane news to you, it's a very basic status report or a very basic term that I've used a million times, and you take the time to active listen me, to paraphrase me back to myself or summarize me or clarify, maybe what I thought was so mundane and uneventful was actually really important and we need to stop and dig into it a little more. All right, so you've got the intel gathering down. I wanna go through a few examples of what I mean by putting this into practice. And these are, I guess, fictionalizations of true situations that have happened to me. So on the one hand, the client has extended a deadline. They tell you on the phone call in the status meeting, hey, we need extra time for some internal materials that we're working on. You guys can go ahead and have another week on that deliverable. We could end the call by saying, yes, extra time. And we did, and it was not good because if we had done what is on the right and dug a little deeper, we would have understood that when the client said that because of their own internal deadlines, they needed to move ours, what they were expecting was additional work. Because we had talked about some phase two things, they thought very understandably that if we had extra time, we could work some of those things in. So what we did was deliver a very polished round one. And they almost had no feedback on round one. It was great. But they didn't recognize that greatness because what they were expecting was an expanded round one, not a finalized round one. So if we had taken the time to just quickly and subtly fact check that, we could have avoided some trouble. On a similar but opposite note, we've told the client, hey, we need your feedback by the end of the week. And they say great. And we move on. And then disaster strikes. Because we didn't take the time to make sure they understood what we meant by gathering their feedback, it meant that when the client consolidated all of the internal feedback, what they did was copy and paste a bunch of feedback they got in an email into an Excel spreadsheet. What we meant by consolidate feedback was actually read it and make sure it doesn't conflict with itself and that we can act on this feedback because you approve of what your peers are saying to us and that we can do something with this feedback. Rather than getting, Bob thinks that the colors need to change and Sally thinks that we need to completely re-architect something. I don't know if Bob or Sally actually matter so should we actually follow this advice? So if we'd taken the time to do what's on the right and maybe just clarify that information a bit, we really could have opened that door when they said, oh, well, what format do you need? We could have said, it doesn't really matter what format it is so long as you take the time to read the comments and make sure that they're actionable. A few other tools that you can use in addition to your information gathering are some reporting artifacts. You can create a codec which is my fancy spy language for saying glossary or list of terms or a bunch of stuff we jotted down because we thought it was important and keeping mission logs or taking notes. So let's talk about our glossary. First and foremost, you wanna determine the best format for your team. If you are co-located and your team often gets together in a shared space, I highly recommend doing something visual on the wall. Sticky notes, whiteboard, something that's always present that people can reference. So that way, if early on in the project you have defined what launch means, it means getting everything that is priority one and two done and sometime later in the project that changes. You can see it there, it's reminding you that something is off, something's not clicking and you can bring it up. If you're not co-located, which is often the case, I recommend a digital format of this, something like a Trello board, a Google spreadsheet, whatever floats your boat, but basically something that you can start right away and that you can keep up. So by starting right away, what I mean is right from the introduction of your project, right from kickoff, start the project off on the note of the importance of vocabulary building and common understanding for your team. Go ahead and confront the demons that you already know are lurking in your scope of work. Define what launch means, define what success is and once you've done those things, document it, share that documentation with your entire team so that as their understanding evolves and your understanding evolves, you can reference it. And that's the keep it up part and I don't just mean keep it up in the way that you need to continually do it, which of course I do mean, but also keep it up physically, like visually show it to yourselves and to your clients on a very regular basis. I once had the great intention of using this list to solve my problem's communications issues and we all got together in a big room. We had a great hearty feels session where we all talked about how we didn't understand each other and nobody was speaking the same language and we jotted everything down and we felt great. And for about two months after that, things were pretty good. But we had taken that list that we put together, put it on Google Drive and never referenced it again. So about two and a half, three months later, as new requirements were introduced, as the project phases started morphing into the next and the next, our understanding of the project needs and our understanding of each other started to change, which meant that we literally ended up having the same meeting a few months later to talk about the same problems because no one was referencing the documentation that we had produced earlier. And then when we remembered that documentation, we all felt ridiculous. So keep it up as in keep doing it and keep it up as in as much as possible, pull it up on the screen when you're meeting. You don't necessarily have to run through it every time, that's a little onerous, but just having it there visually off to the side can be a great way to keep these concepts that you know you struggle with, top of mind. And then from the personal side, keep notes. Every project is a new opportunity for you to learn and for you to recognize when you're a culprit in creating misunderstanding and a way for you to keep it top of mind that you want to be focused on communicating well. So mind your sprint retrospectives or your project closeouts for great intel about things that you're not doing well, others don't do well, things that can be improved, and keep that information with you. Take it to your next project. Bring your learnings from your past projects to your future projects. But challenge your assumptions. Just because on the last three projects, people didn't understand what template meant and they all thought that it meant a page design, that doesn't mean that the next project you need to just go straight to, we're gonna call page design's templates. Because that'll be the time that the client thinks a page design is a page design. So you wanna continually challenge your own assumptions when you're talking about these concepts and make sure that each time you're thinking about the fact that the person you're talking with is new, which means they have new perspective and you kinda have to start all over. Remember that the mission never ends. And so I hope that you can take some of these tools and these tricks and these concepts, take them to your project, take them to your organization at large and how you work with your peers, take them home with your families, your friends, and basically always, always, always challenge your assumptions. And maybe you can avoid some conflicts along the way. So thank you all very much. You do have some time for questions. It's a shorter session, but we do have some time for questions if anybody has some. Sure. So the question was about how to start the list off during the kickoff and how you can facilitate such a conversation. So the way I do it is a little bit cheaty because I've been doing it for a while. So I have a list already built up in my head. If you all wanted to start this, you could easily just steal the slide that had all the words on it. Another great way is to look at your scope of work and think about anything that is not super clearly defined or anything that you know has been tricky in the past. Highlight it and then as you're doing your kickoff, walk through those concepts. And exactly like I was saying, do some paraphrasing, do some summarizing, get people to tell you what they think it means and make sure that you're on the same page. One of the points I didn't hit on too much here but that I feel is really, really important is that if you try to force people to use your language, you are going to suffer. I promise you, you will suffer. Because the thing is in a moment when you're explaining a concept to someone, they can be on the same page as you. They can get behind it. But when they walk away, their brain still has whatever biases, whatever knowledge, whatever concepts they had already there. So that moment when you're like, I explained to the client what a sitemap was. They got it, they repeated it back to me. They drew it on the whiteboard, we were there. Why when I delivered the final sitemap, did they not understand what they were seeing and are proving why? It's because they didn't really understand it in the first place. And so trying to find a common language that you both can get behind, reflecting their language back at them, can be the best way to handle those situations because then you know they're gonna get it when you say the squiggly line thing. I don't care if they call it the squiggly line thing. If they know what the squiggly line thing is, that's what we're calling it. It'll get us over the finished line and that's all we're really trying to do. So once you're in the trenches with all the muck, how do you get out of it? You kind of just have to start exactly back there at the kickoff. And that's what I was saying about the project that had gone off the rails. We did that and it was really successful. It's tough. It's tough to hear some of that feedback and to realize that you didn't communicate as clearly as possible. There were definitely some times when I realized that my assumptions had been part of the problem that the team was having. So if you can kind of put your own ego aside, work through that and then move forward from there with the list always present. Don't make my mistake and have that nice come to Jesus moment only to put it in a box and forget about it. But that, I mean, I would just go right back to the start. Versus something where you dig in, you come out and you say, oh, I thought it was X. You explained to me that it was a number of other things. But that's one person's evaluation of the situation. Does that make sense? Yeah, so I think the question is about how do you talk about the difference between not vocabulary understanding, but actual fact. Yeah, interpretive cases say this. Right, so an example may be something like interpretation of user data. For instance, something like that. Like we've all interpreted it this way, but then Bob here thinks that it means X and is really insistent that it means X. They're not. Gotcha, it does. Yeah, so once you've built a foundation of understanding off of something that is faulty, how do you course correct? Yeah, I would recommend that once you've realized that your foundation is faulty and that you need to course correct, hitting that head on as well. So saying, you know, this is the information we had at the time. This is why we made these decisions at the time. Here's how we can address it from here and here's the impacts that it's going to have. And here's how I'm going to dedicate myself and how we can all dedicate ourselves to avoiding this again in the future. Making sure that you have a method for fact-checking some of those things moving forward. Because the fear once you uncover it is that what if it happens again, right? Well, what else is behind the scenes? Yeah, what else is looking behind the scenes? Well, that brings us to time. Thank you guys very much for your attention. Have a great DrupalCon. I swear I'm not doing it on purpose, you guys. Stay there with that.