Lesson 2016:03

When I left Pearson for the last time as an employee on January 26, 2016, which was 11 months, 5 days (340 days) ago - the day I was laid off - I cared about Pearson documentation.

I still care.

However, I have learned (a-ha!) that I can not control what my co-workers do with the documentation I helped create. I am no longer their co-worker. Yes, I will likely have a morbid curiosity for a period of time. I had that same type of attitude when I could view the Quintrex documentation after I left. Eventually, though, that feeling of ownership dwindles as the balance between what I contributed and what has been contributed since I left tips.

Quintrex? Ah, yes.

When I left Quintrex on October 15, 2010, it was leaving 12 years, 2 weeks (4397 days) of work behind.

I had an empire. I was the only technical writer and every word that went into the online Help, which was seen by the customer, and every word that went into the internal documentation was reviewed by me.

The end-user documentation had started as hundreds of OfficeVision (an AS/400 word processor) documents and a handful of MS Word documents. Over my time there, I had converted that content to WinHelp files (see below) and then to HTML. I can vividly recall that I knew about "span classes" when I initially started working with HTML. I created a CSS definition called "programname" and any time I wanted to have bold, I used that span class. Then I learned about having a separate CSS definition for each "type" of "thing" I wanted to be bold. I defined "check_box" and "dropDown" and "dropDownValue" and was methodically going through all of my HTML files to change "programname" to a specific span class tag. That work was not done when I left.

The internal documentation was called Billopti. That was short for "Billable Options" even though I referred to them as "System Options" in the documentation. Why the difference? In reality, not all "Billable Options" were actually billable to the customer. Some "Billable Options" were standard.

I digress.

When I left Quintrex on October 15, 2010, I really thought I was going to a better situation. I thought I would be able to build the same type of pseudo-kingdom I had built at Quintrex. I thought I was going to do awesome but readers of this blog from October 15, 2010 - April 15, 2011, know the truth.

I digress again. Damnit!

When I left Quintrex on October 15, 2010, I had invested hours upon hours of my own time to learn technologies. I spent hours in the den, downloading WinHelp (.hlp) files and decompiling them to learn how a feature I had seen was done. If it was fairly easy, I would then take that knowledge to work the next day and try to implement it.

When I left Pearson January 26, 2016, I had been with the company for 4 years, 7 months, 3 weeks, 5 days (1701 days), which is obviously not as long as the amount of time I was at Quintrex. Yet, with the Pearson documentation, I really came into a deeper sense of my work. When we shifted from the PDF paradigm to the Wiki paradigm, I was initially not a strong supporter. I knew our existing customers and my co-workers had very specific requirements and I was doubtful they could be met with a Wiki. Initially, the direction was to dismiss those requirements and to not worry about:

1. writing procedures - we would lead the user to the place in the system to do a task but not tell them what to click
2. writing user-role based documentation - we would document all tasks that could be done in the system
3. including screenshots - we would not include screenshots for a variety of reasons
4. creating a printable version - we would not create a PDF because a PDF is instantly out-of-date

Our department had worked in that direction until we showed it to the first customer of the rewritten system. Guess what they wanted? Better, guess what we began to do...

Down the Lane

I read this article - Sympathy Card to a Front-End Developer By Carla Pileggi October 9, 2017 - twice.

The first time, I thought about the low-hanging fruit. Immediately, the story was relevant to my days at Quintrex, the company I worked at from 10/1/1998 to 10/15/2010. The article tells a story about a grieving developer as his beloved system's user interface was being redesigned by the author. At Quintrex, there was a point during those 12 years when our systems had been developed in multiple programming languages and by multiple teams. There was not a single "Quintrex" look and feel. There were rules for using the systems and those rules were dictated by the programming language / team, not by Quintrex, the company. At some point, the decision was made that all of our systems would be converted to (yet another) programming language. It was kind of a running joke. There was always an effort to rewrite the systems in a single programming language and the list of the "chosen" or "standard" programming language was changed several times over the years.

At one point, there was a meeting I attended. The reason I remember this specific meeting is because it was very tense. None of the teams wanted to concede anything about their workflow because, and I get this, their workflow made sense to them and the thought of re-learning the way they did their job was scary. The meeting was riddled with a lot of subtle (and sometimes not subtle) statements, such as these:

