I recently gave a talk at at internal Amazon conference for tech writers. I was a technical writer from early in my career, and still consider tech writing one of my foundational skills. In the talk, I hoped to provide some insight to other technical writers about their own skills, and how those could be used in other roles. I’m sharing all that information here, in case you also find it useful. (It was an hour-long talk, which makes for a very long blog post!)

Introduction

This is the first time in my 30 year plus career that I’m doing a very autobiographical talk.

It will cover my career arc to date, starting with how I developed the skills that made me a good tech writer – even though I never planned to be one. Nor have I planned much of anything else about my career. My life has been unusual, and most of my career has been about adapting to the situations I found myself in. The process of reflecting on my career in order to write this talk has been interesting – in some ways painful, given some of what’s going on in the world – and I hope you’ll find the stories interesting as well as useful.

There’s a subtext throughout this talk that I’d like to call your attention to now, and that is: doing all the things I’ve done, while also being part of a marriage, raising a child, and running a household, has not been easy. I often did not have support at home, let alone in the workplace. And yet… I persisted.

And, in spite of everything, I have survived in this industry which – in spite of everything – I still love. For over 30 years now.

Some Takeaways

Here are some of the interesting tidbits you might take away from this talk:

• History of technical documentation
• Online communication since 1982
• Changing styles of communication
• The early days of the Web
• Historical snapshots of tech in other countries (Italy, Cameroon, India)
• Customers know more than you do
• Early experiences in working remote
• You can work with your life partner and not kill each other
• How to survive 30 years in tech without a STEM degree
• Agile career development

I didn’t know what the demographics of this audience would be, so I didn’t know how many would be surprised to learn that I pre-date the Internet. I now know that I pioneered a lot of things, such as writing in a user-friendly way rather than using marketing weasel talk – I was doing this before the Cluetrain Manifesto came along. I was also providing customer support online in the very early days of the Internet. As part of that work, I was treating customers as a community who could be brought together to share knowledge for the benefit of an entire ecosystem.

I didn’t realize at the time that I was a pioneer. I mostly saw myself as doing what should be done for customers, often because they had directly told me what they wanted and needed.

You might say I was an ante-litteram Amazonian. (And I’ve been a happy Amazon customer for over 20 years.)

How I Became a Tech Writer

This was my third grade school picture. As you can see, I’m left-handed. Hand writing was hard for me, as is true of many lefties. I loved words, but the mechanical process of getting them onto paper was painful and difficult.

Around age ten, I learned to two-finger type on my Dad’s Selectric typewriter.

In high school, one of my statements of individuality was to write in magenta fountain pen ink. I’m sure all my teachers were relieved when I took a typing class and my dad gave me a portable typewriter of my own. I began typing all my papers, and sometimes others’ as well. I never looked back; I’m a keyboard person for life. My keyboard skills eventually launched me on my career in tech.

In high school, I also worked on the school newspaper and the yearbook. These gave me valuable skills in the production and management of what we now call content, as well as more writing and editing. And, like many teens, I wrote bad fiction and worse poetry, which fortunately is now lost to history.

I’m also a reader, always have been – and I’d argue that it’s impossible to be a great writer without being a great reader.

First Manual

I wrote my first ”manual” during my senior year in boarding school – a handbook of school rules and other practicalities. Lists of rules had already existed in some written format, but it was all very dry and forbidding – not what you’d expect teenagers to read and absorb. I tried to make the same basic material fun and engaging enough that my peers would actually read and use the information. I have maintained this friendly, informal tone in most of my writing since, which has worked particularly well in the age of the Internet. When I last visited the school a couple of years ago, I was told that my Survival Kit was still in use, though of course it’s been through 35 years of revisions.

Early Equipment

I should point out that I do not have a STEM background, nor does anyone in my family. In college I took the bare minimum of science and math courses needed to complete my BA. I took one course in programming – Pascal – my freshman year. This was on VAX UNIX terminals; I just missed the punch card era. I did not feel any particular proficiency at or enthusiasm for programming. In hindsight, this may have been because the course was poorly taught. At any rate, that was the extent of my formal education in computers.

