#48 - Communicate to Become a Happy & Productive Engineer - Chris Laffra

Episode Introduction [00:01:09]

Henry Suryawirawan: [00:01:09] Hello, everyone. Welcome back to another episode of the Tech Lead Journal podcast. This is your host, Henry Suryawirawan, and it’s really great to be back here again with another great conversation with my amazing guest. Thank you for spending your time with me today, listening to this episode. If you haven’t, please subscribe to Tech Lead 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 techleadjournal.dev/patron and help me to continue producing great content every week.

For today’s episode, I’m very happy to share my conversation with Chris Laffra. Chris is an experienced software engineer and has been a technical manager, advisor, and staff software engineer with companies such as IBM, Bank of America, Google, Uber, and Sourcegraph. 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 hard 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 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 engineer’s typical source of unhappiness, which are 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 leaving 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. So let’s get this episode started right after our sponsor message.

Introduction [00:04:19]

Henry Suryawirawan: [00:04:19] Hey, everyone. Welcome to another new episode of the Tech Lead Journal. So today I’m very happy to meet someone called Chris Laffra. Chris is an 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 Sourcegraph. 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 to the show.

Chris Laffra: [00:04:52] Hi Henry. Thanks for having me.

Career Journey [00:04:53]

Henry Suryawirawan: [00:04:54] 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.

Chris Laffra: [00:05:03] Yeah, sure. I’m originally Dutch. I grew up in the Netherlands. Did my computer science degree there and a PhD. I lived about half of my life in the US. I’ve worked at technical companies like you mentioned, IBM. I’ve worked in Wall Street, in finance, which is not so different from typical tech companies, actually. And I worked at companies like Google and Uber. And I’m a technical advisor at Sourcegraph 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, IDEs. 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. Where are the opportunities for optimization? That has 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? How we’re recognized? How they become successful or productive?

I personally haven’t discovered this 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 captured that in a book. I also teach courses on this. My main goal here is to make other engineers happy. That has 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.

“Communication for Engineers” Book [00:06:37]

Henry Suryawirawan: [00:06:37] Thanks for sharing your story. I think you have a very great goal, I would say, making engineers happy. While 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, I acknowledge 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?

Chris Laffra: [00:07:08] Yeah, that’s exactly the observation I made myself. I’ve been a technical contributor, an individual contributor, and a manager, a team lead, TLM. So I’ve played the different roles 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 overgeneralizing 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 other engineers on using spaces versus tab. These are the kinds of things that excite us. We get our energy from writing code and throw it through a 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 if eventually you find it, and then you say, “Oh, this is awesome, right?” So this is what drives us.

But probably the most obvious time when communication comes 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, do it. Write about it, write a blog, 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 have 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. It’s 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. That’s basically 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.

Why Engineers Have Difficulty Communicating [00:09:51]

Henry Suryawirawan: [00:09:51] I understand that you’re 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 explained all of this, right? You mentioned that somehow engineers have a challenge to actually communicate well. Why do you think that is the case? Because lots of engineers are smart. We know about facts. We know about logic and all that. Why is it so difficult for them to actually communicate?

Chris Laffra: [00:10:18] So I think that it’s both systemic, and it’s individual. 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 followed was psychology. So I did have one credit on psychology. So I know all the experiments that they did with monkeys and stuff. But I’m not an expert there. So I don’t know what makes a particular individual more in tuned 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 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 attribute 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, they’re hard to achieve. And the other ones are soft.

I think the names should be reversed. Talking with people is 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, it’s very easy to learn the next language. That’s much more difficult with people because everybody’s different. Developing empathy is a 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 focused. 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 my personal observation, engineers are less interested talking to other people. They “hate meetings”. They don’t like to present. It’s like they get nerve wrecking “uh” 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 learn these skills. They’re 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’re soft skills and very hard to learn, we think, they’re not so hard.

Importance of Communication for Engineers [00:13:18]