---

Your system in your programming language looks bad.
My system in my programming language looks awesome.
As a company, we should adopt the way my team do things.
The way my team does things should be the new standard.
All you other teams should have changed your standards to match mine years ago
No, of course I don't have my team's standards in a document that you can read - we know how to do our job!

---

Of course, no, no one actually said those exact words, but there would have been a higher degree of honesty in the room if someone had actually just said those words.

Recalling that meeting in my brain was intriguing so I reread the article. This time, though, I extracted the Developer reaction text from the article into this blog post. Originally, my idea was to use them as a springboard for writing this post. I thought this post would be summarizing the meeting above only. But then something made me think about something else. But before I get to that, here are the stages from the article:

---

Stage I: Denial

Upon seeing the new sketches, the developer’s first reaction was to deny the reality of the situation.
Developer: “I’m sorry, I don’t think you can even do that in HTML. Errr, no, no…. Technically, this just can’t be done. Sorry.”

Stage II: Anger

Developer: “This is wrong—all wrong. You don’t understand this product. I do. Our users won’t like this. Stop sketching and listen to me! Have you worked on this type of application before? These designs are ridiculous! Why aren’t you listening to me?”

Stage III: Bargaining

Developer: “Um, your colors…. Your colors are good. Let’s just take your colors and put them on the existing user interface. Then, can’t we just leave everything else alone?”

Stage IV: Depression

Developer: “You know, I never really cared about what the user interface looked like anyway.”

Stage V: Acceptance

Developer: “Do all of the new product designs have to be implemented in this release?”

---

As I mentioned, the article is presented in the context of a Developer grieving over the changes to a product he brought to life. As I reread the article, I applied my 20+ years of working perspective, I can apply the Developer's grief to my own work as a technical writer when there is a transition. Over the course of my career as a technical writer, I have gone through many transitions. I will name only one at each employer, but, especially at Quintrex, I went through many transitions:

1. NDP: converting from using OfficeVision to write training documentation to using MS Word
2. JSI: transitioning from being a 'stand-alone' silo-type operation to consolidating each person's information / knowledge into a central repository.
3. QDS: transitioning from documentation being a 'stand-alone' silo-type operation where each Quality Assurance tester wrote or updated documentation to developing a workflow where I was to review the changes to the system and figure out what documentation needed to be changed.
4. Unnamed Hellhole in southern Iowa: honestly, bringing me into the department and having me question the tools we used (InDesign) was a big transition. Also, since I was to focus on creating online Help, that was a very different mindset.
5. Pearson: converting from using MS Word and distributing user guides as PDFs to using Confluence
6. Where I am now: transitioning from being a 'stand-alone' silo-type operation to consolidating each person's information / knowledge into a central repository so that I can publish consolidated disaster recovery documentation

Each of the above transitions had pain points that deeply impacted me as a person as well as me as a technical writer. I credit Carla Pileggi with giving me a new way to look at my past.

Notes from Career Panel

I was asked by Mount Mercy University English professor Carol Tyx to be a member of a panel of MMU alumni that were English majors. The purpose of the panel was to discuss our careers. Prior to the panel, Carol emailed me a set of questions and, using those questions as prompts, I created the following content. This is a selfish post, one that specifies a lot of details about myself and my career journey. To prepare for posting my notes to this blog, I did some minor editing just because it's my blog and I can do that since I own the content.

---

Career Panel Thursday Nov. 20 2:00-3:00 109 Warde

What has been your employment journey since graduating from Mt. Mercy?

Context First

I came to Mount Mercy College in fall of 1988. My goal was to be a high school English teacher. I did a semester of Student teaching in Fall 1991. I did not like teaching – stories could be told about being slapped by a student, breaking up a fight, and going through a faith crisis at the same time - what am I doing here on earth? What purpose do I serve?

To summarize, those are the “highlights” of the “Dark Time of my Life” and by the time I graduated in May 1992, I had concluded teaching was not a career for me.

Since I had gone through my college education with a focus on being a teacher, it was difficult when I realized I had no idea what I could do with my degree.

I began my job search in February 1992 and it ended 3 years later in February 1995 and during those 3 years, I applied to many companies for many positions in many cities.