In 1982, while I was a student at the University of Texas, my father bought me my first computer, a Commodore Vic 20. This was a computer built into a keyboard (you had to use a TV for a monitor). My dad claimed that this was to help me learn programming, but for the first few months he was mostly using it to play Space Invaders while recovering from knee surgery. I did eventually get to use the Vic 20, though I still did not learn programming.

Online for the First Time

When I was able to prise the Vic 20 out of my dad’s hands, I quickly discovered what computers were really for: communication. I joined CompuServe in 1982, at that time the province of a few thousand geeks. The first thing I found on CompuServe was the chat rooms – which predated IRC – called CompuServe CB chat. I immediately became fascinated with being able to communicate online with people I hadn’t yet met. In those days, it was so novel that we went to some lengths to have regional meetups.

the CompuServe gang gathers at the Texas State capitol

My CompuServe addiction was cut short by my dad’s unwillingness to pay the bills (I think it cost about $6 an hour). It was a while before I was regularly online again, but that early experience in communicating online became important later in my career.

Have Typewriter, Will Travel

As I mentioned, I have no STEM background. My undergraduate degree ended up being in Asian Studies and Languages, partly because I had grown up in Asia and had a special interest in India, where I went to high school, but also because I was given federal scholarships that covered my tuition as long as I was studying ”exotic” languages like Hindi and Urdu.

The scholarships covered my tuition and my dad helped out with rent, but to earn pocket money, I worked. Early on, I worked as a typist, which often meant that I ended up providing free editing services as well – I couldn’t bring myself to commit bad grammar to paper, even when it was someone else’s bad grammar.

Around 1983, I got a part-time job doing typesetting and word processing on very early electronic machines. I learned markup language, without knowing to call it that, as well as layout and word processing: all skills which I still use today.

Another job I had during college was as a secretary in the Commercial Section of the US Embassy in Jakarta. This involved learning to use a Wang word processing system, with tractor feed printers that jammed all the time.

Those Who Can, Teach

After college, in 1986, I began working as a secretary, which by then meant learning to use Word Perfect on early PCs. Because I was curious and willing to dig in and learn, I became the office expert on the software, often helping and teaching others.

Then I started working in a startup headed by a friend of my dad’s. Initially I did desktop publishing as a service, using Ventura Publisher on the GEM interface (later, on Windows 1.I-don’t-remember). This was pretty easy for me to learn, given my background in typesetting, word processing, and PCs. The boss was taking on whatever work he could get for the company, which one summer included hiring a friend of mine to write a software manual. I sat alongside my friend and did the layout, so I learned something about writing documentation, while adding to my skills in production.

I also started developing and delivering training to others, such as US government employees, on how to do desktop publishing. My training style was to teach the concepts, then have people work on their own projects so that the lessons would stick. It was apparently effective. I also made two trips for the World Bank in 1988, installing desktop publishing systems and teaching people how to use them, in Cameroon and Tanzania. These photos were from the Cameroon trip:

In all these training courses, I was working directly with users and could see first-hand how they understood things and what concepts they had trouble with. I learned to adapt my teaching style to the audience in front of me,  another important skill for a tech writer. And I had to continually extend my own abilities. For example, for the Cameroon trip I was bringing electronic equipment into a harsh environment: extremely humid, with unreliable electricity. Beyond the software and concepts of desktop publishing, I had to know how to troubleshoot, strip down, and rebuild the PCs, and be able to teach my students how to do it.

Both of those trips were great fun and I learned a ton, but … then I married an Italian math professor, had a child, and moved to Italy.

Getting Started – in Italy

By the time we arrived in Milan in January 1991, I had been mostly a stay-at-home mom for about 18 months. I was anxious to get back to work, but Italy’s job market was difficult even then, and it functions very differently from the US one. (I’ve never been very good with job hunting in the US, either.) I was in for months of frustration.

