TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Since this is generating so much interest, thought I'd jump on the band wagon.
I agree many -- I don't see any evil bias. I do see a bias in favor of a strongly technical person with some degree of engineering background, but who wants to stay in a writing position for the long term.
My guess is that they're doing something with cloud/virtual tech. So for the networking bit, no you don't have to tear apart boxes and figure out how they work. Rather, you need to understand networking tiers, maybe bit about protocols, how to configure a device on the network, and how to find a device on the network. And you need to know how to talk to people who set up networks for a living. Maybe they're into managing costs on the Azure Virtual Network... Who knows? But my guess is they're not hoping for an EE degree by a long shot. They are looking for somebody who is not afraid of tech, who can install and configure networked applications, and who can troubleshoot and identify bugs in a networked system.
Startup means you can expect to begin with little to nothing in place for docs. I would ask about your interaction with Marketing AND Engineering... Your position will have to be the one to resist silos between tech docs and marketing docs because Marketing generally doesn't have that on the radar. And you will have to work with product managers (if they have them) to get your doc requirements. You will need to set up your entire doc environment, is my guess, and do it fast. At the bottom of it, although you will have to ask questions to get there, they want somebody who can give them answers. You are going to be doc manager, tech writer, process consultant, content engineer, and who knows what else? The great thing about a startup is that you ultimately get to pick your career path (within tech docs, as the JD states) -- assuming you can wear all the hats in the initial phase.
They want a senior person -- a master of the trade who can come in and set up the whole job. Oh, and who has domain experience (networking/engineering). This should not be cheap. If you don't think you're worth the same as a mid-level engineer, don't apply. You will never get what a dev architect gets, but you should be on the same scale as the engineers below that level. So again, if you don't think you're worth that, don't waste your time. You will work that hard.
Startups are great. I've been with this one for 8 years. Yeah, the hours can be long, and you have to work it out with minimal resources. But it can be a blast, and it can move you forward at rocket speed. So far, here are things I've gotten to do (aside from strictly writing)...
* Implement my own cheap and small embedded help system using FrameMaker and Doxygen
* Implement formatted tooltips (took that whole effort away from engineers)
* Convert my content to DITA
* Invent, implement, and deploy my own online help system that converts DITA to HTML on the fly
* Implement run-time filtering by user role, product feature set, or brand (for OEMs)
* Implement capability to pull real-time data into the docs at run time
* Implement a Jira-to-DITA work flow (gave a talk at LearningDITA https://www.youtube.com/watch?v=9251JCb3zek&list=PL3LkiqjQCkjOUCB0jVvgu2mpXJbtZyJe8&index=14&t=0s)
* Implement the doc side of micro-content (and design the dev/GUI side)
* Manage a tiny team of cool people
In the process, I've contributed a not-insignificant amount of code to the product GUI. And this is along with the regular stuff like planning/writing/delivering docs, contributing to GUI text, contributing to feature work flows, and managing terminology... You should know this full list.
So I would jump at this JD (were I looking). For the right person, this could be an awesome opportunity -- you should check to find out. But it is biased IMO... In favor of somebody who can do all that startup stuff.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | https://techwhirl.com