During the time that I didn’t have a permanent, full-time job, many life events:

• Proposed to my wife in June 1992
  
• Married my wife in August of 1993.
  
• We purchased first house in April 1994.
  

Miscellaneous non-technical writer employment

• Telemarketer at APAC
• Temporary data entry clerk at ACT (Iowa City)
  
• Software Quality Assurance Testing at ACT (Iowa City)
  
• Got an awesome letter of recommendation from manager!
  

First Technical Writer position NDP (Cedar Rapids)

Interview at 8 AM on Friday, February 10, 1995 & signed job offer letter before noon. Words of advice: Always negotiate salary. I was offered $17,500, which was low, so I countered up to $18,000. I should have asked for more. The VP I was interviewing with said that I would have to work that much harder for that extra $500.
Two recurring themes in my career:

• Networking 
• The only reason I even knew about this company was through a friend. My wife and I had a New Year’s Eve party on 12/31/1994. Invited several friends (MMC alumni). One friend was having a “good time” and started talking about how he worked for a great company. If he hadn’t been at our house that night, I would have never known of their existence. There was never a job ad for the position I applied for.
• Focus on content. 
• Don’t rewrite or rephrase what someone tells you should be told to the end user. You should be knowledgeable about your subject so that you pick and choose those details that the user needs.

I worked there for 3 years.

Second Job: Jordan Systems

Jordan Systems had a product that was PC-based software, not AS/400.

Do not fail to value networking! Worked with a MMC alumni who lived on my dorm floor my freshman, sophomore, and junior years. Software on an AS/400 with an interface to a PC. AS/400 used to be a popular platform in the area and you could take programming courses at Kirkwood, but it has since been reduced in popularity and use (at least from my perspective).
Worked there from 2/10/98 – 9/30/98.
Working there was interesting. I had my own office, but it was a small company that had money issues. We used to sit around the lunch table and hope the mailman would bring a check from a customer so that payroll could be met. Went through layoffs – it was a choice between me and a co-worker. Part of not being laid off was the understanding that I would stop doing my technical writing duties and start doing data entry because the company generated revenue from data entry whereas technical writing was an overhead cost.

Third job: Quintrex Data Systems

There was a major life event upcoming: we were expecting our second child and financial security was a must. I sent in a resume for a classified ad in the Cedar Rapids Gazette for a QA Tester. Ad mentioned AS/400 experience a plus. Networking again! The Vice President was a neighbor from birth until about third grade, but he knows my parents and knew me. I worked there a dozen years. My first day was 10/1/1998 and I submitted my resignation on 10/15/2010. A lot of my time at Quintrex was awesome. I was the only dedicated technical writer so I .carved a niche and definitely nested. I was able to branch out into Marketing writing, User Interface design for Windows, and all sorts of other tasks like release distribution (paper copies of instructions & burning multiple CDs). My primary work was to maintain end-user and internal documentation for all their systems. There was a lot of content - multiple 500 sheet reams of paper. I requested and then was sent to conferences in Boston (2004) and Long Beach, CA (2007). I had to adapt to technology changes. The online Help was distributed in a file format called WinHelp. However, Microsoft announced that they were ending support of WinHelp with Windows Vista. This caused a conversion from MS Word to HTML.

This is an important part of my career. Why would I want to leave a good thing and go somewhere else? At the time, these were my reasons I decided to look for a new position outside of Quintrex

1. The company served the Telecommunications industry with software to landline companies.
2. CEO was 65 and refused to reveal his plans
3. There was a subtle change in company culture – documentation isn’t important.

Epilogue: After I left

1. Company was purchased by St. Louis-based NISC
2. The technical writer that was hired to replace me died from a leg clot
   
3. CEO who wouldn’t reveal his retirement plans actually retired in September.
   
4. Did on-site 3 hour training about the tools I had used to write the company’s documentation in August 2011.
   

Unnamed Hellhole in southern Iowa

---

Editor's Note: This section, Unnamed Hellhole in Southern Iowa, is the part of my prepared notes that I didn't get to talk about during the panel. On Friday, I mentioned to a co-worker that I felt somewhat odd that all the talk on the panel was about the "good" that has happened in our careers. Sometimes, there are "not good" parts of a career. Certainly, I hope the students attending the panel never, ever, have to go through what I did. The parallels between this epoch of my life and "The Empire Strikes Back" are easy to sketch as I was definitely going through a time of uncertainty. Life was certainly bleak.

