This question comes up for a lot of us as we trying to advance our career and reach new heights. At the moment when I was challenged by it, I came across a wonderful book by Edmond Lau "Effective Engineer".
As always going through the book, I write new thoughts down. And today I want to share the compilation of things that I have found useful from the book. This is by no means an ad for the book, but I think it has some really interesting approaches for us to explore together.
Who is Edmond Lau and why would I be interested?
Ex Software Engineer in Google, Ex Eng Lead in Quora, Ex Engineer, Architect, Leadership Coach in Quip, and many more mentioned here.
What is leverage ?
Leverage is defined by a simple equation. It’s the value, or impact, produced per time invested ...... Put another way, leverage is the return on investment (ROI) for the effort that’s put in. Effective engineers aren’t the ones trying to get more things done by working more hours. They’re the ones who get things done efficiently—and who focus their limited time on the tasks that produce the most value.
To be effective engineers, we need to be able to identify which activities produce more impact with smaller time investments. Not all work is created equal. Not all efforts, however well-intentioned, translate into impact.
Here's the series of question to ask yourself that naturally would improve leverage:
How can I complete this activity in a shorter amount of time?
How can I increase the value produced by this activity?
Is there something else that I could spend my time on that would produce more value?
We must understand that time is a finite resource, and thinking about leverage makes an engineer focus on what matters most.
Learning
To invest in your own growth, you should carve out your own 20% time. It’s more effective to take it in one- or two-hour chunks each day rather than in one full day each week, because you can then make a daily habit out of improving your skills.
Study code for core abstractions written by the best engineers at your company. Particularly if you’re at a big technology company with a large, shared codebase, read through code in some of the core libraries written by early engineers....
Jump fearlessly into code you don’t know. After years of observation, Bobby Johnson, a former engineering director at Facebook, concluded that engineering success was highly correlated with “having no fear in jumping into code they didn’t know.” Fear of failure often holds us back, causing us to give up before we even try. But as Johnson explains, “in the practice of digging into things you don’t know, you get better at coding.”
Acquiring knowledge is often compared to linear process of collecting information, however:
“Learning follows an exponential growth curve. Knowledge gives you a foundation, enabling you to gain more knowledge even faster. For example, an understanding of recursion provides the basis for many other concepts, like trees and graph searches, which in turn are necessary for understanding compilers and network topologies.”
Prioritising
Do you run your day, of the interruption during the day runs you ?
Regular prioritization is a high-leverage activity, because it determines the leverage of the rest of your time. After all, if you work for weeks on a project that has little impact and garners few lessons, how is that different for your business than not working at all?
Prioritizing is difficult. It consumes time and energy, and sometimes it doesn’t feel productive because you’re not creating anything. Perhaps you won’t want to do it during your downtime when you want to relax. That’s okay—you don’t have to always be prioritizing. But when you have certain personal or professional goals that you want to achieve, you’ll find that prioritization has very high leverage.
Request feedback early on
“Nimrod Hoofien explained. “Any decision you make … should have a feedback loop for it. Otherwise, you’re just … guessing.”
A lot of software engineers learn this lesson in their first jobs. Guessing - is expensive, the longer the time - the harder the consequences of an unsuccessful project/idea/implementation. Therefore, think about:
Don’t wait until after you’ve invested massive amounts of engineering time to seek final project approval. Instead, prioritize building prototypes, collecting early data, conducting user studies, or whatever else is necessary to get preliminary project approval.
At initial stages of working in project, there's always areas that require more details and scoping.
What’s the scariest part of this project? That’s the part with the most unknowns and the most risk. Do that part first.
Productivity and overtime
Hourly productivity decreases with additional hours worked. ”“Over a century of research shows that long hours actually can decrease productivity. 23 Employers in the 1890s achieved higher total output per worker when they experimented with 8-hour work days. 24 In 1909, Sidney Chapman found that productivity during overtime declines rapidly; fatigued workers start making mistakes, and the short-term increase in output comes at the expense of subsequent days’ output. 25 Henry Ford instituted a 40-hour work week in 1922 because years of experiments showed him that it increased total worker output.
Well, software engineer's work can't really be compared to the factory, but we do get a limited amount of focus and mental efforts to spend per day.
I’ve come to learn that working more hours isn’t the most effective way to increase output. In fact, working too many hours leads to decreased productivity and burnout. Output may even turn out to be negative when it’s necessary to repair the mistakes made by overworked and fatigued engineers.
And in case you still feel seduced by sprinting to meet a deadline, here's one more thought:
Why we need to be careful not to use overtime to sprint toward a deadline if we find ourselves falling behind: we may actually still be in the middle of a marathon.
But I also think the culture of working endless hours is unnecessary and abused by ineffective managers around our industry. In addition to being unnecessary, that aspect of our culture is one of the main things that prevents people from choosing long term careers in software engineering—it is unsustainable for people with families, and it creates a homogeneous, immature atmosphere at the companies where it is ubiquitous.”
Now that you've (hopefully) successfully set your working time boundaries:
Focus on tasks that directly bring a product closer to launch; that directly increase the number of users, customers or sales; or that directly impact the core business metric your team is responsible for. Write code for a necessary product feature, tackle roadblocks or secure necessary approvals that would hold back a launch, ensure your team members are working on the right tasks, address high-priority support issues, or do anything else that leads to results.
Once you’re producing results, few people will complain about declined meetings, slow email response times, or even non-urgent bugs not being fixed, unless those other tasks are blocking even more valuable results from being delivered. When you get the important things right, the small things often don’t matter.
Don’t treat every invitation to do something as an obligation. Explain how the meeting, bug, or project will detract from your other tasks, and discuss whether it should have higher priority. If not, you probably shouldn’t be spending your time on it.
Create space and speed up process for others:
There’s a common misconception that being the sole engineer responsible for a project increases your value. After all, if fewer people know what you know, then the scarcity of your knowledge translates into higher demand and value, right? What I’ve learned, however, is that sharing code ownership benefits not only yourself but your entire team as well. As you increase in seniority, your responsibilities as an engineer also grow. You become the point-person for more projects, and other engineers consult with you more frequently. While that can feel good and may even increase your job security, it also comes with a cost.
When you’re the bottleneck for a project, you lose your flexibility to work on other things. High-priority bugs get routed to you more frequently because your expertise enables you to fix them faster. When you’re the only one with complete knowledge of a working system and it goes down, you find yourself as the first (or only!) line of defense.
Importance of planning ahead
Don’t rely on the possibility of overtime as a crutch for not making a contingency plan. When you’re backed into a corner and have no other options, you’re more likely to panic and scramble as the deadline looms closer. An effective engineer knows to plan ahead.
Bill Walsh, former coach of the San Francisco 49ers. In The Score Takes Care of Itself, Walsh discusses a strategy called “scripting for success.” 21 Walsh wrote scripts, or contingency plans, for how to respond to all types of game scenarios. He had a plan for what to do if the team was behind by two or more touchdowns after the first quarter; a plan for what to do if a key player got injured; a plan for what to do if the team had 25 yards to go, one play remaining, and needed a touchdown. Walsh realized that it’s tough to clear your mind and make effective decisions during critical points of the game, especially when thousands of fans are roaring, hecklers are throwing hot dogs and beer cups at you, and the timer is ticking precious seconds away. Scripting moved the decision-making process away from the distracting and intense emotions of the game. In fact, the first 20 to 25 plays of every 49ers game eventually became scripted, a tree of if-then rules that codified what the team would do in different scenarios. By scripting for success, Walsh led the 49ers to 3 Super Bowl.
Here's the talk of Edmond Lau on Youtube, that would summarise all the thoughts above:
Thank you for making it this far, let me know what is the topic you'd like to read about next. Feel free to share your thoughts about the article as well.
