If you have the ability to communicate, if you have the
ability to articulate your goals and execute on them.
So these are all examples of why communication skills are
essential for engineers to be happy again.
This is not about making more money or being successful or
something. My goal is just to make you
happy. I see a lot of Engineers be
unhappy. When I think a lot of that has
to do with not being able to control their environment.
Even articulate. Relate, what they want to have
change in this environment. So I think by becoming a better
Communicator, you will become also happier.
Hey everyone. My name is Henry Surya be Robin.
And you're listening to the tekhelet journal.
The show will 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, everyone.
Welcome. I'm back to another episode of
the tekhelet journal podcast. This is your host, Henry Surya.
We are one, and it's really great to be back here again with
another great conversation. With my amazing guests.
Thank you for spending your time with me today, listening to this
episode. If you haven't, please subscribe
to Tech. Le journal, on your favorite
podcast apps and also follow our social media channels on
LinkedIn, Twitter and Instagram, you can also make some
contribution to the show and support the creation of this
podcast by subscribing, as a patron, at technology know that
deaf. / Patron and help me to continue producing.
Great content every week. Today's episode.
I'm very happy to share my conversation with Chris.
Lavra. Chris is an experience of an
engineer and has been a technical manager advisor and
staff software engineer with companies, such as IBM Bank of
America. Google, Uber and Source graph.
He's also the author of a book titled communication for
engineers. When we talk about great
software Engineers, many people tend to think that those are the
engineers who are great at heart skills.
Such as Solving challenging technical problems coming up
with amazing. Technical design being Wizards
at coding, debugging and testing and many of Engineers.
Also think that to succeed in their career.
They just need to focus on gaining more and more technical
skills such as mastering numerous number of programming,
languages Frameworks, trending Technologies, Etc, but this
could not be further from the truth in this episode.
Chris, shared some insights from his book.
Communication for our Engineers about why communication is such
an important skill for engineers and how they should combine the
hard technical skills with Advanced soft skills such as
communication, skill, influencing skill, collaboration
skill, and so on, in order to become much more impactful
Engineers, Chris also shared great insights and tips on how
to deal with Engineers typical source of unhappiness, which our
imposter syndrome stress and burnout.
And he gave practical tips. That we can use in order to
become successful, productive, and eventually become a happy
engineer. I absolutely love my
conversation with Chris and I hope you will love this episode
as well. Consider helping the show, by
living it, a rating or review on your podcast app or leave us
some comments on our social media channels, those reviews
and comments are one of the best ways to help me get this podcast
to reach more listeners and hopefully they can also benefit
from all the contents in this podcast.
It's so let's get this episode started right after our sponsor
message. Are you looking for a new cool
swag? Taglit Journal.
Now offers you some swags that you can purchase online.
These wax are printed on demand based on your preference and
will be delivered safely to you all over the world.
We're shipping is available. Check out all the cool tracks
available by visiting technology.
No, dot f / shop, and don't forget to break yourself.
Once you receive any of those tracks.
Hey everyone, welcome to another new episode of the tech lead,
you know, so today, I'm very happy to meet someone called
Chris lavra, creases and experienced software engineer.
You can tell from his career Journey so far.
So he has worked at IBM Morgan, Stanley Bank of America.
Google, Uber And subscribe. Chris is very experienced.
Today. We are going to talk a lot about
how to communicate as Engineers. Also, some of the things related
to that, which is about impostor syndrome.
So I'm really looking forward to this conversation.
Chris welcome. The show Larry.
Thanks for having me. So Chris maybe in the beginning
for people to know more about you.
Maybe, can you help to introduce yourself?
Maybe telling us your major highlights or turning points in
your career? Yeah.
Sure. I'm originally Dutch.
I grew up in the Netherlands that my computer science degree
there, and the PHD, I lived about half of my life in the US.
I've worked at technical companies, like, you mentioned
IBM, worked in Wall Street and finance, which is not so
different from typical tech companies.
Actually, and I worked at companies like Google and Uber,
and I'm a technology advisor at source graph at the moment.
So, my career is, I'm a technical contributor and mostly
what? I always say, my audience or my
customer is other Engineers. So I've worked on compilers
analysis, tools, visualization, tools ID.
He's I'm also very interested in workflows.
So try to understand what we built.
But also how do we build it? So to try and understand all the
different tools that go into the process?
We're at opportunities for optimization.
Let us led to a lot of things, like trying to understand
complex systems involving tools, but also humans and that has led
to capturing all that. All the things that I learned
over, maybe the 30 years of my career, how we develop software,
how Engineers are motivated, and we recognized, they become
successful or productive. I personally haven't discovered
it yet, but our industry is very interested in figuring out what
makes engineer especially productive.
I have some theories that I would love to talk with you
about. I capture that in a book.
I also teach courses on this. My main goal here is to make
other Engineers happy. That is always been my driving
force. So that's basically my career.
I'm back in the Netherlands right now.
So, I live very close to Amsterdam.
Thanks for sharing your story. I think you have a very great
goal. I would say, making Engineers
happy. Well, I know, like some
Engineers should be happy, but some of them might not be
because of maybe situation in their career or their job.
So, first of all, right, Knowledge that you actually
wrote this book called communication for engineers.
I think this is a very interesting topic because in
most parts of the world Engineers are probably not
associated with a very good communication skills.
So what was the idea behind how you actually write this book?
Yeah. That's exactly the observation.
I made myself. I've been a technical
contributor individual contributor and a manager team
leads tlm. So I've played the different
roles in. In software development.
And I've seen a lot of other Engineers struggling with
defining. Why are they stuck?
They reach a certain plateau and they think I'm just building
great software. Why am I not advancing?
I've asked myself that question for a while now and not over
generalizing or stigmatizing individuals, but most Engineers,
I think are introverted. They like solving puzzles.
They like learning new languages learning, new compilers they
fight with Engineers on using spaces versus Tab, these are the
kind of things that excite us, we get our energy from writing
code and throw it through compiler and it actually
compiles. This is like awesome feeling,
right? Or you have a really complex bug
that you're trying to solve and it takes you like two or three
days to do the crime scene analysis.
You build up this entire graph in your mind and eventually you
find it and then you said, oh, this is awesome.
Right? So, this is what drives us, but
probably the most obvious time when communication comes it's to
play is during performance time or promotion time where you now
have to explain what you contributed to the company or
the organization. And you have to do this in terms
that other people understand. And this is surprisingly hard
for engineers. So I started thinking what's the
reason for this and I started just reading myself and I think
that the best way to learn about a certain topic is to write
about it. So this is a very meta topic
about communication skills here. So if you want to learn
something It right about it, write a block, give a
presentation about it, do training about it.
That's even better or write a book about it.
I'll be very honest. The reason I wrote the book was
not because I'm an expert Communicator not because I'm a
advanced skills in that area. But because I wanted to learn
how to become one. So that is really the reason why
I wrote the book is to get my mind clear on all these things.
And I think I did pretty well. Lots of people like the
structure of the book. There's A section of theory like
how our brain works and how we have social skills and interact
with other people, but then there's a lot of concrete tips,
like the engineering part of communication.
So, about tickets about emails, about design documents about
writing, clean code, and code reviews.
So those topics that Engineers, find important, especially
motivation. For the book.
It's selfishly to become a better engineer.
A better communicator, but also to share my insights, that I've
collected over the years and give back to the community.
I understand that you also running this as an interactive
course, so it means that many people resonate with the idea of
the book and many people would like to learn more about.
This one thing that I noticed when you explain all this,
right, you mentioned that somehow Engineers have a
challenge actually? Communicate.
Well, why do you think that is the case?
Because lots of Engineers, our smarts, we know about facts, we
know about logic and all that. Why is it so difficult for them
to actually communicate? So I think that it's both
systemic and its Sure. I mean, I'm not a psychologist.
I haven't done studies in brain. Actually, I did computer science
and one of the classes that I fall was psychology.
So I did have one credit on psychology.
So I know all the experiments but they did with monkeys and
stuff, but I'm not an expert there.
So I don't know what makes in particular individual more in
tune to be solving technical problems versus being
extroverted. Like what makes somebody
introverted versus extroverted. I don't know.
But there are systemic things here like Like, I remember that
when I went to college, and if I look at hard skills and soft
skills. We're talking about soft skills.
Now, I think the name of this classification, hard and soft is
already a value judgment that we somehow a tribute to these set
of skills. Like the hard skills.
You're proud of. I know Java.
I know databases. I know Cloud.
Those are hard skills. Apparently, their heart to
achieve and the other ones are soft.
I think the name should be reversed.
Talking with people. This actually hard learning
about programming languages or databases is actually easy and
soft because it's much more predictable as Engineers.
If you know one language is very easy to learn the Lex language.
That's much more difficult to with people, because everybody's
different developing empathy is really difficult, skill for
engineers to get. So that's the systemic approach.
I think when I went to college about 90% of my classes were
hard skills. So technical skills and maybe
10% were Soft skills but not even focus.
So I didn't get a class in how to collaborate in a team how to
make shared decisions how to run a meeting.
Those kinds of key skills that make you more successful in life
and in engineering, I was never taught.
So you're supposed to pick them up.
You have to be very lucky to be in an environment where your
environment actually helps you to learn all these kinds of
skills after you're already hired.
Basically some companies have really good mentoring
environments. Internal training and aside from
that, from a personal observation Engineers are less
interested. Talking to other people.
They quote unquote hate meetings.
They don't like the present. It's like they get nerve-racking
nervous. If they have to present about
their work, even in their own team.
I've really tried to discover what that is.
So what I've done is just give a list of all those skills that I
think are key and show how easy it is to to learn these skills
are learnable skills. We often think as Engineers that
somebody is just a good presenter or they have social
skills, or they have Charisma or they're a natural leader.
Nobody's a natural leader. Everybody can learn.
This is a skill and you can become a better presenter by
practicing by using methodologies.
All these things, even though they soft skills and very hard
to learn. We think they're not so hard.
I like the way that you said that we should probably think
about Reba. Seeing the hard and the soft.
I kind of resonate that as well. Having been an engineer or my
life as well. Sometimes.
Yes, communicating is hard. Which brings us to the important
topic here. Why do you think communication
is so important for engineers? All Engineers?
Would think that. Okay.
My job is to write code and I talk to the machine.
I don't talk to people. So why do you think
communication is so important for engineers?
It's very good question. I used to work at Google, like
we said in the introduction, I was involved in a project called
tempo. Go where we wanted to figure out
how to make Engineers more productive.
Tempo is actually a tool that instruments, your desktop and it
just watches, what you're doing all the time, using machine
learning. We then try to figure out how
productive you were and we try to correlate that to whether you
were happy of that. So, we actually asked, literally
the question randomly, the pop-up shows up, how happy are
you right now? We just ask the question and you
get a star 125, right? If you have enough data at some
point. Stock correlating using machine
learning, which is great for this.
You can start correlating situations that make engineer's,
unhappy versus situations that make them happy.
One of the things that we figured out, was that deep work
like long blocks of uninterrupted studying time on
the problem and solving it is what makes engineer's happy.
I mean, they voted more happy when they were in this Zone
phase or in the concentration phase.
We also tried cameras. So if you allow And if you are
an engineer at Google, doing this research, that Google does
your more tempting to do this by turning on your camera all day,
and you can do analysis of facial expressions.
And you can actually see if somebody is happy or not.
So then you have a fine-grained signal to see.
What are they doing right now? Like how many times did they
switch between tools? And we started finding out that
context. Switching is very expensive and
they hurt your productivity. So these are all like useful
information. To solve our problem, like what
makes them more productive but a side effect from that was that
we also measured. What are you doing right now?
And classify the things that you were doing, like, sometimes you
go to email and they spend some time, there you go to chat and
then you go to the IDE type, some things and you do builds.
And then if you do a measurement of how much time do you actually
spend coding? It's about thirty percent of
your time or the average engineer that had this tool,
turn on. So what do you do in the rest of
the time? The other 70% And that's all
communication that is all interacting with other
Engineers. This is all has to do with
making decisions together, planning synchronizing, our
work, increasing the quality of the code that we delivered as a
team as a organization. It's about learning what is
important for our organization right now.
So a lot of that has nothing to do with coding.
But more about why are we building the code or our are we
doing this certain process? So that is one.
Interesting fact. I think thirty percent of your
time is coding and you better be good at the other 70%.
Because if you get twice as good in the communication part, you
have a lot more opportunity for growing your impact, but I've
seen to is that at some point, engineer's become more senior.
And when you get more senior, you tend to spend time in coding
even less, and you spend more time into mentoring other
engineers and guiding them in trying to understand the bigger
picture as a Junior engineer. You're right out of school, you
go to stand up, and to give you five tickets and your work,
these five tickets. And that's it.
You may have some questions about what is this mean?
What does this mean? How do I do that?
But you don't try to understand? Why are we building these
tickets? Your emphasis is to fix these
five tickets as quickly as possible and get the next five.
So at some point somebody has to give you these tickets and
that's what senior Engineers do. We're all on the scale of
between like Junior and very Advanced but at some point Reach
a position where most of your impact is actually measured on
how you influence other people how you show leadership like the
work leadership in itself assumes that you transfer your
experience to other people and that by delegating the work that
you would normally do yourself to others.
You can actually become much more impactful and that requires
a lot of communication to. So when you see people
transition from a more Junior role to a more senior role.
They will also become better communicators.
So in summary, if you want to grow, you need to communicate.
If you want to be productive, you want to be impactful, you
need to communicate. So I see this as you explain
when you said that the deepest encoding time and 70% is more
about communication planning coordination, and all that.
And as you get more senior, the Lesser time, it is to actually
spend time in coding. I think this is also a lot of
time. A lot of seniors growing
aspiring senior engineer struggle as well because They
thought that when they become engineer, they're supposed to do
a lot more coding work. But as they progress through
their career, the reverse is true.
The less time you spend coding and more about communication.
What's your take on all this? Of course, there are exceptions.
They're always individuals that you look at the knowledge of our
experience of a particular individual.
There is something like the T, experience at the structure red.
So you broad but then you have one specialist in which you are
really deep. Most In ears, if you ask them.
Like, I am Chris Mulligan, who are you?
And they say, I'm an Android engineer, or they say, I'm a
back-end engineer, or I write go or whatever.
This is not you, right? This is one of your deep skills.
So as I senior engineer, you start to focus more on your
horizontal skills, like your understanding of the full stack
of problems that customers have and how are we solving them?
Being able to break down problems into smaller parts?
Communicating teams? Like I said earlier, seeing the
A picture. So those skills come up
automatically. Once you get more senior, the
are many channels in which you do this communication.
I'll just give you some examples.
Here is like emails tickets chats design, Doc's, meetings
and a meeting as multi-dimensional.
You have to learn how to send invites.
It seems like a simple thing but it's not so simple.
Somebody has to take notes in a meeting.
How do you set up, Zoom? How do you set up a camera
correctly? I was talking in a meeting with
making sure that everybody's heard.
Heard, how do you get diversity? But some actually Excel and they
treat this as an opportunity to sell their brand.
That's what you see, as well as like successful Engineers.
They have a brand and they treated as such I mentioned
earlier performance reviews which are highly stressful event
for engineers because now you have suddenly have to write
about what you've done this year.
Even if you remember, how do you actually translate it into
something that other people find impressive is not?
Easy, even writing, commits code reviews.
These are all communication. I'll just share this to the
audience. Like before we had this call
Henry and I we had a few minutes before we hit record.
We actually talked about the commonalities that we had, like
our common experience. Our common history to find some
common ground so that we interact better.
Those are very subtle things that if you know to apply them,
you will come over as a better communicator and therefore get
more opportunities as an engineer.
This is ideal. Ali?
What you want, right? You're in a team and you want to
grow, not just get a better title, but you want to move to a
project. That is interesting, even inside
the company, there are opportunities.
I'll use Google against a your work on Google Cloud.
Now, you want to work on Google Maps.
How do you get that opportunity? How do you find out?
What you can do, what you can add or contribute to Maps?
How do you know, who's working there?
So, all these things are opportunities if you have the
ability to communicate, if you have the ability to Collect your
goals and execute on them. So these are all examples of why
communication skills are essential for engineers to be
happy again. This is not about making more
money or being successful or something.
My goal is just to make you happy.
I see a lot of Engineers be unhappy.
When I think a lot of that has to do with not being able to
control their environment, even articulate what they want to
have changed in this environment.
So, I think by becoming Aiming a better Communicator, you will
become also happier. So as you mentioned, all these
different channels, different mediums like emails like invite.
Even these days. We are all working remotely from
Hope and we don't necessarily actually talked a lot with
different people. So all we do is just chat.
Maybe design document, PR pull request.
Thanks for sharing all this. So now, we understand that.
Okay, actually communication is not just talking directly with
people. It's also in all these mediums
and chapters as well. So, one thing that I noticed
when you mentioned before Review and promo.
This seems to be one of the bane of software Engineers.
How do you actually sell yourself?
So to speak in order to get a good promotion or good
performance review? So maybe you can share a little
bit tips here. How should an engineer's
actually communicate their contribution, their performance
in order to get good performance review.
I've struggled with that. I've been a manager.
I've seen people struggle with this.
I think by far the most detrimental skill that Engineers
have in In general to hurt their own performance review and promo
is the scale of procrastination. We know we have to do this and
we don't like doing this. So what we do is we look at it.
Oh, this is so hard. I'll do this tomorrow.
When is the deadline deadline is Friday?
Oh, okay. It's Tuesday.
I still have four days. Okay.
Before you know, it's Friday, the fact that we have to give
deadlines for these kinds of documents is already an
indicator that procrastination is a challenge.
So don't do that. You have months to About your
contributions. So keep a document.
What I always did is I had a live document in which I
collected my contributions, and I wrote it almost like in an
advertisement about myself. So if you treat yourself as a
brand or a product and you want to get other people interested
in your brand if you have to sell it.
So you have to tell stories. So how do you tell stories?
There are patterns there? Everybody has interviewed as an
engineer and that two kinds of interviews.
Like one of the technical Bones, and then, they are other one,
the behavioral interviews and they often go like, can you give
me an example of a situation where you had a conflict with
your manager and how to get resolved?
And that's things like that these hard ones, but it's
actually very easy. And there are two, well, known
patterns for telling this story, one is called Sao and the other
one is star. STAAR Sao is situation action
outcome and star is situation title action result.
So I'll look at Because it's a little bit more detailed then
Sao. So situation.
As you describe the problem, basically, the environment like
I came in, we are losing 30% of our customers because the tool
is always down whatever. So that's the situation I come
in. My title is a sari or another
engineer. So you define what your role is
in this situation, then you describe what your action is.
So you did a full analysis of the problem.
You set up meetings with stakeholders.
You generated 12. Of tickets.
We got a new build and the result now is that we're only
losing 10% of the customers. Something like this.
You focus on the situation. What your role was in this.
The actions that you did that led to this awesome result.
And that result could be you ship something, but it can also
be something vague especially if you become What's called the
leader. You're focusing Less on shipping
code. So your result will not be
shipped, 30 dips, or something like this.
But it will be more like translatable to business
results. So, you will have metrics that
have to do with improving the quality of the products that we
sell, or a number of them are Revenue.
I think most Engineers are far away from having an ability to
express their impact on Revenue, but you can find
business-oriented like the number of bugs that customers
report and as a result of my efforts that has come down.
So this indicates that you care, not.
Just about writing code. But you care about.
Why are we writing the code? And you have sort of the bigger
picture in mind? Let's hit that Engineers like to
solve problems. But if we can't articulate, what
the problem is and how we solved it.
Then that makes it harder for us to make a recognition.
So focus on that. Don't procrastinate.
Keep alive document. It's a lot easier to write down.
Once you've done the thing, the next day or the next week, 12
months from now, you're not going to remember.
You're going to forget about this crucial detail and add
links. So people like Like seeing
links. So if you mention like you wrote
a design, doc, have a link to that.
If you have 12, diffs that went into this solution, just linked
them all in there and especially for promotion.
This is also key at Google, for instance, when it's time to get
promoted, your manager will not tell you.
This is not your manager. Coming to you and saying, I
think you need to be promoted because you're so awesome.
No, it's the engineer themselves.
So they have to identify for themselves.
That they've been acting at a level.
Just above their current pay great or their current title.
They've been doing the expectations for these levels
in. These are all documented so you
can look them up and then you say like I want to get promoted
and how you prove it. You're right 8 promo document.
So the promo document is a really interesting exercise.
I've been on both sides like I've written my own promo docs
and I've been in promo committees.
Your motivation is different. If you want to get promoted, you
have to convince the committee. I've seen the famous.
Seems like people have written a thousand pages of information
about why they think they should get promoted and this is really
taxing on the persons that have to evaluate this because how can
you read 1000 pages? So the skill of being able to
pick out your individual contributions and the impact you
made on the company and I keep it simple and condensed.
So, do not procrastinate use the patterns like star and then try
and keep it short. You will see that if you Keep it
short, emphasize the impact that you made people will actually
read your document and understand better what you've
done. If you just give them a wall of
text and I'm going to read everything.
If you write a design doc and you want other Engineers to
evaluate your opinions and solutions for your decisions
were certain technology. They also not going to read it,
if it's 50 pages, they have better things to do.
So, if you give them five pages, yeah, you have a chance of the
actually read it. So finding out what words you
can remove. That's it's a key communication
technique as well. So as you are explaining about
this condensing things, I was imagining as well.
You have a big chunk of code that you re fact the into
smaller and smaller, maybe more functions, so that the code base
actually, the written one class becomes less, and less a.
I'm thinking it in the sense of, you know, for engineers to think
about this, refractory your contribution, your impact in
such a way that actually, when people see it, it's a short
condensed version rather than the bigger one.
I love that metaphor. Yes, and if we use other,
Quality metrics in code as well. You don't write a function that
is 1000 lines. We know this, it's not going to
get through code review. So you break it up in smaller
functions, you give the meaningful names.
And if you know this as an engineer you write code, you can
do this with Doc's as well. Break up your code, into smaller
paragraph at titles. Those are like the equivalence
of writing small functions. So then people can decide
whether they want to read the individual function or Not.
So, reading and writing are so closely connected.
So, I like that metaphor that you mentioned.
Yes, coding and writing docks are very similar.
You write clean code. That is readable for other
people. The same thing, you have to
focus on writing documentation. You have to grow your vocabulary
because often one word can replace three others.
You have to worry about grammar. How do I break up a long
sentence? What is passive voice?
All these kinds of attributes of writing text.
The soft skill comes back here. We don't invest in this
engineer's. We actually should as much.
As we invest in understanding and quiet on the difference
between a for Loop and a list comprehension.
We know and we can argue why one is much better than the other
one. Can we do the same about English
language? And if you notice then yeah, you
become an expert. If you notice difference, when
did use list comprehension went to use a for Loop?
It becomes automatic, right? We start forgetting that.
We actually had to learn this skill and now it becomes an
intuition. That's the nice thing about
communication as well. Your investment will at some
point. And turn into intuition.
Just an example here is I used to say a lot.
I still do it when I speak I've learned and I taught myself to
not say up, but just say a pause in the beginning that took a
long time, but now it's automatic and it becomes an
intuition. So these things are all
learnable and every engineer picks them up, one picks them up
faster than the other. But like coding and like the
investment that we put into making our Clean and refactoring
it making a testable as they apply to go.
They also apply to communication.
So you have also another thing while we're speaking about this,
there seems to be some Engineers who are actually good at selling
themselves. So to speak like good
communication skills. So what do you think those
things that make these type of Engineers actually more
impactful than the others? Yeah, but I mentioned the
research done at Google for getting more insight into what
makes an engineer productive. They also did research into
understanding what makes certain people more productive than
others or more impactful. So what is a highly successful
individual at Google? What are the attributes?
And if you analyze their communication Network, you can
actually do at Google because you have access to all the
metadata there, anonymized and all.
But you can actually understand how they interact with other
people through all these channels that I mentioned
earlier. There are breadcrumbs for each
interaction, every email, every meeting, every Jap.
And then if you put that, All in one big graph.
And then you look at this individual, the successful
person. They look like what is called, a
super node there. The one in the middle, and
everything connects to them. You can see, sort of islands.
There's a little team in the top, right?
This is like five or six people that work on a certain tool and
then in the bottom left, there's another team and they don't
connect with each other. But they connect through this
person. So you can see, this is the
typical design interview that you do when you go with the A
company they say like build me Twitter, you start drawing boxes
and they said, well isn't this a bottleneck?
So, InDesign interviews, these bottlenecks are a No-No you want
to avoid them in your designs of your software, but in real life,
these bottlenecks, if they're people they're actually the most
successful ones because they monopolize this information.
So that's one observation. So just by communicating a lot
by having a big Network and I mean that literally not The
Social Network. Kind of network.
If you have a big network of interaction, your graph is big,
the chances are that information flows through you is higher, and
that you control the destiny of individual teams, which is put
this very dramatically here, but you can filter information and
share it with others to make it very effective.
Very successful people know how to do this intuitively, but they
learned, this is a skill again. So you have to figure out, you
have to develop empathy. You have to understand.
We are talking. To like we do with networks.
You have a protocol and you get in a Json record and you have to
transform it to protobuf. You filter out certain things
you extract other things. You get some other information
from a third source and you enrich the data.
And then you generate a new packet.
This is what successful communicators do as well.
So this is not a metaphor from our common background here, but
I've seen two is very successful people.
They treat other people like an audience and I don't mean that
like, they're an influencer on YouTube or something.
But what I mean? That is the aim to influence
other people in a profound way. So rather than just educating
them. This is what our product can do.
And here are all the features, whatever, they try to inspire
other people to use their product.
Instead of motivating them to do something.
They fire them up. These are like, different levels
of Engagement that you try to create with your audience and
instead of influencing, which is, that's what we think.
If you're a leader, your influence others now know, your
goal has to be to to change lives.
How do you actually make people feel better just by being there?
And how do you do that? So, there are some takes trips.
You can use, like, how do I get to the stage?
How do you build Charisma? L.
Do I make people like me? Like, when I go to a party, I
just want to sit on the edge. The word mole flower is
invented. For this.
Most Engineers are Wallflowers. They don't want to stand in the
middle because then you get uncomfortable there.
But if you do communicate, I develop five rules that you can
apply that. I've seen a lot.
Of successful Engineers use. So the first one is facts.
Your communication should be based on facts, not on feelings,
not on assumptions. If you meet your director and
you have to scrape the idea to use a new database or some new
API to go to the direct and you say, I think we should use this
and he says, like why? And now you have to explain why.
Right? So our transaction rate will go
up by 200% and this is a great thing because it will lower our
costs, and blah, blah blah. Oh, yeah, those are great facts,
so Now your decision-making is based on knowledge, not on
feelings. So try and sprinkle in your
facts in your decision-making. So don't say, I think, but say
because of these numbers, we should do this.
So that takes me to the second point, which conviction, so
never come over as somebody who doesn't know.
But use the facts that you obtained in your previous phase
and use them to change your language, just your posture, the
way you communicate with other people and you're The expert
just assumed that. And how do you know?
Because you research that, right?
You looked at all the Alternatives and this is the
best alternative and therefore we do this, just sign here.
This is how you structure a design document as well.
So if you write a design document, that explains to the
rest of the organization, why we should build something you have
to tell them. And they have to sign off on
this and approve it. What technologies will go into
the system? And what alternatives are there
and why have we chosen for this one?
I do sometimes, this is built forces by.
There's an open-source technology that almost does what
we want. But of course, it will not work
for our environment. So we have to build ourselves or
there's an internal system. That, like I said, earlier, only
as Json. We need protobuf, so we can use
it. So there's some technical
reasons why you will discard one alternative and choose for the
other. But you have to be showing
conviction and you can only do this if you've actually looked
at the Alternatives and you know, which one to choose.
So make sure Sure, that you become an expert and then
radiated expertise to others. That doesn't mean you have to
become arrogant. I know I really good, right?
So we have to do this, but you translate your conviction to
others by giving the reasoning behind us and that takes us to
transparency. So transparency is about showing
other people. What your decision making
Matrix, looks like as Engineers. We tend to be uncertain in this,
right. It's not easy showing yourself
to be the expert because Is home and I don't know this other
people have way smarter than me. I want to make the document,
perfect before I share it. That's what a lot of Engineers
told me, like, when I said, I haven't you shared the document
yet. You're working on this for two
three weeks now. Yeah, it isn't done yet.
Yeah, this is not how we develop software.
We have an agile approach, right?
We have a running system and we incrementally make it better.
So, treat your documents in the same way, make your documents
transparent and invite criticism as soon as you can.
So ask other people to give their feedback on one of the
decisions that you have there. If it's like on a data storage
topic, you reach out to an individual who has the expertise
on that. And you say, like, am I making
the right decision here? If it's about observability
aspects, you add an SRE in say, like, I'm planning to use this,
in this technology to get a daily dashboard.
Will that work? So you very quickly, open up
your analysis and you're discovering things to others.
You will discover that collaboration.
There becomes much more effective and this comes back to
Performance and promo again, like one of the things that we
do in promo projects is we look at all your dips, of course, but
especially as a senior engineer, you're expected to have written
some design Doc's, that describe your contribution.
How do you get started with this as a junior engineer?
What we see often is that Engineers think that to get
promoted, you have to write the design doc, like it has to be
your work, but that's not how it works.
Really. What the committee is looking
for, is your ability to communicate, your ability to
collaborate to engage other people in the decision making
and to find mistakes quickly. Because if you find mistakes
late, they're extremely expensive to fix.
We notice in software, give a bug comes in from a customer.
This is really expensive. So, this is why we do testing,
right? We don't do this enough with
documents. So, if you write a design
document, aim for collaboration work with other people, don't
just put your own name. On top, put five people on top
because if you now have four, other people writing this doc,
you only have to spend 20% of it and then you can spend the other
80% on for more docks. And now, you got the promo time
and suddenly, you have five documents that your name is on
top. So this allows you to not just
learn how other people work, you grow your network.
It is actually an indicator of your being more senior and
you're not fighting without an engineer's.
You're not trying to win this game of getting.
Mission, but you aim for making the system better.
So consistency is then the fourth area.
So we talked about facts conviction.
Transparency consistency is all about keeping your message,
simple. Because if you make it simple,
then it's a lot easier to say it.
Right? The second time.
This comes back in like we selling promo documents but also
in design documents in emails, even in chats, and then the
fifth direction, if you want to be a successful Communicator, as
an engineer is to show people. A positive direction, that's not
easy, but we often focus on the problems as Engineers, write,
all the possible ways that this can go wrong.
If you look at somebody who is like a product manager, and they
talked to customers. They have a much more positive
outlook on life. They know how to articulate
goals into something. That is a better place.
So as Engineers, we should also focus on that because people are
really inspired. If you tell them something
positive, if you just tell them the negative things, if You're
in meetings and you're always explaining why that won't work
at some point. People start hating you, it's
not because they hate you but they want to hear something
nice, something positive. So if you focus on that first be
optimistic, I've always been very optimistic in my career in
my life problems. Are there.
Like I always say a problem is an opportunity a problem for
one. It's an opportunity for another.
If you look at the problems than this is an opportunity for you
to show how your impact will actually turn this problem into
something positive. This, so keep that mind set in
place. So facts, conviction,
transparency, consistency, and a positive outlook on life will
make Engineers much better. Communicators.
Thanks for sharing this sort of framework to think of how you
can make yourself becoming more impactful.
So I think for all Engineers out there, think do make sure that
you understand these tips. So, speaking of sharing about
our impact, I think, just what you mentioned as you described
earlier, is that some Engineers think that, oh my Impact.
My contribution. I think it's little than the
others. Some other people are smarter.
They did all this great stuff. While I just did this small
module, small product or whatever.
That is, which brings back to the topic of impostor syndrome
and you wrote a very good blog post about it, which I read a
few weeks back. So maybe, can you share a little
bit about what is imposter syndrome?
Why a lot of Engineers actually suffer from this just to start
off with, I will admit that. I'm an imposter.
What that means. If you look up the definition on
Wikipedia, I'll read it up here. Imposter syndrome is a
psychological pattern in which an individual has doubts about
their own accomplishments. So this means that you have a
persistent internalised fear of being exposed as a fraud as we
call it. I had that when I was hired at
Google, of course, I spend a lot of time interviewing and
whatever and guys spend months in exercising, the interviews.
When I got hired, I was still like, I got the offer.
I was like, wow, it's like you win the Lottery or something and
then you go to introduction and you meet all these other people.
One of them is an Olympic Athlete running marathons for
Sweden, and the other person has done three companies already.
And you start seeing all the other individuals who are much
more smarter than you are. They have achieved so much more.
It just waiting for them to find out that you're just fake and
you're going to get fired. So this is natural.
I think this happens at every level.
It's not just Junior Engineers or This will Engineers the think
that successful Engineers don't have this kind of feeling, they
also have it all your Heroes have their own doubts.
Everybody is human often what people with impostor Syndrome
have is they attribute their success to luck?
Like I said, I was hired at Google and I was like winning
the lottery. I was lucky must have been
lucky. Now, of course, you have to have
luck. You have to be in the right
place in the right time. You have to have met this one
person that gives you the lead to another Opportunity.
But a lot of that is actually something you can control.
You should avoid feeling found out soon and something like
this. There's an interesting anecdote
is that they did research at Google.
They asked NPS scores. So in the last three months, how
did you like your manager like 125?
How did you like the work you're doing it?
And at some point, they asked in the last six months that you
feel like you were on the fear of being fired by Google, we're
talking about engineers at Google.
These are the top of the crop, right?
Google gets like 2 million resumes a year and the funnel is
so narrow that at the end you have the best of the best 70% of
people that filled in the survey were afraid of getting fired and
less six months. So this means that 70% of
extremely successful engineers at Google have impostor
syndrome. So if they have imposter
syndrome, everybody can have it, right?
We are all imposters and that's normal.
This is okay. This is a great cartoon or
diagram that I can share about this.
As a podcast, I can explain what it looks like.
It's Erin sign. So, looking to notes.
It has a diagram with three areas, pie chart, with three
areas. And the first one says, people
who get impostor syndrome. So it's about a third of the
dining room. And then there's the second
area. Other people who get imposter
syndrome. And then the third area is,
literally everyone else who also gets imposter seen.
This is a very funny way of showing that it's normal.
Everybody gets it. Thanks for sharing all these
thought process. Why we Feel this like a big
challenge for us, especially as Engineers for me.
I'm also imposters, especially I went to Google that time as
well. I was also feeling the same
thing. Okay, really?
They want to hire me. And after you join, you see all
these smart people around you. Then it will say, okay, really?
I am I qualified enough to be at this place.
So all these things, I think what you mentioned is ringing
true to all people, right? We all suffer at one point in
time that we think we are not enough and especially in
technology. That's so many Technologies out
there. You wouldn't be possible to
understand everything. Oh, so there will be areas and
parts where you are not expert in something.
And that's probably sometimes we feel that.
Oh, we are not an expert of everything.
So we suffer from this. So what can we do actually about
this feeling? How can we overcome this?
Because it's such a challenge for many people, especially
intact. All right, so we talked about,
you're not the only one we mentioned the 70% of googlers,
you Henry myself. Chris.
We acknowledge that were Impostors.
So you're not alone. We all have this at some point
in our lives, every engineer gets this.
So This already helps the second way of dealing with it is fake
it until you make it. That's a nice phrase, but it
actually takes care of imposter syndrome.
So if you're uncertain, what you're doing, just do it for a
while and you will learn things, you will get better at it.
You will just keep doing it and at some point, you're there,
right? So you reached that point that
you thought you would never reach because you've going to
find out, you should just view everything in life.
We're just on a journey. This is a big stage.
We all play our roles and You constantly switch between roles
at the same time, or in different phases of your life.
And at every point in time. You just playing a role.
Sometimes you're a parent. Sometimes you're an employee at
a company. Sometimes, you're in the store,
trying to get a discount, and these are all different roles
that you play each one. You get better at some, you
don't spend time in. I mentioned earlier that our
goal in life, should be, to be happy to get the best out of
ourselves that we can get. It's not about winning.
Not about achieving the same thing that other person, that is
much smarter than you actually gets and you will never get
there. This is detrimental to our.
You have to think about it. That's the famous Dutch football
player and Coach Yeo won cuff. He is well known for his
down-to-earth quotes when he talks about the game of
football, but there's one that I really love, so he said like to
be happy, do things that make you happy.
This is what we put on a tile in the Nautilus.
You have to understand what makes you happy if there.
Are things that do not make you happy, change your environment,
just be fine. Be thankful for the luck that
falls upon you. We had the luck of being going
through the system, be happy. I remember like walking around
during my orientation in the building, which I spent so much
time getting there. I was.
So happy just walking around there and enjoying and talking
to other people and learning from these individuals that have
achieved so much more than I thought, learning from how they
got there. So plan to become an Olympic
athletes and what they had to sacrifice for this and now they
dealt with that. There's a lot of things to be
learned, and if you turn it around, then all of a sudden,
you become somebody who grows in this environment, I think also
very closely related to imposter syndrome is being stressed out,
imposter syndrome can lead us to become inferior and therefore,
creates stress. Now, I always say, happy
Engineers are productive engineer, but the corollary is
that unhappy ones are Rest, so, focus on the things that make
you happy, we all want to solve technical problems.
We have meaningless meetings. So can you find a way to get out
of these meetings or make them more meaningful?
There's two approaches to this. Make sure that every meeting has
a calendar and agenda. Somebody takes notes criticized
while you're there, it is repeating meeting and it's,
especially some so take control of your environment.
If you're stressed out. It usually means that you feel
out of control. You don't have to Economy to
make decisions that eventually will work down on you and you
become unhappy. You mentioned overwhelming
complexity in the beginning. I think that's a great Point.
All of this stress doesn't have to be internalized, right?
Doesn't have to come from. You imposter syndrome, might be
a source of internal stress like feeling incapable of doing the
same thing that others do. But there are a lot of things
that make a stress from the outside just to complexity of
today's industry. Nobody can know all the tools
out there. But if you think that you
should, then it overwhelms, you, I did a count at some point, a
tuber to see how many tools did we have to develop software to
go the entire workflow from the beginning, from idealization to
capturing requirements, to writing a design, doc to writing
the code and deploying and monitoring and Incident
Management, all of this, and I gave up when I reached 100.
So there were, at least 100 tools that I had to learn to be
effective in an Workflow and every tool is different.
So this is enormous impact on your brain, like on your
ability, to take pause and reflect on this and learn and
remove the stress. So be careful to not.
Let the external complexity of the system overwhelm you too
much. So protect yourself from that
kind of stress because repositories now have billions
of lines of code. Like, how do you start?
I remember being in college and the way I learned programming
was By reading the source to Unix the Unix operating system
back to front like everything in the operating system today.
That is almost impossible. You're on a team and Google and
you say, like, I'm going to read all the source code that Google
is this like impossible. So how do you get started?
So we need better tools for that?
The industry is always innovating.
Can't make an impact on less. You introduce a new solution.
What happens to all the other old Solutions, somebody still
needs to maintain them? Don't try to keep up all the
time, reaching a state of flow, is also very difficult for
engineers. Like, I mentioned the
interruptions that you get the context switches.
So this is up to you, to make sure that you actually have that
ability to do deep work control over your own calendar.
Some companies generate days off like uber we have Thursday, no
meeting day. So that's nice.
So then, you know, at least a Thursday, I can do work.
There are still some especially if you become a senior engineer,
you get still pulled into really important meetings.
That you have to come to so be in control of your own agenda.
Your own Calendar, create blocks in their figure out.
What's the time when you're most happy to do deep work.
Like I mentioned that tool that we had at Google Tempo.
There are commercial tools. This tool called rescue time.
I have no affiliation with them, but it tracks all you do.
So you have to be comfortable, sharing, all that private data.
It gives you a deep insight into how you spend your That's useful
information for discovering. When do I do deep work?
Is it in the morning? Is that the best time or the
afternoon us being remote more and more?
Now our interactions with other people also become time zone
independent, but sort of creeping into this complexity
thing and causing stress. That I know if you work in
Europe is unavoidable, having meetings in the evening, to talk
to the people and the u.s. You want to get ahead in life.
Life. You want to make a career.
You have to talk to these people and you can only do that when
they're awake. They're not going to wake up at
5:00 a.m. In the morning.
They expect you to have a meeting at 10:00 p.m.
Or 11 p.m. So be careful how you get sucked
into that kind of communication models where this is going to
cause stress. So be in control to timeboxing
of the things that caused your stress for that.
You have to course, first develop some emotional skills,
like self-awareness. You have to understand.
This is making me unhappy in. This is not Atul asking you are
you right now happy. It's actually a trigger for you
to be more self-aware by which you need a tool for this.
You can tell if you're happy or not, if you're grumpy, but maybe
you don't have the processor running yet.
So you need to load a programming.
The background that monitors yourself from time to time.
Thanks for sharing all these, as I listen to you explaining all
this. I think I could relate to some
of the experience that you mentioned.
So we are all in this industry, but we are not alone as well.
So increasing our self-awareness.
Has of this issue knowing how or what makes us happy.
And I like the quote from Johan Cruyff to be happy, you have to
do, what makes you happy. And this is such a fascinating
conversation. I feel that we could go on and
on and on. But due to time, probably is not
possible. But for people who are
interested to learn more about all these that you explain where
can they find it? So I have a website, which is my
name, Chris laughs right.com., There's a link to my book, which
I recommend you read because there's a lot of thoughts that I
developed over time and that we just talked about right now.
Should in that, there's also a link to my other source of
information that the top has biography.
And there you can find the blocks that I've written like
the one you just mentioned on LinkedIn.
For instance. You can find it there.
So, that is, if you want to learn from me, we haven't talked
about burnout yet, but that's a phase where if you cannot escape
the stress and it's like consistently causing you to deal
with that. You may come into a situation,
what we call a burnout. So that is, chronic stress and
burnout signal. So you might discover for
yourself. Now that you're overly cynical
at work that you're less inspired to contribute.
Maybe you missing your old passion, you wake up in the
morning. You say?
Oh man, I got to get back to work.
I luckily never had that. Like for me work is like my
hobby and I get paid for it. I'm very lucky.
Maybe you have frequent headaches or stomachaches.
You think that your overall work performance is going down or
lacking. You find it harder to produce
creative things. It's just harder to come up with
good ideas to solve these box, so I know.
Something that took like minutes.
Now, takes you an hour. All these things are red flags
for you. Being on the spectrum of having
a burnout. If you find yourself having that
then act immediately don't wait talk to other people that can
help you talk to a professional. Your company often has a way to
talk to other people and deal with this speak.
Get a mentor inside your company or external.
So if all of this way, You up and saying, yeah, I recognize a
lot of things in here and all this stress.
Go talk to somebody else. That's very important.
So don't just read my book, but reach out to other people.
Just talking to other people is actually stress-reducing as
well. If you want to do that, I
recommend you take a walk with the other person.
I've seen that being very successful at some companies.
We're about, and I have a meeting where you sit down, you
take a walk because that inspires your frontal, lobe to
control your emotions and lower your stress.
So, all these things help, so, thanks for covering the burnout.
So I think this is also another topic for a lot of Engineers.
They feel burn are just turning cold out of code.
Probably sometimes not getting the recognition that they think
they should have. So, I think this is also one
thing for all of us to think about.
So, thanks for sharing all the resources.
I'll make sure to put it in the show notes.
So Chris one last question from me, which is like a custom in
this show, which is for the guest to actually share their
three, technical leadership wisdom.
So would you be able to share your so that we all can learn?
From you definitely. I think number one will not
surprise you and the audience is a productive.
Engineer is a happy engineer. If you want to become productive
become happy, this is not a causal relationship, like not
every happy engineer is a productive one, but it is
definitely a requirement. So a productive, Engineers,
happy engineer. That's number one.
Number two is Engineers, should communicate with facts and
conviction. I gave 25 things like facts from
fiction. I gave three more, but if you
just figure out the first two, if you But those to make all
your communication based on percentages or numbers or
Alternatives that you evaluate it, and you're making the right
decision. So use facts and Biddy expert.
And then the third one is we talked about stress.
We talked about impostor syndrome.
So what is this successful engineer?
So, that's number three. Success is about achieving the
best we can be. It's not about winning.
So those three are productive, engineer, happy engineer
engineer, should communicate with facts and conviction and
success is about achieving the Best we can be not about winning
right now. I sound really wise and just
found these things on the internet, but, no, I think.
Number one. I actually came up with, so I
really care about that one. Really thankful for sharing all
these. I like, the last one success is
about achieving the best. We all can be, it's not about
winning trophy or winning the promo winning something.
So, thanks for reminding that for us.
So Chris has been a very wonderful conversation.
I'm really glad that we have this conversation.
So thanks again for being on the show really, really happy, too.
Have you sharing all this wisdom for all of us actually to learn
from. So make the engineers become
more productive and hence also happy at the same time.
Thank you, Henry. It was a pleasure.
Thank you for listening to this episode and for staying right
till the end. If you highly enjoyed, please
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 really, really helps me a lot in order to grow these podcasts
better. You can also find the full show
notes of this conversation on the episode page at technology.
No, the death website. Including the full transcript
interesting quotes, and links to the resources and mentions from
the conversation. And lastly make sure to
subscribe to the show's mailing list on technology.
No, the deaf to get notified for any future episodes.
Stay tuned for the next technique Journal episode.
And until then. Goodbye.