I started freelancing for Italian computer magazines, writing articles in Italian. One of my first pieces was a review of The Manhole, a kids’ game from the people who later went on to do Myst. This photo was used in the magazine; that’s my daughter, then two years old, playing the game.

Freelancing didn’t pay much, but there were perks, such as occasional travel to tech events.

Then I began working for Fabrizio Caffarelli at Incat Systems, his small software startup in Milan. At that time, tech startups in Italy were vanishingly rare. The Italian business climate was not friendly towards small, new businesses, so Fabrizio was very unusual in being a Silicon Valley-style tech entrepreneur operating in Italy in the 1990s.

My first project for him was a manual for an OCR software he was producing. Because his market was mostly in Italy, what I wrote was translated, more or less simultaneously, by Fabrizio’s niece. When that project was completed, Fabrizio said: “I like the way you work, but I don’t have any more work for you right now.” So I went on vacation, wrote some more articles, and began thinking maybe I should write a technical book. A few months later, while I was still casting about for a topic, Fabrizio called me and asked: “Hey, do you want to write a book with me?”

The Book

So we did.

“Publish Yourself on CD-ROM” was partly a marketing ploy on Fabrizio’s part. When we began writing it in late ’91, CD recording was still difficult and expensive, using command-line driven software on machines that cost $100,000 and were the size of a mini-fridge, burning discs that cost $100 each. It was easy to screw up a command and waste those expensive discs. Fabrizio foresaw the advent and eventual popularity of low-cost, desktop CD recorders, and that there would be a need for easy-to-use software targeted at home users. He put together an engineering team to start developing this software.

The book had to explain difficult concepts that at the time were covered only in expensive standards documents from Sony and Philips. I learned by reading those, and by talking with Fabrizio. In the book, I tried for a friendly tone that would invite people in rather than scare them off.

We didn’t get much of an advance on the book, and Fabrizio took most of that, so I made some extra money by doing all the layout and indexing for the book myself, using Framemaker.

The book was one of the first in the world to be published with a CD, which contained a trial version of Easy CD 1.0. I also produced a screen-readable, hypertext-rich version of the text, also done in Framemaker (because Adobe PDF wasn’t quite ready for use then, though I was aware that it was coming).

This showed me early on the power and flexibility of electronic texts. At the time, I saw hypertext as a way to make books even more useful as aids to learning. For example, our book had an extensive glossary, and I linked occurrences of glossary words in the text to the glossary, so the reader could pop up a definition at any time while reading. Remember, all this was happening in 1992, before most people had heard of the worldwide web. The book was published by Random House in early 1993.

All About CD-R

By the time the book was published, I was working full time for Fabrizio doing documentation – here you can see some of my output.

I also did OEM versions of manuals for all our software, which forced me to be clever with tools. I was using FrameMaker with variables to automatically generate vendor-specific versions of each manual. I also learned how to deal with business partners, as I was working directly with those OEMs on their documentation needs.

Incat being a startup, we all wore many hats. Other things I did for the company included all aspects of manual production. And I got heavily involved in the software itself: I worked with the engineers from the beta stage or earlier, testing and reporting bugs, and making suggestions for interface and feature improvements. I realized that, if a feature was hard to explain to users, it probably wasn’t implemented correctly in the first place, and we should be re-thinking it. I also wrote and implemented the context-sensitive help in the UI.

Other things I did included writing and editing marketing materials and other collateral, helping sales staff with technical information, and giving talks at industry trade shows and other seminars and lectures.

Most importantly, I was communicating online with customers. I was a Section leader and participant in CompuServe forums, participated in Internet mailing lists on related issues, and monitored CD-R related Usenet groups. I was the first point of contact for online support. That sometimes spilled over to helping out on the phones as well.

For any job in tech, I strongly recommend spending some time doing support: you learn fast that way about customer pain points.

