Maximizing Impact as a Technical Writer: Insights from "The Effective Engineer"
- Lilian Lee
- 2025-06-14
- Book Insights
On this page
At first glance, Edmond Lau’s The Effective Engineer might seem exclusively for software engineers. But as the author himself notes in the epilogue, “most of the advice in this book applies beyond engineering.” As a Technical Writer, I couldn’t agree more. Many of the ideas deeply resonate with our work in technical communication.
In fact, in Chinese, our role is often translated as “Technical Documentation Engineer” (技术文档工程师) — yes, with “engineer” in the title! So, technically, we’re engineers too, just with a different kind of syntax.
This book, boasting an impressive 4.25 rating on Goodreads as of June 12, 2025, is a worthwhile read that will likely spark fresh ideas, especially in the AI-driven era. In this post, I’ll highlight five key insights from the book and explore them through the lens of a Technical Writer:
- Focus on high-leverage activities
- Relentlessly automate mechanical tasks
- Measure and instrument as much as possible
- Adopt a growth mindset
- Balance quality with pragmatism
1. Focus on high-leverage activities
The core idea of the book is simple yet powerful: focus on high-leverage activities.
So, what counts as high-leverage activities? In short, they are the ones that let you create greater impact with less time invested.
The leverage formula is: Leverage = Impact produced ÷ Time invested ⭐️
To become more effective, we need to consciously choose tasks that offer a high return on investment (ROI) for the effort we put in.
This connects nicely with the Pareto Principle (also known as the 80/20 Rule), an observation that roughly 80% of outcomes come from 20% of causes. For example, 20% of customers bring 80% of profits, or 20% of products dominate 80% of the market.
If you reflect on your past performance reviews at work, you might notice that the achievements that truly helped you stand out came from just 20% (or even less) of your work. The remaining 80% was often seen as routine or unremarkable.
So, how can we systematically increase the leverage at work?
In High Output Management, former Intel CEO Andrew Grove points out that the overall leverage can only be increased in the following three ways:
- Reduce the time it takes to complete a certain activity.
- Increase the output of a particular activity.
- Shift to higher-leverage activities.
For many Technical Writers, a significant portion of their time is dedicated to essential, yet often routine, tasks like documentation project management, cross-team communication, and content reviews. While critical, these tasks, which can consume a large percentage of our time, may not always be what truly differentiates our performance or maximizes our impact.
Therefore, once your documentation workflows are mature, it’s time to look for new opportunities to create impact. For example:
- Introduce AI or automation tools to improve the efficiency and reduce time spent on routine tasks.
- When delivering work that brings value to users or partner teams, actively promote and share it to increase visibility and broaden impact.
- Align your work with company and department strategy, and explore new ways for documentation to add value, whether by going deeper (specialization) or wider (cross-functional contributions).
2. Relentlessly automate mechanical tasks
If you find yourself repeating a task often, that’s a good sign it might be worth automating. However, before diving in, it’s crucial to evaluate the decision carefully to ensure its correctness. Consider the cost of automation, the potential ROI, how long it will take to realize that ROI, and whether your team currently has the necessary skills or is willing to learn them.
In the daily work of Technical Writers, there are plenty of repetitive and mechanical tasks. Over the years, the documentation team I help lead has introduced automation at many stages of the documentation workflow. And with AI continuing to evolve, there’s even more we can explore.
Our automation toolkit includes shell scripts, Python scripts, GitHub Actions, browser extensions, and custom-built tools. Some of these are open source — feel free to check them out:
Time and human resources are always limited, and continuously driving automation can effectively save both. Once a task is automated, the more frequently it is used by more people, the more significant the compounding effect and the greater the return it generates over time.
3. Measure and instrument as much as possible
Management guru Peter Drucker points out in The Effective Executive that “If you can’t measure it, you can’t improve it.” That’s why picking the right metrics is crucial.
The right metrics act as a north star — they help align the team and keep everyone moving in the same direction. Unlike some roles, quantifying the direct impact of documentation can be challenging, making the deliberate selection of metrics even more crucial.
When deciding which metrics to use, Edmond suggests choosing ones that maximize impact, are actionable, and are responsive yet robust:
- Maximizing impact: Optimizing the metric can lead to the biggest positive outcome.
- Actionable: The metric improvement can be causally linked to the team’s efforts and accurately reflects the quality of their work.
- Responsive yet robust: The metric responds quickly enough to reflect whether a change had a positive or negative impact, and it isn’t significantly affected by external factors beyond the team’s control.
When setting goals, it’s critical to carefully determine what core metrics to measure (or not measure) and optimize. Additionally, in day-to-day operations, you also need supporting metrics. In many cases, the effective optimization of a core metric depends on the systematic measurement of a comprehensive set of supporting metrics.
Therefore, we need to cultivate a metrics-driven mindset and build a monitoring system that provides both a high-level overview and deep insights into specific areas. By systematically monitoring documentation usage data, we can gain a better understanding of overall status and progress, and make better decisions. For example, we can:
- Understand how users interact with documentation
- Identify which docs need improvement
- Detect issues users face while using the docs
- Track the impact of new features or interactive modules
- Measure content-driven conversion or engagement
4. Adopt a growth mindset
As the old saying goes, adapt or perish. In a career that spans decades, continuous learning and growth are essential. Otherwise, it’s easy to fall behind.
I’m fortunate that throughout my years as a Technical Writer, I’ve been surrounded by exceptional, self-motivated colleagues. They consistently pursue new skills or deepen existing ones, continually pushing the boundaries of their abilities and perspectives.
People with a growth mindset believe that they can acquire new skills and improve their thinking through learning and effort.
This growth can happen both inside and outside of work. For Technical Writers:
On the job: Take on different types of projects, learn from experienced teammates, or study internal resources.
Outside of work: Read industry books, follow bloggers and conference talks, learn a programming language, or explore new hobbies.
In fact, the book notes that even hobbies unrelated to engineering can sharpen your skills. “Research suggests that creativity stems from combining existing and often disparate ideas in new ways. Projects in seemingly orthogonal areas like drawing and writing can have benefits that flow over to help you be a better engineer.”
One idea that stood out to me was Google’s famous “20% time”, where engineers spend the equivalent of one day a week on a side project that could benefit the company.
This “20% time” can be used to dive deeper into your area of expertise and tools, or to develop skills in “adjacent disciplines”. Adjacent disciplines are areas related to your core role, where gaining more knowledge can make you more self-sufficient and effective.
For Technical Writers, adjacent disciplines include programming, product management, UX design, developer relations, or content marketing. While we may not have a dedicated “20% time” in daily work, we can still try to set aside a few hours each week in spare time to expand our skill set.
5. Balance quality with pragmatism
“Ultimately, software quality boils down to a matter of tradeoffs, and there’s no one universal rule for how to do things.”
Strictly insisting on “the right way” to build something can paralyze discussions about tradeoffs and alternative solutions. A more effective approach is to adopt a pragmatic mindset — thinking in terms of what does and doesn’t work for achieving our goals — as a basis for evaluating quality.
Strict code reviews can improve code quality, but they may sometimes slow down product iteration speed. We want both high code quality and fast iteration, so we need to strike the right balance. For example:
- Establish a sustainable code review process.
- Take on technical debt when meeting a deadline is critical, but remember to pay off that debt periodically. Note that not all technical debt is worth repaying; some may not justify the cost.
The same applies to documentation. As Technical Writers, we want every piece of content on the official documentation site to go through a thorough review. But under tight deadlines, we sometimes need to make trade-offs and relax certain standards to deliver on time. Once published, we can come back later for refinements.
Relaxing standards doesn’t mean abandoning quality. We still need to maintain baseline expectations. Otherwise, we risk hurting user trust and accumulating documentation debt that’s hard to fix later due to complexity and time constraints.
Google holds Fixit days like Docs Fixit, Customer Happiness Fixit, or Internationalization Fixit — where engineers are encouraged to tackle specific themes — as a lightweight mechanism to pay off technical debt.
Conclusion
These five takeaways from The Effective Engineer left the strongest impression on me. Of course, the book contains many other useful insights, such as prioritizing regularly to focus on high-leverage activities, speeding up iteration, validating ideas early and often, and improving project estimation skills.
Everyone may take away something different from this book, but there’s something in it for all of us. I hope my reflections as a Technical Writer provide a fresh perspective.
Have you read The Effective Engineer? What insights resonated most with you, or how do you apply these principles in your own work?
