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.
This is good and I think what's interesting is normally in a career you do a one-off thing along these lines and you think, at the time, "Gee, that was pretty interesting," and then you forget about it. But it can be a bullet point on your resume or LinkedIn profile.
It's not that you're going to pitch to somebody to be a DevOps 100% of the time, but if it's something you enjoyed, you might have the chance to do it again. Even regardless of that, the bullet point adds value, because this is not something that's normally associated with Tech Comm.
It makes me think back to so many things in my career that were one-offs that never made it to the resume and yet were pretty interesting.
Another option is to look at skills inventories to get ideas.
This isn't about building a resume so much as thinking about things differently.
Thanks, Tony.
Steve
On Wednesday, September 07, 2016 11:16 PM, Tony Chung wrote:
Another tangent that happened to me this week. I was asked months ago to teach a hands-on workshop at our corporate conference. While preparing the lab document, which participants could take with them, I also had to set up the system to model the training objectives.
Our system required a lot of testing and server configuration to ensure everyone started at a known state. I had to perform a lot of the testing, troubleshoot the log files, reimage the environment and prep the materials again.
I performed more as a DevOps than a writer. Chances are, our innate business analyst understands the technical material from the user's needs, and we speak to those needs in order to position our technology as a solution.
Tony
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
