5 Things I Learned as a Tech Writer at a Startup

Is it listicle time? It is listicle time!

I just completed a ~3 year tenure at Databricks, a "startup" on the cusp of becoming a large corporation. It was a fascinating experience and I gotta say, it helped me grow as a writer and manager in a lot of ways that I would not have experienced if I'd stuck with FAANG-type companies. At the very least, it taught or reinforced 5 things I think most if not all tech writers should understand about this role in 2025.

1. There is no room or place for tech writers who just "complete tickets". Perhaps the worst thing a tech writer can do, in 2025, is settle into a comfortable "stenographical" role where someone else queues up the work and the writer publishes prose to deliver it. Not only is this an abdication of the real work involved in being a tech writer -- the content strategy, the planning, the information architecture and content design, the cross-functional project management, the wrangling of SMEs, the gathering of customer feedback and the pursuit of insight from content analytics -- it really, really harms the expectations other disciplines have for the role. Every writer I saw flame out had the idea that delivering prose was the alpha and the omega of the job, and neglected everything else. In the crucible of an under-resourced discipline at a growing startup, it is far more important to have impact at scale through content strategy and planning, not by publishing more pages.

2. Field engineers, support engineers, and solutions architects should be your besties. They live and work the closest to the customers, and can provide you the insights and use cases that PM cannot. They also share a common mission with technical writing: Helping the customer be successful given the reality of the product, not the potential. Cultivate good relationships with them and make them your ally. As a writer, you have a lot to offer when working in close conjunction with them -- you can create the canonical content they can direct customers to confidently and save costly and exhausting support hours, and in turn, they can provide you with the details of customer use cases you need to target your content effectively. Seek them out and negotiate working partnerships.

3. Very few leaders in any technical corporation or company -- and especially startups -- understand the work of technical documentation (although they seem to value the results). They profess to understand technical writing, of course, possibly having written many blog posts and white papers and strategy docs, but reliably, the truth of their ignorance is revealed with 4 simple words: "But it's just typing!" This has been true at every company I've worked for. It's not going to change, so take the time to guide your E-staff, Product, and Engineering stakeholders to understand the deeper work of docs. Provide clear strategy and planning docs that follow the corporate templates, and take the time to celebrate your efforts in Slack or email to raise awareness of the challenges in developing great tech docs. IC PMs and engineers usually grasp the difficulty of the work, so make them into allies and supporters. You can't get change the miscalibrated expectations of up-level leaders directly, so represent your work and the details of your efforts using the protocols provided by PM and Engineering organizations, and seek to get your projects and work repped in the same venues.

4. "Dealing with ambiguity" is not just a startup survival skill, it is THE essential skill for tech writing. Look, nobody wants to answer your technical questions. Nobody really wants to talk about doc needs and issues when every day is an engineering or product firedrill, with your Eng stakeholders sleeping under their desks and your PM peeps panicking over GTM crises. You're downstream from them, and if my own experience is any indicator, any requests from writers in the late stages of a product release are "a bridge too far" in their minds -- you'll get complaints from even the nicest stakeholders about how the writer is "a distraction" and should be "doing their own homework". Avoid being perceived as unwanted baggage by anticipating and planning the content work, and be your own product and project manager. Talk to the field and the solutions folks, understand the key use cases early, plan the docs, file your own tickets, track in the open, report in common channels, and align your work to the ship schedule.

5. Modern technical documentation work is very similar to Engineering work, if not nearly identical. Look: I've been a dev and a tech writer. The biggest difference in these Docs-as-Code days is that I encode English in some markup or structured syntax, while a dev codes up logic for app or service features using a proper deterministic language. I work in Git and an IDE, I use Jira, I test/lint, I stage for review and integration, I publish, I gather feedback, and I iterate. Heck, I'm often creating code samples and notebooks which need full-on dev code reviews. Sometimes I'm making scripts and tools, or changing site behaviors and adding features. My day doesn't look THAT different from a dev's, except that I'm generally submitting more PRs in a day/week and dealing with more Git headaches. Knowing this, you should rep your work as engineering work and align your efforts with the larger feature development planning in the formats and models engineers and eng leads use. After all, you too are building a critical product feature in an Agile environment or for a shared deadline.

6. BONUS! (Tricked ya.) Make sure you work for a manager or executive who truly gets technical documentation and is reasonably up-to-date on the concepts and best practices that define it as a modern discipline. (Shout out to Jennifer Hubbard , the best doc leader and manager I've had.) If not, you will find yourself dealing with conflicting expectations, burgeoning doc debt, an utter lack of resourcing, and the sort of passive contempt for the role that comes from folks who think you "just type things up with nice words and grammar". When you interview, make sure the hiring manager either really understands modern documentation principles and practices, or at least will trust you enough to support you with proper resourcing and expectations.

These are, of course, generalizations based on my experiences. If I can sum it up, I'd say that the ownership and "dealing with ambiguity" skills you can build and refine at a startup are worth the challenges, and can make you stand out at a larger company if you can effectively get the support you need. At the very least, you'll get a lot better at Git. Haha, Git. Whew.