In late 1993, Fabrizio moved the Italian engineers to Silicon Valley. I began traveling there four times a year to work with them. In August of 1995, the company was acquired by Adaptec for $48M, which was a good exit for the time. I began working for Adaptec as a contractor, because they would not hire me in Italy.

The Problem with Paper

Writing documentation has never been easy, and it was even harder back in the 90s. A software release had to be finished enough that you could work with it, and then after writing was completed you also needed time for printing and packaging. Software releases were infrequent for these and other reasons, and documentation usually lagged customer needs.

Paper manuals were also expensive to produce, print, and distribute. Even the help screens and context-sensitive help within the software could not be revved any more frequently than the software itself. All of this was starting to feel very cumbersome.

Sometime around 1993, I remember sitting in the back of a bus on my way to or from work in Milan, reading a copy of the Seybold Report that I’d borrowed from the office. There was a small article – just a box, really – about this new thing called the World Wide Web. I remember thinking: “That’s going to be important.”

As we entered the Web 1.0 age, customers’ expectations of company responsiveness increased, and our old, slow, expensive processes were no longer sufficient. We needed a way to provide customers with updated and expanded information about our software, on demand (in response to FAQs and newly-discovered bugs as they arose), and at low cost.

I started creating pages for a website, even though I had no idea how to get it online. I called up UUNet, then one of the largest Internet Service Providers, to try to learn more. The person I got on the phone told me rather rudely that our company was too small to have its own website. One of the souvenirs I’ve kept from that era is a UUNet hat given to me by a friend. AFAIK, the company is no more.

Moving it Online

By the time the acquisition of Incat was completed, Adaptec had its own brand-new website, and I had pages ready to post on it. These were created with the rudimentary HTML tools then available in Microsoft Word. Not long afterwards, I found myself responsible for the busiest section of the Adaptec site, eventually bringing in 70% of overall traffic.

I was happy to hand off my responsibilities for printed manuals to someone else, and it was around this time that I stopped referring to myself as a technical writer. Nevertheless, I saw myself as doing essentially the same job: helping customers understand how to use our software. I just kept expanding the ways and means I used to do that.

Web Apps

Another thing I figured out early on was that some kinds of information are better structured as an app or searchable database than as a manual or web page. Again, I was moving away from the traditional narrative style of documentation, towards something more interactive and updatable.

And I started crowd-sourcing useful information, such as where to get a good deal on recordable CDs, before anyone called that crowd-sourcing (or even “user-generated content”).

Communicating with Customers

I had begun to interact daily with customers online around 1993, and I soon learned to value their knowledge. No QA or tech writing team can match the thousands of hours with a product that a large pool of users will collectively spend. Nor can an internal team hope to duplicate all the diverse situations in which customers will use something. When we tap into what customers know about our products, we all benefit.

I was an active participant on Usenet forums: answering questions, keeping an eye on hot issues, and conveying customer feedback to engineering and management. These feedback loops helped improve the customer experience at every touchpoint, from the software to the documentation to support and service.

In 1996, at the request of customers, I launched a moderated, email-based discussion list where we could discuss CD-R in depth, without the distractions of Usenet trolls. (Yes, there were trolls back then, too.)

A lot of useful information flowed through these forums. Part of my job was to pick out what was important, edit and organize it, and disseminate it again via other channels. Again, it was a feedback loop, helping to address customer needs as quickly and thoroughly as possible.

Newsletters

The original Majordomo discussion list became too active for some people, who requested a weekly newsletter instead. At first I simply condensed and edited the most interesting and useful stuff from the discussion list. Then I started writing topical articles, and eventually hired freelancers – other experts I knew in CD-R – to contribute. Later still, we had separate Windows and Mac editions. Over time we accumulated 160,000 subscribers between the two lists, and most of that growth was organic.

The reply-to on all these emails was my own email address. This meant that people could ask more questions immediately, and they did. I replied to every email myself.