---

To this point, my career had been going quite well. I had worked as a technical writer for nearly 16 years and thought I “knew” all I needed to know about this profession. Working at this place showed me I do not. Thus, I am going to tell you something that you may not hear from anyone else – there are times in life where you will realize you are in the wrong place. I consider this a misstep in my career. Swayed to leave Quintrex with false promises of building the same type of situation I had at Quintrex from the ground up and more money. Quintrex counter offered to keep me, but I didn’t even look at the number because of the above 3 reasons. Should have looked at the number. Traded security for “opportunity” that seemed like a good idea. Learned a lot about myself and my character.

• Began working there on 10/18/2010. 
• Processes in place were wrong. 
• Used a page layout app (InDesign) to maintain 100+ page user guide. ID is fine for brochures, but was the wrong tool for creating online Help in HTML. 
• Manually typed the Table of Contents, then reprinting to verify pages matched 
• Manually drew a line to margin 
• One space or two – use one unless it “looks funny” then use 2. 
• Tedious copy and paste work for other languages. 
• Stopped working there on 4/13/2011. 

Being told I was a good fit for the position has turned into a blessing in disguise. It certainly was not at the time. I had been replaced at Quintrex so I couldn't return. This was a tumultuous time in my life. I was back to searching for a job, as I had done from 2/1992 through 2/1995. I began attending daily mass at our parish. During this time, networking became key.

1. Father of a kid on my son’s baseball team came to a game with a programming language book. Started conversation about it. I hadn’t known he was a programmer. Found out he worked at where I had applied, and that since he knew my current manager, he said he would put in a good word for me.
2. Neighbor’s sister-in-law worked at my current employer, knew my current manager, and said she would put in a good word for me. She was recently reassigned to my department. My cubicle is less than 5 feet from her.
3. Fellow parish member worked at my current employer. Had known her for 20+ years. She knew my current manager, and said she would put in a good word for me.

Eventually, I interviewed with my current manager, and then followed up with HR, who told me I was the “top candidate” for the position. That thought still makes for a nice ego stroke. Job offer came via phone call during supper. When I was told what the salary was for the position, it was higher than I had imagined and took me by surprise to the extent that I didn't even try to negotiate! Always negotiate.

What kind of work do you do currently?

Software documentation

What skills are needed to perform your job?

These are ideas that are not limited to my work at my employer – spans all of career. Given: you know how to arrange words in an order that is clear and easy to read.

1. Ability to analyze and use previous knowledge to make decisions about new situations.
2. Critical thinking skills
• If you are told the system should create A, but you have never been able to create A in the system – you can only create B, what is different? What steps did the person telling you A is created take to achieve that and where are the differences between your knowledge where you only see B and the knowledge of the person telling you should be able to create A?
3. Teamwork Skills
• You have your strengths and you have your weaknesses. 
• I work on a team where my strengths (tools) and weaknesses (project management) are balanced out by others on the team.
4. Compromise
• Our department had a recent discussion about expand / collapse. This became my pet peeve issue that if you search for a keyword in the "site" search and the keyword is found and you click the search result to go to the page that the word is supposed to be on and you do a page-level search for the same word, if that word is in a collapsed section, you wouldn’t be able to find the word that your "site" search listed in the search results. We were collaboratively working on a user guide where the original design of a page had 7 expand / collapse sections and the word I was using as an example was in the seventh collapsed section. 7 user clicks to find information – making the user do more work than necessary. To go along with this, there is often more than one way to write something. Negotiating a style that you will use to make them read as if one person, one department, wrote all of the documentation.You could write:
  
• To do A, click B.
• or
• Click B to do A.
5. Philosophical differences
• There are different approaches to any situation. 
• Your experience is just as valuable as your co-worker’s experience.
6. Do not be totalitarian in your opinions and dismiss others’ opinions. 
• Who is the best writer - Shakespeare or Chaucer? 
• Often there is no right answer so you have to use the skills you gained from being an English major to analyze the situation and make a decision.