Henry Suryawirawan: [00:13:18] I like the way that you said that we should probably think about reversing the hard and the soft. I kind of resonate (with) that as well. Having been an engineer all 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?

Chris Laffra: [00:13:44] Yep. It’s a very good question. I used to work at Google, like we said in the introduction. I was involved in a project called Tempo, 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 tried to figure out how productive you were, and we tried to correlate that to whether you were happy or not. So we actually asked literally the question, randomly the pop-up shows up, “How happy are you right now?” We just asked the question, and you gotta star it one to five, right? If you have enough data, at some point, you can start correlating using machine learning, which is great for this. You can start correlating situations that make engineers 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 engineers 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’re allowed, and if you’re an engineer at Google doing this research that Google does, you’re more tempting to do this by turning on your camera all day, and you can do analysis of facial expressions, and you could actually see if somebody is happy or not. So then you have a fine-grain 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, tried to solve a 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 then you spend some time there, you go to chat, and then you go to your IDE, type some things, and then you do builds. And then if you do a measurement of how much time do you actually spend coding, it’s about 30% of your time for the average engineer that had this tool turned 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 deliver as a team, as an 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 how are we doing this certain process?

So that is one interesting fact, I think. 30% 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. What I’ve seen too is that at some point engineers 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 standup, and they give you five tickets. And you work these five tickets and that’s it. You may have some questions about what does 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 to 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, you reach a position where most of your impact is actually measured on how you influence other people. How you show leadership. Like the word 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 too. 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.

Henry Suryawirawan: [00:18:01] So I see this, as you explained, when you said that 30% coding 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 engineers struggle as well, because they thought that when they become engineer, they are supposed to do a lot more coding work. But as they progress throughout their career, the reverse is true. The less time you spend in coding and more about communication. What’s your take on all this?

Chris Laffra: [00:18:35] Yeah, of course there are exceptions. There are always individuals that if you look at the knowledge over experience of a particular individual, there is something like the T experience, a T structure, right? So you’re broad, but then you have one specialist in which you’re really deep. Most engineers, if you ask them like, “Hi, I’m Chris and who are you?” And they said, “I’m an Android engineer.” Or they say, “I’m a backend engineer”, or “I write Go”, or whatever. This is not you, right? This is one of your deep skills. So as a senior engineer, you start to focus more on your horizontal skills. Like your understanding of the full stack of the 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 bigger picture. So those skills come up automatically once you get more senior.

There are many channels in which you do this communication. I’ll just give you some examples here. It’s like emails, tickets, chats, design docs, meetings. And a meeting is multidimensional. You have to learn how to send invites. That seems like a simple thing, but it’s not so simple. Somebody has to take notes in the meeting. How do you set up Zoom? How do you set up a camera correctly? Who is talking in the meeting? Who is making sure that everybody’s 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 treat it as such. I mentioned earlier, performance reviews, which are highly stressful event for engineers. Because now you suddenly you 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? It’s 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 (how) to apply them, you will come over as a better communicator, and therefore get more opportunities as an engineer. This is ideally 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 again, say you 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 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 what they want to have changed in this environment. So I think by becoming a better communicator, you will become also happier.

Communication for Performance Review and Promotion [00:21:54]

Henry Suryawirawan: [00:21:54] So as you mentioned all these different channels, different mediums, like email, Slack, invite, even these days, we are all working remotely from home, and we don’t necessarily actually talk a lot with different people. So all we do is just chat, maybe design document PR, pull requests. Thanks for sharing all this. So now we understand that, okay, actually communication is not just talking directly to people, it’s also in all these mediums and chats as well.

So one thing that I noticed when you mentioned performance 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 a good performance review? So maybe you can share a little bit tips here. How should engineers actually communicate their contribution, their performance in order to get good performance review?

