To establish value, focus more on high priority projects: Reading Michael Lynch's post on why he quit Google to work for himself
Documentation doesn’t help engineering promotions
In one of his attempts at promotion, Lynch noted that for one of his projects he “documented the pipeline as I learned it so that the institutional knowledge was available to my teammates instead of siloed in my head.” A cartoon graphic in his post demonstrates what happened:
Because engineers are measured by their contributions to projects with high technical complexity, writing documentation will likely be an insignificant footnote for most promotion committees. It’s not a factor in a promo packet in which an engineer must demonstrate how they solved problems involving significant technical complexity. Hence, documentation efforts for most engineers will be put aside because they don’t fit into their promotion trajectory. This might help explain why engineers never seem to want to contribute to documentation, even if they’re capable of writing. Lynch writes,
“I submitted my first promo packet, and the results were what I feared: the promotion committee said that I hadn’t proven I could handle technical complexity ….”
The importance of working on high-impact projects
The second highlight from this post is Lynch’s attempt to contribute to an impactful project. Lynch explains:
“To continue advancing my career, I’d need projects that were even larger in scope and involved collaboration with more partner teams.”
If you work on projects no one cares about, it’s also hard to get promoted. Many of his projects were canceled six months in. I think one reason I was successful in my promotion effort is because of the business group I’m in. The products are a profit center with many high-profile partners and impact. It matters a lot to people in the organization, and I’m the only tech writer for these efforts. In contrast, if I were working on a product that was much less significant to the company’s business interests, no matter how awesome the documentation I created, it wouldn’t matter much because the product area wouldn’t be significant to the company.
I’ve written before about company layoffs and how tech writers can provide value to companies. (See my series titled Reflecting seven years later about why we were laid off.) Lynch’s post suggests that it doesn’t matter how good of a programmer you are; what matters is the importance of the projects you work on. I think I intuitively understood this, because I’ve consistently gravitated toward more important business areas in the documentation I work on. When I was at Amazon, it was Fire TV more than Kindle and other devices. At Google, it’s the automotive API products.
In technical writing roles, you have a surprising ability to focus your efforts on documentation projects you believe in. I have about 60+ documentation bugs sitting in my queue. Which ones do I work on? Which do I prioritize? If a product has an upcoming release, sure, I make sure we have docs for those features. Or if partners are complaining loudly about an issue, I also prioritize those fixes. But beyond those P0 type bugs, there’s a lot of leeway to ignore some products and prioritize others. Making that judgment call could be more significant than the quality of documentation you write. In other words, instead of focusing so much on documentation quality, focus on documentation priority. Are you working on products that matter to the company? That decision might matter more in your promotion efforts than the quality of documentation you write.
In one comment on Hacker News by “nostrademons”, an engineering manager explains that getting promoted is also highly dependent on the manager’s ability to articulate your value in the context of business-significant projects:
“Nobody knows or cares how good a programmer you are. Nobody really cares how hard you work either. Your ability to get promoted is basically dependent upon how well your manager knows how to work the system and then whether you listen to your manager.
The last promotion packet hinged on work that took him maybe a couple months to do, but that I managed to spin into a big complex project, because it was stuff that folks at the Director/VP level cared about deeply but had no idea how to do …”
I’m more and more convinced of that point of view. There are some weeks where I might work extra hard, putting in additional time in the evenings and weekends, and other weeks where I just coast. No one seems to notice from week to week. What matters more is my general alignment on important, high-impact projects that matter to the business. And more importantly, my manager’s ability to understand that integration and to highlight my involvement in those projects, explaining my role in these complex, high-impact projects to promotion committees.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.