How might an English major prepare for the job market?

1. Embrace technology.
• You don’t have to own the latest / greatest gadget or use the latest / greatest Windows operating system or Mac operating system, but you should be familiar with it. I knew nothing about computers when I graduated and consider myself to be dangerous enough to think I know what I’m doing when it comes to trying to remedy laptop or computer issues.
• The trend is for companies to use social media to research you as a candidate. Your online images and words create an impression of you by people you may never meet.
2. Understand the value of a recent backup
• Consider if the device upon which you store your music collection or even your term papers for this semester were to suddenly not work. I was using my work laptop when I suddenly got an odd Windows message. The end result is that I lost a lot of data. I’ve also lost music files that were created by converting from CD to MP3.
3. Humility
• You are not the gift to writing that you think you are. You will encounter multiple people in multiple situations where what you think is “right” is exactly what they think is “wrong” and your challenge is to and Embrace that person’s opinion. Make yourself learn from that person. Adapt your world to incorporate their knowledge to improve yourself.
• Side note: In my experience, everyone thinks that they are a writer. The quip I’ve often heard is that “writing is easy. After all, it’s just typing words.” My value as a technical writer is the ability to choose the words that communicate the information the user needs and to put those words in the correct order. At every position in my career, there was always a co-worker that believed they would be able to do my job “better” than me. There is probably a person on this campus that has the same interests as you and may think they are as skilled in that interest as you are. 
4. Soft skills
• Being able to work on a team. 
• Recent Gazette article: http://thegazette.com/subject/news/soft-skills-hot-commodity-among-employers-20141019 
5. Develop good habits
• Decide that you’re going to do something at 3:30, M-F, and then track whether you follow through with doing it. 
• If you don’t follow through, analyze your motivations for not following through. 
6. Don’t be discouraged by the advertised jobs you will come across. When you go to Rockwellcollins.com or ACT.org or Corridorcareers.com, searching for "writer" or "write" will not yield many results. 
• Expand your search criteria or, perhaps, don't specify any search criteria and simply scan all available jobs. 
• There's many job titles for a "technical writer" such as "documentation specialist", "technical communicator" and so forth.

Is there anything you wish you had done while you were a student that would have prepared you more effectively for the work world?

1. Take programming classes, especially if you are interested in writing software documentation. As someone who writes about software, a basic understanding of the logic and approach to programming - what it takes to create the systems I write about – would be helpful. You can learn on your own.
2. Take a basic business class and/or accounting class. Economics, ledgers, taxes. I was in a position where I did technical writing contracts outside of regular work. Have no idea if what I did was correct or not, but I did it. <grin>
3. Spend time in the computer lab helping users solve issues with computers and software.
4. Try different things that are outside of your comfort zone. Have preferences, know what you’re good at, but don’t pigeon-hole yourself into a limited area.

 

Acceptance Gives Me

I get a daily email called "Thought for the Day" and today's thought is this:

---

Acceptance gives me the experience of being like an angel: never judging, never criticizing and never worrying.

---

It's so ironic that I just read those words because I don't do well with accepting things in life. I really don't. I don't accept many decisions I have made, both personally and professionally. In the personal realm, being sober for nearly 5 years - 12/31/2015 is my five year anniversary - is just one example of where I have refused to accept my past behavior and incidents I was involved in as being the way I want to live my life. Because I can choose to drink booze or to not drink booze, the decision to live a sober life is mine alone.

Professionally, though, is a different story. I've made choices in my 20+ years as a technical writer that I wholeheartedly refuse to accept. It would seem that leaving Quintrex, now NISC, can easily creep up to the top of that list. I write that because, in the background of all that is going on in my life, I've learned that Quintrex, now NISC, is looking for a technical writer. I pasted the job description below. This is the company & position I had for a dozen years. Since I left there on 10/15/2010, Quintrex had hired two women - Laura & Kathy - to do my former technical writer duties. Tragically, both of those women have passed away.

I knew this position was going to be posted and I know that even though it states the location is Missouri, I would be considered for this position upon submission of my credentials. In my private journal, I've pondered the idea of submitting my resume for the position below. There was a time in my life, including almost immediately after I left, when knowing I could apply for my former position was all I prayed for. I filled page after page in my private journal with desperate words of my desire to return.

