Friday Oct 04, 2013

Mentoring the Technical Writers of the Future

Today's blog is from one of our technical writers, Caroline Wissing, from the Service Fulfillment writing team. Caroline has been a technical writer at Oracle Communications for just over three years. She has worked in documentation since 1999 and has mentored many new writers during those years. She took on the role as the primary mentor for the 2013 technical writing interns, who were hired through Ottawa’s Algonquin College co-operative education program. Thanks, Caroline for this blog as well as your support and mentorship of our interns!

Cheryl Lander, Oracle Communications InfoDev Senior Director


Kayla and Rachel’s internship has ended and we were sad to see them go. As our previous intern, Carly, was before them (and is now permanently), they were an asset to the organization during the four months they worked for the Oracle CGBU Information Development (InfoDev) organization. At least the blog post that they co-wrote remains with us to remind us of their contributions, and the experience and knowledge they gained during their time at our office.

But let’s not forget that experience and knowledge go both ways. This was our second time, here in Ottawa, hiring and working with interns and I like to think we learn a little from each experience. In the spirit of reciprocal blogging, I thought I’d chronicle this same journey, except from a mentorship perspective. Each section below details an aspect of the mentorship role and then outlines a few things that experience has taught us over the past two internships.

Interviewing and Hiring

The first step in the process is before the mentorship begins, but is also the most important: hiring the right people.

When we receive the resumes of potential internship candidates, there are typically several resumes to peruse leisurely, from which we can select people to interview. We learned not to be too leisurely in the perusal, however, because if we dragged our heels, we risked the hottest prospects getting snatched up by companies that chose to interview candidates early.

In preparation for interviewing the three or four candidates we’d chosen, we reviewed their resumes in more detail and prepared a set of questions, some of which were generic and some of which we tailored to each individual’s knowledge and experience. We also devised a short writing test with sections that measured skills such as organizing content, writing procedures and understanding the difference between conceptual and procedural information.

After the fun of meeting and interviewing was over, the final selection process started. We ranked the candidates based on the criteria available: resume, interview and test.

This can be tricky because one candidate can have a strong interview but a weak test, and vice versa. Ranking them was based on performance but also on our instinct and their potential. We solicited feedback about the resume and test portions from the wider team. InfoDev leads from the Editing, Architecture and Production departments had the opportunity to weigh in, as well as the management team.

What We’ve Learned

We have learned to trust our instincts about who would be a good fit for our team. Someone who can put procedure steps in the correct order on a test but comes to the interview wearing a tinfoil hat and talking to an imaginary camel is not likely the better candidate. (For the record, neither Rachel nor Kayla wore her tinfoil hat to the interview.)

Preparing and First Day Jitters

There are several things you can do to help interns feel both welcome and better prepared to jump into life at Oracle. They’re here for a good time, not a long time, so the quicker you can get them up to speed, the quicker they can get to work with confidence.

  • Order equipment early and set it up ahead of time. New hires learn about Oracle process by doing a lot of their software setup themselves. However, interns need to get moving fast. It saves time if you can get them in the system and have their laptop ready for them to start working within their first or second day. If their equipment hasn’t even arrived, you risk that they’ll be sitting around idle for days doing nothing more than reading a paper copy of the Oracle Style Guide. They might not come back the following week.
  • Provide the new hire checklist. Whether you print it out or email it to them, have it ready. Modify it if you’ve done any of the tasks for them.
  • Provide a list of acronyms. When interns attend their first meeting and hear nothing but a string of letters, much like this: “The OSM BRD for SR3 with updated RMIs and FEATs is up on the TWiki along with FDDs and TDDs, so InfoDev can create CPs with more accurate LOEs by APM Gate 3,” their heads are apt to explode. Sure we know what that means, but it might as well be Sanskrit to an InfoDev newbie. Remember, they were students the week before and might never have worked in documentation.
  • Provide a list of useful links. Despite efforts to improve navigation, the InfoDev Twiki (the department’s knowledge base) can be a labyrinthine warren and if you go down the wrong rabbit hole, you might never find your way back, or the information you’re searching for. Providing this list helps interns quickly add important links to their browser’s bookmarks list.
  • Make a list of tasks. Knowing what tasks you need them to do, at least for the first month, lets you get them busy and keep them busy. Make sure you give them simple tasks first until they get comfortable with the documentation and process. We created a high-level schedule for their tasks and assigned a mentor for each task. Although this work plan needed to remain flexible to accommodate changing priorities, it helped to guide the intern’s work for the duration of their term.

What We’ve Learned

According to feedback from Kayla and Rachel, and from Carly (who didn’t get one), the most essential early tool we provided for them was the list of acronyms. It’s easy to forget how little meaning there is in an average meeting for anyone who doesn’t know these definitions.

Transferring Knowledge

This internship is for their benefit as well as ours. Never is this symbiotic relationship more important than in the area of knowledge transfer. We could give them just enough information to complete each simple, discrete task, or we could give them the broader perspective. For the latest pair of interns, in their first few weeks, we provided lots of instruction, including formal meetings about the following topics: overview of the APM release lifecycle; using Oracle Review; the bug process; working with RSB; and working with the editor, architect and production team.

One-on-one meetings with their mentor (hopefully) allow interns to ask any question in a comfortable and supportive setting. They also come to the end of their internship with knowledge that’s transferrable to other jobs in the technical writing industry.

What We’ve Learned

Understanding the big picture helps interns integrate more quickly and participate more actively in team meetings.

Providing Support without Doing the Work

No one wants to be micro-managed, not even interns. If given the right task at the right time in their internship, they can accomplish a lot on their own. As long as an identified go-to mentor is approachable and readily available, it’s important to let them use their accumulated skills and new knowledge to figure things out independently.

What We’ve Learned

Tailor the mentorship style to the intern’s individual learning style. Some people like to grapple with a problem, devise a solution, and then solicit feedback, while some people would rather ask lots of questions upfront before they feel comfortable making changes to documentation. Either way, the mentor should check in with interns daily to make sure they aren’t stuck or overwhelmed.


We hope Kayla and Rachel left Oracle with invaluable knowledge and experience that they carry with them to their next opportunity. In turn, we enjoyed four months of their great company and hard work.

We wish them well!

We Value Your Feedback

If you would like to suggest improvements or report issues on any of the product documentation, curriculum, or training produced by the Oracle Communications Information Development team, you can use these channels:

Thanks for reading!


This is a blog from the Oracle Communications Information Development team, led by Cheryl Lander, Sr. Director. She and members of her team from various functions (writers, curriculum developers, and architects) and product lines will share their approach to documentation and curriculum, all with the goal of getting feedback to improve their deliverables. We'd like to thank Joe Sciallo, UCS Tech Writer (former Sun) for pushing us into the social media world. The primary team driving this blog is called "Joe and the Blogettes"; other members include Brenda Roldan (BSS Tech Writer), Jodie Wilford (OSS InfoDev Director), Leif Lourie (SDP Curriculum Developer), and Scott T. Miller (Documentation Architect).


« October 2013 »