Guest: Edmond Lau, Author of The Effective Engineer
If you’re a technical person, such as an engineer or designer, then your to-do list is probably filled with product launches, bug fixes, interviewing candidates, attending meetings, answering emails, and fighting fires.
The daily grind can leave you wondering if the work that you do is actually worthwhile and makes a big impact.
While it’s easy for people to tell us to work smarter, not harder, the bulk of the work still falls on our shoulders, and it often feels like the only way to get it all done is to put in more hours!
In today’s episode of FemgineerTV, we’re going to tackle your to-do list. We’ll talk about how you can identify activities that will make a big impact for your organization, your team, and yourself, and how to feel good about deprioritizing those that don’t!
For expert guidance, I’ve invited Edmond Lau, who is the author of the new book The Effective Engineer. Edmond has worked as an engineer at big companies like Google and growth-stage startups like Ooyala, Quora, and, most recently, Quip. While he onboarded and mentored many new engineers at work, he discovered which habits, techniques, and mindsets set them up for success early on (read: huge impact in less time).
Edmond will help us identify common myths about productivity in software development that hold us back from making a big impact. We’ll also share our favorite framework for evaluating how much impact our activities and tasks actually have, using the concept of leverage.
Watch the episode and learn:
If you find yourself drowning in tasks and feel like you’re not making the kind of impact you want to make, then you’ll want to watch this episode!
After you’ve watched the video, let us know what your favorite part of the episode was in the blog comments below.
The next episode of FemgineerTV airs in July. I’ll be hosting the founders of Pop Up Archive, Anne Wootton and Bailey Smith. Subscribe to our YouTube channel to know when it’s out!
Poornima Vijayashanker is currently the founder at Femgineer, an education company that helps empower engineers, founders, and product leads to transform their ideas into tangible, high-impact products. She is also an entrepreneur-in-residence at 500 Startups, where she advises companies on product development, technical recruiting, growth, and fundraising.
Previously, she was a lecturer at Duke University’s Pratt School of Engineering, and the founding engineer at Mint.com, where she helped build, launch, and scale the product until its acquisition in 2009.
When she’s not building products or companies, she enjoys Bikram yoga, rock climbing, and running. Poornima lives in sunny Palo Alto, CA.
Poornima Vijayashanker: Welcome to the 5th episode of Femgineer TV, brought to you by Pivotal Tracker. I’m your host, Poornima Vijayashanker, the founder of Femgineer. Femgineer is an education company where we teach innovators how to build software products so they can find freedom in their careers, enrich other people’s lives, and make the tech community a lot more inclusive and flexible.
Back in Episode 2 of Femgineer TV, we had special guest, Jocelyn Goldfein, the former director of engineering at Facebook. Jocelyn and I were talking about how to make smart tradeoffs when building software products, and we talked about the importance of looking at the text as well as the business model before deciding on how to make a tradeoff. Now, that episode might have given you some great insights into how to make decisions from a very, very high level, but you probably were left wondering what to do on a day-to-day basis.
How do you prioritize all the various activities that are vying for your attention? Today on Femgineer TV, we’re going to be tackling your to-do list. If you’re an engineer or a designer, then your days are probably filled with a myriad of to-dos, such as product launches, bug fixes, answering emails, debugging issues, interviewing candidates, and so on and so on. You’re probably left wondering if the work that you’re doing is actually making a big impact.
Well, it’s easy for other people to tell us that we just need to work smarter, not harder. The bulk of the work falls on our shoulders, and often times, the only way we can get it all done is by actually putting in more hours. To help us identify efforts that are going to make a big impact and produce results, I’ve invited our special guest today, Edmond Lau, who is the author of the newest book, The Effective Engineer. Edmond has worked at large companies like Google as well as growth-stage startups like Ooyala, Quora, and most recently, Quip. Hey Edmond. Thanks for joining us today.
Edmond Lau: Hey, Poornima. Glad to be here.
Poornima Vijayashanker: Thanks. Congratulations on the launch of your new book, The Effective Engineer.
Edmond Lau: Thanks.
Poornima Vijayashanker: Yeah. Before we dig into your work, I want to just start by asking you what got you into writing?
Edmond Lau: I first started writing soon after I joined Quora. Quora was a question/answer site where a lot of people were asking questions about, “how do I get the most out of my engineering job, how to I have a larger impact on what I’m doing,” and people were just asking for lots of advice, and when I started answering questions, I found that a lot of people were really excited that there was some advice that they could get on the web. That felt rewarding to me.
That’s what got me on the path to basically start writing. Then, specifically focusing on engineering writing. One thing that I did while I was at Quora was build out the onboarding and mentoring program for new engineers, because there’s a lot of lessons that more senior engineers learn through years and years of experience and years and years of trial and effort that a lot of the new engineers simply didn’t know. What we found was that, I just started investing a little bit of work in the beginning, we could really change trajectory of a lot of these newer engineers. Writing about engineering topics and writing about how to be a more effective engineer was an extension of just doing onboarding for Quora’s engineers. With writing I’m able to actually reach a much larger audience and share some of the same lessons, stories, and advice that new engineers at Quora found helpful but except that larger scale.
Poornima Vijayashanker: That must have been a lot of work to balance writing code and writing the book. How did you get it all done?
Edmond Lau: Yeah. It’s my first book, so I didn’t really know what I was doing when I first started. I definitely asked a lot of people who had written books before to give some of their advice. When I first started writing the book, I actually took a personal sabbatical and took ten months off to basically focus purely on the book. I would sit down every day, set a goal for myself. Initially it was write 1,000 words per day, and I wouldn’t stop until I hit my 1,000 words. I stayed in that consistent habit and day over day I was about to actually produce a manuscript. That was a really exciting part of just writing the book.
Poornima Vijayashanker: Well, kudos to you for creating the book. I’ve definitely enjoyed reading it because I think it does a really good job of capturing all the things I’ve learned of building software products for the last ten years. In today’s episode, I want to share a number of the strategies that you actually talk about in the book. I know one of the big goals is obviously to be effective at what you do, but to also translate that into making a big impact and creating results. For our viewers, they might have a sense of what a big impact means to them, but for the purposes of our conversation, I’d like to come up with like a definition or a context by what we mean about big impact and results. Let’s start there. What exactly does that mean?
Edmond Lau: Sure. I think when people talk about impact and they talk about the value that they’re adding, it’s usually in the context of one of two things. One is impact and value that you’re producing for the organization that you’re working at. That might be customers added. It might be products built. It might be, if you are doing rentals or like nights booked, rides booked, etc. The other side of impact is impact on the team, so how much value are you adding toward the team of people that you’re actually working with. Usually when we start to talk about impact, it’s in the context of one of those two things.
Poornima Vijayashanker: OK, so one of the goals of this show is to do some mythbusting, and one of the common myths that I see time and time again is when people think that they only need to focus on their technical skills and they put a lot of importance into improving how they code, learning new languages, etc. I think a lot of this originates from engineering school where we’re taught how to build something. We’re taught that it’s important to think about new languages and new frameworks, etc., but a lot of times, that can be ineffective and we should take the time to figure out whether something should be built or should not be built. Can you elaborate on why it’s important to think about the “why” something should or should not be built, versus the “how?”
Edmond Lau: When I first left Google to join the startup world, I thought to myself, “OK, I really want this startup to succeed.” We’re an underdog and that means that we have to work really, really hard if we’re actually to do well. I had a mindset of, “OK, I’m going to work 70- to 80-hour weeks. I’m just going to power through everything.” My team thought the same way, and we thought that, “OK, if we just worked really hard, then we’re going to maximize the chances that our startup will actually do well.”
It took me awhile to start really questioning that idea, and in fact there were a few instances where I really started asking myself, “Is working 70- to 80-hour weeks, is that really the best strategy for helping our startup succeed?” There was an analytics module that a video startup I worked at, built for a customer. We spent maybe about two or three weeks building it, but the customer never even used it, and it was clear that any technical decision that went into building the analytics module ultimately had no impact. It really didn’t matter. We could have skipped that two or three weeks’ worth of work and we’d be at the same place we were before.
There was another case where we built a bunch of content management tools and it just never got the user adoption that we wanted. There was a time where I was on vacation and hiking around volcanoes in Hawaii and then I got paged. Was that really the best usage of my time? Was thinking about work all the time really the best strategy? It really took me many years of trial and error to realize that it’s not really about how many hours you work or how hard you work. What you’re working on also matters. The decision of where you should actually spend your time is actually really critical in terms of determining your impact and perhaps much more critical than the actual technical work that you’re producing.
Poornima Vijayashanker: Got it. OK, so we know that we can’t just focus on technical work. We need to do some other things, but often times we get stuck doing a lot of busywork. We sit in meetings. We write emails. We have to debug issues and fight fires and we have all these things going on and often times we also have to build new product features, that you said for example may or may not actually take off. That can get really tricky when we have all these other tasks, and then to make matters worse, a lot of times, we have to appeal to management requests or other departments, and what I’ve seen a lot of times is engineers will just drop everything that they’re doing to satisfy some of those requests. It’s hard to say no to those people, so myth #2 is a lot of times people feel like they need to drop everything and answer either a management or another department’s request rather than staying focused on their tasks and what they’re doing. How do you address that?
Edmond Lau: Yeah. That’s a great question. A lot of times when a manager or a project manager asks you to do something, they have a lot of things going on. They have a lot of priorities that they’re juggling, and so they’re not really aware of all the priorities on your own plate. That’s why it’s important for you as an engineer or a product designer to think through priorities yourself. Not all the work that you’re going to do is really created equal, right? Poornima Vijayashanker: Right.
Edmond Lau: There’s a lot of well-intentioned work, like the work that I did when I first joined a startup community that really didn’t have much of an impact. You have to be very conscientious about where you are spending your time. One really useful framework for thinking about impact and work and where you should be spending your time is this concept of leverage. Leverage is a concept that I cover a lot in my book, The Effective Engineer. What leverage basically means is it’s the amount of impact that you are producing per unit of time that you are investing in something. You can also think about it as the 80-20 rule. Is there something that you can do that only takes 20 percent of the effort but that generates 80 percent of the results?
The reason why leverage is so important for engineer or building products is because we all have a finite amount of time.
Poornima Vijayashanker: Right.
Edmond Lau: There’s only so many hours during the workweek. And if you can focus on the leverage activities that ensures that you are going to be producing as much impact as you can with the limited amount of time that you have. When you are thinking about what to work on, how to prioritize, you really should just be thinking about for every minute or hours that I’m going to be putting in this activity, how much impact can I generate? How does that compare with leverage of other activities? That’s where you should start thinking about priorities.
Poornima Vijayashanker: OK. We know that we have to do some high-level thinking and sit down and look at our tasks and prioritize them before we get down to work. For our viewers out there, they might not yet be familiar with what that 20 percent of work is that’s going to generate 80 percent of the results. How do we need to be thinking about our tasks? How do we comb through them?
Edmond Lau: We know that leverage is impact produced per unit of time. One way to think about it is, consider any activity that you are trying to do. If you want to increase your leverage, you can basically ask yourself a few questions. You can ask yourself, “Is there a way to get this activity done faster?” Because if you can decrease the amount of time it takes, then you are producing more impact for less time spent on that activity. You can ask yourself, “Is there a way to generate more value out of the same activity?” Or you can ask yourself, “Is there something else that you can be doing entirely different that would have higher leverage?”
Just to walk through a few examples, maybe you have an hour-long meeting that you are scheduled to discuss a design. You think through your questions, “Is there a way that we can shorten this meeting? Can we just hold a half-hour meeting instead of an hour-long meeting?” That would increase the leverage of the meeting. You can think about, “Can I come up with an agenda beforehand that I can send to all the meeting attendees?” That way during that actual meeting itself, you are able to produce a lot more value being focused on the things that you actually care about. You can also take it a step further, maybe you can avoid the meeting entirely. Poornima Vijayashanker: That’s my favorite.
Edmond Lau: Yeah. Maybe you can just write up a small design doc, send it around, and just get feedback. Maybe that just ends up saving a lot more time while also getting most of the value that you want.
Take another example: maybe you’re working on improving the performance of a product. You can think about it as, “Can I do that faster? Can I learn some type of profiling tool so that I can identify the bottlenecks in less time and fix them more quickly?” You can try to see if you can increase impact of the activity. Maybe you ask yourself, “Of all the webpages that are in my application, which ones get the most traffic?” Priority those webpages first when you are trying to improve performance. That way any work that you put into performance improvements impacts a larger percentage of people. You could also go a step further, maybe you can even just build a culture with the team where everyone considers performance as a feature and not just something that you tack on at the end. You give everyone the tools and the mindset necessary to really address performance as you are building products, as you’re building features, and perhaps that can save you from having to investigate those performance issues in the first place. In any activity you can basically ask yourself those three questions to try to shift the leverage of that activity to something higher.
Poornima Vijayashanker: Nice. So, it’s a combination of process and tools. Especially what you said about the meetings because BusyBee, my previous startup, we actually got rid of all of our meetings.
Edmond Lau: That’s great.
Poornima Vijayashanker: We would have daily standups. Then we did post-mortems every quarter, which was great. But then in between we had asynchronous communication, which was basically having a chat, not a lot of people use Slack. It was the precursor to Slack, where we would just put messages for people. We would at them so they knew the message was for them. We also set a standard, like you were suggesting, of we shouldn’t have things that are on fire cause that means we’ve done something wrong engineering wise. There shouldn’t be something where people have to get constantly interrupted to take a meeting or to resolve an issue and the asynchronous communication should just smooth all of that out. More importantly we have good process of doing test-driven development, in these things where we’re not having to interrupt people.
Edmond Lau: Yeah. Even right now at Quip, we really only have only one standing engineering meeting a week. The same way that it sounds like you did at BusyBee. Any decisions we would have to make, typically an engineer with just write the design docs and share it on Quip with the team. We’ll just do a lot of Quip chat, basically tackle any issues, answer any question, or do any short discussions and we use that in place of meetings and that’s worked out really well.
Poornima Vijayashanker: Nice. And you’re also dogfooding your product.
Edmond Lau: Exactly.
Poornima Vijayashanker: Awesome. I’m a big fan of building internal tools to save time, especially for those recurring tasks. I will take the time to make sure that I evaluate whether there’s already a tool that exists in the market and then pay the $10 or $100 a month to use that and integrate it into our product. I know a lot of people jump right in and start building when they might have done a better job of just buying something or even holding off. How do you get people to think about when’s the right time to build? Any suggestions?
Edmond Lau: Yeah, I would say that the mindset of investing a tool, that question you are asking yourself, is already a really good question because automation is a very high-leverage activity. You do it once and then it takes care of itself going forward. You don’t have to spend, hopefully, any time maintaining this going forward. In terms of whether, of when you should be automating something, I would say that engineers in general tend to under-automate. It’s partially because we underestimate a lot of times how often we’ll have to do something manually. We think, “Oh, we’re just going to do this once,” but then some requirements changed and you basically have to end up doing something manually again. There’s a tendency to basically under-invest in tooling. Another reason is because automation is also a skill. The more that you automate, the easier it becomes.
Poornima Vijayashanker: Right.
Edmond Lau: If we aren’t used to doing automation, we can bias towards doing things manually because it’s comfortable because we are confident, we can get it done with a fixed amount of time. A better way to think about it is to actually do the math, right? Maybe there’s a server that crashes and it takes you three hours every week to get it back up and running and make sure everything is OK. If you can build a tool that maybe takes you twelve hours to automate it, that means that after a month you’ve paid off that cost, that investment that you’ve made. Anything going forward is just per gains. Doing that math is really important.
Another rule of thumb that I learned when I was talking with Raf Krikorian, who was a former VP of Engineering at Twitter, that he use to tell his team that anytime you do something manually for the third time, that’s probably a time that you should consider automating it or writing a tool. I think that’s a pretty good rule of thumb. If you notice yourself doing something multiple times, you should pause. Think about, “Is there a way that I can automate what I’m doing?” If it takes a lot of work to automate, you can also think about, “Will learning to automate this thing help me be more efficient at automating in the future?” That’s also a benefit that a lot of people overlook.
Poornima Vijayashanker: Right.
Edmond Lau: That’s probably a good starting point.
Poornima Vijayashanker: Yeah. I’ve also noticed, if you do that amortization math and you tell it to, say somebody who’s mostly business focused, then they actually get it.
Edmond Lau: Yeah.
Poornima Vijayashanker: Cause then they are like, “Oh, OK, it makes sense.” But if you are just like, “Oh, I have to do this thing,” they are like, “Why is that important,” right? I think it’s valuable for yourself but it’s also valuable if you are trying to prioritize and get somebody to give you time to do the work. A lot of times you might have some level of push back. I think that’s a great technique.
Edmond Lau: Yeah, to add on to that, in communicating with, especially nontechnical members of the team, if you can translate your work into quantifiable impact, maybe some business metric, your team understands. Or you can translate it into actual hours, that becomes this really useful language that you can use for nontechnical members of the team. They might not understand the engineering that needs to go into it. They might not understand why automation might be hard or not hard, but it can quantify as, “this is the impact it’s going to have.” This is how long it’s going to take. Then they can also do that math and align their interest or align their thinking with what you’ve been thinking.
Poornima Vijayashanker: Got it. It’s also really easy as we start to build these tools and develop a level of confidence, that we just have to keep tweaking and perfecting our code and building tools. A lot of times people will actually halt themselves from actually pushing it out cause they are just like, “Oh, I just have to add one more thing and one more thing.” How do we convince people to push forward and iterate rather than trying to get everything done and then doing a deployment or pushing it out?
Edmond Lau: I think it’s important to focus on the goal that you might have. If you are building a new version of product, then your goal is probably to learn as much as possible in a short amount of time. In that case, what you want to do is make choices and make decisions that help you get feedback from users sooner. That might mean you do things in a more iterative fashion. You build something, you release it to some users, you get some data, you get all the feedback or quantitative feedback, and then use that information to then build the next iteration of the product.
If instead you are building a product that’s already fairly well established, then very likely there is already some metric that you are using to judge the success of that product. Maybe it’s weekly active users. Maybe it’s revenue that’s being collected from customers. In that case, you should really be making decisions and tradeoffs that help you to increase that metric more rapidly. You can do experiments. Do you increase that metric more when you focus on launching new features that your customers want? Or are you able to increase that metric more by doing small iterations? You can experiment with both. Spend a month doing iteration. Spend a month building a new feature and see which approach gets you more leverage in terms of increasing that core business metric. Really, it just depends on the goal that you have and then collecting data to see which avenue best helps you achieve that goal.
Poornima Vijayashanker: So, we’ve talked about leverage and you mention it in your book. I think it’s a great concept both personally, thinking about how can you create leverage from your activities, but it’s also important in terms of the team’s effort. In the book, you bring up two great examples of leverage activities, at least my two favorite, which are onboarding as well as mentoring new hires. You give an example of how you did it at Quora at a time where you had to bring on a lot of employees at once. Unfortunately, I think Quora is probably one of the companies that are in the minority when it comes to making the investment in terms of onboarding and mentoring employees. Can you share with us what were the results of doing this investment? What did you see in terms of impact?
Edmond Lau: Sure. I think it’s also helpful just to cover some of the mind set of rational of what went into that onboarding.
Poornima Vijayashanker: Yeah, sure.
Edmond Lau: The average engineer over a course of a year probably puts in around 2,000 hours of work if you consider the hours, like a 40-hour work week. Two thousand hours is a lot of hours, right? There’s a lot of output you can create during those 2,000 hours. Doing some investment in onboarding and mentoring, does that make sense? Well, if you spent, say, an hour a day for a new hire for a month, that’s really only 20 hours, right? That’s only one percent of the new hire’s time for that entire year. Those 20 hours can make a huge impact on what that new hire ends up doing. If you can get them to pick up best practices or if you get them to figure out how the organization or the processes or the culture works, that new hire can be a lot more effective. It might seem that building this program is a huge investment. How do you justify that to managers or justify that to the rest of the team?
Poornima Vijayashanker: Yeah, I’ve in fact heard from VPs who have said, “Oh, you know if the developer shows up on the first day and can’t get set up, then they are probably a bad hire.” A lot of times, it’s hard to justify, so yeah, how would you justify it?
Edmond Lau: Right. The important thing to realize is that onboarding and mentoring doesn’t have to be this binary variable, right? It’s not, we have onboarding or mentor or we don’t, right? It’s a very incremental process.
Poornima Vijayashanker: I see.
Edmond Lau: For instance, when I first joined Quip, there wasn’t really much in terms of onboarding. One of the first things I did was I just started a doc. That doc had, what are all the things I did during my first day or my first few days to get setup, these are helpful resources, these are links you might consider reading. Just making that small little investment probably only took me an hour or two. The next new hire was able to ramp up a lot more quickly.
Poornima Vijayashanker: Right.
Edmond Lau: That was a pretty high-leverage activity for the team. And moreover, by just having that small doc, new hires could then add to it. People could build upon that. It really only just takes a little amount of effort to really get started. From that you can iterate: would it be helpful to have more tutorials or more docs available to more new hires? Would it be helpful to have some onboarding talks? Over time you can build up a more full-fledged program, but all it has to start with is just one small doc.
You also had a question about what were the results? What is actually accomplished? At Quora, we ended up having a series of documents called Code Labs. That’s an idea that I borrowed from Google. A Code Lab is basically a document that walks over a core abstraction of the company. It talks about why this abstraction exists. How do we go about building it? What are the relevant pieces of code that you should look over to really understand how this core abstraction works? It also has a few exercises to validate your understanding. At Quora we had maybe around ten Code Labs that the Engineering team had written up.
We also had roughly ten onboarding talks that every new hire goes through that taught them how the Engineering team works, what the expected best practices were, what the quality standards were, etc. The end result of that type of onboarding plus assigning them a mentor was that in a new hire’s first day, they were able to make a change to the code that they were able to push to production. It was something simple as adding themselves a team page. Then in their first week, most of the new hires were then able to also do some meaningful bug fix or implement some meaningful small feature.
That is something that we’ve been able to do at Quip as well. At Quip, the onboarding is much smaller because it’s a much smaller company. With that onboarding new hire doc, your new hires are able to typically push something to production their first week as well. That really helps to set the tone of, you can get ramped up quickly and we expect you to ramp up quickly. We’ll also give you the tools that you need to make meaningful changes to the code base and to the product even in your first week.
Poornima Vijayashanker: It probably helps with employee retention, too.
Edmond Lau: Yeah. Employees are a lot more excited when they can actually ship something right after they join.
Poornima Vijayashanker: Yeah, so it’s giving them that positive first-time experience, just like you would with a customer when they are coming to your product for the first time.
Edmond Lau: Exactly.
Poornima Vijayashanker: Yeah, nice. So, onboarding and mentoring employees is great. It’s a high-leverage activity and it gets everybody on the same page in terms of best practices. What do you do in the instances where you are dependent on someone else? You are just stuck and you can’t move forward? Or maybe they’re stuck and they can’t move forward. How do you resolve that situation?
Edmond Lau: In any optimization problem, I think the first step is figure out what your bottleneck is, right? Is this dependency the bottleneck, or did something that you could go off and work on, do your other work for projects while you are waiting for this person to complete that dependency? If that’s the case, then maybe you should focus on something else instead.
If that’s not the case, then the next step is figuring out, are they bottlenecked on this issue because it’s not a priority for them? Sometimes you might be working on a part of the product, you might depend on this library being built or this server having some feature and it’s really important to you. It might not be at the top of their priority list. Having some initial conversation with them to make sure that your priorities are aligned is the first step. Make sure that they understand where your priorities are and what’s important to you. Also understand what their priorities are and what’s important to them. If it was just some miscommunication, then sometimes that can conversation can help resolve it.
Otherwise, it might also be the case that what’s most important for your team is not necessarily what’s most important for their team. In that case you have a few options. One is maybe you ask this person to actually ramp you up on their part of the code base so that you can actually make the change. Granted it might take you more time than someone on that team to make that change. But, if this is the bottleneck for your project, then it could still be extremely high leverage for you to basically learn that code base sufficiently so you can go in yourself and make that change. Maybe that’s the right solution.
Poornima Vijayashanker: I’ve actually talked about this with designers and developers because the designer will be like, “I need time to make this look good,” and the developer will be like, “OK, but I just need to see something basic so that I could start to figure where to do the layout and all of that.” I actually met a designer I believe it was either at Square or somewhere else where they said, “Oh, I’ll work on perfecting it, but then I’ll just give them some rudimentary files that they can go off and get what they need to done so that it’s not that bottleneck.” Do you have other examples like that?
Edmond Lau: As long as I see people ask me, “What are the best skills I should be focusing up on learning?” Your example reminded me of that and sometimes I would tell them that it’s really useful to pick up basic skills, adjacent disciplines. For instance, I do a lot of work on user growth. Just knowing some amount of minimal UI design or knowing some amount of copy editing can really go pretty far in terms of having a product or prototype that feels good. If you are a front-end engineer, learning some amount of how to run your own servers can be pretty useful. Knowing some product management skills would also be part of the adjacent disciplines for a front-end engineer. If you are someone who is working server-side code, maybe learning some machine learning or maybe learning some minimal front-end design skills should be pretty useful for a job. I think considering adjacent disciplines is one useful way to think about it.
Poornima Vijayashanker: I think that’s actually pretty highly leveragable activity. I remember, primarily back as an engineer, and I remember when I first had to learn CSS, I didn’t enjoy it. But, when I figured out just a little bit, then I could very quickly go in a debug issues. Prior to that I was always tapping on my front-end engineer’s desk, “I don’t know how to do this.” Then, finally he got frustrated, I got frustrated, and then just decided to resolve it by learning just a little bit and it actually made the whole process go a lot smoother.
Edmond Lau: It’s actually very common. A little bit of knowledge can make you pretty dangerous.
Poornima Vijayashanker: Yeah. I definitely wasn’t good enough to do the work on my own, but it got us moving past and in return I also taught him just a little bit to get him off the ground when it came to database design. That way we weren’t always working in a way that was getting the other person stuck. I think that’s really valuable.
Edmond Lau: That’s great.
Poornima Vijayashanker: Cool. OK, final question for you. What would you recommend that our viewers do in terms of just one to two simple steps that would get them off on the right track?
Edmond Lau: I think one great way to get started is just to find people who have done it before. One of the reasons why mentoring and onboarding worked really well was because it took all this knowledge from some of the more senior engineers and passed that knowledge to some of the newer hires. That’s something that I’ve tried to do when I was basically spending those two years writing my book, I went around Silicon Valley and I interviewed a lot of engineering leaders. People from like…Bobby Johnson that use to be a Director of Engineering at Facebook or Marc Hedlund, who’s the VP of Engineering at Stripe and a bunch of people from Google, Twitter, LinkedIn, etc.
The reason I did that was because these people have a lot of knowledge, a lot stories, a lot of lessons that they learned over many years of trial and error. If we can distill some of those stories and distill some of those themes and those lessons, we can save ourselves a lot of time. I found it to be extremely high leverage just to figure out what are the patterns that we see from other engineering leaders. What are the top mistakes that they make? That why I spent those two years trying to distill into my book.
I think through that book, you’ll learn a lot about leverage, which we started talking about in today’s session. You also learn about how to apply the principle of leverage to basically everything you do as an engineer. Whether it’s figuring out metrics, whether it’s prioritizing what to do next, whether it’s maintaining the quality of your code base, estimating how long projects take to do. If this is something that you are interested in, I think learning those lessons from the best of the engineering leaders in Silicon Valley is a great way to start.
Poornima Vijayashanker: I really enjoyed reading your book, The Effective Engineer, and I think it was great way to distill, one a lot of the strategies that I have learned over time. But, two also to read other people’s stories of how they went about building products and teams. For our viewers, can you tell us one to two ways in which they would benefit from picking up a copy of your book and reading it?
Edmond Lau: Like I said at the beginning, when I first started working at startups, I had this conception that the more hours I worked, the higher the impact could produce. That’s really not the case. A lot of times, we’ll do work that doesn’t necessarily lead to impact. So, one of the core things that the book would teach you is this framework of leverage that you can use to identify what are the actual efforts that will lead to a disproportionate impact. Where are the places where you can spend your time so that you are not just wasting it but instead producing value for the product, for the team, and also for yourself and your career.
Another one of the things that I learned when I was just going around Silicon Valley and interviewing engineering leaders to get their stories or lessons or their mistakes was that all of these skills that help the best engineers be effective, they are all learnable. They’re not magical things that are out of everyone’s grasp. There are very basic frameworks and mindsets that we can adopt, to being thinking how the most effective engineers think. What the book will teach you is it will help you identify where are the efforts you should be spending to achieve significantly more value for your team and for yourself but with fewer hours of work.
Poornima Vijayashanker: Just to quickly recap, we covered three things. The first thing we covered was that it’s not enough to just have technical chops. We also need to work on improving how we focus and where we spend our time. The second is that we might have a very, very long to-do list but we need to take the time to prioritize that and figure out what are the activities that are actually going to make a difference and have an impact and produce results. And the third is thinking about leverage. How can we pursue activities that will create leverage for ourselves as well as our teams, and the two examples that we gave you were onboarding and mentoring new hires. The benefit of making the investment initially is that they come up to speed really quickly. You often times retain them as employees and beyond that your entire team is productive and happy and shipping product.
Thanks again to our special guest, Edmond Lau, for joining us today.
Edmond Lau: Thanks for having me.
Poornima Vijayashanker: And of course to all of you out there, our viewers, and our sponsor Pivotal Tracker for helping us in producing this episode of Femgineer TV. Subscribe to Femgineer’s YouTube channel to receive the next episode where we’ll have special guests the founders of Pop Up Archive, Anne Wotten and Bailey Smith. And if you’ve enjoyed this episode, then please share it with your friends, your teammates, and your boss. And let us know in the blog comments below what was your favorite part about this episode. I’m looking forward to reading your comments.
This episode of Femgineer TV is brought to you by Pivotal Tracker—build better software faster. Check out Edmond Lau’s latest book, The Effective Engineer. Visit https://theeffectiveengineer.com/book.
FemgineerTV is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
