1 00:00:00,040 --> 00:00:03,000 If you think about a game of snakes and ladders, the 2 00:00:03,000 --> 00:00:06,520 technical skills, they can be ladders, but they can also turn 3 00:00:06,520 --> 00:00:09,080 into snakes. If you end up putting a lot of 4 00:00:09,080 --> 00:00:12,040 time and effort into a technology that then falls off 5 00:00:12,040 --> 00:00:16,920 the hype curve and gets forgotten, you then can't get 6 00:00:17,080 --> 00:00:18,840 the work you can't apply to the jobs. 7 00:00:19,200 --> 00:00:23,440 But if you put the work into the soft skills, they are always 8 00:00:23,440 --> 00:00:27,560 going to be ladders. They're not going to ever send 9 00:00:27,560 --> 00:00:30,200 you down a snake if you are learning these things. 10 00:00:30,680 --> 00:00:32,520 So I think that's the key difference, and a lot of people 11 00:00:32,520 --> 00:00:40,760 just don't realize it. Hey everyone, my name is Henry 12 00:00:40,760 --> 00:00:44,880 Surya Virawan and you're listening to the Technically 13 00:00:44,880 --> 00:00:48,080 Journal Podcast, the show where I'll be bringing you the 14 00:00:48,080 --> 00:00:51,240 greatest technical leaders, practitioners and thought 15 00:00:51,240 --> 00:00:54,640 leaders in the industry to discuss about their journey, 16 00:00:54,880 --> 00:00:59,360 ideas and practices that we all can learn and apply to build a 17 00:00:59,360 --> 00:01:02,920 highly performing technical team and to make an impact in your 18 00:01:02,920 --> 00:01:06,160 personal work. So let's dive into our journal. 19 00:01:11,160 --> 00:01:13,080 Hello, welcome to the Technical Journal Podcast. 20 00:01:13,080 --> 00:01:16,080 Today I have with me Jackie Reed, So she's the author of 21 00:01:16,080 --> 00:01:19,000 Communications Patterns. So Jackie, looking forward for 22 00:01:19,000 --> 00:01:21,920 our conversation because I think communication is one of the core 23 00:01:21,920 --> 00:01:26,000 skills for not just engineers, but also all the technical 24 00:01:26,040 --> 00:01:27,560 people working in the tech industry. 25 00:01:27,560 --> 00:01:31,080 So welcome to the show. Thank you very much and hello to 26 00:01:31,400 --> 00:01:33,080 everyone listening. Thank you for having me on the 27 00:01:33,080 --> 00:01:35,000 Tech Lead journal. It's a pleasure to be here. 28 00:01:35,240 --> 00:01:37,840 Great to be part of something with so many great guests with 29 00:01:37,840 --> 00:01:40,080 lots of useful and interesting things to say. 30 00:01:40,560 --> 00:01:43,720 So Jackie, I always love to maybe ask from you first to 31 00:01:43,720 --> 00:01:46,440 share anything from your career, maybe any kind of highlights or 32 00:01:46,440 --> 00:01:48,840 turning points that you think we all can learn from you? 33 00:01:49,600 --> 00:01:52,960 Well, I came from a.net development background 34 00:01:53,080 --> 00:01:56,320 originally and I think one of the turning points for me is 35 00:01:56,320 --> 00:02:00,680 when I moved into software architecture, that was the thing 36 00:02:00,680 --> 00:02:04,320 that propelled me into the architecture space. 37 00:02:04,480 --> 00:02:10,320 And then I entered a competition that O'Reilly run a software 38 00:02:10,320 --> 00:02:13,320 architecture CATA, which they run a couple of times a year. 39 00:02:13,880 --> 00:02:19,840 And since I LED A-Team to win that in 2021, I've done quite a 40 00:02:19,840 --> 00:02:21,880 lot of work with O'Reilly. So I've written my book 41 00:02:21,880 --> 00:02:26,720 Communication Patterns, and I've started my own consultancy as 42 00:02:26,720 --> 00:02:28,480 well. So I provide architecture 43 00:02:28,480 --> 00:02:32,520 consultancy and training along with speaking and running 44 00:02:32,520 --> 00:02:34,520 workshops at international conferences. 45 00:02:35,000 --> 00:02:40,200 And so that move into architecture really pushed me 46 00:02:40,200 --> 00:02:42,520 into these more interesting spaces really. 47 00:02:42,640 --> 00:02:46,000 Hey, thank you for being part of the Techly Journal community. 48 00:02:46,360 --> 00:02:49,640 This show wouldn't be the same without your ears, and you are 49 00:02:49,640 --> 00:02:53,920 the reason this show exists. If you're loving TLJ and want to 50 00:02:53,920 --> 00:02:57,160 see it keep on growing. Consider becoming a patron at 51 00:02:57,160 --> 00:03:01,120 Techligional dot Dev Patron or buying me a coffee at 52 00:03:01,120 --> 00:03:05,960 Techligional dot Dev Coffee. Every little bit helps field the 53 00:03:05,960 --> 00:03:09,520 research, editing, and sleepless nights that go into making this 54 00:03:09,520 --> 00:03:12,760 show the best it can be. Thanks for being the best 55 00:03:12,760 --> 00:03:14,920 listeners any podcast could ask for. 56 00:03:15,320 --> 00:03:17,280 And now let's get back to our episode. 57 00:03:17,720 --> 00:03:20,200 Wow. So if you don't mind so tell us 58 00:03:20,240 --> 00:03:22,960 a little bit more about this architecture Kata sounds really 59 00:03:22,960 --> 00:03:25,800 interesting for those of us who probably haven't heard about it 60 00:03:25,800 --> 00:03:28,520 before. OK, so the idea of an 61 00:03:28,520 --> 00:03:34,360 architecture kata is that as architects, we don't really get 62 00:03:34,360 --> 00:03:37,120 the chance to architect that many systems. 63 00:03:37,120 --> 00:03:41,800 And so it's a practice. So the word kata comes from the 64 00:03:42,040 --> 00:03:45,680 sort of martial arts where kata is a sequence of moves that you 65 00:03:45,680 --> 00:03:47,080 go through and you practice those. 66 00:03:47,720 --> 00:03:52,640 And so these started with the O'Reilly conferences. 67 00:03:52,640 --> 00:03:58,080 They started running these catters actually in person as 68 00:03:58,080 --> 00:04:01,080 short evening events. And then they started when the 69 00:04:01,160 --> 00:04:05,120 pandemic hit, they started doing them online and they now run 70 00:04:05,120 --> 00:04:09,320 them about once or twice a year. So anyone who subscribed to 71 00:04:09,320 --> 00:04:13,240 their online training system, so they don't just get books, 72 00:04:13,240 --> 00:04:15,960 they've got all the live trainings, which I do as well. 73 00:04:16,320 --> 00:04:21,040 But the cat is a part of that and so anyone can enter it and 74 00:04:21,040 --> 00:04:23,840 you can form a team just with random other people, which is 75 00:04:23,840 --> 00:04:25,920 what I did. Or you can bring a team along 76 00:04:26,240 --> 00:04:29,760 and you get a problem which you can solve and they try to get a 77 00:04:29,760 --> 00:04:33,360 real life problem from a non profit, that kind of thing. 78 00:04:33,680 --> 00:04:36,760 And so you can actually solve these problems and create a 79 00:04:36,760 --> 00:04:41,680 repository of your design. And since I won it, I've 80 00:04:41,680 --> 00:04:45,880 actually been a judge on it, which is really good, really 81 00:04:45,880 --> 00:04:48,160 interesting thing to do. So I do that normally about 82 00:04:48,160 --> 00:04:50,920 twice a year at the moment. That sounds really cool. 83 00:04:50,920 --> 00:04:54,120 So I hope for people who love doing architecture, I'm sure 84 00:04:54,120 --> 00:04:56,640 it's not just about monolith versus micro service. 85 00:04:56,640 --> 00:04:58,720 I I hope. But yeah, for those of you who 86 00:04:58,720 --> 00:05:01,640 are interested, maybe, yeah, maybe you can also join this 87 00:05:01,640 --> 00:05:03,240 architecture kata, it's twice a year. 88 00:05:03,760 --> 00:05:07,400 So Jackie, the book that you just published quite recent is 89 00:05:07,400 --> 00:05:10,760 called Communication Patterns. So it's a little bit different 90 00:05:10,760 --> 00:05:13,280 than the architecture thing that you're doing in the 1st place. 91 00:05:13,280 --> 00:05:15,880 Maybe if you can elaborate the background story, right? 92 00:05:15,880 --> 00:05:17,600 Why do you come up with this book? 93 00:05:18,440 --> 00:05:22,320 Well, I was kind of pushed to think about writing a book once 94 00:05:22,320 --> 00:05:26,200 I won that competition because I thought, well, I looked at all 95 00:05:26,200 --> 00:05:28,800 the other books that the people were writing and I thought, oh, 96 00:05:28,800 --> 00:05:30,840 I could do that. I kind of came to the 97 00:05:30,840 --> 00:05:34,960 realisation through winning that I did have some useful knowledge 98 00:05:34,960 --> 00:05:39,800 and things and useful skills. So I thought, what is really 99 00:05:39,800 --> 00:05:44,320 missing at the moment? And communication is kind of a 100 00:05:44,400 --> 00:05:46,200 big thing. It's part of the soft skills 101 00:05:46,200 --> 00:05:51,520 which people tend to forget about because they're so pushed 102 00:05:51,680 --> 00:05:55,120 to focus on their technical skills because that's really 103 00:05:55,200 --> 00:05:59,400 their day job. And so I kind of realised that I 104 00:05:59,400 --> 00:06:03,200 had a lot of techniques and principles I was applying which 105 00:06:03,240 --> 00:06:06,480 either naturally or because I'd learned it from other areas 106 00:06:06,480 --> 00:06:09,160 outside of technology, because I have lots of different 107 00:06:09,160 --> 00:06:11,440 interests. And so pulling these all 108 00:06:11,440 --> 00:06:14,600 together I realized that I had a lot of things that could be 109 00:06:14,600 --> 00:06:18,760 summarized as patterns or anti patterns, which are things that 110 00:06:19,040 --> 00:06:22,880 developers and architects and other technical people can 111 00:06:22,880 --> 00:06:24,640 understand because we use them in code. 112 00:06:25,280 --> 00:06:30,480 And so I proposed this to O'Reilly, and they were really 113 00:06:30,480 --> 00:06:33,800 interested in it. And we've aimed the book at 114 00:06:33,880 --> 00:06:37,120 developers and architects primarily, but it's got plenty 115 00:06:37,120 --> 00:06:40,840 of useful techniques and patterns for other people who 116 00:06:40,840 --> 00:06:44,800 are working in tech. And in fact, one of the people 117 00:06:44,800 --> 00:06:48,720 who wrote some praise for it, Rebecca Parsons, let me get this 118 00:06:48,840 --> 00:06:51,480 correct. She said anyone, particularly in 119 00:06:51,480 --> 00:06:53,880 a leadership position should read this book to become more 120 00:06:53,880 --> 00:06:57,000 effective. So in her mind, anybody working 121 00:06:57,200 --> 00:07:01,040 in technology really could benefit from the book, but my 122 00:07:01,040 --> 00:07:04,280 hope is that it will get technical people who otherwise 123 00:07:04,280 --> 00:07:06,840 wouldn't prioritize their soft skills to look into it a bit 124 00:07:06,840 --> 00:07:10,280 more, because it's very important when they're boosting 125 00:07:10,320 --> 00:07:12,040 their career. Yeah. 126 00:07:12,040 --> 00:07:14,680 So in preparation of this conversation, right, I actually 127 00:07:14,680 --> 00:07:17,640 read some parts of the book. I fully agree that this is not 128 00:07:17,640 --> 00:07:20,240 just for engineers or those architects, right? 129 00:07:20,240 --> 00:07:23,440 So it can apply to everyone, not just in tech, actually. 130 00:07:23,440 --> 00:07:27,040 So some of the coverage is also about general leadership 131 00:07:27,040 --> 00:07:29,320 principles, ways of working and things like that. 132 00:07:29,680 --> 00:07:32,520 So I think I fully agree that this book can apply to any kind 133 00:07:32,520 --> 00:07:34,960 of roles. And I was intrigued when you 134 00:07:34,960 --> 00:07:39,200 mentioned that many tech people actually don't focus or don't 135 00:07:39,440 --> 00:07:41,160 try to improve their soft skills. 136 00:07:41,440 --> 00:07:45,520 Maybe in your view, why is that a challenge for tech people? 137 00:07:46,200 --> 00:07:49,360 I think one of the main things is that if people have any kind 138 00:07:49,360 --> 00:07:53,080 of learning budget at all where they don't get to go to many 139 00:07:53,080 --> 00:07:55,760 conferences, they probably don't get to go on many courses at 140 00:07:55,760 --> 00:07:58,280 all. And so they feel pressured 141 00:07:58,280 --> 00:08:01,960 really into looking at the technical skills. 142 00:08:01,960 --> 00:08:04,680 And probably their managers are probably expecting them to be 143 00:08:04,920 --> 00:08:10,000 doing a course on Kubernetes rather than a course on their 144 00:08:10,000 --> 00:08:13,600 communication skills. And I think it's more people 145 00:08:13,600 --> 00:08:19,400 don't realise that when you're looking at tech skills there 146 00:08:19,560 --> 00:08:24,680 they are key to our jobs. But if you think about a game of 147 00:08:24,680 --> 00:08:28,160 snakes and ladders, the technical skills, they can be 148 00:08:28,160 --> 00:08:30,520 ladders but they can also turn into snakes. 149 00:08:30,880 --> 00:08:33,400 If you end up putting a lot of time and effort into a 150 00:08:33,400 --> 00:08:36,840 technology that then falls off the hype curve and gets 151 00:08:36,840 --> 00:08:40,799 forgotten, you then can't get the work. 152 00:08:40,799 --> 00:08:44,560 You can't apply to the jobs. But if you put the work into the 153 00:08:44,560 --> 00:08:47,640 soft skills, they are always going to be ladders. 154 00:08:47,760 --> 00:08:52,400 They're not going to ever send you down a snake if you are 155 00:08:52,400 --> 00:08:54,600 learning these things. So I think that's the key 156 00:08:54,600 --> 00:08:56,600 difference, and a lot of people just don't realize it. 157 00:08:57,400 --> 00:09:00,040 Right, this is the first time I heard about this analogy. 158 00:09:00,040 --> 00:09:02,400 You know the ladder and snake, so I fully agree. 159 00:09:02,400 --> 00:09:05,640 Again, the communication skills, the soft skills part could 160 00:09:05,680 --> 00:09:08,840 actually propel someone's career and also the effectiveness or 161 00:09:08,840 --> 00:09:12,600 impact in their day-to-day job. Again, a very interesting 162 00:09:12,600 --> 00:09:15,760 analogy, Ladder and snakes for people who still think soft 163 00:09:15,760 --> 00:09:18,880 skill is just you know like wishy washy kind of a skill set, 164 00:09:18,880 --> 00:09:20,440 right? So I think please check out this 165 00:09:20,440 --> 00:09:23,000 conversation later so that you can also improve your 166 00:09:23,000 --> 00:09:26,080 communication skills. So in your book you cover 167 00:09:26,280 --> 00:09:28,840 communication patterns into four different areas. 168 00:09:29,080 --> 00:09:31,560 So the first one is about visual communication. 169 00:09:31,840 --> 00:09:34,680 So this is probably something about turning, you know, 170 00:09:34,680 --> 00:09:38,600 architecture maybe into a charts or diagrams or maybe PowerPoint 171 00:09:38,600 --> 00:09:40,920 slides. So maybe tell us a little bit 172 00:09:40,920 --> 00:09:43,280 more about this area of visual communication. 173 00:09:44,080 --> 00:09:47,920 Yes, I think visual is probably one of the most important areas 174 00:09:48,040 --> 00:09:51,960 really to look at, because visuals are what your audience 175 00:09:51,960 --> 00:09:55,920 spend a lot of time looking at. They might be the only thing 176 00:09:55,920 --> 00:09:59,440 that they actually look at closely, and so they're a great 177 00:09:59,440 --> 00:10:02,480 way to communicate your concepts and ideas. 178 00:10:02,480 --> 00:10:06,280 And they're usually much easier to understand than text because 179 00:10:06,280 --> 00:10:11,080 they are an abstraction of what could be a complete wall of text 180 00:10:11,160 --> 00:10:14,360 if you didn't do it visually. So they're very important 181 00:10:14,360 --> 00:10:17,840 aspects and that's why I started the book with the visuals, and 182 00:10:17,840 --> 00:10:21,040 it's actually kind of where the book grew from originally. 183 00:10:21,040 --> 00:10:24,520 I started with that concept and then grew it into all the 184 00:10:24,520 --> 00:10:27,520 communication. So I start with some of the 185 00:10:27,800 --> 00:10:31,760 foundational visual concepts, which is where any reader should 186 00:10:31,760 --> 00:10:36,000 make sure that they consistently are doing these things before 187 00:10:36,000 --> 00:10:38,520 they try out any of the other patterns and anti patterns. 188 00:10:39,000 --> 00:10:44,240 And I split all of these out into various patterns and tell 189 00:10:44,240 --> 00:10:47,760 people things to look out for, things to apply. 190 00:10:48,160 --> 00:10:51,160 And one of those is called Know your audience. 191 00:10:51,280 --> 00:10:55,680 And this is one that people tend to think that they already know 192 00:10:55,680 --> 00:10:59,320 about, but it's not really just what your audience wants from 193 00:10:59,320 --> 00:11:02,560 you, but it's also what you want from your audience. 194 00:11:03,120 --> 00:11:05,280 And there's a few different questions in there you can ask 195 00:11:05,280 --> 00:11:07,160 yourself. But one of the most important, I 196 00:11:07,160 --> 00:11:10,320 think, is what do you want from your audience? 197 00:11:10,440 --> 00:11:15,640 And if you are carefully thinking about your audience's 198 00:11:15,800 --> 00:11:20,560 knowledge, you can create a diagram That is what they want. 199 00:11:20,960 --> 00:11:24,400 But you also need to get back from them what you need. 200 00:11:24,400 --> 00:11:30,000 So maybe you need them to make a decision or they need to come up 201 00:11:30,000 --> 00:11:32,800 with some ideas based on what you're giving them. 202 00:11:33,240 --> 00:11:37,240 And if you don't give them what they need to do that, then you 203 00:11:37,240 --> 00:11:38,520 won't get what you want from them. 204 00:11:38,880 --> 00:11:43,440 So it's one of those big sort of cyclical questions, what do they 205 00:11:43,440 --> 00:11:44,960 want from me? What do I want from them? 206 00:11:45,320 --> 00:11:49,120 And that know your audience can be a lot more complex than 207 00:11:49,120 --> 00:11:51,760 people think. So there's a whole pattern on 208 00:11:51,760 --> 00:11:54,800 that in there. Wow, it's a great reminder, 209 00:11:54,800 --> 00:11:57,360 right. So it's not just what we want 210 00:11:57,360 --> 00:12:00,000 from the diagram, right. So also like what we want from 211 00:12:00,000 --> 00:12:01,320 them, right. So it could be you know, 212 00:12:01,320 --> 00:12:04,600 something about making decision or even understanding what kind 213 00:12:04,600 --> 00:12:05,920 of solutions that we're building. 214 00:12:06,160 --> 00:12:08,680 So I think that's really key because a lot of people just 215 00:12:08,680 --> 00:12:11,480 build diagrams, I don't know, just to tick the box I would 216 00:12:11,480 --> 00:12:13,520 say. And I think one thing as well, 217 00:12:13,520 --> 00:12:17,200 when you draw a diagram, very little standard is there maybe 218 00:12:17,200 --> 00:12:20,920 previously maybe during my days there is this UML, right? 219 00:12:21,040 --> 00:12:23,960 It was kind of like widely used, but these days I think the 220 00:12:23,960 --> 00:12:26,840 standard has been missing. So what is your view about for 221 00:12:26,840 --> 00:12:29,800 people to actually come up with a good kind of a set of 222 00:12:29,840 --> 00:12:32,160 architecture diagram? Probably of some kind of diagram 223 00:12:32,400 --> 00:12:36,320 to explain technical solutions. I think that it's not 224 00:12:36,320 --> 00:12:38,720 particularly important that people choose a particular 225 00:12:38,720 --> 00:12:42,720 standard, but that they standardize what they're 226 00:12:42,720 --> 00:12:46,360 creating. Because if you have lots of 227 00:12:46,360 --> 00:12:51,400 different types of diagram and they all use different colours, 228 00:12:51,400 --> 00:12:54,760 different keys, different symbols and things like that, 229 00:12:54,960 --> 00:12:59,880 it's very difficult for people to switch from one diagram to 230 00:12:59,880 --> 00:13:03,440 another because they have to change their mental models of 231 00:13:03,480 --> 00:13:06,720 what they're seeing. And one of the big things that's 232 00:13:06,720 --> 00:13:09,400 important with communication is making things as easy to 233 00:13:09,400 --> 00:13:12,680 understand as possible from your audience's point of view. 234 00:13:13,200 --> 00:13:17,280 So I don't say to people you have to use UML, you have to use 235 00:13:17,280 --> 00:13:20,640 AC4 model. You should be using something 236 00:13:20,640 --> 00:13:25,880 that's standard and one part of that is thinking about making it 237 00:13:25,880 --> 00:13:29,840 accessible for everyone so you can think about your colours and 238 00:13:29,840 --> 00:13:35,640 making them OK for people who are colour blind and things like 239 00:13:35,640 --> 00:13:37,200 that. There's lots of different 240 00:13:37,200 --> 00:13:39,560 accessibility things that I've put. 241 00:13:39,560 --> 00:13:43,560 In fact, it's got a whole chapter on accessibility in just 242 00:13:43,560 --> 00:13:47,360 the visuals alone, so there's an awful lot you can do. 243 00:13:47,800 --> 00:13:51,840 But when you're creating your diagrams, you should be thinking 244 00:13:51,840 --> 00:13:55,240 about not mixing levels of abstraction. 245 00:13:55,520 --> 00:13:59,720 Just like when that's done in code, you get an unmaintainable 246 00:13:59,720 --> 00:14:02,680 and confusing mess. And the same is true for 247 00:14:02,680 --> 00:14:05,440 diagrams if you separate out into layers. 248 00:14:05,440 --> 00:14:10,400 So you might have that your context A conceptual, logical 249 00:14:10,400 --> 00:14:11,880 and physical, that kind of thing. 250 00:14:11,880 --> 00:14:15,320 Or if you're using C4 models, you probably have your context, 251 00:14:15,680 --> 00:14:18,240 your container, component and code. 252 00:14:18,600 --> 00:14:21,280 Although component and code they're less useful, but the top 253 00:14:21,280 --> 00:14:24,840 two are very useful, and once you separate these out, that 254 00:14:24,840 --> 00:14:29,040 means your audience can more easily understand what they're 255 00:14:29,040 --> 00:14:33,680 looking at, which is really your main goal when you're 256 00:14:33,680 --> 00:14:35,800 communicating with different people. 257 00:14:36,240 --> 00:14:40,400 So when you're creating your diagrams and making them 258 00:14:40,560 --> 00:14:46,360 consistent, you can also use another pattern in there which I 259 00:14:46,360 --> 00:14:48,520 call representational consistency. 260 00:14:48,960 --> 00:14:53,240 And that's how you make sure that there are explicit links 261 00:14:53,240 --> 00:14:56,280 between your diagrams. So part of that is using 262 00:14:56,280 --> 00:15:00,320 consistent keys and colours and things like that. 263 00:15:00,720 --> 00:15:04,680 If you're using different notations like UML or data flow 264 00:15:04,680 --> 00:15:08,920 diagram, you are going to have different shapes, but you need 265 00:15:08,920 --> 00:15:13,400 to be consistent in how you're presenting things and how you're 266 00:15:13,400 --> 00:15:17,320 referring to different things in your text and the colours you're 267 00:15:17,320 --> 00:15:20,680 using and things like that. But when you're separating 268 00:15:20,680 --> 00:15:22,760 things out into the different levels of abstraction, you're 269 00:15:22,760 --> 00:15:26,400 going to end up with more than one diagram, which is really 270 00:15:26,400 --> 00:15:29,720 good for getting people to understand what's in it because 271 00:15:29,720 --> 00:15:32,360 there's less in it and different diagrams are going to be for 272 00:15:32,360 --> 00:15:35,480 different audiences as well. But you need to make sure that 273 00:15:35,480 --> 00:15:39,240 your audience can navigate between those diagrams and see 274 00:15:39,240 --> 00:15:41,800 how they fit together, and there's lots of ways you can do 275 00:15:41,800 --> 00:15:44,240 that. One of those is when you use 276 00:15:44,480 --> 00:15:48,120 identifiers in each diagram. So if you've ever used a data 277 00:15:48,120 --> 00:15:52,880 flow diagram, it has processes which are numbered, and data 278 00:15:52,880 --> 00:15:56,000 stores typically have a letter identifier for them. 279 00:15:56,320 --> 00:16:00,240 So if you're using different levels of data flow, if you're 280 00:16:00,480 --> 00:16:04,680 moving down and breaking things down, each of your diagrams 281 00:16:04,680 --> 00:16:07,840 should have the same identifiers on it for the different data 282 00:16:07,840 --> 00:16:09,920 stores. If they appear in one diagram. 283 00:16:10,320 --> 00:16:15,400 But also if you've got a process that's labeled #2-IN-1 diagram, 284 00:16:15,640 --> 00:16:17,920 then when you break that down into another diagram, you can 285 00:16:17,920 --> 00:16:23,960 label it 2.12.22.3, etcetera. And so you're just creating that 286 00:16:24,320 --> 00:16:27,920 link between them, make it easier for people to understand. 287 00:16:28,800 --> 00:16:32,280 Speaking about consistency, you know color accessibility, right? 288 00:16:32,280 --> 00:16:35,400 When I read your book, I must realize that I've never cared 289 00:16:35,400 --> 00:16:38,240 about those things before. But now that you mentioned in 290 00:16:38,240 --> 00:16:40,040 your book, right? So I think it's really 291 00:16:40,040 --> 00:16:42,920 important, especially maybe for different kind of audience, 292 00:16:42,920 --> 00:16:44,880 right. We sometimes just pick the color 293 00:16:44,880 --> 00:16:47,640 that we think are nice, but in your book you cover there are 294 00:16:47,640 --> 00:16:50,560 different kind of a gradient or maybe that kind of color that 295 00:16:50,560 --> 00:16:53,560 you should choose instead use the consistent theme, right? 296 00:16:53,560 --> 00:16:55,840 I think you mentioned about consistency so many times, not 297 00:16:55,840 --> 00:16:59,400 just color but also shapes. And I think very, very important 298 00:16:59,400 --> 00:17:02,120 is about the mixing level of abstraction, right. 299 00:17:02,120 --> 00:17:05,839 So I think when we draw diagrams, sometimes we don't use 300 00:17:05,839 --> 00:17:08,880 the same kind of abstraction. Sometimes you could be in a 301 00:17:08,880 --> 00:17:12,280 context, but sometimes you go down into more like a physical 302 00:17:12,280 --> 00:17:14,920 deployment sometimes, right. And you put it all together in 303 00:17:14,920 --> 00:17:18,160 one diagram. So I think I like the C4 model 304 00:17:18,200 --> 00:17:21,440 from Simon Brown. So when I read his book also, he 305 00:17:21,440 --> 00:17:24,800 covers from his audience, right? There are so many different 306 00:17:24,800 --> 00:17:28,119 types of diagrams and it's very, very confusing because they all 307 00:17:28,200 --> 00:17:30,040 look different. That's the first thing. 308 00:17:30,120 --> 00:17:32,280 And the second thing is the levels of abstraction. 309 00:17:32,280 --> 00:17:34,400 Usually it's mixed jumbled up together. 310 00:17:34,720 --> 00:17:38,240 So I think it makes it really hard unless you follow how the 311 00:17:38,240 --> 00:17:39,960 author is creating the diagram, right? 312 00:17:40,160 --> 00:17:42,880 So for people who just saw the diagram first time, I'm sure 313 00:17:43,000 --> 00:17:45,520 they will be confused. So I think very, very important 314 00:17:45,520 --> 00:17:47,840 about this. And I think another thing you 315 00:17:47,840 --> 00:17:50,520 cover in your book about this visual communication is about 316 00:17:50,520 --> 00:17:53,960 the narrative, maybe how you present about the diagram, 317 00:17:53,960 --> 00:17:55,520 right? So tell us more about how can 318 00:17:55,520 --> 00:17:57,880 you narrate your kind of visual better? 319 00:17:58,440 --> 00:18:02,280 Well, narrative is actually very important factor when it comes 320 00:18:02,280 --> 00:18:05,600 to communication as a whole. So when you're thinking about 321 00:18:05,840 --> 00:18:10,000 when you're telling a story or when you're writing something or 322 00:18:10,000 --> 00:18:14,680 when you're creating a diagram. And one of the main reason for 323 00:18:14,680 --> 00:18:19,400 this is that we evolved listening to stories and passing 324 00:18:19,400 --> 00:18:23,160 information on in stories because we could speak and use 325 00:18:23,160 --> 00:18:25,880 language before we could write anything down. 326 00:18:26,240 --> 00:18:29,160 And so our brains as kind of tuned into stories. 327 00:18:29,520 --> 00:18:34,760 And so narrative is very useful when you're trying to get 328 00:18:34,760 --> 00:18:39,680 somebody to understand something, but it's also really 329 00:18:39,680 --> 00:18:45,000 useful in diagrams as well. And the main way that you can 330 00:18:45,000 --> 00:18:48,040 apply this to diagrams is when you've got those various 331 00:18:48,040 --> 00:18:50,480 different diagrams. As I said before, you're going 332 00:18:50,480 --> 00:18:54,560 to have these different kind of levels of abstraction. 333 00:18:54,560 --> 00:18:57,520 And when you're talking to people about things, you need to 334 00:18:57,520 --> 00:19:01,360 order them from the high level down to the low level. 335 00:19:01,760 --> 00:19:05,280 And the pattern, I call this the big picture comes first. 336 00:19:05,800 --> 00:19:08,840 So we often forget that others don't have the same 337 00:19:08,840 --> 00:19:12,200 understanding as us and we need to give them that opportunity to 338 00:19:12,200 --> 00:19:15,760 learn and take that important higher level information and 339 00:19:15,760 --> 00:19:18,680 fill in any holes before we dive into what we really want to 340 00:19:18,680 --> 00:19:21,520 communicate to them. So maybe you are talking about 341 00:19:21,520 --> 00:19:25,840 how you are specifically going to handle a small process down 342 00:19:25,920 --> 00:19:28,960 and you really want to get to this low level data flow diagram 343 00:19:28,960 --> 00:19:31,680 that you've got. But you need to consider what 344 00:19:31,680 --> 00:19:34,600 information your audience needs 1st and maybe start all the way 345 00:19:34,640 --> 00:19:39,320 up at a context diagram to give people an idea of what other 346 00:19:39,320 --> 00:19:41,400 systems you're talking to, because that's important 347 00:19:41,400 --> 00:19:43,240 information when you get down to that. 348 00:19:43,480 --> 00:19:46,240 And so you probably need to actually go through several 349 00:19:46,240 --> 00:19:50,560 different diagrams or slides or just giving people other 350 00:19:50,560 --> 00:19:53,760 information. Like it might be the constraints 351 00:19:54,080 --> 00:19:57,120 for the system that are important to what you're going 352 00:19:57,120 --> 00:20:00,000 to be talking about. And so it's important to start 353 00:20:00,000 --> 00:20:04,120 at that high level and go lower, because if you start right at 354 00:20:04,120 --> 00:20:07,120 the bottom, you're going to get lots of questions and people 355 00:20:07,120 --> 00:20:09,280 won't understand what's going on. 356 00:20:09,280 --> 00:20:11,720 They'll probably also be quite bored as well, because if you 357 00:20:11,720 --> 00:20:13,440 dive straight into the details, that's quite boring. 358 00:20:13,720 --> 00:20:16,880 So give them that big picture 1st and then. 359 00:20:17,200 --> 00:20:20,320 Get down to that point so that everybody's got the information 360 00:20:20,320 --> 00:20:21,720 you need. Yeah. 361 00:20:21,720 --> 00:20:24,800 So I find this different level of views, right. 362 00:20:24,800 --> 00:20:27,080 So it's really important depending on your audience, 363 00:20:27,080 --> 00:20:28,720 which you mentioned in the beginning, right? 364 00:20:28,720 --> 00:20:31,760 So understand the audience and present them with the kind of 365 00:20:31,760 --> 00:20:35,000 view that is suitable for them. It's not like, for example, if 366 00:20:35,000 --> 00:20:37,640 you're talking to stakeholders, maybe don't show directly to the 367 00:20:37,800 --> 00:20:40,480 component or code level, because most likely they'll feel lost. 368 00:20:40,880 --> 00:20:43,680 And it's very, very important to actually know the audience and 369 00:20:43,680 --> 00:20:46,600 present them with the view that you want and narrate that such 370 00:20:46,600 --> 00:20:48,840 that people can understand. So thank you so much for 371 00:20:48,840 --> 00:20:50,720 covering this visual. Maybe just a little bit of 372 00:20:50,720 --> 00:20:52,680 recap, right. The first thing is about knowing 373 00:20:52,680 --> 00:20:55,800 your audience. Don't mix levels of abstraction. 374 00:20:56,120 --> 00:20:59,320 Be consistent in representing the things in your diagram, be 375 00:20:59,320 --> 00:21:01,200 it colour, notations and things like that. 376 00:21:01,640 --> 00:21:03,760 And when you narrate big picture comes first. 377 00:21:04,040 --> 00:21:07,440 So I think that's really key for people who want to find out more 378 00:21:07,440 --> 00:21:09,240 patterns about visual, go check out the book. 379 00:21:09,520 --> 00:21:12,200 So let's move to the second section of your communication 380 00:21:12,200 --> 00:21:15,760 pattern which is about multi model communication, essentially 381 00:21:16,040 --> 00:21:19,080 things like written, verbal and non verbal communications. 382 00:21:19,440 --> 00:21:22,480 So maybe tell us why this is important for engineers and 383 00:21:22,480 --> 00:21:24,120 architects. Yes. 384 00:21:24,120 --> 00:21:27,560 So I called it multi modal so that I could give it a bit of an 385 00:21:27,560 --> 00:21:30,480 umbrella term for written, verbal and non verbal. 386 00:21:30,880 --> 00:21:36,680 And these are skills that we quite often forget that we use 387 00:21:36,680 --> 00:21:40,480 on a day-to-day basis. Even if we're not working in an 388 00:21:40,480 --> 00:21:46,160 office, we're still using verbal and nonverbal skills and 389 00:21:46,160 --> 00:21:50,920 techniques when we're on a call with people with video or not. 390 00:21:51,440 --> 00:21:54,920 And so this area is quite important really. 391 00:21:55,360 --> 00:21:59,360 And I started off with the written area and there's quite a 392 00:21:59,360 --> 00:22:02,600 few different patterns and anti patterns in that one. 393 00:22:03,040 --> 00:22:06,920 One of the simplest things that people can apply has simple in 394 00:22:06,920 --> 00:22:09,960 its name as well, and that's using simple language. 395 00:22:10,320 --> 00:22:14,240 And it makes it much easier for people to understand if you use 396 00:22:14,240 --> 00:22:19,120 a simple vocabulary compared to sort of more terms that aren't 397 00:22:19,120 --> 00:22:21,920 used very much. And it helps everyone. 398 00:22:21,920 --> 00:22:25,320 But it's especially good for those for whom the language that 399 00:22:25,320 --> 00:22:27,840 you're using is not their native language. 400 00:22:28,280 --> 00:22:31,440 And you're also being more inclusive to people who have 401 00:22:31,600 --> 00:22:35,280 dyslexia or things like autism or ADHD as well, because you're 402 00:22:35,280 --> 00:22:37,320 making it more understandable for everyone. 403 00:22:37,720 --> 00:22:42,560 So a couple of easy examples, if you can use the word buy rather 404 00:22:42,560 --> 00:22:46,920 than acquire, and you can use the word most rather than the 405 00:22:46,920 --> 00:22:51,160 phrase a majority of and it just makes it so much easier for 406 00:22:51,160 --> 00:22:54,760 people to understand. But also if you're using less 407 00:22:54,760 --> 00:22:58,440 words as well, it means people can read it quicker and so 408 00:22:58,440 --> 00:23:02,480 people are much more likely to be quite happy with that and 409 00:23:02,520 --> 00:23:06,120 also with the writing aspect. I look at how you can structure 410 00:23:06,200 --> 00:23:10,520 your technical writing, and one of the principles I've pulled in 411 00:23:10,600 --> 00:23:14,680 from other areas is the Minto Pyramid Principle. 412 00:23:14,880 --> 00:23:18,560 And there's a whole book and loads of training and stuff on 413 00:23:18,560 --> 00:23:22,640 that by Barbara Minto if you are interested in that. 414 00:23:22,920 --> 00:23:27,960 And it's all about using structure to make a point. 415 00:23:27,960 --> 00:23:31,040 And then once you've made that point, you then back it up. 416 00:23:31,440 --> 00:23:34,960 So you're making sure that most important information comes 417 00:23:34,960 --> 00:23:39,760 first and it can be applied to documentation, but also it can 418 00:23:39,760 --> 00:23:42,960 basically applied to your emails and messages every day. 419 00:23:43,400 --> 00:23:46,320 And you might actually see people applying that sort of 420 00:23:46,320 --> 00:23:48,680 thing on their social media messages. 421 00:23:48,680 --> 00:23:52,720 So that first sentence catches your attention because quite 422 00:23:52,720 --> 00:23:56,480 often it's the only bit you can see unless you click show more. 423 00:23:56,880 --> 00:24:01,040 So it's getting people's attention, but it's also giving 424 00:24:01,040 --> 00:24:04,080 them that most important information. 1st and news 425 00:24:04,080 --> 00:24:05,400 articles are written in that way. 426 00:24:05,400 --> 00:24:08,600 You've got the headline, the most important information, and 427 00:24:08,720 --> 00:24:11,400 then you get the next most important information. 428 00:24:11,400 --> 00:24:14,400 And so at any point you can stop, but you've already seen 429 00:24:14,400 --> 00:24:18,560 the most important information in that, and you can apply that 430 00:24:18,560 --> 00:24:21,400 very easily. It's really useful in emails and 431 00:24:21,400 --> 00:24:22,760 things. How often have you read an 432 00:24:22,760 --> 00:24:25,320 e-mail where it's kind of rambling on about different 433 00:24:25,320 --> 00:24:28,160 things, And eventually you find the bit that you really need to 434 00:24:28,160 --> 00:24:31,200 do something about, and it's hidden down in there. 435 00:24:31,200 --> 00:24:33,680 And if you hadn't read it properly, you wouldn't have been 436 00:24:33,680 --> 00:24:37,360 able to find that. And so if it had just started 437 00:24:37,400 --> 00:24:41,160 with that most important piece and then given some explanation, 438 00:24:41,440 --> 00:24:43,080 then that would be much easier for you. 439 00:24:43,360 --> 00:24:48,080 And so it's just thinking about, again, making things easy for 440 00:24:48,080 --> 00:24:49,480 people to consume and understand. 441 00:24:50,280 --> 00:24:51,920 So thanks for explaining some of this, right. 442 00:24:51,920 --> 00:24:53,840 So I recently read a book as well. 443 00:24:53,840 --> 00:24:56,720 I think it's called Writing for busy Reader or something like 444 00:24:56,720 --> 00:24:58,520 that. I think some of the key points 445 00:24:58,520 --> 00:25:00,560 mentioned in the book also covered by you just now. 446 00:25:00,560 --> 00:25:02,480 Right. So first, use simple language. 447 00:25:02,720 --> 00:25:05,200 Less is better, right? So don't write in a more 448 00:25:05,200 --> 00:25:07,200 elaborate and long sentence, right? 449 00:25:07,200 --> 00:25:10,080 So if you write it shorter, people will be able to read it 450 00:25:10,080 --> 00:25:13,520 faster and they will make sure to read it in full as well, 451 00:25:13,520 --> 00:25:14,760 right? Because if it's too long, right? 452 00:25:14,760 --> 00:25:17,360 Sometimes people just scan through and maybe skip or 453 00:25:17,360 --> 00:25:19,880 archive your e-mail, right? And the Minto pyramid. 454 00:25:19,880 --> 00:25:23,320 I think it's also very very insightful for some people who 455 00:25:23,320 --> 00:25:25,520 never learn about writing before, right? 456 00:25:25,760 --> 00:25:29,040 It seems counter intuitive in the first time, but actually if 457 00:25:29,040 --> 00:25:31,560 you learn about it right, I think it will make your writing 458 00:25:31,560 --> 00:25:33,120 communication much more effective. 459 00:25:33,480 --> 00:25:36,240 You know some people also call this technique something like 460 00:25:36,240 --> 00:25:39,000 TLDR right? So what's your too long, didn't 461 00:25:39,000 --> 00:25:40,760 read kind of a message right? Your key message. 462 00:25:41,040 --> 00:25:42,480 Some people call it bluff, right? 463 00:25:42,520 --> 00:25:44,960 Bottom line upfront, I think it's used in military. 464 00:25:45,280 --> 00:25:47,080 So I think it's the same key message, right. 465 00:25:47,120 --> 00:25:49,720 Your headline first the most important thing first before you 466 00:25:49,720 --> 00:25:52,800 actually kind of like cover your rationale I think in mental 467 00:25:52,800 --> 00:25:56,400 pyramid as well you kind of like breakdown your main topics into 468 00:25:56,400 --> 00:25:59,920 like at Max three I think the recommendation and you start 469 00:25:59,920 --> 00:26:02,360 building a tree like a chain thought of reasoning. 470 00:26:02,560 --> 00:26:05,520 So I think people should read about this technique and this 471 00:26:05,520 --> 00:26:08,440 mental pyramid also use I think from McKinsey, right. 472 00:26:08,480 --> 00:26:11,600 And they kind of like mandate that for all their consultants 473 00:26:11,600 --> 00:26:14,600 to use this kind of technique. Yeah, I think she developed it 474 00:26:14,600 --> 00:26:16,040 when she was working at Mackenzie. 475 00:26:16,520 --> 00:26:19,840 Yeah, so I think for people who hasn't not heard about this 476 00:26:19,840 --> 00:26:22,400 technique before, do check it out because I think it will make 477 00:26:22,400 --> 00:26:25,400 your writing slightly more effective if it's the first time 478 00:26:25,400 --> 00:26:27,280 right? But if you consistently use it, 479 00:26:27,280 --> 00:26:29,360 I think it will make it even more effective. 480 00:26:29,960 --> 00:26:34,640 So moving to maybe the verbal communication aspect, I think 481 00:26:34,640 --> 00:26:38,440 most engineers prefer chat rather than talking in person, 482 00:26:38,440 --> 00:26:40,400 right? But what is the key message that 483 00:26:40,400 --> 00:26:42,760 you want to cover this about verbal communication? 484 00:26:43,560 --> 00:26:45,200 Yes. So as well as the written, I 485 00:26:45,200 --> 00:26:50,040 cover the verbal and the non verbal and I think people 486 00:26:50,040 --> 00:26:53,000 sometimes think of the verbal, but the non verbal is something 487 00:26:53,000 --> 00:26:57,600 that we think about less. And so we use this all the time, 488 00:26:57,600 --> 00:27:04,480 in person or remotely, and a lot of what we get from conversation 489 00:27:04,480 --> 00:27:08,400 we actually pick up really simply and quickly. 490 00:27:08,480 --> 00:27:13,640 There's the System One and System 2, which was written 491 00:27:13,640 --> 00:27:19,160 about by Daniel Kaneman. And with the System One makes a 492 00:27:19,160 --> 00:27:22,560 lot of decisions really quickly, really snappily. 493 00:27:23,000 --> 00:27:26,920 And a lot of that we like from people's facial expressions and 494 00:27:26,920 --> 00:27:30,080 things like that. And when I've written this, I've 495 00:27:30,120 --> 00:27:33,000 structured it as I've written with the patterns and anti 496 00:27:33,000 --> 00:27:35,000 patterns to help technical people. 497 00:27:35,000 --> 00:27:39,560 I've also structured this around encoding and decoding messages, 498 00:27:40,000 --> 00:27:42,720 which is something we're all kind of familiar with software 499 00:27:42,720 --> 00:27:45,640 development and we don't really think about it in real life. 500 00:27:46,160 --> 00:27:50,520 So when we're setting up communication between services 501 00:27:50,560 --> 00:27:55,560 and different parts of the code or APIs, we encode what we're 502 00:27:55,560 --> 00:27:59,280 communicating and we also decode any replies. 503 00:27:59,640 --> 00:28:04,560 So it might be using HTTPS or message queues, but we're doing 504 00:28:04,560 --> 00:28:07,960 a translation each way, and we don't really think about when 505 00:28:07,960 --> 00:28:11,880 we're talking to someone else. Even if you're speaking the same 506 00:28:12,000 --> 00:28:15,080 native language, everyone's an individual with different 507 00:28:15,080 --> 00:28:18,360 backgrounds. And so we are constantly 508 00:28:18,360 --> 00:28:22,200 encoding and decoding, and things can get easily lost or 509 00:28:22,200 --> 00:28:25,280 misunderstood. And so I talk about some 510 00:28:25,560 --> 00:28:30,360 different cognitive biases and also body language. 511 00:28:30,600 --> 00:28:34,680 And it's based on the fact that if you think about these things, 512 00:28:34,680 --> 00:28:38,280 then you can think about encoding them yourself to 513 00:28:38,280 --> 00:28:41,560 actually give other people the correct message, the message you 514 00:28:41,560 --> 00:28:45,560 want them to receive. But you can also work out better 515 00:28:45,560 --> 00:28:49,160 how to decode things that other people are saying, so you can 516 00:28:49,160 --> 00:28:53,360 realize that they're actually thinking possibly something 517 00:28:53,360 --> 00:28:55,200 different to what they're saying. 518 00:28:55,560 --> 00:28:57,960 And then you can start to try and dig deeper into that. 519 00:28:58,440 --> 00:29:02,760 And so by reading this section, you can improve the accuracy of 520 00:29:02,760 --> 00:29:06,760 your own encoding and decoding and take all these things sort 521 00:29:06,760 --> 00:29:10,560 of use them to your advantage, rather than just being 522 00:29:10,560 --> 00:29:13,880 completely oblivious to them, which quite a few people are. 523 00:29:14,720 --> 00:29:18,040 Yeah, software developer, I think we are all used to, you 524 00:29:18,040 --> 00:29:20,680 know this encoding, decoding, right Be it, you know, you're 525 00:29:20,680 --> 00:29:24,040 calling APIs, you use some kind of interface contract between 526 00:29:24,040 --> 00:29:26,920 two different protocols, right. So I think we are so used to it, 527 00:29:26,920 --> 00:29:30,240 but in the communication, maybe it's written, verbal or whatever 528 00:29:30,240 --> 00:29:32,040 that is, right? We don't actually think about 529 00:29:32,040 --> 00:29:33,880 it. And I think these days we all 530 00:29:33,880 --> 00:29:37,280 work in a pretty global setup where people have different 531 00:29:37,280 --> 00:29:40,120 culture, different language, different interpretation of 532 00:29:40,120 --> 00:29:42,680 stuff. Even some culture actually might 533 00:29:42,680 --> 00:29:45,840 take a certain word differently than other culture, right? 534 00:29:46,160 --> 00:29:49,400 So I think it's really important that we use the right encoding 535 00:29:49,400 --> 00:29:53,120 and also for you to do the right decoding because sometimes there 536 00:29:53,120 --> 00:29:56,160 might be a misunderstanding happening if you don't use the 537 00:29:56,160 --> 00:29:58,040 same protocol or the same contract, right? 538 00:29:58,240 --> 00:30:00,760 Sometimes being explicit, like when you mention about 539 00:30:00,760 --> 00:30:03,000 something, right? Just explain what you actually 540 00:30:03,000 --> 00:30:06,600 mean exactly by using that term. I think it's really important as 541 00:30:06,600 --> 00:30:09,640 well in your view, right? In this global remote set up 542 00:30:09,640 --> 00:30:12,760 these days, how can people become more aware of conscious 543 00:30:12,760 --> 00:30:14,840 about this encoding decoding process? 544 00:30:15,680 --> 00:30:20,640 Yeah, well, I think as you said, a lot of people are much more 545 00:30:20,640 --> 00:30:25,400 likely to type a quick message than they are to either call 546 00:30:25,400 --> 00:30:28,080 someone or pick up a phone these days. 547 00:30:28,440 --> 00:30:34,840 And one problem with text is that you can't get this body 548 00:30:34,840 --> 00:30:39,640 language, the tone of voice. You can't get all those things 549 00:30:39,640 --> 00:30:42,520 in there which you do even if you're just talking on the 550 00:30:42,520 --> 00:30:46,400 phone, you get something from that even if it's not face to 551 00:30:46,400 --> 00:30:49,760 face or on a video call. And even if you're on a video 552 00:30:49,760 --> 00:30:54,760 call, it's actually a lot harder to decode things from somebody 553 00:30:54,760 --> 00:30:56,720 on a video than it is in real life. 554 00:30:57,120 --> 00:30:59,720 And so when we're using all these remote forms of 555 00:30:59,720 --> 00:31:03,280 communication, we're making it a lot harder for ourselves having 556 00:31:03,280 --> 00:31:06,960 it to work a lot harder to understand each other. 557 00:31:07,240 --> 00:31:11,680 And so knowing about these different things to do with body 558 00:31:11,680 --> 00:31:18,240 language and how you can encode things a bit better is very 559 00:31:18,240 --> 00:31:21,320 useful. So applying the writing just the 560 00:31:21,320 --> 00:31:26,560 pyramid principle, that really helps people, and if you are 561 00:31:26,960 --> 00:31:30,720 reducing the amount of effort that people need to use to 562 00:31:30,720 --> 00:31:34,800 understand you, then people are much more likely to come around 563 00:31:34,800 --> 00:31:39,240 to your way of thinking because you've given them something 564 00:31:39,320 --> 00:31:42,360 really easily, whereas they might have to work a lot harder 565 00:31:42,400 --> 00:31:45,560 with someone else. Yeah, I find when you interact 566 00:31:45,560 --> 00:31:47,040 with someone through chats, right? 567 00:31:47,040 --> 00:31:49,320 Sometimes, yeah. Like what you said, the emotion 568 00:31:49,320 --> 00:31:51,280 is not there. Sometimes we actually fill in 569 00:31:51,280 --> 00:31:54,760 the emotion by ourselves, our own perception of maybe this 570 00:31:54,760 --> 00:31:57,000 person is angry, this person is frustrated, right? 571 00:31:57,000 --> 00:32:00,360 But it may not be true from the person's perspective itself that 572 00:32:00,360 --> 00:32:03,160 actually they are frustrated. So I think it's very important 573 00:32:03,160 --> 00:32:06,600 not to judge quickly, right? Or sometimes just clarify with 574 00:32:06,600 --> 00:32:09,880 the person before you actually make assumption and maybe use a 575 00:32:09,880 --> 00:32:12,280 lot more emojis, right? I think you mentioned it in your 576 00:32:12,280 --> 00:32:14,240 book. To actually convey some emotion 577 00:32:14,240 --> 00:32:17,800 in your message, use some more emojis, although emoji can be 578 00:32:17,800 --> 00:32:20,240 interpreted differently as well in some different culture. 579 00:32:20,600 --> 00:32:23,640 So thanks for covering that. Let's move on to the next 580 00:32:23,640 --> 00:32:26,440 section which is talking about communicating knowledge. 581 00:32:26,760 --> 00:32:30,480 So this is something maybe about coming up with wiki or sharing 582 00:32:30,480 --> 00:32:33,840 documentations which I think many engineers know it's 583 00:32:33,840 --> 00:32:37,560 important but somehow still many of us don't get it right. 584 00:32:37,920 --> 00:32:41,760 So tell us how can we upscale our communicating knowledge kind 585 00:32:41,760 --> 00:32:45,080 of skill set? Yes, so this is all about 586 00:32:45,200 --> 00:32:47,760 knowledge rather than just documentation. 587 00:32:47,760 --> 00:32:50,920 Because documentation is a very small part of knowledge and I 588 00:32:50,920 --> 00:32:53,720 know that a lot of people are turned off by the word 589 00:32:53,720 --> 00:32:56,440 documentation. They don't want to have to 590 00:32:56,560 --> 00:32:59,000 create that. But despite it's worth, 591 00:32:59,000 --> 00:33:03,040 knowledge is often neglected in organisations. 592 00:33:03,040 --> 00:33:06,240 It's not part of people's day-to-day job. 593 00:33:06,560 --> 00:33:12,040 They're not rewarded for sharing knowledge, and code is often 594 00:33:12,040 --> 00:33:14,280 given a lot higher priority than data. 595 00:33:14,480 --> 00:33:19,400 So people are very insistent they use version and control for 596 00:33:19,560 --> 00:33:22,080 your code. But when they're thinking about 597 00:33:22,080 --> 00:33:25,840 data, that's often like backups for it and often an 598 00:33:25,840 --> 00:33:29,520 afterthought, despite the fact that data is often a lot harder 599 00:33:29,560 --> 00:33:31,440 and sometimes impossible to replace. 600 00:33:31,640 --> 00:33:35,440 Whereas you can rewrite some code that your data will be 601 00:33:35,440 --> 00:33:37,600 lost. So knowledge is really 602 00:33:37,600 --> 00:33:39,960 important. But just like data, not given 603 00:33:40,200 --> 00:33:45,000 enough information, not given enough thought in a lot of 604 00:33:45,000 --> 00:33:48,240 organisations, but documentation and knowledge management, they 605 00:33:48,240 --> 00:33:50,600 give so many benefits when they're done well. 606 00:33:50,960 --> 00:33:54,160 If you just think about all the time that's wasted by people 607 00:33:54,160 --> 00:33:58,640 trying to find communication, I think it was a Forrester study 608 00:33:58,840 --> 00:34:03,160 that said that knowledge workers spend 30% of their time looking 609 00:34:03,160 --> 00:34:05,200 for information. And that's what we are. 610 00:34:05,200 --> 00:34:08,320 We're knowledge workers. And what would your boss say if 611 00:34:08,320 --> 00:34:12,719 you said, oh, actually I spend 1.5 days per week looking for 612 00:34:12,719 --> 00:34:15,000 the information I need? I don't think they'd be 613 00:34:15,000 --> 00:34:19,560 particularly happy about that. So that's why I've dedicated a 614 00:34:19,560 --> 00:34:25,280 whole part of this book to knowledge and how we can improve 615 00:34:25,679 --> 00:34:29,719 our use of it because there are so many benefits to the way 616 00:34:29,719 --> 00:34:34,920 people work and the end results for products and for customers 617 00:34:35,080 --> 00:34:36,800 and all these other things as well. 618 00:34:37,320 --> 00:34:41,480 And so I cover some principles of knowledge management and that 619 00:34:41,480 --> 00:34:44,920 includes one that I call perspective driven 620 00:34:44,920 --> 00:34:48,960 documentation. And this is my own principle and 621 00:34:48,960 --> 00:34:53,520 practice that I have come up with with all the research that 622 00:34:53,520 --> 00:34:57,120 I've done on this. And it puts the focus on who 623 00:34:57,120 --> 00:35:00,920 you're communicating with and also why you're communicating 624 00:35:00,920 --> 00:35:03,480 with them. Because when you're thinking 625 00:35:03,480 --> 00:35:09,240 about your audience, you're not just thinking about who's 626 00:35:09,400 --> 00:35:12,600 looking at a particular piece of information. 627 00:35:12,600 --> 00:35:15,640 You are communicating with them for a reason. 628 00:35:15,880 --> 00:35:19,320 Maybe it's because they've asked for that information, or maybe 629 00:35:19,320 --> 00:35:23,000 it's because they really need that information even if they 630 00:35:23,000 --> 00:35:26,880 haven't asked for it. Basically you need to determine 631 00:35:26,880 --> 00:35:30,480 what should be communicated by thinking about who you're 632 00:35:30,480 --> 00:35:34,160 communicating to and why and rather than the other way 633 00:35:34,160 --> 00:35:36,160 around. Quite often people, as you said, 634 00:35:36,160 --> 00:35:40,440 it's the tick box exercise. Like Oh yes, I've created a 635 00:35:40,440 --> 00:35:45,840 context diagram, I've created the constraints documentation 636 00:35:45,840 --> 00:35:50,120 for this, but you really need to think about why and who you're 637 00:35:50,120 --> 00:35:53,040 talking to and then that will help you work out what you need 638 00:35:53,040 --> 00:35:55,760 to do. And if you come a tip from that 639 00:35:55,760 --> 00:35:58,680 point of view, then you'll probably not waste time creating 640 00:35:58,680 --> 00:36:01,600 things that actually people didn't need in the first place. 641 00:36:02,080 --> 00:36:05,800 And so stakeholders need to be able to find and understand that 642 00:36:05,800 --> 00:36:08,040 information they need when they need it. 643 00:36:08,480 --> 00:36:11,720 And many people are going to be in one of two situations. 644 00:36:12,040 --> 00:36:16,120 Either all of their information in some sort of bloated huge 645 00:36:16,120 --> 00:36:19,400 word processing document or similar, and it's difficult to 646 00:36:19,400 --> 00:36:22,360 find what you need and it's difficult to version that whole 647 00:36:22,600 --> 00:36:27,720 huge horrible Word document. Or it's spread across many, many 648 00:36:27,720 --> 00:36:31,200 applications and different teams are using different knowledge 649 00:36:31,200 --> 00:36:33,320 repositories. And some people have got it in a 650 00:36:33,320 --> 00:36:35,040 wiki. Other people have got it in 651 00:36:35,040 --> 00:36:37,240 something like Confluence or Notion. 652 00:36:37,560 --> 00:36:44,200 And you inevitably end up with old data lost in various legacy 653 00:36:44,200 --> 00:36:46,640 applications that no one wants to use anymore. 654 00:36:46,800 --> 00:36:48,760 And we thought we'd migrated from them, but we haven't. 655 00:36:49,200 --> 00:36:51,960 And so of course, there's going to be information locked away in 656 00:36:51,960 --> 00:36:54,480 people's heads and also their personal notes. 657 00:36:54,600 --> 00:36:57,840 And so when you look at this perspective driven 658 00:36:58,160 --> 00:37:02,120 documentation, it organizes that information into what I call 659 00:37:02,120 --> 00:37:04,720 perspectives. You could also call them views, 660 00:37:04,720 --> 00:37:07,800 but that's a very overloaded word in technology. 661 00:37:08,200 --> 00:37:12,160 And each of these perspectives addresses the needs of a 662 00:37:12,200 --> 00:37:16,680 particular stakeholder, and so items within that perspective 663 00:37:16,680 --> 00:37:18,320 can be reused in other perspectives. 664 00:37:18,320 --> 00:37:21,520 So that might be a diagram appears in more than one of 665 00:37:21,520 --> 00:37:23,720 these perspectives because more than one stakeholder is 666 00:37:23,720 --> 00:37:26,320 interested in it. It's a little bit like reusing 667 00:37:26,320 --> 00:37:29,200 code so you can follow the DRY principle with it that Don't 668 00:37:29,200 --> 00:37:33,200 Repeat yourself and it makes things easier to maintain. 669 00:37:33,480 --> 00:37:36,720 And I found it actually also goes really well with Domain 670 00:37:36,720 --> 00:37:39,080 Driven Design if you're doing that. 671 00:37:39,320 --> 00:37:43,880 But when you create these perspectives, you can reuse 672 00:37:44,000 --> 00:37:45,720 things. So you might create it as 673 00:37:45,720 --> 00:37:51,120 different wiki pages, and then you embed a diagram into each of 674 00:37:51,120 --> 00:37:54,480 those wiki pages. But when you're doing that, one 675 00:37:54,480 --> 00:37:57,400 thing to think about with this DRY principle is that sometimes 676 00:37:57,400 --> 00:37:59,480 you don't want things to always be the same. 677 00:37:59,880 --> 00:38:05,680 So maybe you're referencing a particular law or a standard 678 00:38:06,040 --> 00:38:09,440 that's applicable at the time. And if you just link to that, or 679 00:38:09,440 --> 00:38:12,840 if you always keep that as the most updated version of that 680 00:38:12,840 --> 00:38:15,080 standard, then it won't make sense. 681 00:38:15,080 --> 00:38:17,560 If you look back at that and people say to you, oh, why 682 00:38:17,560 --> 00:38:19,960 didn't you follow that bit of the standard? 683 00:38:20,480 --> 00:38:23,640 You would have to work out that it didn't exist at the time you 684 00:38:23,880 --> 00:38:27,360 did this part of the project. But if you keep it as this is 685 00:38:27,360 --> 00:38:33,480 the version of it as it was in January 2024 or whatever, then 686 00:38:33,560 --> 00:38:37,080 you can see that, oh, things have changed now and so we need 687 00:38:37,080 --> 00:38:41,360 to make some changes. But it's all about creating 688 00:38:41,600 --> 00:38:46,160 these perspectives for people for particular stakeholders and 689 00:38:46,160 --> 00:38:49,480 therefore not creating stuff that people don't actually want 690 00:38:49,800 --> 00:38:52,120 and wasting your time. And that's probably one of the 691 00:38:52,120 --> 00:38:56,080 main benefits of this way not wasting your time on things and 692 00:38:56,080 --> 00:38:57,440 giving people what they actually need. 693 00:38:58,320 --> 00:39:00,760 Yeah, sometimes what I can see in practice. 694 00:39:00,760 --> 00:39:02,520 OK, there are a few things that I see in practice. 695 00:39:02,520 --> 00:39:06,280 The first thing is we all love to communicate through chats 696 00:39:06,280 --> 00:39:08,880 these days and put a lot of information, maybe sometimes 697 00:39:08,880 --> 00:39:11,600 meeting notes, maybe things that we discuss and everything is 698 00:39:11,600 --> 00:39:14,000 over chat, mostly slacks or teams, right? 699 00:39:14,400 --> 00:39:17,080 And we never take the time to actually put it somewhere in a 700 00:39:17,080 --> 00:39:20,880 repository, be wiki or maybe some centralized place and we 701 00:39:20,880 --> 00:39:23,640 just assume that everything can be searched on chat. 702 00:39:23,920 --> 00:39:26,440 But chat, I think it's a semi structured communication 703 00:39:26,440 --> 00:39:29,600 channel, so sometimes things are not so easy to find as well and 704 00:39:29,600 --> 00:39:32,320 especially if you have multiple threats you know, discussing the 705 00:39:32,320 --> 00:39:34,920 same thing. So probably that is 1 experience 706 00:39:34,920 --> 00:39:36,720 that I have. The second thing is about what 707 00:39:36,720 --> 00:39:40,080 you mentioned, right? People seem to value code much 708 00:39:40,080 --> 00:39:42,520 more than the knowledge of the data, right? 709 00:39:42,920 --> 00:39:45,560 And they push engineer to always start with coding. 710 00:39:45,560 --> 00:39:47,320 You know, start with coding as soon as possible. 711 00:39:47,320 --> 00:39:50,120 But sometimes, for example things like requirements or 712 00:39:50,120 --> 00:39:53,600 maybe even like drawing some kind of design diagram or system 713 00:39:53,600 --> 00:39:57,240 design diagram is something that sometimes get neglected and 714 00:39:57,240 --> 00:39:59,560 people prefer to jump straight to the code. 715 00:39:59,920 --> 00:40:01,400 And I think the third thing, like you mentioned right 716 00:40:01,400 --> 00:40:03,520 perspective driven documentation. 717 00:40:03,520 --> 00:40:05,920 Sometimes we just write documentation for the sake of 718 00:40:05,920 --> 00:40:09,320 ticking the box without actually knowing who will actually read 719 00:40:09,320 --> 00:40:12,040 the documentation. So I think those 3 aspects are 720 00:40:12,040 --> 00:40:14,200 things that I normally see in my career as well. 721 00:40:14,520 --> 00:40:17,880 So for people to start thinking about coming up with a good way 722 00:40:17,880 --> 00:40:21,480 of capturing knowledge, any kind of tips and tricks for 723 00:40:21,480 --> 00:40:24,360 developers to do things better on this area? 724 00:40:25,120 --> 00:40:29,680 I think as you just mentioned about there being knowledge in 725 00:40:29,800 --> 00:40:34,080 chats and emails and things, I think that's possibly one of the 726 00:40:34,080 --> 00:40:37,800 worst situations you can have when all the knowledge is locked 727 00:40:37,800 --> 00:40:40,640 away in places other people can't find it. 728 00:40:41,000 --> 00:40:45,520 So I once heard someone talking about they were saying, Oh yes, 729 00:40:45,520 --> 00:40:49,640 or whenever I want the answer to a question, I just search in 730 00:40:49,640 --> 00:40:51,720 Slack. And quite often someone's 731 00:40:51,720 --> 00:40:55,120 already asked it and that felt you were dread. 732 00:40:55,120 --> 00:40:57,720 Because I thought, well, if someone needs that information, 733 00:40:57,720 --> 00:41:02,080 do they know it's in Slack? Do they have access to the Slack 734 00:41:02,080 --> 00:41:04,880 channels that it's in? And when does that information 735 00:41:04,880 --> 00:41:08,240 get archived or possibly deleted by the products you're using? 736 00:41:08,720 --> 00:41:11,960 And if you're doing that same thing with e-mail, giving people 737 00:41:12,040 --> 00:41:15,720 information over e-mail, then only the people whoever received 738 00:41:15,720 --> 00:41:17,720 that e-mail will get it forwarded to them. 739 00:41:18,000 --> 00:41:21,280 Ever have that knowledge. And quite often your 740 00:41:21,280 --> 00:41:25,520 organization will be archiving or deleting e-mail that's maybe 741 00:41:25,520 --> 00:41:27,040 over a year old or something like that. 742 00:41:27,040 --> 00:41:28,280 And maybe you don't even know that. 743 00:41:28,560 --> 00:41:32,240 And so all that knowledge then gets lost, especially if those 744 00:41:32,240 --> 00:41:34,400 people who wrote it then leave the company. 745 00:41:34,760 --> 00:41:38,920 And so one big tip that I have is when you're sharing 746 00:41:38,920 --> 00:41:42,200 knowledge, if people ask a question on a message or over 747 00:41:42,200 --> 00:41:44,080 e-mail, don't share the knowledge. 748 00:41:44,080 --> 00:41:48,600 Share a link to the knowledge because then people will know 749 00:41:48,600 --> 00:41:52,480 where to find it. If it doesn't exist in your wiki 750 00:41:52,480 --> 00:41:55,880 or whatever you're using, then create it and share the link. 751 00:41:56,080 --> 00:41:59,760 If you look at it and you realise it's out of date then 752 00:42:00,040 --> 00:42:02,360 you can update it and share the link. 753 00:42:02,760 --> 00:42:05,360 I mean you might have to get together to work out how to 754 00:42:05,360 --> 00:42:08,960 update it, but that's really important for all of your 755 00:42:08,960 --> 00:42:11,320 knowledge. But if you just think about 756 00:42:11,320 --> 00:42:15,240 sharing this link, that will help you to keep all your 757 00:42:15,240 --> 00:42:19,240 knowledge in a place that is accessible to everyone and not 758 00:42:19,240 --> 00:42:23,840 spread across all these many many apps that people don't know 759 00:42:23,840 --> 00:42:26,720 where it is and they probably don't have permission to access 760 00:42:26,720 --> 00:42:29,440 it anyway. So that's my big tip there, 761 00:42:29,520 --> 00:42:31,680 Share a link rather than the knowledge itself. 762 00:42:32,360 --> 00:42:33,640 Yeah, I think it's a great tips, right? 763 00:42:33,640 --> 00:42:37,160 Because sometimes we actually want to answer quick, right? 764 00:42:37,160 --> 00:42:39,080 Maybe because of busy or whatever, right? 765 00:42:39,080 --> 00:42:42,000 We want to answer very quick and we just dump the knowledge and 766 00:42:42,000 --> 00:42:45,400 the content in the chat itself. But I think the tip is really, 767 00:42:45,400 --> 00:42:47,960 really useful, right? So provide a link, take your 768 00:42:47,960 --> 00:42:51,080 time, put it in the wiki. It takes a village to actually 769 00:42:51,160 --> 00:42:53,560 do this kind of discipline. It should not be just one person 770 00:42:53,560 --> 00:42:55,880 doing it all the time, right? It takes a village. 771 00:42:55,960 --> 00:42:58,360 Everyone should be conscious about doing this. 772 00:42:58,600 --> 00:43:01,520 So I think sooner than later your knowledge management will 773 00:43:01,520 --> 00:43:04,280 become much richer and people will be able to find knowledge 774 00:43:04,280 --> 00:43:07,280 much more often. Another thing that I find really 775 00:43:07,280 --> 00:43:10,240 useful in your book you cover in this area is about getting 776 00:43:10,240 --> 00:43:14,320 feedback early and often and also just in time architecture, 777 00:43:14,320 --> 00:43:15,800 right? So I think sometimes when 778 00:43:15,800 --> 00:43:19,000 developers are being tasked to create documentation, we kind of 779 00:43:19,000 --> 00:43:23,000 like take the whole week or few days to actually write a long 780 00:43:23,000 --> 00:43:24,960 document before we share it to other people. 781 00:43:25,080 --> 00:43:27,800 I think it's worth to mention about these two aspects so that 782 00:43:27,800 --> 00:43:30,800 engineers maybe can get feedback early and also just write 783 00:43:30,800 --> 00:43:33,160 whatever that is necessary at that point in time. 784 00:43:33,160 --> 00:43:35,000 So maybe if you can cover a little bit on this. 785 00:43:35,760 --> 00:43:39,560 Yeah, so with knowledge, as I said, it's not just about 786 00:43:39,560 --> 00:43:43,800 managing documentation and it's not about just what knowledge 787 00:43:43,800 --> 00:43:47,000 management system you use. It's actually socio technical. 788 00:43:47,240 --> 00:43:50,640 And so you have to take into account people for it to be 789 00:43:50,640 --> 00:43:54,240 successful. And a simple way to improve your 790 00:43:54,240 --> 00:43:57,200 knowledge and documentation, as you say, is to get feedback 791 00:43:57,320 --> 00:44:00,840 early and often. And it really helps you to not 792 00:44:00,840 --> 00:44:05,280 go too far down the wrong path without being able to course 793 00:44:05,280 --> 00:44:08,880 correct. So don't wait days or weeks to 794 00:44:09,040 --> 00:44:12,600 ask a colleague or a stakeholder for feedback on the artefacts 795 00:44:12,600 --> 00:44:16,400 you're creating, whether that's something written or a diagram. 796 00:44:16,720 --> 00:44:21,720 And don't spend more than a few hours on something big or even a 797 00:44:21,720 --> 00:44:24,360 shorter time on something smaller before you get feedback. 798 00:44:24,680 --> 00:44:29,280 Because if there's something that you didn't know, that means 799 00:44:29,280 --> 00:44:31,560 that you're going to waste a lot of time on that. 800 00:44:31,560 --> 00:44:35,560 You want to get that feedback early. 801 00:44:35,760 --> 00:44:40,120 So we all know that when we get given requirements that they're 802 00:44:40,120 --> 00:44:43,200 not going to be complete or they're going to be incorrect. 803 00:44:43,560 --> 00:44:47,360 And so if you work for a long time designing something based 804 00:44:47,360 --> 00:44:50,280 on those requirements, then take it to your stakeholders and they 805 00:44:50,280 --> 00:44:52,640 tell you that something was missing or something's wrong, 806 00:44:52,880 --> 00:44:56,960 you've spent a lot of wasted time and effort on that. 807 00:44:57,320 --> 00:45:02,560 And so get that feedback really, really as quickly as you can. 808 00:45:02,840 --> 00:45:06,760 And it might be something fairly informal if you're in an office, 809 00:45:06,760 --> 00:45:10,000 just asking someone who's sitting next to you to have a 810 00:45:10,000 --> 00:45:13,320 quick look. Or it might be actually setting 811 00:45:13,320 --> 00:45:18,360 up just a brief 15 minute conversation with someone, a 812 00:45:18,360 --> 00:45:22,600 video chat, just to show them it doesn't have to be a big like 813 00:45:22,640 --> 00:45:25,040 all three hour meeting. We need to have a look at what 814 00:45:25,040 --> 00:45:27,960 I've done so far, because you haven't even spent three hours 815 00:45:27,960 --> 00:45:32,320 on it, but it's just getting that feedback quickly so that if 816 00:45:32,320 --> 00:45:34,760 you think about Agile, this is what we're trying to do. 817 00:45:34,760 --> 00:45:37,240 We're trying to get quick feedback loops. 818 00:45:37,560 --> 00:45:41,360 And I think even if people are managing to do that with the 819 00:45:41,360 --> 00:45:44,080 code that they're putting into the system, get it to the 820 00:45:44,080 --> 00:45:48,720 customer early, get feedback quickly, they forget about this 821 00:45:48,720 --> 00:45:51,920 and they can apply that same principle to all the work 822 00:45:51,920 --> 00:45:54,000 they're doing and it will help you in that. 823 00:45:54,520 --> 00:45:58,160 And then this also complements another pattern which I talk 824 00:45:58,160 --> 00:46:00,400 about, which you mentioned, which is just in time 825 00:46:00,560 --> 00:46:05,440 architecture. And it's important not to make a 826 00:46:05,440 --> 00:46:09,640 decision earlier than the what I call the last responsible 827 00:46:09,720 --> 00:46:14,160 moment. And that means that making the 828 00:46:15,080 --> 00:46:19,880 decision too early can mean having to change that decision 829 00:46:20,000 --> 00:46:22,400 when you get new information which comes to light. 830 00:46:22,920 --> 00:46:26,360 And if you'll change your decision, that's often expensive 831 00:46:26,440 --> 00:46:30,640 thing to do, either money wise or effort and time wise, and 832 00:46:30,640 --> 00:46:32,440 therefore that costs money anyway. 833 00:46:32,800 --> 00:46:34,960 And especially if they're architectural decisions, they 834 00:46:34,960 --> 00:46:37,120 tend to be more expensive to change. 835 00:46:37,440 --> 00:46:40,680 And if you have to change that one decision, what about all the 836 00:46:40,680 --> 00:46:44,240 other decisions that you made based on the outcome of that 837 00:46:44,240 --> 00:46:46,160 decision? You probably got to change all 838 00:46:46,160 --> 00:46:48,120 those as well. And so you can get this awful 839 00:46:48,320 --> 00:46:52,360 chain reaction because you've made a decision too early. 840 00:46:52,880 --> 00:46:56,080 So even if you've got someone kind of breathing down your neck 841 00:46:56,120 --> 00:47:00,480 asking for a particular artefact or a particular decision, you 842 00:47:00,480 --> 00:47:03,920 really need to try and put them off until that last responsible 843 00:47:04,000 --> 00:47:07,600 moment and you create your artefacts just in time. 844 00:47:08,040 --> 00:47:12,400 If people really are insisting, then you can create something 845 00:47:12,400 --> 00:47:15,880 and just say put something on it, like a disclaimer that this 846 00:47:15,880 --> 00:47:18,320 is a draft. If you base anything on this, it 847 00:47:18,320 --> 00:47:23,200 may need to change and that can help to communicate why you 848 00:47:23,200 --> 00:47:27,000 can't just make this decision now or create this artefact 849 00:47:27,320 --> 00:47:31,280 right now and in the end it's going to save you time and 850 00:47:31,280 --> 00:47:32,680 money. But one of the other really good 851 00:47:32,680 --> 00:47:35,640 things about this is that it means you can focus on what 852 00:47:35,640 --> 00:47:39,120 really needs to be done now instead of having all your time 853 00:47:39,120 --> 00:47:41,400 blocked out working on things that aren't needed yet. 854 00:47:41,760 --> 00:47:46,440 Because we all get unexpected work, this inevitably comes our 855 00:47:46,440 --> 00:47:49,640 way all the time. Things go wrong or something 856 00:47:49,640 --> 00:47:53,240 pops up, and if you've got your time blocked out working on 857 00:47:53,240 --> 00:47:56,800 stuff that isn't needed right now, you don't have that slack 858 00:47:56,800 --> 00:47:59,720 to take on that inevitable unexpected work. 859 00:48:00,200 --> 00:48:05,360 So doing this just in time architecture means that you have 860 00:48:05,360 --> 00:48:07,400 that time to work on the unexpected. 861 00:48:07,400 --> 00:48:11,760 You don't waste time on decisions that shouldn't have 862 00:48:11,760 --> 00:48:15,560 been made at that point, and you just get a much more agile 863 00:48:15,560 --> 00:48:20,120 process to your working as well. Yeah, I would recommend people 864 00:48:20,120 --> 00:48:23,160 who probably do a lot of documentation to think about 865 00:48:23,160 --> 00:48:26,160 these two aspects really, really closer to your heart, right? 866 00:48:26,160 --> 00:48:29,800 Because sometimes I see so many engineers spend many, many days 867 00:48:29,800 --> 00:48:32,960 to come up with documentations, which actually in the end, 868 00:48:32,960 --> 00:48:35,760 right, sometimes they need to do a rework or it just doesn't 869 00:48:35,760 --> 00:48:38,520 solve the kind of problem that they're trying to solve by 870 00:48:38,520 --> 00:48:39,800 coming up with the documentation. 871 00:48:39,800 --> 00:48:42,400 So get feedback early and sometimes I think in your book 872 00:48:42,400 --> 00:48:43,840 you mentioned about templates, right? 873 00:48:44,080 --> 00:48:46,520 You can actually also come up with templates so that people 874 00:48:46,520 --> 00:48:49,480 are guided on what aspects to fill in in the documentation 875 00:48:49,480 --> 00:48:51,920 rather than always having to come up with a different kind of 876 00:48:51,920 --> 00:48:55,080 a format all the time. So I think people please bear 877 00:48:55,080 --> 00:48:58,480 these two key points so that you can communicate your knowledge 878 00:48:58,480 --> 00:49:00,400 much better. So the last aspect is about 879 00:49:00,400 --> 00:49:03,520 communicating remotely. So probably if we know about 880 00:49:03,520 --> 00:49:06,200 this remote work right, there are always two things that are 881 00:49:06,200 --> 00:49:10,320 always mentioned, synchronous and asynchronous meetings, no 882 00:49:10,320 --> 00:49:12,000 meetings, deep work and things like that. 883 00:49:12,200 --> 00:49:15,600 So maybe a little bit of advice here for people who are more 884 00:49:15,600 --> 00:49:18,920 used to this kind of remote set up now or also hybrid kind of a 885 00:49:18,920 --> 00:49:22,160 work set up. Yes, a lot of us are either 886 00:49:22,160 --> 00:49:26,040 working remotely or in a hybrid, or even if you're working in an 887 00:49:26,040 --> 00:49:29,760 office, you are probably working with other people who are 888 00:49:29,760 --> 00:49:33,400 working remotely in hybrid. Or maybe you're working with 889 00:49:33,400 --> 00:49:37,400 people who are in office in another country, even other time 890 00:49:37,400 --> 00:49:40,440 zones, of course. And so there's an awful lot to 891 00:49:40,480 --> 00:49:44,480 take into account when we think about how we're communicating 892 00:49:44,640 --> 00:49:46,760 with people. And a lot of people kind of 893 00:49:46,760 --> 00:49:49,680 think they're feel a bit sort of professional at this now because 894 00:49:49,680 --> 00:49:52,120 we've been doing it for quite a while. 895 00:49:52,520 --> 00:49:56,320 But it's not really quite as simple as people think. 896 00:49:56,320 --> 00:49:59,360 If you consider how many companies at the moment, even 897 00:49:59,360 --> 00:50:02,720 ones who actually make remote communication tools, they're 898 00:50:02,720 --> 00:50:05,680 trying to get their employees to come back into the office for 899 00:50:05,680 --> 00:50:08,000 more of the time. And yet you've got other 900 00:50:08,000 --> 00:50:12,680 companies who are thriving as fully distributed or hybrid 901 00:50:12,680 --> 00:50:15,880 organisations. And it's the fact that the way 902 00:50:15,880 --> 00:50:18,880 in which things are communicated seriously effects people's 903 00:50:18,920 --> 00:50:21,440 understanding and their productivity. 904 00:50:21,760 --> 00:50:25,600 And people need to understand a lot to decide whether a 905 00:50:25,600 --> 00:50:29,760 communication method should be either synchronous, which is in 906 00:50:29,760 --> 00:50:33,680 real time, like a meeting, or asynchronous, where the 907 00:50:33,680 --> 00:50:37,600 recipients read and respond on their own timetable. 908 00:50:37,920 --> 00:50:40,800 In fact, the podcast is also an asynchronous method of 909 00:50:40,800 --> 00:50:43,240 communication, so you're experiencing that right now. 910 00:50:43,680 --> 00:50:47,160 But many people don't realise how disruptive synchronous 911 00:50:47,160 --> 00:50:49,440 communication can be to people's work. 912 00:50:49,680 --> 00:50:54,000 So working out which communication should be async is 913 00:50:54,000 --> 00:50:56,440 vital people getting their best work done. 914 00:50:56,920 --> 00:51:00,640 So for example synchronous activities, things that work 915 00:51:00,720 --> 00:51:04,600 very well synchronously are things like generating ideas or 916 00:51:04,600 --> 00:51:08,680 building rapport like team building or maybe a project kick 917 00:51:08,680 --> 00:51:10,600 off. That can be good for a 918 00:51:10,600 --> 00:51:14,400 synchronous meeting with asynchronous things like 919 00:51:14,400 --> 00:51:18,040 reporting progress or gathering feedback. 920 00:51:18,040 --> 00:51:24,200 So using things like comments on documents or architecture 921 00:51:24,200 --> 00:51:28,280 decision records or other forms of decision records, those can 922 00:51:28,280 --> 00:51:33,240 be done asynchronously and often communication should actually be 923 00:51:33,240 --> 00:51:37,600 split between the two. Some people like to evangelize 924 00:51:37,720 --> 00:51:41,520 asynchronous communication, but really some things are better 925 00:51:41,520 --> 00:51:44,960 done synchronously. And one of the things I talk 926 00:51:44,960 --> 00:51:48,720 about in the book is an asynchronous sandwich, and 927 00:51:48,720 --> 00:51:53,320 that's where you are maximizing your synchronous time. 928 00:51:53,440 --> 00:51:56,160 So if you're getting everyone together for an hour 929 00:51:56,160 --> 00:52:01,920 synchronously, then you want that hour to be all activities 930 00:52:02,000 --> 00:52:04,160 that are best done synchronously. 931 00:52:04,360 --> 00:52:08,400 So any part of that that is best done asynchronously before or 932 00:52:08,400 --> 00:52:11,840 after, you want to split off from that so that you're not 933 00:52:11,840 --> 00:52:14,440 wasting people's time. If you have to get everyone 934 00:52:14,440 --> 00:52:18,720 together for two hours, that really knocks everybody's 935 00:52:18,720 --> 00:52:22,320 productivity and probably not everybody needs to be there for 936 00:52:22,320 --> 00:52:24,480 those two hours. And that's one of the things 937 00:52:24,480 --> 00:52:27,760 that people really hate about meetings, especially remote 938 00:52:28,000 --> 00:52:32,640 meetings, because they're even harder to concentrate in. 939 00:52:32,640 --> 00:52:36,560 I said earlier about it's much more difficult to read people's 940 00:52:36,680 --> 00:52:41,800 verbal and body language, and so you're already putting more 941 00:52:41,800 --> 00:52:46,600 stress on people. So making that synchronous 942 00:52:46,600 --> 00:52:50,360 activity just for the stuff that works well at synchronously is 943 00:52:50,440 --> 00:52:52,520 going to be really useful for that. 944 00:52:53,280 --> 00:52:55,040 Yeah, sometimes I think it's very tricky right? 945 00:52:55,040 --> 00:52:57,680 Some people is more towards asynchronous. 946 00:52:57,680 --> 00:53:01,280 Like I would prefer asynchronous all the time or some people like 947 00:53:01,320 --> 00:53:03,920 for those who come back to office are forced to come back 948 00:53:03,920 --> 00:53:05,760 to office. Maybe the management or 949 00:53:05,760 --> 00:53:08,080 leadership likes to be In Sync all the time. 950 00:53:08,360 --> 00:53:10,600 So I think always they're polarizing thoughts. 951 00:53:10,600 --> 00:53:13,040 But I think your book kind of like give a good guidance. 952 00:53:13,040 --> 00:53:16,440 Like for example you probably need to do meetings in person 953 00:53:16,440 --> 00:53:19,800 synchronously if you want to get like some kind of consensus, you 954 00:53:19,800 --> 00:53:23,040 know like kick off idea generation right rather than 955 00:53:23,040 --> 00:53:25,600 asynchronously. And async is more towards 956 00:53:25,600 --> 00:53:28,280 thinking you know like getting comments, feedback, ideas. 957 00:53:28,720 --> 00:53:32,000 And I think I also like one of the thought from James Daniel 958 00:53:32,000 --> 00:53:33,640 about asynchronous versus synchronous. 959 00:53:33,680 --> 00:53:36,240 I think he mentioned about if you want to get a strong 960 00:53:36,240 --> 00:53:40,000 consistency do it synchronously. But if you think you can do like 961 00:53:40,280 --> 00:53:43,120 a virtual consistency kind of manner, do it in asynchronous 962 00:53:43,120 --> 00:53:44,880 way. And I think in your book you 963 00:53:44,880 --> 00:53:47,840 also mentioned one anti pattern that I see happen all the time. 964 00:53:47,920 --> 00:53:51,880 We try to do async meaning like using chat, but actually we kind 965 00:53:51,880 --> 00:53:55,040 of like reply back and forth synchronously in real time in 966 00:53:55,040 --> 00:53:58,600 the chat and we make decision very very quickly on that chat 967 00:53:58,600 --> 00:54:00,440 as well. So I think this probably is an 968 00:54:00,440 --> 00:54:02,920 anti pattern because there are some people who are not in the 969 00:54:02,920 --> 00:54:06,000 conversation itself and also it's a lot of back and forth 970 00:54:06,000 --> 00:54:09,360 means probably the ideas need to be talked through much better 971 00:54:09,360 --> 00:54:12,360 rather than in chat, right? So for people probably if you're 972 00:54:12,360 --> 00:54:15,080 frustrated with some of your asynchronous or synchronous kind 973 00:54:15,080 --> 00:54:18,840 of communication, do check out Jackie's book on this aspect. 974 00:54:18,840 --> 00:54:22,480 So I think you'll get a lot of more tips on how you can improve 975 00:54:22,480 --> 00:54:24,800 on this. So Jackie, it's been a great 976 00:54:24,800 --> 00:54:26,760 conversation. Unfortunately, we have to wrap 977 00:54:26,760 --> 00:54:29,120 up pretty soon. I have one last question, which 978 00:54:29,120 --> 00:54:30,640 I normally ask for all my guests. 979 00:54:30,880 --> 00:54:33,280 I call this the three technical leadership wisdom. 980 00:54:33,640 --> 00:54:36,440 You can think of it just like advice for all of us to learn 981 00:54:36,440 --> 00:54:38,440 from you. So is there something that you 982 00:54:38,440 --> 00:54:41,240 can share with us about 3 technical leadership wisdom? 983 00:54:42,000 --> 00:54:45,600 Yes, I had a good thing about this and the first one I want to 984 00:54:45,600 --> 00:54:51,040 share of the three is the soft skills are pretty much always 985 00:54:51,040 --> 00:54:54,400 going to be those ladders for you to climb in your career, 986 00:54:54,680 --> 00:54:59,000 whereas your tech skills can turn into snakes, meaning you've 987 00:54:59,000 --> 00:55:00,960 got to start again with another skill. 988 00:55:01,040 --> 00:55:05,040 So emphasizing that from before, the second thing that I'd like 989 00:55:05,040 --> 00:55:10,120 to share is that there are always trade-offs with anything 990 00:55:10,120 --> 00:55:13,560 in in technology, probably pretty much area in life. 991 00:55:13,560 --> 00:55:14,960 There's always going to be trade-offs. 992 00:55:14,960 --> 00:55:18,640 There's no silver bullets in technology or architecture or 993 00:55:18,640 --> 00:55:22,040 anything really. And you need to understand 994 00:55:22,040 --> 00:55:25,200 what's important to make every decision. 995 00:55:25,680 --> 00:55:31,320 It's not just about what's the latest technology or anything 996 00:55:31,320 --> 00:55:34,360 like that. And so you need to use tools 997 00:55:34,360 --> 00:55:38,360 such as Architecture Decision Records to help you with this 998 00:55:38,800 --> 00:55:43,880 And thinking about architecture characteristics, which I also 999 00:55:43,880 --> 00:55:46,960 talk about in the book and that helps you, it gives you this 1000 00:55:46,960 --> 00:55:50,920 guidance or what's important for making that decision. 1001 00:55:51,480 --> 00:55:56,960 Then my third tip is what we do as technical professionals 1002 00:55:57,040 --> 00:56:01,000 always involves people. Systems are always socio 1003 00:56:01,000 --> 00:56:05,000 technical, so you cannot ignore the people when you're trying to 1004 00:56:05,000 --> 00:56:08,800 build or make changes to a software system. 1005 00:56:09,240 --> 00:56:12,960 And things that are useful to help with this are systems 1006 00:56:12,960 --> 00:56:16,960 thinking and also techniques like collaborative modelling. 1007 00:56:17,320 --> 00:56:20,680 Team topologies is an interesting area to look at and 1008 00:56:20,680 --> 00:56:25,440 also things in my book like Just in Time Architecture can help 1009 00:56:25,440 --> 00:56:28,120 you with this socio technical element. 1010 00:56:28,560 --> 00:56:31,360 So those are my top three tips at the moment. 1011 00:56:32,200 --> 00:56:35,440 Well, I I really love the ladder and snake analogy, so I'll use 1012 00:56:35,440 --> 00:56:37,240 it more often. I think you put it very 1013 00:56:37,240 --> 00:56:39,840 interestingly, right. So communication skills is like 1014 00:56:39,840 --> 00:56:42,800 a ladder for you to climb to bring you always up, right? 1015 00:56:43,000 --> 00:56:45,520 Sometimes it could also bring you down if you communicate 1016 00:56:45,520 --> 00:56:48,000 wrongly I guess. But yeah, technology always 1017 00:56:48,040 --> 00:56:50,320 keeps changing, right. So I think it's like a snake 1018 00:56:50,320 --> 00:56:52,880 where you always kind of like have to up to date yourself, 1019 00:56:52,880 --> 00:56:54,360 right. And also keep following the 1020 00:56:54,360 --> 00:56:56,040 trend. But I think, yeah, the 1021 00:56:56,040 --> 00:56:58,560 communication is always applicable in any type of 1022 00:56:58,560 --> 00:57:01,560 situation, no matter what role or what job that you have. 1023 00:57:02,080 --> 00:57:05,320 So Jackie, if people love this conversation, they want to reach 1024 00:57:05,320 --> 00:57:09,000 out to you or ask you anything in person or online, right? 1025 00:57:09,200 --> 00:57:10,640 Is there a place where they can find you? 1026 00:57:11,320 --> 00:57:13,880 Yes, the best place to find me is my website 1027 00:57:13,880 --> 00:57:23,440 whichisjackiereed.com JACQUIR ead.com and you can also find 1028 00:57:23,520 --> 00:57:28,120 the book on its website whichiscommunicationpatternsbook.com. 1029 00:57:28,360 --> 00:57:33,200 So for everyone who's interested in this, please reach out to me 1030 00:57:33,200 --> 00:57:37,640 especially if you want to look at working together in any of 1031 00:57:37,640 --> 00:57:40,600 the aspects that I've talked about today or in software 1032 00:57:40,600 --> 00:57:43,120 architecture and socio technical areas in general. 1033 00:57:43,680 --> 00:57:47,280 And thank you very much for having me on tech lead journal. 1034 00:57:48,000 --> 00:57:50,800 Yeah, so I highly recommend reading Jackie's book again, 1035 00:57:50,800 --> 00:57:54,360 Communication and Soft Skills. Probably not so many engineers 1036 00:57:54,440 --> 00:57:57,040 think this is important, right? Rather than, you know, following 1037 00:57:57,040 --> 00:58:00,880 all this technology or maybe AIML now generative AI, right. 1038 00:58:01,160 --> 00:58:04,040 So I think communication is still applicable no matter what 1039 00:58:04,040 --> 00:58:06,880 age, what era you are, right? And there's always a lot of 1040 00:58:06,880 --> 00:58:10,120 things that you can improve in terms of communicating better. 1041 00:58:10,360 --> 00:58:12,040 So thank you for your time today, Jackie. 1042 00:58:12,520 --> 00:58:13,320 Brilliant. Thank you. 1043 00:58:16,200 --> 00:58:19,440 Thank you for listening to this episode and for staying right 1044 00:58:19,480 --> 00:58:22,200 until the end. If you highly enjoyed it, I 1045 00:58:22,200 --> 00:58:24,920 would appreciate if you share it with your friends and colleagues 1046 00:58:25,200 --> 00:58:28,160 who you think would also benefit from listening to this episode. 1047 00:58:28,600 --> 00:58:31,320 And if you're new to the podcast, make sure to subscribe 1048 00:58:31,360 --> 00:58:33,720 and leave me your valuable review and feedback. 1049 00:58:34,080 --> 00:58:36,960 It helps me a lot in order to grow this podcast better. 1050 00:58:37,480 --> 00:58:40,360 You can also find the full show notes of this conversation on 1051 00:58:40,360 --> 00:58:43,360 the episode page at techlitjournal dot dev website, 1052 00:58:43,640 --> 00:58:47,240 including the full transcript, interesting quotes, and links to 1053 00:58:47,240 --> 00:58:49,640 the resources mentioned from the conversation. 1054 00:58:50,080 --> 00:58:53,120 And lastly, make sure to subscribe to the show's mailing 1055 00:58:53,120 --> 00:58:56,960 list on techlitjournal dot dev to get notified for any future 1056 00:58:56,960 --> 00:58:59,400 episodes. Stay tuned for the next Tech 1057 00:58:59,400 --> 00:59:02,440 Lead journal episode, and until then, goodbye.