Chris Laffra: [00:22:42] 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 general to hurt their own performance review and promo is the skill 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, 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 think about your contribution. 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 product, and you want to get other people interested in your brand, 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 there are two kinds of interviews, like one of the technical ones, and then they are the 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 did you resolve 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, S T A R. SAO is Situation Action Outcome and STAR is Situation Title Action Result.

So I’ll look at STAR because it’s a little bit more detailed than SAO. So situation is 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 SRE, 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 the stakeholders. You generated 12 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, I shipped 30 diffs 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 the number of them or 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 gone 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.

I said 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 a live 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 the links. So people like seeing links. So if you mentioned, like you wrote a design doc, have a link to that. If you have 12 diffs that went into this solution, just link 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, which is above their current pay grade or their current title. They’ve been doing the expectations for these levels and 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 write a 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 ones, 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 a thousand 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, they’re not going to read everything. If you write a design doc and you want other engineers to evaluate your opinions and solutions for or decisions for certain technology, they’re 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 that they actually read it. So finding out what words you can remove, that’s a key communication technique as well.

Henry Suryawirawan: [00:28:24] So as you are explaining about this condensing things, I was imagining as well, you have a big chunk of code that you refactor into smaller and smaller, maybe more functions. So that the code base actually written in one class becomes lesser and lesser. I’m thinking it in the sense of you know, for engineers, to think about this refactoring 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.

Chris Laffra: [00:28:48] I love that metaphor. Yes. And if we use other quality metrics in code as well. You don’t write a function that is a thousand lines. We know this. It’s not going to get through code review. So you break it up in smaller functions. You give them meaningful names. And if you know this as an engineer, you write code, you can do this with docs as well. Break up your code into smaller paragraphs, add titles. Those are like the equivalent 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 docs 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 texts. The soft skill comes back here. We don’t invest in this as engineers. We actually should. As much as we invest in understanding in Python, 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 know this then yeah, you become an expert. If you know this difference, when to choose list comprehension, when 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 turn into intuition. Just an example here is I used to say “uh” a lot. I still do it when I speak. I’ve learned, and I taught myself to not say, “uh,” 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 ups. One picks them up faster than the other. But like coding and like the investment that we put into making our code clean and refactoring it, making it testable. As they apply to code, they also apply to communication.

How to Become More Impactful Engineers [00:30:58]

Henry Suryawirawan: [00:30:58] So you have also another thing, while we we were speaking about this. There seem 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?

Chris Laffra: [00:31:13] Yeah, what 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 chat. And then if you put that all in one big graph, and then you look at this individual, this successful person, they look like what is called a super node. They’re 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 a tech company, they say like, build me Twitter. You start drawing boxes and they say, “Well, isn’t this a bottleneck?” So in design interviews, these bottlenecks are a no-no. You want to avoid them in your design of your software. But in real life, these bottlenecks, if they are people, they are actually the most successful ones, because they monopolise 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. Let’s just 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 learn. This is a skill, again. So you have to figure out, you have to develop empathy. You have to understand who you’re 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.

What I’ve seen too 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 with that is they 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 the 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 you’re influencing others. No, no, no. Your goal has to be 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 tips tricks you can use. Like how do I get to that stage? How do you build charisma? How do I make people like me? Like when I go to a party, I just want to sit on the edge. The word wallflower is invented for this. Most engineers are wallflowers. They don’t want to stand in the middle because then you get, “uh, I’m 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 this great idea to use a new database, or some new API. You go to the director 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%. Now 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 is 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 assume that, and how do you know? Because you researched it, 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? So sometimes this is build versus buy. 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 has JSON, we need protobufs so we can use it. So there’re 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 that you become an expert and then radiate that expertise to others. That doesn’t mean you have to become arrogant. “I know everything is right, so we have to do this.” But you translate your conviction to others by giving them the reasoning behind this.

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. But it’s not easy showing yourself to be the expert because, “Oh, man. I don’t know, these other people are 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, “Why haven’t you shared a document yet? You’re working on this two, three weeks now.” “Yeah, it isn’t done yet.” No. 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 and you say like, “I’m planning to use this and this technology to get a daily dashboard, will that work?” So you very quickly open up your analysis and you are 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 diffs, of course, but especially as a senior engineer, you’re expected to have written some design docs that describe your contribution. How do you get started with this as a junior engineer? What we’ve seen 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 know this in software. If 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% at it, and then you can spend the other 80% on four more docs. And now you go to 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 you’re being more senior, and you’re not fighting with other engineers. You’re not trying to win this game of getting recognition, 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 said in promo documents, but also in design documents and 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, right? All the possible ways that this can go wrong. If you look at somebody who is like a product manager, and they talk to customers, they have a much more positive look 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 will start hating you. It’s not because they hate you, but they want to hear something nice and that’s 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 is an opportunity for another. If you look at the problems, then this is an opportunity for you to show how your impact will actually turn this problem into something positive. So keep that mindset in place. So facts, conviction, transparency, consistency, and a positive outlook on life will make engineers much better communicators.

