If you think about a game of snakes and ladders, the
technical skills, they can be ladders, but they can also turn
into snakes. If you end up putting a lot of
time and effort into a technology that then falls off
the hype curve and gets forgotten, you then can't get
the work you can't apply to the jobs.
But if you put the work into the soft skills, they are always
going to be ladders. They're not going to ever send
you down a snake if you are learning these things.
So I think that's the key difference, and a lot of people
just don't realize it. Hey everyone, my name is Henry
Surya Virawan and you're listening to the Technically
Journal Podcast, the show where I'll be bringing you the
greatest technical leaders, practitioners and thought
leaders in the industry to discuss about their journey,
ideas and practices that we all can learn and apply to build a
highly performing technical team and to make an impact in your
personal work. So let's dive into our journal.
Hello, welcome to the Technical Journal Podcast.
Today I have with me Jackie Reed, So she's the author of
Communications Patterns. So Jackie, looking forward for
our conversation because I think communication is one of the core
skills for not just engineers, but also all the technical
people working in the tech industry.
So welcome to the show. Thank you very much and hello to
everyone listening. Thank you for having me on the
Tech Lead journal. It's a pleasure to be here.
Great to be part of something with so many great guests with
lots of useful and interesting things to say.
So Jackie, I always love to maybe ask from you first to
share anything from your career, maybe any kind of highlights or
turning points that you think we all can learn from you?
Well, I came from a.net development background
originally and I think one of the turning points for me is
when I moved into software architecture, that was the thing
that propelled me into the architecture space.
And then I entered a competition that O'Reilly run a software
architecture CATA, which they run a couple of times a year.
And since I LED A-Team to win that in 2021, I've done quite a
lot of work with O'Reilly. So I've written my book
Communication Patterns, and I've started my own consultancy as
well. So I provide architecture
consultancy and training along with speaking and running
workshops at international conferences.
And so that move into architecture really pushed me
into these more interesting spaces really.
Hey, thank you for being part of the Techly Journal community.
This show wouldn't be the same without your ears, and you are
the reason this show exists. If you're loving TLJ and want to
see it keep on growing. Consider becoming a patron at
Techligional dot Dev Patron or buying me a coffee at
Techligional dot Dev Coffee. Every little bit helps field the
research, editing, and sleepless nights that go into making this
show the best it can be. Thanks for being the best
listeners any podcast could ask for.
And now let's get back to our episode.
Wow. So if you don't mind so tell us
a little bit more about this architecture Kata sounds really
interesting for those of us who probably haven't heard about it
before. OK, so the idea of an
architecture kata is that as architects, we don't really get
the chance to architect that many systems.
And so it's a practice. So the word kata comes from the
sort of martial arts where kata is a sequence of moves that you
go through and you practice those.
And so these started with the O'Reilly conferences.
They started running these catters actually in person as
short evening events. And then they started when the
pandemic hit, they started doing them online and they now run
them about once or twice a year. So anyone who subscribed to
their online training system, so they don't just get books,
they've got all the live trainings, which I do as well.
But the cat is a part of that and so anyone can enter it and
you can form a team just with random other people, which is
what I did. Or you can bring a team along
and you get a problem which you can solve and they try to get a
real life problem from a non profit, that kind of thing.
And so you can actually solve these problems and create a
repository of your design. And since I won it, I've
actually been a judge on it, which is really good, really
interesting thing to do. So I do that normally about
twice a year at the moment. That sounds really cool.
So I hope for people who love doing architecture, I'm sure
it's not just about monolith versus micro service.
I I hope. But yeah, for those of you who
are interested, maybe, yeah, maybe you can also join this
architecture kata, it's twice a year.
So Jackie, the book that you just published quite recent is
called Communication Patterns. So it's a little bit different
than the architecture thing that you're doing in the 1st place.
Maybe if you can elaborate the background story, right?
Why do you come up with this book?
Well, I was kind of pushed to think about writing a book once
I won that competition because I thought, well, I looked at all
the other books that the people were writing and I thought, oh,
I could do that. I kind of came to the
realisation through winning that I did have some useful knowledge
and things and useful skills. So I thought, what is really
missing at the moment? And communication is kind of a
big thing. It's part of the soft skills
which people tend to forget about because they're so pushed
to focus on their technical skills because that's really
their day job. And so I kind of realised that I
had a lot of techniques and principles I was applying which
either naturally or because I'd learned it from other areas
outside of technology, because I have lots of different
interests. And so pulling these all
together I realized that I had a lot of things that could be
summarized as patterns or anti patterns, which are things that
developers and architects and other technical people can
understand because we use them in code.
And so I proposed this to O'Reilly, and they were really
interested in it. And we've aimed the book at
developers and architects primarily, but it's got plenty
of useful techniques and patterns for other people who
are working in tech. And in fact, one of the people
who wrote some praise for it, Rebecca Parsons, let me get this
correct. She said anyone, particularly in
a leadership position should read this book to become more
effective. So in her mind, anybody working
in technology really could benefit from the book, but my
hope is that it will get technical people who otherwise
wouldn't prioritize their soft skills to look into it a bit
more, because it's very important when they're boosting
their career. Yeah.
So in preparation of this conversation, right, I actually
read some parts of the book. I fully agree that this is not
just for engineers or those architects, right?
So it can apply to everyone, not just in tech, actually.
So some of the coverage is also about general leadership
principles, ways of working and things like that.
So I think I fully agree that this book can apply to any kind
of roles. And I was intrigued when you
mentioned that many tech people actually don't focus or don't
try to improve their soft skills.
Maybe in your view, why is that a challenge for tech people?
I think one of the main things is that if people have any kind
of learning budget at all where they don't get to go to many
conferences, they probably don't get to go on many courses at
all. And so they feel pressured
really into looking at the technical skills.
And probably their managers are probably expecting them to be
doing a course on Kubernetes rather than a course on their
communication skills. And I think it's more people
don't realise that when you're looking at tech skills there
they are key to our jobs. But if you think about a game of
snakes and ladders, the technical skills, they can be
ladders but they can also turn into snakes.
If you end up putting a lot of time and effort into a
technology that then falls off the hype curve and gets
forgotten, you then can't get the work.
You can't apply to the jobs. But if you put the work into the
soft skills, they are always going to be ladders.
They're not going to ever send you down a snake if you are
learning these things. So I think that's the key
difference, and a lot of people just don't realize it.
Right, this is the first time I heard about this analogy.
You know the ladder and snake, so I fully agree.
Again, the communication skills, the soft skills part could
actually propel someone's career and also the effectiveness or
impact in their day-to-day job. Again, a very interesting
analogy, Ladder and snakes for people who still think soft
skill is just you know like wishy washy kind of a skill set,
right? So I think please check out this
conversation later so that you can also improve your
communication skills. So in your book you cover
communication patterns into four different areas.
So the first one is about visual communication.
So this is probably something about turning, you know,
architecture maybe into a charts or diagrams or maybe PowerPoint
slides. So maybe tell us a little bit
more about this area of visual communication.
Yes, I think visual is probably one of the most important areas
really to look at, because visuals are what your audience
spend a lot of time looking at. They might be the only thing
that they actually look at closely, and so they're a great
way to communicate your concepts and ideas.
And they're usually much easier to understand than text because
they are an abstraction of what could be a complete wall of text
if you didn't do it visually. So they're very important
aspects and that's why I started the book with the visuals, and
it's actually kind of where the book grew from originally.
I started with that concept and then grew it into all the
communication. So I start with some of the
foundational visual concepts, which is where any reader should
make sure that they consistently are doing these things before
they try out any of the other patterns and anti patterns.
And I split all of these out into various patterns and tell
people things to look out for, things to apply.
And one of those is called Know your audience.
And this is one that people tend to think that they already know
about, but it's not really just what your audience wants from
you, but it's also what you want from your audience.
And there's a few different questions in there you can ask
yourself. But one of the most important, I
think, is what do you want from your audience?
And if you are carefully thinking about your audience's
knowledge, you can create a diagram That is what they want.
But you also need to get back from them what you need.
So maybe you need them to make a decision or they need to come up
with some ideas based on what you're giving them.
And if you don't give them what they need to do that, then you
won't get what you want from them.
So it's one of those big sort of cyclical questions, what do they
want from me? What do I want from them?
And that know your audience can be a lot more complex than
people think. So there's a whole pattern on
that in there. Wow, it's a great reminder,
right. So it's not just what we want
from the diagram, right. So also like what we want from
them, right. So it could be you know,
something about making decision or even understanding what kind
of solutions that we're building.
So I think that's really key because a lot of people just
build diagrams, I don't know, just to tick the box I would
say. And I think one thing as well,
when you draw a diagram, very little standard is there maybe
previously maybe during my days there is this UML, right?
It was kind of like widely used, but these days I think the
standard has been missing. So what is your view about for
people to actually come up with a good kind of a set of
architecture diagram? Probably of some kind of diagram
to explain technical solutions. I think that it's not
particularly important that people choose a particular
standard, but that they standardize what they're
creating. Because if you have lots of
different types of diagram and they all use different colours,
different keys, different symbols and things like that,
it's very difficult for people to switch from one diagram to
another because they have to change their mental models of
what they're seeing. And one of the big things that's
important with communication is making things as easy to
understand as possible from your audience's point of view.
So I don't say to people you have to use UML, you have to use
AC4 model. You should be using something
that's standard and one part of that is thinking about making it
accessible for everyone so you can think about your colours and
making them OK for people who are colour blind and things like
that. There's lots of different
accessibility things that I've put.
In fact, it's got a whole chapter on accessibility in just
the visuals alone, so there's an awful lot you can do.
But when you're creating your diagrams, you should be thinking
about not mixing levels of abstraction.
Just like when that's done in code, you get an unmaintainable
and confusing mess. And the same is true for
diagrams if you separate out into layers.
So you might have that your context A conceptual, logical
and physical, that kind of thing.
Or if you're using C4 models, you probably have your context,
your container, component and code.
Although component and code they're less useful, but the top
two are very useful, and once you separate these out, that
means your audience can more easily understand what they're
looking at, which is really your main goal when you're
communicating with different people.
So when you're creating your diagrams and making them
consistent, you can also use another pattern in there which I
call representational consistency.
And that's how you make sure that there are explicit links
between your diagrams. So part of that is using
consistent keys and colours and things like that.
If you're using different notations like UML or data flow
diagram, you are going to have different shapes, but you need
to be consistent in how you're presenting things and how you're
referring to different things in your text and the colours you're
using and things like that. But when you're separating
things out into the different levels of abstraction, you're
going to end up with more than one diagram, which is really
good for getting people to understand what's in it because
there's less in it and different diagrams are going to be for
different audiences as well. But you need to make sure that
your audience can navigate between those diagrams and see
how they fit together, and there's lots of ways you can do
that. One of those is when you use
identifiers in each diagram. So if you've ever used a data
flow diagram, it has processes which are numbered, and data
stores typically have a letter identifier for them.
So if you're using different levels of data flow, if you're
moving down and breaking things down, each of your diagrams
should have the same identifiers on it for the different data
stores. If they appear in one diagram.
But also if you've got a process that's labeled #2-IN-1 diagram,
then when you break that down into another diagram, you can
label it 2.12.22.3, etcetera. And so you're just creating that
link between them, make it easier for people to understand.
Speaking about consistency, you know color accessibility, right?
When I read your book, I must realize that I've never cared
about those things before. But now that you mentioned in
your book, right? So I think it's really
important, especially maybe for different kind of audience,
right. We sometimes just pick the color
that we think are nice, but in your book you cover there are
different kind of a gradient or maybe that kind of color that
you should choose instead use the consistent theme, right?
I think you mentioned about consistency so many times, not
just color but also shapes. And I think very, very important
is about the mixing level of abstraction, right.
So I think when we draw diagrams, sometimes we don't use
the same kind of abstraction. Sometimes you could be in a
context, but sometimes you go down into more like a physical
deployment sometimes, right. And you put it all together in
one diagram. So I think I like the C4 model
from Simon Brown. So when I read his book also, he
covers from his audience, right? There are so many different
types of diagrams and it's very, very confusing because they all
look different. That's the first thing.
And the second thing is the levels of abstraction.
Usually it's mixed jumbled up together.
So I think it makes it really hard unless you follow how the
author is creating the diagram, right?
So for people who just saw the diagram first time, I'm sure
they will be confused. So I think very, very important
about this. And I think another thing you
cover in your book about this visual communication is about
the narrative, maybe how you present about the diagram,
right? So tell us more about how can
you narrate your kind of visual better?
Well, narrative is actually very important factor when it comes
to communication as a whole. So when you're thinking about
when you're telling a story or when you're writing something or
when you're creating a diagram. And one of the main reason for
this is that we evolved listening to stories and passing
information on in stories because we could speak and use
language before we could write anything down.
And so our brains as kind of tuned into stories.
And so narrative is very useful when you're trying to get
somebody to understand something, but it's also really
useful in diagrams as well. And the main way that you can
apply this to diagrams is when you've got those various
different diagrams. As I said before, you're going
to have these different kind of levels of abstraction.
And when you're talking to people about things, you need to
order them from the high level down to the low level.
And the pattern, I call this the big picture comes first.
So we often forget that others don't have the same
understanding as us and we need to give them that opportunity to
learn and take that important higher level information and
fill in any holes before we dive into what we really want to
communicate to them. So maybe you are talking about
how you are specifically going to handle a small process down
and you really want to get to this low level data flow diagram
that you've got. But you need to consider what
information your audience needs 1st and maybe start all the way
up at a context diagram to give people an idea of what other
systems you're talking to, because that's important
information when you get down to that.
And so you probably need to actually go through several
different diagrams or slides or just giving people other
information. Like it might be the constraints
for the system that are important to what you're going
to be talking about. And so it's important to start
at that high level and go lower, because if you start right at
the bottom, you're going to get lots of questions and people
won't understand what's going on.
They'll probably also be quite bored as well, because if you
dive straight into the details, that's quite boring.
So give them that big picture 1st and then.
Get down to that point so that everybody's got the information
you need. Yeah.
So I find this different level of views, right.
So it's really important depending on your audience,
which you mentioned in the beginning, right?
So understand the audience and present them with the kind of
view that is suitable for them. It's not like, for example, if
you're talking to stakeholders, maybe don't show directly to the
component or code level, because most likely they'll feel lost.
And it's very, very important to actually know the audience and
present them with the view that you want and narrate that such
that people can understand. So thank you so much for
covering this visual. Maybe just a little bit of
recap, right. The first thing is about knowing
your audience. Don't mix levels of abstraction.
Be consistent in representing the things in your diagram, be
it colour, notations and things like that.
And when you narrate big picture comes first.
So I think that's really key for people who want to find out more
patterns about visual, go check out the book.
So let's move to the second section of your communication
pattern which is about multi model communication, essentially
things like written, verbal and non verbal communications.
So maybe tell us why this is important for engineers and
architects. Yes.
So I called it multi modal so that I could give it a bit of an
umbrella term for written, verbal and non verbal.
And these are skills that we quite often forget that we use
on a day-to-day basis. Even if we're not working in an
office, we're still using verbal and nonverbal skills and
techniques when we're on a call with people with video or not.
And so this area is quite important really.
And I started off with the written area and there's quite a
few different patterns and anti patterns in that one.
One of the simplest things that people can apply has simple in
its name as well, and that's using simple language.
And it makes it much easier for people to understand if you use
a simple vocabulary compared to sort of more terms that aren't
used very much. And it helps everyone.
But it's especially good for those for whom the language that
you're using is not their native language.
And you're also being more inclusive to people who have
dyslexia or things like autism or ADHD as well, because you're
making it more understandable for everyone.
So a couple of easy examples, if you can use the word buy rather
than acquire, and you can use the word most rather than the
phrase a majority of and it just makes it so much easier for
people to understand. But also if you're using less
words as well, it means people can read it quicker and so
people are much more likely to be quite happy with that and
also with the writing aspect. I look at how you can structure
your technical writing, and one of the principles I've pulled in
from other areas is the Minto Pyramid Principle.
And there's a whole book and loads of training and stuff on
that by Barbara Minto if you are interested in that.
And it's all about using structure to make a point.
And then once you've made that point, you then back it up.
So you're making sure that most important information comes
first and it can be applied to documentation, but also it can
basically applied to your emails and messages every day.
And you might actually see people applying that sort of
thing on their social media messages.
So that first sentence catches your attention because quite
often it's the only bit you can see unless you click show more.
So it's getting people's attention, but it's also giving
them that most important information. 1st and news
articles are written in that way.
You've got the headline, the most important information, and
then you get the next most important information.
And so at any point you can stop, but you've already seen
the most important information in that, and you can apply that
very easily. It's really useful in emails and
things. How often have you read an
e-mail where it's kind of rambling on about different
things, And eventually you find the bit that you really need to
do something about, and it's hidden down in there.
And if you hadn't read it properly, you wouldn't have been
able to find that. And so if it had just started
with that most important piece and then given some explanation,
then that would be much easier for you.
And so it's just thinking about, again, making things easy for
people to consume and understand.
So thanks for explaining some of this, right.
So I recently read a book as well.
I think it's called Writing for busy Reader or something like
that. I think some of the key points
mentioned in the book also covered by you just now.
Right. So first, use simple language.
Less is better, right? So don't write in a more
elaborate and long sentence, right?
So if you write it shorter, people will be able to read it
faster and they will make sure to read it in full as well,
right? Because if it's too long, right?
Sometimes people just scan through and maybe skip or
archive your e-mail, right? And the Minto pyramid.
I think it's also very very insightful for some people who
never learn about writing before, right?
It seems counter intuitive in the first time, but actually if
you learn about it right, I think it will make your writing
communication much more effective.
You know some people also call this technique something like
TLDR right? So what's your too long, didn't
read kind of a message right? Your key message.
Some people call it bluff, right?
Bottom line upfront, I think it's used in military.
So I think it's the same key message, right.
Your headline first the most important thing first before you
actually kind of like cover your rationale I think in mental
pyramid as well you kind of like breakdown your main topics into
like at Max three I think the recommendation and you start
building a tree like a chain thought of reasoning.
So I think people should read about this technique and this
mental pyramid also use I think from McKinsey, right.
And they kind of like mandate that for all their consultants
to use this kind of technique. Yeah, I think she developed it
when she was working at Mackenzie.
Yeah, so I think for people who hasn't not heard about this
technique before, do check it out because I think it will make
your writing slightly more effective if it's the first time
right? But if you consistently use it,
I think it will make it even more effective.
So moving to maybe the verbal communication aspect, I think
most engineers prefer chat rather than talking in person,
right? But what is the key message that
you want to cover this about verbal communication?
Yes. So as well as the written, I
cover the verbal and the non verbal and I think people
sometimes think of the verbal, but the non verbal is something
that we think about less. And so we use this all the time,
in person or remotely, and a lot of what we get from conversation
we actually pick up really simply and quickly.
There's the System One and System 2, which was written
about by Daniel Kaneman. And with the System One makes a
lot of decisions really quickly, really snappily.
And a lot of that we like from people's facial expressions and
things like that. And when I've written this, I've
structured it as I've written with the patterns and anti
patterns to help technical people.
I've also structured this around encoding and decoding messages,
which is something we're all kind of familiar with software
development and we don't really think about it in real life.
So when we're setting up communication between services
and different parts of the code or APIs, we encode what we're
communicating and we also decode any replies.
So it might be using HTTPS or message queues, but we're doing
a translation each way, and we don't really think about when
we're talking to someone else. Even if you're speaking the same
native language, everyone's an individual with different
backgrounds. And so we are constantly
encoding and decoding, and things can get easily lost or
misunderstood. And so I talk about some
different cognitive biases and also body language.
And it's based on the fact that if you think about these things,
then you can think about encoding them yourself to
actually give other people the correct message, the message you
want them to receive. But you can also work out better
how to decode things that other people are saying, so you can
realize that they're actually thinking possibly something
different to what they're saying.
And then you can start to try and dig deeper into that.
And so by reading this section, you can improve the accuracy of
your own encoding and decoding and take all these things sort
of use them to your advantage, rather than just being
completely oblivious to them, which quite a few people are.
Yeah, software developer, I think we are all used to, you
know this encoding, decoding, right Be it, you know, you're
calling APIs, you use some kind of interface contract between
two different protocols, right. So I think we are so used to it,
but in the communication, maybe it's written, verbal or whatever
that is, right? We don't actually think about
it. And I think these days we all
work in a pretty global setup where people have different
culture, different language, different interpretation of
stuff. Even some culture actually might
take a certain word differently than other culture, right?
So I think it's really important that we use the right encoding
and also for you to do the right decoding because sometimes there
might be a misunderstanding happening if you don't use the
same protocol or the same contract, right?
Sometimes being explicit, like when you mention about
something, right? Just explain what you actually
mean exactly by using that term. I think it's really important as
well in your view, right? In this global remote set up
these days, how can people become more aware of conscious
about this encoding decoding process?
Yeah, well, I think as you said, a lot of people are much more
likely to type a quick message than they are to either call
someone or pick up a phone these days.
And one problem with text is that you can't get this body
language, the tone of voice. You can't get all those things
in there which you do even if you're just talking on the
phone, you get something from that even if it's not face to
face or on a video call. And even if you're on a video
call, it's actually a lot harder to decode things from somebody
on a video than it is in real life.
And so when we're using all these remote forms of
communication, we're making it a lot harder for ourselves having
it to work a lot harder to understand each other.
And so knowing about these different things to do with body
language and how you can encode things a bit better is very
useful. So applying the writing just the
pyramid principle, that really helps people, and if you are
reducing the amount of effort that people need to use to
understand you, then people are much more likely to come around
to your way of thinking because you've given them something
really easily, whereas they might have to work a lot harder
with someone else. Yeah, I find when you interact
with someone through chats, right?
Sometimes, yeah. Like what you said, the emotion
is not there. Sometimes we actually fill in
the emotion by ourselves, our own perception of maybe this
person is angry, this person is frustrated, right?
But it may not be true from the person's perspective itself that
actually they are frustrated. So I think it's very important
not to judge quickly, right? Or sometimes just clarify with
the person before you actually make assumption and maybe use a
lot more emojis, right? I think you mentioned it in your
book. To actually convey some emotion
in your message, use some more emojis, although emoji can be
interpreted differently as well in some different culture.
So thanks for covering that. Let's move on to the next
section which is talking about communicating knowledge.
So this is something maybe about coming up with wiki or sharing
documentations which I think many engineers know it's
important but somehow still many of us don't get it right.
So tell us how can we upscale our communicating knowledge kind
of skill set? Yes, so this is all about
knowledge rather than just documentation.
Because documentation is a very small part of knowledge and I
know that a lot of people are turned off by the word
documentation. They don't want to have to
create that. But despite it's worth,
knowledge is often neglected in organisations.
It's not part of people's day-to-day job.
They're not rewarded for sharing knowledge, and code is often
given a lot higher priority than data.
So people are very insistent they use version and control for
your code. But when they're thinking about
data, that's often like backups for it and often an
afterthought, despite the fact that data is often a lot harder
and sometimes impossible to replace.
Whereas you can rewrite some code that your data will be
lost. So knowledge is really
important. But just like data, not given
enough information, not given enough thought in a lot of
organisations, but documentation and knowledge management, they
give so many benefits when they're done well.
If you just think about all the time that's wasted by people
trying to find communication, I think it was a Forrester study
that said that knowledge workers spend 30% of their time looking
for information. And that's what we are.
We're knowledge workers. And what would your boss say if
you said, oh, actually I spend 1.5 days per week looking for
the information I need? I don't think they'd be
particularly happy about that. So that's why I've dedicated a
whole part of this book to knowledge and how we can improve
our use of it because there are so many benefits to the way
people work and the end results for products and for customers
and all these other things as well.
And so I cover some principles of knowledge management and that
includes one that I call perspective driven
documentation. And this is my own principle and
practice that I have come up with with all the research that
I've done on this. And it puts the focus on who
you're communicating with and also why you're communicating
with them. Because when you're thinking
about your audience, you're not just thinking about who's
looking at a particular piece of information.
You are communicating with them for a reason.
Maybe it's because they've asked for that information, or maybe
it's because they really need that information even if they
haven't asked for it. Basically you need to determine
what should be communicated by thinking about who you're
communicating to and why and rather than the other way
around. Quite often people, as you said,
it's the tick box exercise. Like Oh yes, I've created a
context diagram, I've created the constraints documentation
for this, but you really need to think about why and who you're
talking to and then that will help you work out what you need
to do. And if you come a tip from that
point of view, then you'll probably not waste time creating
things that actually people didn't need in the first place.
And so stakeholders need to be able to find and understand that
information they need when they need it.
And many people are going to be in one of two situations.
Either all of their information in some sort of bloated huge
word processing document or similar, and it's difficult to
find what you need and it's difficult to version that whole
huge horrible Word document. Or it's spread across many, many
applications and different teams are using different knowledge
repositories. And some people have got it in a
wiki. Other people have got it in
something like Confluence or Notion.
And you inevitably end up with old data lost in various legacy
applications that no one wants to use anymore.
And we thought we'd migrated from them, but we haven't.
And so of course, there's going to be information locked away in
people's heads and also their personal notes.
And so when you look at this perspective driven
documentation, it organizes that information into what I call
perspectives. You could also call them views,
but that's a very overloaded word in technology.
And each of these perspectives addresses the needs of a
particular stakeholder, and so items within that perspective
can be reused in other perspectives.
So that might be a diagram appears in more than one of
these perspectives because more than one stakeholder is
interested in it. It's a little bit like reusing
code so you can follow the DRY principle with it that Don't
Repeat yourself and it makes things easier to maintain.
And I found it actually also goes really well with Domain
Driven Design if you're doing that.
But when you create these perspectives, you can reuse
things. So you might create it as
different wiki pages, and then you embed a diagram into each of
those wiki pages. But when you're doing that, one
thing to think about with this DRY principle is that sometimes
you don't want things to always be the same.
So maybe you're referencing a particular law or a standard
that's applicable at the time. And if you just link to that, or
if you always keep that as the most updated version of that
standard, then it won't make sense.
If you look back at that and people say to you, oh, why
didn't you follow that bit of the standard?
You would have to work out that it didn't exist at the time you
did this part of the project. But if you keep it as this is
the version of it as it was in January 2024 or whatever, then
you can see that, oh, things have changed now and so we need
to make some changes. But it's all about creating
these perspectives for people for particular stakeholders and
therefore not creating stuff that people don't actually want
and wasting your time. And that's probably one of the
main benefits of this way not wasting your time on things and
giving people what they actually need.
Yeah, sometimes what I can see in practice.
OK, there are a few things that I see in practice.
The first thing is we all love to communicate through chats
these days and put a lot of information, maybe sometimes
meeting notes, maybe things that we discuss and everything is
over chat, mostly slacks or teams, right?
And we never take the time to actually put it somewhere in a
repository, be wiki or maybe some centralized place and we
just assume that everything can be searched on chat.
But chat, I think it's a semi structured communication
channel, so sometimes things are not so easy to find as well and
especially if you have multiple threats you know, discussing the
same thing. So probably that is 1 experience
that I have. The second thing is about what
you mentioned, right? People seem to value code much
more than the knowledge of the data, right?
And they push engineer to always start with coding.
You know, start with coding as soon as possible.
But sometimes, for example things like requirements or
maybe even like drawing some kind of design diagram or system
design diagram is something that sometimes get neglected and
people prefer to jump straight to the code.
And I think the third thing, like you mentioned right
perspective driven documentation.
Sometimes we just write documentation for the sake of
ticking the box without actually knowing who will actually read
the documentation. So I think those 3 aspects are
things that I normally see in my career as well.
So for people to start thinking about coming up with a good way
of capturing knowledge, any kind of tips and tricks for
developers to do things better on this area?
I think as you just mentioned about there being knowledge in
chats and emails and things, I think that's possibly one of the
worst situations you can have when all the knowledge is locked
away in places other people can't find it.
So I once heard someone talking about they were saying, Oh yes,
or whenever I want the answer to a question, I just search in
Slack. And quite often someone's
already asked it and that felt you were dread.
Because I thought, well, if someone needs that information,
do they know it's in Slack? Do they have access to the Slack
channels that it's in? And when does that information
get archived or possibly deleted by the products you're using?
And if you're doing that same thing with e-mail, giving people
information over e-mail, then only the people whoever received
that e-mail will get it forwarded to them.
Ever have that knowledge. And quite often your
organization will be archiving or deleting e-mail that's maybe
over a year old or something like that.
And maybe you don't even know that.
And so all that knowledge then gets lost, especially if those
people who wrote it then leave the company.
And so one big tip that I have is when you're sharing
knowledge, if people ask a question on a message or over
e-mail, don't share the knowledge.
Share a link to the knowledge because then people will know
where to find it. If it doesn't exist in your wiki
or whatever you're using, then create it and share the link.
If you look at it and you realise it's out of date then
you can update it and share the link.
I mean you might have to get together to work out how to
update it, but that's really important for all of your
knowledge. But if you just think about
sharing this link, that will help you to keep all your
knowledge in a place that is accessible to everyone and not
spread across all these many many apps that people don't know
where it is and they probably don't have permission to access
it anyway. So that's my big tip there,
Share a link rather than the knowledge itself.
Yeah, I think it's a great tips, right?
Because sometimes we actually want to answer quick, right?
Maybe because of busy or whatever, right?
We want to answer very quick and we just dump the knowledge and
the content in the chat itself. But I think the tip is really,
really useful, right? So provide a link, take your
time, put it in the wiki. It takes a village to actually
do this kind of discipline. It should not be just one person
doing it all the time, right? It takes a village.
Everyone should be conscious about doing this.
So I think sooner than later your knowledge management will
become much richer and people will be able to find knowledge
much more often. Another thing that I find really
useful in your book you cover in this area is about getting
feedback early and often and also just in time architecture,
right? So I think sometimes when
developers are being tasked to create documentation, we kind of
like take the whole week or few days to actually write a long
document before we share it to other people.
I think it's worth to mention about these two aspects so that
engineers maybe can get feedback early and also just write
whatever that is necessary at that point in time.
So maybe if you can cover a little bit on this.
Yeah, so with knowledge, as I said, it's not just about
managing documentation and it's not about just what knowledge
management system you use. It's actually socio technical.
And so you have to take into account people for it to be
successful. And a simple way to improve your
knowledge and documentation, as you say, is to get feedback
early and often. And it really helps you to not
go too far down the wrong path without being able to course
correct. So don't wait days or weeks to
ask a colleague or a stakeholder for feedback on the artefacts
you're creating, whether that's something written or a diagram.
And don't spend more than a few hours on something big or even a
shorter time on something smaller before you get feedback.
Because if there's something that you didn't know, that means
that you're going to waste a lot of time on that.
You want to get that feedback early.
So we all know that when we get given requirements that they're
not going to be complete or they're going to be incorrect.
And so if you work for a long time designing something based
on those requirements, then take it to your stakeholders and they
tell you that something was missing or something's wrong,
you've spent a lot of wasted time and effort on that.
And so get that feedback really, really as quickly as you can.
And it might be something fairly informal if you're in an office,
just asking someone who's sitting next to you to have a
quick look. Or it might be actually setting
up just a brief 15 minute conversation with someone, a
video chat, just to show them it doesn't have to be a big like
all three hour meeting. We need to have a look at what
I've done so far, because you haven't even spent three hours
on it, but it's just getting that feedback quickly so that if
you think about Agile, this is what we're trying to do.
We're trying to get quick feedback loops.
And I think even if people are managing to do that with the
code that they're putting into the system, get it to the
customer early, get feedback quickly, they forget about this
and they can apply that same principle to all the work
they're doing and it will help you in that.
And then this also complements another pattern which I talk
about, which you mentioned, which is just in time
architecture. And it's important not to make a
decision earlier than the what I call the last responsible
moment. And that means that making the
decision too early can mean having to change that decision
when you get new information which comes to light.
And if you'll change your decision, that's often expensive
thing to do, either money wise or effort and time wise, and
therefore that costs money anyway.
And especially if they're architectural decisions, they
tend to be more expensive to change.
And if you have to change that one decision, what about all the
other decisions that you made based on the outcome of that
decision? You probably got to change all
those as well. And so you can get this awful
chain reaction because you've made a decision too early.
So even if you've got someone kind of breathing down your neck
asking for a particular artefact or a particular decision, you
really need to try and put them off until that last responsible
moment and you create your artefacts just in time.
If people really are insisting, then you can create something
and just say put something on it, like a disclaimer that this
is a draft. If you base anything on this, it
may need to change and that can help to communicate why you
can't just make this decision now or create this artefact
right now and in the end it's going to save you time and
money. But one of the other really good
things about this is that it means you can focus on what
really needs to be done now instead of having all your time
blocked out working on things that aren't needed yet.
Because we all get unexpected work, this inevitably comes our
way all the time. Things go wrong or something
pops up, and if you've got your time blocked out working on
stuff that isn't needed right now, you don't have that slack
to take on that inevitable unexpected work.
So doing this just in time architecture means that you have
that time to work on the unexpected.
You don't waste time on decisions that shouldn't have
been made at that point, and you just get a much more agile
process to your working as well. Yeah, I would recommend people
who probably do a lot of documentation to think about
these two aspects really, really closer to your heart, right?
Because sometimes I see so many engineers spend many, many days
to come up with documentations, which actually in the end,
right, sometimes they need to do a rework or it just doesn't
solve the kind of problem that they're trying to solve by
coming up with the documentation.
So get feedback early and sometimes I think in your book
you mentioned about templates, right?
You can actually also come up with templates so that people
are guided on what aspects to fill in in the documentation
rather than always having to come up with a different kind of
a format all the time. So I think people please bear
these two key points so that you can communicate your knowledge
much better. So the last aspect is about
communicating remotely. So probably if we know about
this remote work right, there are always two things that are
always mentioned, synchronous and asynchronous meetings, no
meetings, deep work and things like that.
So maybe a little bit of advice here for people who are more
used to this kind of remote set up now or also hybrid kind of a
work set up. Yes, a lot of us are either
working remotely or in a hybrid, or even if you're working in an
office, you are probably working with other people who are
working remotely in hybrid. Or maybe you're working with
people who are in office in another country, even other time
zones, of course. And so there's an awful lot to
take into account when we think about how we're communicating
with people. And a lot of people kind of
think they're feel a bit sort of professional at this now because
we've been doing it for quite a while.
But it's not really quite as simple as people think.
If you consider how many companies at the moment, even
ones who actually make remote communication tools, they're
trying to get their employees to come back into the office for
more of the time. And yet you've got other
companies who are thriving as fully distributed or hybrid
organisations. And it's the fact that the way
in which things are communicated seriously effects people's
understanding and their productivity.
And people need to understand a lot to decide whether a
communication method should be either synchronous, which is in
real time, like a meeting, or asynchronous, where the
recipients read and respond on their own timetable.
In fact, the podcast is also an asynchronous method of
communication, so you're experiencing that right now.
But many people don't realise how disruptive synchronous
communication can be to people's work.
So working out which communication should be async is
vital people getting their best work done.
So for example synchronous activities, things that work
very well synchronously are things like generating ideas or
building rapport like team building or maybe a project kick
off. That can be good for a
synchronous meeting with asynchronous things like
reporting progress or gathering feedback.
So using things like comments on documents or architecture
decision records or other forms of decision records, those can
be done asynchronously and often communication should actually be
split between the two. Some people like to evangelize
asynchronous communication, but really some things are better
done synchronously. And one of the things I talk
about in the book is an asynchronous sandwich, and
that's where you are maximizing your synchronous time.
So if you're getting everyone together for an hour
synchronously, then you want that hour to be all activities
that are best done synchronously.
So any part of that that is best done asynchronously before or
after, you want to split off from that so that you're not
wasting people's time. If you have to get everyone
together for two hours, that really knocks everybody's
productivity and probably not everybody needs to be there for
those two hours. And that's one of the things
that people really hate about meetings, especially remote
meetings, because they're even harder to concentrate in.
I said earlier about it's much more difficult to read people's
verbal and body language, and so you're already putting more
stress on people. So making that synchronous
activity just for the stuff that works well at synchronously is
going to be really useful for that.
Yeah, sometimes I think it's very tricky right?
Some people is more towards asynchronous.
Like I would prefer asynchronous all the time or some people like
for those who come back to office are forced to come back
to office. Maybe the management or
leadership likes to be In Sync all the time.
So I think always they're polarizing thoughts.
But I think your book kind of like give a good guidance.
Like for example you probably need to do meetings in person
synchronously if you want to get like some kind of consensus, you
know like kick off idea generation right rather than
asynchronously. And async is more towards
thinking you know like getting comments, feedback, ideas.
And I think I also like one of the thought from James Daniel
about asynchronous versus synchronous.
I think he mentioned about if you want to get a strong
consistency do it synchronously. But if you think you can do like
a virtual consistency kind of manner, do it in asynchronous
way. And I think in your book you
also mentioned one anti pattern that I see happen all the time.
We try to do async meaning like using chat, but actually we kind
of like reply back and forth synchronously in real time in
the chat and we make decision very very quickly on that chat
as well. So I think this probably is an
anti pattern because there are some people who are not in the
conversation itself and also it's a lot of back and forth
means probably the ideas need to be talked through much better
rather than in chat, right? So for people probably if you're
frustrated with some of your asynchronous or synchronous kind
of communication, do check out Jackie's book on this aspect.
So I think you'll get a lot of more tips on how you can improve
on this. So Jackie, it's been a great
conversation. Unfortunately, we have to wrap
up pretty soon. I have one last question, which
I normally ask for all my guests.
I call this the three technical leadership wisdom.
You can think of it just like advice for all of us to learn
from you. So is there something that you
can share with us about 3 technical leadership wisdom?
Yes, I had a good thing about this and the first one I want to
share of the three is the soft skills are pretty much always
going to be those ladders for you to climb in your career,
whereas your tech skills can turn into snakes, meaning you've
got to start again with another skill.
So emphasizing that from before, the second thing that I'd like
to share is that there are always trade-offs with anything
in in technology, probably pretty much area in life.
There's always going to be trade-offs.
There's no silver bullets in technology or architecture or
anything really. And you need to understand
what's important to make every decision.
It's not just about what's the latest technology or anything
like that. And so you need to use tools
such as Architecture Decision Records to help you with this
And thinking about architecture characteristics, which I also
talk about in the book and that helps you, it gives you this
guidance or what's important for making that decision.
Then my third tip is what we do as technical professionals
always involves people. Systems are always socio
technical, so you cannot ignore the people when you're trying to
build or make changes to a software system.
And things that are useful to help with this are systems
thinking and also techniques like collaborative modelling.
Team topologies is an interesting area to look at and
also things in my book like Just in Time Architecture can help
you with this socio technical element.
So those are my top three tips at the moment.
Well, I I really love the ladder and snake analogy, so I'll use
it more often. I think you put it very
interestingly, right. So communication skills is like
a ladder for you to climb to bring you always up, right?
Sometimes it could also bring you down if you communicate
wrongly I guess. But yeah, technology always
keeps changing, right. So I think it's like a snake
where you always kind of like have to up to date yourself,
right. And also keep following the
trend. But I think, yeah, the
communication is always applicable in any type of
situation, no matter what role or what job that you have.
So Jackie, if people love this conversation, they want to reach
out to you or ask you anything in person or online, right?
Is there a place where they can find you?
Yes, the best place to find me is my website
whichisjackiereed.com JACQUIR ead.com and you can also find
the book on its website whichiscommunicationpatternsbook.com.
So for everyone who's interested in this, please reach out to me
especially if you want to look at working together in any of
the aspects that I've talked about today or in software
architecture and socio technical areas in general.
And thank you very much for having me on tech lead journal.
Yeah, so I highly recommend reading Jackie's book again,
Communication and Soft Skills. Probably not so many engineers
think this is important, right? Rather than, you know, following
all this technology or maybe AIML now generative AI, right.
So I think communication is still applicable no matter what
age, what era you are, right? And there's always a lot of
things that you can improve in terms of communicating better.
So thank you for your time today, Jackie.
Brilliant. Thank you.
Thank you for listening to this episode and for staying right
until the end. If you highly enjoyed it, I
would appreciate if you share it with your friends and colleagues
who you think would also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe
and leave me your valuable review and feedback.
It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on
the episode page at techlitjournal dot dev website,
including the full transcript, interesting quotes, and links to
the resources mentioned from the conversation.
And lastly, make sure to subscribe to the show's mailing
list on techlitjournal dot dev to get notified for any future
episodes. Stay tuned for the next Tech
Lead journal episode, and until then, goodbye.