The articles were archived on the website, and over time I had to grapple with how to organize an ever-growing mass of information so that people could find what they needed, even when they didn’t know they needed it. I added information architecture to my skill set.

I was also still doing customer support on the Usenet (CompuServe had pretty much died by this time). I hired two people to help out with that, one for the Windows side and one for Mac. We all worked closely together to keep the information feedback loop going.

And btw – all three of us worked remote. I was still mostly in Italy, Adrian was in the UK, and Brian was in Texas. I had hired Adrian without ever meeting or even speaking to him, purely on the basis of how well he grasped the concepts and communicated them online. And he was great at the job.

Key Skills as a Tech Writer

• Typing (fast)
• Writing (fast)
• Editing
• Layout
• Markup
• Deadlines
• Basic graphics and design
• Information architecture
• Listening to people
• Helping different types of people communicate with each other
• Communicating effectively and politely with anyone (almost)
• Exploring new media and means of communication as they come along

This is a non-exhaustive list of key skills I had developed by this point in my career. I’m pretty sure that, as tech writers, all of you have these skills as well. As you’ll see, all of them have continued to be useful in my subsequent jobs.

Key Traits

• Willingness to learn by doing/using/figuring it out
• Empathy for people (users/customers)
• Creativity
• Extreme attention to detail
• Project management
• Ability to meet deadlines
• Inability to leave things alone – it can always be better, right?

I’d also say that we tech writers have some key traits which can serve us well in other roles. Almost any role, really.

Roxio

By 2000, Adaptec had decided it didn’t want to be in the software business after all, and would spin us off as a new company, Roxio.

As webmaster, I led the design and development of the first Roxio site. It may have been the first to include a user community area and other features that would later be classified as “Web 2.0.”

The project to create the new site, including putting the platform in place to run it on, required me to be in the office to work closely with my colleagues. From mid 2000 through early 2001, I was flying back and forth between Italy and California every six weeks, working 14 hour days, and trying do an MBA on the side as well. Needless to say, this period was exhausting, though it was also fun in some ways.

I was moving away from being a specialist in CD recording. As it turned out, that was the last technology area in my career in which I felt myself to be a true, deep subject matter expert. For years after that, I cringed and apologized at my lack of depth in other technical topics. It took me a long time to understand the value of what I bring to the table beyond specific subject matter expertise.

The Dot Com Crash

In early 2001, after a failed attempt to get my family to move with me from Italy to Silicon Valley, I returned to Milan. In July of that year I quit my job with Roxio, in part because my mother-in-law got cancer. But I also saw the dot com crash coming, and I was particularly vulnerable because I was working remote again. I would have been laid off within months anyway.

I wrote a farewell email to my newsletter and discussion lists, and was a bit surprised at the response. I knew from emails over the years that people had found what I was doing useful. I had not understood the extent to which they felt a personal connection with me, and loved my writing. Perhaps the biggest compliment I ever got was that my clear writing style reminded someone of JK Rowling.

A few people explicitly said: “I want to read whatever you write, not just about technology.” That was a surprise, and I took them up on it.

Personal Website

I started writing about my life in Italy and other topics that happened to interest me. At first I sent this stuff out as another newsletter, but it obviously made sense to have a website of my own.

I learned DreamWeaver from Lynda.com, and off I went.

Over the next couple of years I still had some freelance work in documentation and UI, mostly thanks to former colleagues still working on CD-R. But that dwindled away, and I had a lot of time on my hands to learn more about websites. One critical new skill I started developing during this time was metrics: I learned to collect and analyze the logs from my own website. Around this time, a few people were making serious money with early forms of website monetization, via Google AdSense and others. I never made much money, but I learned a lot in trying to understand how it could be done. In particular, I learned about driving traffic to websites, at a time when social media was not yet an option.

TVBLOB