However, the way my career played out, I ultimately did not even have the opportunity to return because, as I mentioned, my replacement(s) had been hired and there was not money for a third technical writer position, if I recall correctly. I went on to be hired at my current employer and tomorrow will actually be 4 years, 6 months, and 3 weeks.

It will also be 5 years, 2 months, 6 days since I worked at Quintrex. I know for a fact that a lot has changed there since I left. I still have friends that work there and I still keep in touch with them. I've heard from them that NISC, the new owner, is a good company, which makes me happy for my former co-workers.

Anyways, this is the current opening and the ball is in my court as far as applying for it or not. I'm honestly 50 / 50, at this point. I like where I am and I like my co-workers immensely. I like the fact that I am able to spend a lot of my time focused on the tools side of technical writing, such as identifying where there are differences in

Position	Technical Writer
Location	Missouri
Primary Responsibilities	This position reports to the QA/Technical Communications Team Lead. Has a high level of internal customer interaction, including all NISC divisions needing written technical communications. Works closely with the Quality Assurance team, as well as with Member Support Subject Matter Experts (SMEs) and RDQ developers. This position is responsible for the writing and editing of operation and maintenance documentation for NISC’s software applications, technical systems, and technical publications, as well as other Member-oriented publications.
Disclaimer	Management may modify this job description by assigning or reassigning duties and responsibilities at any time.
Essential Functions	·         Writes new and modifies existing technical documentation and technical publications according to set standards regarding order, clarity, conciseness, style and terminology. ·         Gathers and organizes source materials such as design and test specifications, design diagrams and schematics. ·         Investigates and studies material used through examination of systems, diagrams and interviews. ·         Establishes organization-wide user documentation standards for online and printed documentation. ·         Works with low level of supervision on technical projects or assignments. ·         Works closely with Quality Assurance and SME (Subject Matter Experts) in planning projects and meeting deadlines. ·         Prepares CRs (Change Requests) for developers to complete to adhere to Technical Communications Standards. ·         Completes CRs as assigned by developers, QA or Member Support. ·         Utilizes all technical development tools as directed, including the repository, StarTeam, Subversion, iSupport, Caliber, as well as various other tools when deemed necessary. ·         Writes other Member-oriented publications, such as brochures, release notes, web pages, newsletters, training documents, job aids, etc. ·         Answers basic questions regarding application screens and processes responsible for documenting. ·         Develops web-based training modules following established standards and processes. ·         Follows standard practices to resolve moderate to complex problems. ·         May be required to travel. ·         May be required to attend training seminars online, internally or at various external locations. ·         May be required to participate on design review boards and change review boards regarding enhancements to technical documentation. ·         Prepares weekly status reports for Team Lead as well as attends weekly technical communications status meetings.
Minimum Physical Requirements	The physical demands described here are representative of those that must be met by an employee to successfully perform the essential functions of this position. Reasonable accommodations may be made to enable individuals with disabilities to perform the essential functions. Employees must be able to see, speak, and hear, to operate computer keyboards or office equipment, and are required to stand, walk, and sit.
Desired Education	Bachelor’s degree in a related field such as English, Journalism, Communications or Computer Science or equivalent experience.
Desired Job Experience	·         Generally requires 3 to 5 years of technical writing experience either at NISC or at another company in a technical writing profession. ·         Excellent writing and proofreading skills with strengths in grammar, punctuation and spelling. ·         Working knowledge of NISC’s applications. ·         Working knowledge of other integrated applications and services. ·         Strong verbal and written interpersonal and communication skills. ·         Strong research and problem solving skills with a good attention to detail. ·         Ability to organize and prioritize a large volume of work. ·         Strong PC skills including a working knowledge of Microsoft Word. ·         Working knowledge of Macromedia software including RoboHelp and RoboDemo. ·         Working knowledge of writing using HTML code. ·         Working knowledge of capturing and inserting graphics into documentation. ·         Ability to interact in a positive manner with internal and external customers. ·         Ability to work in a team environment. ·         Knowledge of the Rural Electric industry. ·         Ability to travel as necessary. ·         Commitment to NISC’s Statement of Shared Values.
Certifications Required	None
Other Qualifications	None