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.