Around 2003, my old boss Fabrizio founded a new startup called TVBLOB. His new idea was to create a set-top device that would allow the family television to be used for two-way communication. I joined this effort, with a terrible commute to Milan because we now lived on Lake Como, and at very low pay. Nonetheless, I was interested in the task of creating a unified customer experience, from UI design to customer support and service.

The point of the product was to make it easy to communicate over the Internet using video. As part of my research, I wondered how difficult it would be to do that in a browser, at the current state of web technology. I began experimenting, and quickly learned that it was very difficult indeed. You had to shoot analog video, digitize it, compress the hell out of it (because bandwidth was so tight in those days), and somehow embed it and get it to play back in a web page.

I stumbled onto the Yahoo videobloggers group, whose early members included the people who went on to found all the video hosting sites. Yes, even the YouTube guys were briefly part of that group. Others stuck around longer, and many of the early videobloggers are still my friends. I was enjoying playing around with video as a medium. I experimented with video tutorials, such as this one about how to connect up our TVBLOB box.

Fabrizio was paying me very little, and my dot com savings were dwindling away. For family reasons, I needed to be making real money again.

Sun Microsystems – Blogs & Other Content

I pinged an old friend from Adaptec who was now working for Sun. He brought me on as a contractor for the Solaris Storage Software group, initially focused on getting engineers to blog. Sun had made a big push to get everyone blogging a few years before and had thousands of blogs, but many had never got beyond one or two posts.

At Sun, I was definitely not a subject matter expert. This was all deep systems stuff, and there was very little that I could write myself. My job was more about encouraging, assisting, and in some sense managing engineers to write blog posts. I was able to help bring a few blogs back to life, but it soon became clear that many people simply didn’t have the time, skills, or interest to keep a blog going.

My manager said: “You’ve got some video skills, let’s use that.” He bought me a videocamera, and I started traveling to conferences to film technical talks being given by Sun engineers – from the engineers’ point of view, having me film and produce their talks added nothing to their workload. This was a few years before most conferences started routinely filming talks themselves.

I filmed at many conferences, but I soon went beyond that. If an engineer had a talk but no immediate conference to deliver it at, I’d film them in the office. I even filmed a series of short videos about ZFS in my own living room. One day, three of Sun’s top performance engineers all happened to be in San Francisco (one of them visiting from France), so I grabbed a conference room and spent half a day capturing conversations among them about performance topics.

I encountered some resistance to publishing my videos externally, from the Sun branding people and professional video crew. Sun had a video studio, but it was expensive and was used mostly to film executives talking about launches and earnings. The few times engineers were asked to film there, they were often rushed through in an attempt to save money on studio time. Most of them were not experienced at being on camera, so some would get nervous and the result would be unusable video. I had time to be patient and encouraging, so I could get good camera performances out of the rankest amateurs.

The material I was filming was also more interesting to Sun’s users, who were highly technical people uninterested in marketing messages. I ended up filming a lot of deep technology talks, which you can still find on my YouTube channel.

As ever, I tried to share my meta-knowledge. I ran internal workshops on how to do video, and, though I wasn’t keen on being in front of the camera, I made and shared videos of myself talking about how to do video.

Community & Content

I joined Sun full time in early 2008, moving from Italy to Colorado. I was part of a small team within Solaris engineering whose job was to encourage the adoption, use, and community growth of OpenSolaris worldwide, and to improve communication between Sun engineers and external developer and user communities. Our activities included user group workshops, technical events, and content.

This was my first involvement with open source, and thanks to all the content I was producing, I quickly became very visible in the open source world. I was not only filming events now, but also live streaming them and running social media feeds – usually carrying out all these activities simultaneously!

In 2010, I survived Oracle’s acquisition of Sun, but not in my community manager role. I was put into marketing and essentially told: “Your little videos are all very nice, but leave that to the professionals – you go write white papers.” White papers were a means of communication whose effectiveness I had been questioning for some time.

I was still working closely with engineers, attending weekly meetings with various dev teams. I still did video at a few events such as the last Sun Tech Days.