Henry Suryawirawan: [00:41:33] 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, I 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.”

Impostor Syndrome [00:42:01]

Henry Suryawirawan: [00:42:01] 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 impostor syndrome? Why a lot of engineers actually suffer from this?

Chris Laffra: [00:42:15] Yes. To start off with, I will admit that I’m an impostor. What that means is if you look up the definition on Wikipedia, I’ll read it up here. Impostor syndrome is a psychological pattern in which an individual has doubts about their own accomplishments. So this means that you have a persistent, internalized fear of being exposed as a fraud, as we call it. I had that when I was hired at Google. Of course, I spent a lot of time interviewing and whatever, and I 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. You’re 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 unsuccessful engineers. They 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 that was like winning the lottery. I was lucky. Must’ve 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 in 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 one to five. How did you like the work you’re doing? And at some point they asked, in the last six months, did 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 in the last six months. So this means that 70% of extremely successful engineers at Google have impostor syndrome. So if they have impostor syndrome, everybody can have it, right? We are all impostors. And that’s normal. This is okay.

There’s a great cartoon or diagram that I can share, but this is a podcast. I can explain what it looks like. It’s ErrantScience. So look in the 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 diagram. And then there’s a second area, other people who get impostor syndrome, and then the third area is literally everyone else who also gets impostor syndrome. This is a very funny way of showing that it’s normal. Everybody gets it.

How to Deal with Impostor Syndrome [00:45:18]

Henry Suryawirawan: [00:45:18] Thanks for sharing all this thought process, why we all feel this like a big challenge for us, especially as engineers. For me, I’m also impostor. 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 you will say, okay, really? 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, there’re so many technologies out there, you wouldn’t be possible to understand everything. 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 in tech, right?

Chris Laffra: [00:46:07] So we talked about you’re not the only one. We mentioned the 70% of Googlers. You Henry, myself, Chris, we acknowledged that we’re impostors. So you’re not alone. We all have this at some point in our lives. Every engineer gets this. So knowing 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 impostor 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’re 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’re 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. It’s 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 how you’d have to think about this.