In late 2010, I left Oracle for a cloud startup called Joyent. There I wore two hats: head of training, and community manager for SmartOS, the Solaris-derived operating system that Joyent ran on. Again, I was managing the production of all kinds of technical content, as well as developing some of it directly myself: training courses, blog, wiki, web pages, videos.

Editing Books

Between 2010 and 2013, Brendan Gregg, who is now my partner, wrote two books. I ended up being heavily involved in both: copy editing, managing expert reviewers, marketing, and just generally listening and encouraging. If you are or have ever lived with an author, you’ll know that they are single-minded while a book is in the works. For however long it takes to complete a book, that’s all you’re going to hear about. I was so thoroughly steeped in each book that at the time I didn’t fully grasp the new skills I was developing in editing deeply technical content. The two books together ran over 2000 pages, so I definitely got a lot of practice. Of course, this has been a huge help in later work, especially now at AWS.

Ericsson

In mid-2014 I followed Jason Hoffman, one of Joyent’s founders, to Ericsson, the Swedish telecom, which was starting a new cloud hardware and software business. Within six months of joining, I was diagnosed with breast cancer, but I wanted and was able to keep working through most of my treatment.

I was doing a blog and social media for Ericsson, but I also managed to produce a handful of new web pages on the Ericsson site. This was very difficult to achieve, as the site was still running on Interwoven Teamsite, a software platform that had been installed in 2001 – I had in fact used Teamsite for the Roxio site back in the day! The Ericsson site could only be updated by a handful of expensive contractors who still knew how to use Teamsite.

We needed a much more ambitious and easily-updated site to support Ericsson’s cloud business, which would have been impossible on the existing platform. I pitched for and won the opportunity to create a new site on the new platform that Ericsson was then slowly putting in place. Ours would run ahead of the overall project as a pilot. I got approval for this in late September or early October of 2015, and I had a hard launch date: Mobile World Congress in late February, 2016. With a hell of a lot of hard work, alongside some great colleagues and vendors, and several trips to Stockholm in the cold, dark winter, I pulled it off: the site launched on time, the morning that Mobile World Congress opened. It was running on the Episerver CMS and integrated the Hubspot inbound marketing tool, which hosted the new cloud blog.

I picked up a lot of new skills during this time, including going deep on SEO, as well as extending my project management skills. But this job was still primarily about producing technical content, and making it inviting and usable. My work always comes back to that.

By mid 2016, I was managing a team of interns and contractors (some of whom later became full-time employees) to create, produce, and analyze the results of web content, blogs, and social media. I greatly enjoyed managing and mentoring people, and passing on my years of skills.

That all went well for a while, then Ericsson had a series of disastrous earnings announcements. I held onto my job, but found myself doing the work I’d previously had interns and contractors doing. Once again it was clear that, if I stuck around, I was in danger of being laid off. I started job hunting again.

Amazon Web Services

In June, 2017, I joined AWS as part of the Open Source team in the marketing organization. I’m the Open Source Content Lead: it’s my job to help spread the word about all the things Amazon is doing in open source.

The week before re:Invent 2017, I launched the new AWS Open Source blog. It has very broad scope: I can cover basically anything open source that’s worked on, created by, or runs on AWS, as well as open source projects from other parts of Amazon. I also manage the @AWSOpen Twitter handle.

Summing It Up

Though I stopped calling myself a technical writer years ago, I never stopped being one. Being a very good writer is still my core skill, and everything else flows from that. The additional skills and traits of a tech writer have also continued to serve me well in all the variety of jobs I’ve had.

I think all tech writers have those traits as well and, as you’ve seen, they can all be applied in a huge variety of roles – even though most people wouldn’t choose to do it quite the way I have.

I wish you all success and happiness in whatever comes next for you, and if you think career advice from me would be helpful, please feel free to ask!

You might also like:

The Place for Me My New Job Resumé / CV The Evolution of a Technical Writer – Bringing Documentation Into the Web 2.0 Age