There’s a famous Dutch football player and coach, Johan Cruyff. 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 Netherlands. 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 the discipline to become an Olympic athlete, and what they had to sacrifice for this and how they dealt with that. There’s a lot of things to be learnt, 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 impostor syndrome is being stressed out. Impostor syndrome can lead us to become inferior and therefore create stress. Now, I always say happy engineers are productive engineer. But the corollary is that unhappy ones are stressed. So focus on the things that make you happy. We all want to solve technical problems. We hate meaningless meetings. So can you find a way to get out of these meetings or make them more meaningful? There’re two approaches to this. Make sure that every meeting has a calendar and agenda. Somebody takes notes and criticize why you’re there. If this is a repeating meeting, then it’s especially so. So take control of your environment. If you’re stressed out, it usually means that you feel out of control. You don’t have the autonomy 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. Impostor 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 us stress from the outside. Just the 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 account at some point at Uber, to see how many tools that we have to develop software. To go with the entire workflow from the beginning, from ideation to capturing requirements, to writing a design doc, to writing the code, and deploying and monitoring and incident management, all of these, and I gave up when I reached a hundred. So there were at least a hundred tools that I had to learn to be effective in that entire workflow. And every tool is different. So this is an enormous impact on your brain, like on your ability to take pauses and reflect on this and learn and remove the stress. So be careful. Do 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 learnt 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. If you’re on a team in Google and you say like, I’m going to read all the source code at Google. This is like impossible. So how do you get started? So we need better tools for that. Industry is always innovating. You can’t make an impact unless you introduce a new solution. But what happens to all the other old solutions? Somebody still needs to maintain them. So 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 at Uber, we have Thursday, no meeting day. So that’s nice. So then, you know at least at Thursday I can do work. There are still some exceptions, 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 there. 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 RescueTime. 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 week, and 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. That sort of creeping into this complexity thing, and causing stress that I know if you work in Europe, it’s unavoidable having meetings in the evening to talk to the people in the US.

Do you want to get ahead in 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 5:00 AM in the morning. They expect you to have a meeting at 10:00 PM or 11:00 PM. So be careful how you get sucked into that kind of communication models where this is going to cost stress. So be in control. Do time boxing of the things that cause your stress. For that you have to, of course, first develop some emotional skills, like self-awareness. You have to understand this is making me unhappy, and this is not. So a tool asking you, “Are you right now happy?” is actually a trigger for you to be more self-aware. Why would 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 program in the background that monitors yourself from time to time.

Henry Suryawirawan: [00:53:39] Thanks for sharing all these. As I listened to you explaining all these, 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 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.”

Handling Burnout [00:53:58]

Henry Suryawirawan: [00:53:58] And this is such a fascinating conversation. I feel that we could go on and on and on. But due to time probably it’s not possible. But for people who are interested to learn more about all these that you explained, where can they find it?

Chris Laffra: [00:54:10] So I have a website which is my name, ChrisLaffra.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 are captured in that. It’s also linked to my other source of information at the topmost biography. And there you can find the blogs 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 signals. So you might discover for yourself that you’re overly cynical at work, that you are less inspired to contribute. Maybe you’re missing your old passion. You wake up in the morning, and you say, “Oh man, I’ve 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 bugs, suddenly 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 or get a mentor inside your company or external. So if all of these wake 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 where rather than 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.

Henry Suryawirawan: [00:56:22] So thanks for covering the burnout. So I think this is also another topic for a lot of engineers. They feel burnout, just churning code 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.

3 Tech Lead Wisdom [00:56:40]

Henry Suryawirawan: [00:56:40] So Chris, one last question from me, which is like a custom in this show, which is for the guests to actually share their three technical leadership wisdom. So would you be able to share yours so that we all can learn from you?

Chris Laffra: [00:56:51] Definitely. And 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 engineer is happy engineer. That’s number one.

Number two is engineers should communicate with facts and conviction. I gave the five things like facts, conviction. I gave three more. But if you just figure out the first two, if you start with those, so make all your communication based on percentages or numbers or alternatives that you evaluated, then you’re making the right decision. So use facts and be the expert.

And then the third one is we talked about stress. We talked about impostor syndrome. So what is a 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. Engineers should communicate with facts and conviction, and successes about achieving the best we can be. Not about winning. Now, I sound really wise and I just found these things on the internet, but no. I think number one I actually came up with, so I really care about that a lot.

Henry Suryawirawan: [00:58:01] Really thankful for sharing all this. I like the last one. Success is about achieving the best we all can be. It’s not about winning a trophy or winning the promo, winning something. So thanks for reminding that for us. So Chris, it’s 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 to 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.

Chris Laffra: [00:58:29] Thank you, Henry. It was a pleasure.

– End –