Technical Writing Training Course in Singapore

A 1-day intensive course for anyone (engineers/writers) who want to know all about technical writing, documentation process, documentation types, and Knowledge Management System. If you're an engineer, you will learn how to write a technical report/technical paper. If you're a copywriter or content writer, you will learn the nitty gritties to jumpstart into technical writing.

What will be covered in this course:
  • Different types of writing
  • What is technical writing
  • What is not technical writing
  • What is science writing
  • Difference between scientific and technical writing
  • Purpose of writing
  • Four key writing metrics
  • Technical writing process
  • Managing technical writing projects
  • How to write a Technical Paper - Guidelines & Style Guide
  • How to write a Technical Report - Guidelines & Style Guide
  • How to write a Technical White Paper 
  • How to create a template in Microsoft Word
  • Grammar for authors
  • Introduction to Knowledge Management System (KMS)
  • Knowledge Management Models 
  • How to develop and organize your KMS
  • KMS Metrics
  • Recommended KMS tools 

Contact me at, or call +65 82086393.

Technical Writing, Training, and Documentation Service Provider in Singapore

    The Journal of My Technical Writing Career

    A brief about me

    As a child, I dreamed of pilot, as a young boy I dreamed of being a doctor, but there are dreams that cannot be and storms we cannot weather. I am now a Writer in the business of informing, persuading, and evangelising through white papers, engineering blogs, Standard Operating Procedures, Developer Guides, User Guides, and Online Help. I am the bridge between engineers and end users, communicating the technical knowledge, arousing the reader's curiosity.

    The process of learning excites meI love to research and convey complex information in a simple, understandable, and user-friendly formats. I am energised by the steady and deliberate journey from ignorance to competence. The thrill of breaking the barrier of ignorance, the early efforts to pen what I have learned, the growing confidence of a subject being mastered motivates me.

    Technical Writer
    As a student, my goal was to be a top ranker in the class. I performed well in my studies and ranked among the top 10 students. On rare occasions, my rank slipped below my expectations, but I always bounced back. Life’s biggest goals were finishing exams, scoring well and traveling to my hometown - Kottayam, an adventurous journey by train for three days and two nights, passing through hills, mountains, rivers, fields, and tunnels. 

    After tenth, like every student in the science stream, my goal was to be a doctor or an engineer. I let go of all extracurricular activities and focused only on studies. In XII, most of us had private tuitions on top of what school teachers were already providing. But things didn't work out as per my plans. I did not qualify for an Engineering or Medicine seat. Based on the merit system, I enrolled for the bachelor's degree in Science from the M.S. University of Baroda

    While in the first year, I still pursued my dream. I studied for medical entrance while I was doing BSc, but due to clashes in the examination dates, I let go of my dream and carried on with a renewed mind. I scored 62% in the first year and expected similar performance in the second year but to my surprise, I scored only 52%.

    During the final year BSc., I decided to pursue Masters in Computer Applications (MCA) and prepared for MCA entrance examination. To qualify for the entrance examination, I needed to score at least 60% in the final year BSc, so that the average of the second and third year comes out to be 55%. By God's grace, I managed to score 62% in the final year. 

    I appeared for the MCA entrance examination in May 1998. It was a miracle from God to see my rank in top 10. 

    When I attended the first semester classes, the subjects were very different from what I had studied until then. The programming languages were foreign to me. The only subjects that I was comfortable, were Maths and Economics. During the first year, I performed badly in the programming languages. But from the second year onwards, my grades improved. In the last semesters, I did projects at ABB and Railway Staff College. That was the time when I was exposed to the 'Internet' for the first time. In the overall three years of MCA curriculum, I scored first class. Praise God.

    During the college days, every student's goal was to get through campus interviews. In the fifth semester, 2001, companies like Amdocs, TCS, Patni, Wipro, MBT hired more than half the class of our MCA graduates. But in the later part of the year, due to dot-com bubble burst coupled with World Trade Center attack, companies canceled or postponed their job offers. It was a blow to those who were given job offer letters. Miraculously, I managed to get into a US-based startup company - Amtel Security Systems. I was interviewed by Suresh Gajwani, the founder, when he was on a visit to Baroda.

    At Amtel, I was involved in documentation, technical support, gathering customer requirements, writing persuasive RFP responses, assisting sales in identifying customer's business requirements and delivering technically correct solutions, testing, and even purchasing controllers and chips. I had a hands-on experience with almost everything except coding. I loved the RFID and security products and enjoyed my work there.

    I worked at Amtel for two and half years, but there was no salary increment. I decided to change the company. By this time, my programming skills got rusted, and I lost the passion for coding. The only option I had was to work as a Testing Engineer or Sales Engineer. While browsing for jobs in newspapers, I came across a post of Technical Writer that caught my attention. Until then I was not aware of a post called Technical Writer. 

    I gave two interviews, one with Impetus Technologies for Testing Engineer and another with Zensar Technologies for Technical Writer. I remember traveling Ahmedabad to attend the Impetus Technologies interview. Zensar conducted my interview via telephone.

    While in Kerala for our house-warming event, I first got the offer letter from Impetus. 
    After reaching Baroda, I put forth my resignation and joined Impetus, Indore in Feb 2004 as a Software Testing Engineer. That was the first time I started living independently away from my parents. I was given a week's accommodation in a hotel. 

    Cross Roads
    Two weeks later, after joining Impetus, I got the Zensar Technologies offer for the post of Technical Writer with a better salary. I was in a dilemma whether to accept the offer since I was happy with the role of Software Testing Engineer. After much pondering, I decided to go for Zensar's offer that established my career as a Technical Writer, a road not taken by the MCA graduates.

    Two roads diverged in a yellow wood,
    And sorry I could not travel both
    And be one traveler, long I stood
    And looked down one as far as I could
    To where it bent in the undergrowth;
    Then took the other, as just as fair,
    And having perhaps the better claim
    Because it was grassy and wanted wear,
    Though as for that the passing there
    Had worn them really about the same,
    And both that morning equally lay
    In leaves no step had trodden black.
    Oh, I marked the first for another day!
    Yet knowing how way leads on to way
    I doubted if I should ever come back.
    I shall be telling this with a sigh
    Somewhere ages and ages hence:
    Two roads diverged in a wood, and I,
    I took the one less traveled by,
    And that has made all the difference

    At Zensar, I wrote documentation for the UML tool - BluePrint Foundry, created a help file using a freeware tool “Cheetah”, and wrote ADDL syntax Programmer’s Guide.

    Sometime in Oct 2004, I received an email for Technical Writing position with Samsung Electronics, South Korea. It was a great opportunity. I decided to appear for the interview by flying to Bangalore from Pune.

    After landing Bangalore, I took a taxi directly to the Samsung office. When I entered the meeting room, I was surprised to see a room full of Korean nationalities. The interview went well, but I was not sure of my performance.

    In November 2004, through God's favor, I received the confirmation letter from Samsung about my selection.

    During the same time, I received another offer from a company in Pune, but I decided to join Samsung Electronics. I resigned from Zensar Technologies on 10th Jan 2004.

    I arrived S. Korea on 21st Feb 2005. It was one of the coldest days with temperature below minus 15 degrees. You can read about my experience here I was with the Flash Management Software group, Memory Division, responsible for creating product documentation and white papers for Samsung's XSR, Whimory, RFS, and TFS4 file systems.

    Memory Division, Samsung Electronics
    Memory Division, Samsung Electronics
    The best part of working in Samsung, Korea was that they provided fully furnished flat, festival bonuses during Chinese New Year (Feb) and Chuseok Festival (Sep), performance bonus equivalent to 2-3 months salary, year ending completion bonus, two-way flight tickets to your home country, relocation allowance, and zero tax for foreigners with Master's degree and 3+ years of work experience. 
    Samsung Electronics Residence
    A view from my flat in S.Korea
    I enjoyed the weather in Korea especially the snow in winter. Some of the beautiful places I love there are Jeju, Busan, and Seoul. The company provided free Korean language training.

    When I joined the Memory Division, it was the most profitable division of Samsung Electronics. But in 2009 due to the global recession, the company suffered loss, and the management decided not to renew the contract for foreigners. Most of my colleagues opted to work in Samsung India, Bangalore.

    Before the turn of these events, I had decided to work in the UK. In October 2008, I applied for the Tier 1 work permit (HSMP) and within a week, it was approved. I could stay in the UK and look for a job without requiring any company to sponsor my work permit.

    After my contract with Samsung, I arrived UK in March 2009. But it was an economic recession there too. I stayed at Cambridge with a Nigerian family for a monthly rent of 350 pounds. It was through them; I got the chance to attend the African-American Worship service at the City of David Church - one of the most vibrant and energetic people I ever met in my life. While staying in the UK for three months, I managed to get three interviews in Bristol and Cambridge, but no success. I decided to return India to continue my career as a technical writer. On June 2nd, 2009 I left Cambridge and came back to my hometown - Kottayam. In the mid-June, out of blue, I received an email from a consultancy in Singapore for the post of a technical writer with Savi Technology - A Lockheed Martin Company

    Singapore was never in my radar. I had never dreamed of working there. But God had a plan for me.

    There were five rounds of telephonic interview with Information Development (ID) Manager, Principal Writer, ID Director, Product Manager, and Vice President of Savi, Singapore. By God's favor, the interviews were successful, and I was selected to work in Singapore for Savi Technologies. I was supposed to join on July 15th, 2009 but later I discovered that I could not travel since my passport validity was less than six months. I applied for the tatkal passport in Kochi and got my passport after seven days. It took another one week to get my employment pass from the Singapore MoM.  I was provided the flight tickets and two weeks accommodation at Spottiswood Park, Tanjong Pagar. On July 26, 2009, I arrived Singapore and joined Savi Technologies. It was my first experience to work in an Agile Scrum environment.  I wrote SDK Installation Guide, User Guides, Installation Guides for Savi’s SmartChain RFID applications, using  XMetal as a Single Sourcing tool for generating content in various formats such as Online Help, CHM, and JAR files, and performed quality assurance and usability testing in the process of producing user documentation.

    Savi Technology Collegues
    Savi Colleagues
    After working there for a year, in August 2010, due to company's financial performance, the US office decided to outsource the development work to the Pune office in India. Nobody expected the closure of operations in Singapore.The employees were given the choice to work in India, but nobody opted for it. In the middle of September, through God's favor, I received two offers, one with Philips Electronics and another with Tagit Pte Ltd, for a one-year contract. I was in dilemma to choose the company since both offered the same pay package but I decided to go for Tagit. My responsibilities were to create user guides, installation guides, and training materials for the mobile banking application, Mobeix. 

    In August 2011, history repeated itself. Due to the financial situation, Tagit started cutting staff, and I was also laid off. Since I was employed through consultancy, they tried their best to find another client but no success. Meanwhile, I applied for PEP and got approval within three weeks. I could work for any company in Singapore without requiring a company sponsored work permit.

    In the first week of October 2011, I got an interview call for a technical writing position with PayPal, an eBay company, at Suntec City, Singapore. It was a six months contract position. There were four candidates vying for the same post. On Oct 10, a day before my birthday, I got confirmation about my selection. Praise God. My responsibilities were to create API documentation for their SOA based financial instrument services. 

    On February 29, 2012, I received a call from the consultant informing that my last working day would be on April 16th, 2012. I was taken by surprise since I expected an extension of my contract.

    I started applying for jobs. In the third week of March 2012, I got an interview call from JDSU Test & Measurements Singapore Pte Ltd, a US based Telecom company. I attended the interview and within two weeks, I received confirmation about my selection. All praises to my Lord and Savior Jesus Christ. One thing I know for sure, God can do it again and again when you call Him. After my selection, PayPal wanted to extend my contract for three more months, but it was too late.

    After working at JDSU for three years and two months, the company split into two different groups, Viavi Solutions, and Lumentum. Because of the split, it carried a burden of 50 million USD. To manage the expenses, JDSU decided to close the R&D division in Singapore, phase by phase. I was given a month's notice period. The company provided the relocation expenses and three months salary for the number of years I worked.

    A week before leaving Singapore, I got an interview with NextLabs, through referral from an ex-colleague. I cleared the first round which comprised of a written test, interview with a product lead, and with the director. The second round was a telephonic interview with a senior writer in the US. I cleared that and then there was a third round of telephonic interview scheduled on 29th July with the VP of the R&D division from the US. 

    I also had an interview scheduled with a different company on 30th July, but my visa was valid until 26th July. I went to ICA Singapore, to extend my visa, but it was denied.

    While in India, I completed the third round of the telephonic interview and submitted three references of my previous company as per the NextLabs HR policy.

    After two weeks, I received confirmation of my selection. The company applied for my Employment Pass, which was approved within a week. Praise God for His favor. After I joined the company on 26th August 2015, I came to know there were other candidates vying for the same post. 

    Life was going smooth, I was enjoying the workplace, people were cooperative, there were new products coming up that needed constant documentation. We went for occasional team outings and were having fun. In the month of March 2017, we got our salary after a delay of 2 weeks. It was the first sign of financial trouble. During the quarterly all-hands meeting in May, the CEO indicated about the possibility of pruning the workforce if the situation didn't improve. I was nonchalant. On June 7th, when I entered the office, the admin was not in her seat. I came to know she was let off the previous day. At 1 pm, as I was about to go for lunch, the director called me to a meeting room. I was informed that it was my last day in the office. With all the leaves and 2 weeks notice period, my official last day would be July 4th. I would get my salary until July 4th but I need not come office. I was calm. I knew God was in control and something better would turn up. As I was packing my stuff, there were few other employees given the termination letter.

    I started updating my resume on the job sites. I managed to attend 5 interviews in a span of 2 months. That's a great miracle in itself. Some of the interviewers gave high hopes as if they were about to hire me the next day but at the last moment they backtracked.

    I got confirmation from Xchanging, a DXC Technology company, but they wanted me to relocate to Kuala Lumpur, Malaysia. I gave my consent for relocation and they applied for my EP. Two weeks later, I got an interview offer with Veritas Technologies, in Singapore for a one-year contract. They confirmed my selection after a week. I had to renege the Malaysian offer but it was cordial. Since my Singapore visa was valid until 4th August, we left for Kerala on 31st July. Meanwhile, the company applied for my EP on 3rd August, MoM approved the application on 25th, and I joined the company on 30th August. All glory to my Lord Jesus Christ.

    At Veritas, my primary responsibility was to complete the documentation for the GovTech Singapore Backup-as-a-Service Cloud project. I finished that by the end of December 2017. There was not much documentation work after this project. In Jan 2018, I applied for the technical writing position with a "reputed" startup company in Singapore. It was a permanent position. There were 2 rounds of interviews. In February, I received confirmation about my selection. I submitted my resignation with Veritas, gave 1 month notice period, and joined the new company in April 2018! All Glory to God!

    Why Hire Me?

    I am surprised to see advertisements from high-tech companies in Singapore, looking for Technical Writers with just 2 to 3 years of experience. I believe it is because of the cost factor to hire experienced writers with 10+ years of experience. But the companies that adopt such an approach are unaware of its effect on the documentation quality. Technical documents are designed to convey information clearly and persuasively but there are no definite, measurable standards to judge. It's possible that writing can be error-free and still not communicate effectively. There are no algorithms for writing. It takes years of experience and mentorship for writers to come out with quality documentation. The key to writing a good document is that it has to be a good experience for both - the writer, and the reader. The satisfaction of the writer and the reader are interwoven.You wouldn't want a novice taxi driver to ride you to your destination. Nor would you want a novice doctor to treat your medical condition. But writing? Can everybody do it? If your documentation is written by engineers, you risk satisfying your customers. Check this link for potential costs of poor or missing documentation

    Technical Writing is an art as well as science. We practice our craft to service the reader. We don't expel raw material; we transmute it to provide what the reader most wants.Technical Writers are not magicians who can generate content out-of-blue. We need a thorough understanding of the product before we can come out with the first draft. That's why it's important to interact with product engineers, testing engineers, and product manager to gain a first-hand knowledge of the product before coming out with the first draft. 
    When a writer has to work on multiple products, it is economical from the company's standpoint, but from the writer's perspective, it does not allow him to master the product.  Time is critical when a writer has to work on multiple products.

    My Advantage
    • Excellent interpersonal skills
    • Excellent communication skills 
    • IELTS score 8
    • Master of Computer Applications (MCA) and Bachelor of Science (Physics)
    • More than 15 years of writing experience with reputed companies
    • Mentored by professional Writers and Editors
    • Expert in using documentation tools such as XMetal Author, Robohelp, Altova XML Spy, Adobe FrameMaker, Microsoft Word, Microsoft Visio
    • Expert in creating API Documentation, SDK Developer Guide, User Guides, Installation Guides, White Papers, Training Materials, and Standard Operating Procedures (SOP)
    • Worked in Agile Scrum and Waterfall environment
    • Expert in working with version control tools such as GIT, Tortoise Subversion, ClearCase, and Snapshot CM

    Domain Experience
    • Telecommunications
    • Electronics
    • Mobile applications
    • Software
    • Security Systems
    • Financial Instruments
    • Client-Server applications
    • Scientific instruments

    If you have any questions, or you want to hire me, send me an email at

    If you want to outsource your writing and documentation projects, visit, email:, or call +65-82086393. 

    Principles of Technical Writing

    This post provides a look at the "technical writing principles" I've found useful in helping writers to become highly effective and valued as a member of an engineering team.

    Have a positive attitude
    You have to know how to collaborate and be a good judge of people. Additionally, you must be willing to interact with different personalities of the people you are working with. There is an innate skill to draw information out of people or get your work reviewed by the SMEs without aggravating them. The success you experience as a writer depends 100% on your attitude. Sometimes, you may be given an assignment that has nothing to do with user documentation. But you must display a positive attitude towards such requests. 
    Quality should be the priority
    Your job is to make sure that your work is complete, correct, thoroughly fact-checked, and technically reviewed. Make sure that when you start something, you actually
    complete it. If people know they can rely on you to do high-quality work, you will win the trust.
    Communicate, Communicate, and Communicate
    Writers should strive to be superior communicators, as ineffective communication leads to confusion and reflects poorly on the entire team. The writer will be judged by the quality of his work. For better quality, communication is the key factor:
    • Documentation Plans - Make it clear to all stakeholders' what document outputs to expect at any given point of time in the product life-cycle.
    • Review - Use the Google doc or Adobe Shared Review process to receive feedbacks.
    • Communication via emails/chats/meetings - Keep the stakeholders informed about the progress of your documentation. Use the email meeting to schedule appointment with SMEs, and Product Managers. Ad-hoc chat also works depending on your relationship.
    Know your assignment
    Like it, or not, writers are 'contractors’ who are hired to provide User Manuals, API documentation, Training Materials, Engineering Blogs, etc. Technical documentation is meant for users of the engineering product. The users may be within the company but external; they may be engineers or layman. Understanding the users will help to improve the quality of the writing and, ultimately, the quality of the product.
    Avoid ambiguity
    This implies "Never presume" and clarify whenever there is ambiguity. Making speculation about how a product’s features/functionality, schedules, etc. will lead to a variety of issues:
    • Wrong content
    • Incomplete work
    • Bad impression on the documentation team
    Writers must avoid ambiguity in the documentation so as not to muddle others.
    Inhale and Exhale Content
    Writers 'live and breath' content. They consume content, and they create content. Practice your craft to serve the readers. Don't expel raw material but transmute it to provide what the reader most wants.
    Trust facts - Question assumptions 
    Related to the principle of avoiding ambiguity, writers must never make assumptions. As doing so can have a significant impact on the entire business.
    Writers must:
    • Work with the cross-functional team to address issues with requirements, user stories, etc.
    • Clarify schedules/expectations when in doubt.
    • Leverage documentation plan to articulate and set expectations on the documentation.
    • Track/manage outstanding issues until they are resolved.
    • Ensure a thorough document review by engineers and stakeholders.
    Think innovation
    Regardless of your busy schedule, writers must think out-of-box. Improvement ideas should be socialised, shared and investigated with managers and writers. Small changes can make a huge difference to the organization. Innovation that can benefit the documentation is always welcome.
    • Tweaks to processes, templates, style guide
    • Suggest better tools
    • Use videos where possible
    Remember, the companies are always looking for ways to increase efficiency and make the most out of the limited documentation budget.
    Embrace restrictions
    On the surface it may appear as if style guide does, in fact, restrict the writer; however, if you dig deeper you will discover that style guide helps by improving communications by establishing consistency in all the documents.
    Plan wisely
    A well thought out and a documented plan is worth its weight in gold. The documentation plan is the primary tool used to set expectations for all the stakeholders. There is a limited budget for documentation, and it is your responsibility to ensure the effectiveness of the plan such that it provides the highest ROI (Return on Investment).
    Identify priorities
    At the end of the day, the most important Technical Writing principle is "If you do not know - ASK".  Writers are expected to ask questions until they are confident that they have the information needed to write content. Just remember, unanswered questions contribute ambiguity to the content and add risk to the business.

    If you have questions, email me at 

    How I write a White Paper

    An Overview of  White Paper

    White papers are a favorite marketing tool for companies. Companies aim to sell products as solutions to their customers through a white paper. The white papers educate readers and enables them to make decisions in choosing the solution that suits their needs. In this case, the white paper becomes an excellent marketing and SEO tool that advertises the company's products or services. Check this link about when you need to have a white paper.

    But writing a white paper is a challenging task. It involves an in-depth study of the product and its application, gathering information from the subject matter experts, and reviewing the product design documents. The objective is not only to convey information but to spark reader's interest to engage him in reading the rest. Precision and clarity are the watchwords. Naked facts are not enough to invite a reader's invitation to the rest of the document. It's their context- the writing, the container of the information - that illuminates facts for the reader and gives them significant meaning.

    A typical length of a white paper varies from 8-12 pages.

    How I write a white paper

    I meet the product owner, understand the requirements, check the target audience, ask for a date of completion, and request for an introduction or a demo of the product.

    After the preliminary discussion, I do my own research. After gaining sufficient knowledge, I write the first draft, juxtapose words, and convey information that gives a richer experience to readers.

    Occasionally, the first draft may not meet the expectations. Every good writer knows that the first draft of any piece of writing rarely resembles the polished, final version. It can be due to many factors such as I might have missed certain features, or it might not have been discussed in the first meeting. I then have a second round of discussion. This is when I get new insights. I capture these intricate details and put them in my second draft. This draft is almost a perfect piece. Over the years, I have learned that a writer needs a tough skin, for no matter how advanced one's experience and career, expert criticism cuts to the quick, and one learns to endure and to perfect. Writing is
    iterative, and a text reaches its full potential through multiple drafts, feedback, revision, and editing.

     Principal components of a white paper

    • A good page layout - A good page layout ensures that language, graphics, and colors combine on a page to promote clear communication. Readers of the page will find it pleasing and easy to read even though they may not be conscious of all the page layout techniques.
    • A title that arouses curiosity - A good title is the title of a successful white paper. A good title is like coming to a house you have never been in before and having the owner open the door and say "Welcome". A good title can make a tremendous difference in the early acceptance of a white paper.
    • Table of Contents - TOC help readers in two ways: 1. they outline the structure of the document and thus provide insight into the document's organization. 2. they provide the page numbers for all sections and subsections, thus helping readers to locate parts of the document.
    • Background/introduction to the document - The introduction sets the stage. It normally includes the historical background of the product and establishes the scope of the product. In essence, the introduction is a road map, it orients the reader by providing a context for the reading. In short, the introduction prepares the reader for what will follow. 
    • Graphics - Graphics are essential for conveying key information in the white paper. Readers will recall one impactful graphic long after they have forgotten a thousand words of text. Create visuals first, write text last. Graphics are more emphatic than text and should, therefore, be designed early in the writing process.
    • How the product solves the problem
    • System functions
    • Benefits of the product.
    • Architecture of the product
    • Evaluation criteria for choosing the product
    • Conclusions

    If you need help in writing a white paper, email me at or call +65-82086393.

    Essential Tips for Writing a Technical Article

    Writing a Technical Article

    Tips for Technical Writing

    • Get to the Point  - Your objective is to make the reader understand your topic quickly. The readers are not interested to spend hours reading the article.
    • Avoid wordy phrases. A fundamental of good writing style is to avoid unnecessary words.  Do not say All of a sudden. Just say, suddenly. Instead of a later date, say later. The shorter, simple words or expressions make your writing more concise and, consequently, make it look and sound more professional. 
    • Keep it Short and Simple - Write short sentences by eliminating punctuation without affecting the readability of the sentence. Use fewer commas, more periods, and no semicolons at all, if possible.
    • Improve the Presentation - Always provide a brief description of the subject followed by steps to achieve. Provide screenshots where possible.
    • Improve your Template - Use numbering if the steps are to be performed in a sequential manner otherwise use bullets. The title and headings should convey the subject matter. The headings, steps, and body text should follow a consistent format.
    • Use a Style Guide - Follow your company style guide. Otherwise, use Chicago Manual of Style or Microsoft Manual of Style.


    How to write an engineering blog?

    Writing an engineering blog is like a marriage between art and technology. You need to be a good story teller to write a blog. That’s my expertise as a Writer. For the technology part, I depend on the SMEs. 

    Engineers should look at blog posts as a way of crystallising ideas like the code.

    The major challenge is to identify what to blog. 

    Being an engineer, you have insights into technology that may not have been elucidated. You need to ask what others do not understand, and how can I explain it clearly. You can also highlight the specific problems that you encountered, methods that proved to be a workable solution, and some advantages/disadvantages of alternative solutions.  

    As a writer, my role is to sieve the content from the fat. I give life to the technical jargons like characters in a novel. 

    Six principles for a good story telling are: 1. Absence of lengthy verbiage; 2. total objectivity; 3. truthful descriptions; 4. extreme brevity; 5. audacity and originality...and; 6. show and not tell.

    The two basic building blocks of a story are the anecdote and a moment of reflection explaining what it all means. In other words, the most satisfying structure for a story has a simple pattern: action followed by summary.

    The purpose of the anecdote is to draw the reader into the action, and the point of the summary is to tell the reader why the story is being told in the first place. 
    The topic sentence is the opening in the paragraph where we routinely set forth our purpose. 

    Once the draft is ready, the next step is editing - fixing the grammar, spelling, and punctuation. Make sentences short and easy to read. Write in the active voice. Trim wordings if the sentence can convey the meaning correctly. The presentation and grammar are equally important. They help express the meaning.

    Check out this link for writing best practices

    If you need help in writing an engineering blog or editing, reach out to me at, or call +65 82086393.

    9 steps to create Technical Documentation

    1. Read the Marketing Requirements Document (MRD) and functional specification. The MRD should list out clearly the documentation requirements.
    2. On the basis of MRD and functional specs, create a documentation plan that includes
      •  Product name, scope, and purpose
      • Milestone dates 
      • List of documents that will be created and/or updated. If the project is about updating an existing product, list the features to be documented. If the project is about releasing a new product, additional planning is required. There are multiple customer documentation deliverable types a project could require, ranging from a single-paged addendum to a context-sensitive online help system.  
      • Features that will be documented
      • Work estimate and committed schedule for documenting each feature or completing each document 
      • Committed documentation milestones
      • Documentation Reviewers including review schedule. There are 2 ways to conduct a review, collect edits individually from each reviewer or hold a review meeting to review everyone's comments. Multiple reviews may be required. You can also use Adobe's Shared review process to collect feedbacks from multiple reviewers.
      • Depending on the program, include any training material needed for the Launch.
      • Risks, assumptions, and dependencies. Include the following: Main risks of the documentation project (e.g. last minute feature additions), probability of each risk, Impact of each risk, Risk mitigation plan, Owner of the mitigation plan)
      • Affected BOMs and/or document numbers
      •  Doc approval process and approvers (outside the tech pubs team)
      • Documentation delivery and distribution plan.
    3. Distribute the plan to the core team members: PLM (Marketing), R&D lead (Engineering),  and PM (Program Manager) who will review and approve the plan.
    4. After the approval, create the draft document by attending the core team meetings, interacting with the application, studying design documents, asking questions to the testers/developers.
    5. Send the draft to the reviewers identified in the documentation plan.
    6. Update the documents as per the review comments, address all the major and critical documentation CRs and defects identified during the documentation validation.
    7. Obtain the documentation approval from the designated reviewers/approvers.
    8. Generate the final version.
    9. Check in the final document into the build branch.
    If you have any questions, or you want to hire me, send me an email at If you want to outsource your writing and documentation projects, contact Geenu Ann via email or call +65-82086393.

    Technical Writing in an Agile Environment

      While working as a Technical Writer in Savi Technologies, Singapore, the company strictly followed the Agile Scrum methodology. I was in the Typhoon team. Every day the team gathered in one of the cubicles to discuss what we did the previous day, plans for the day, and any blocking issues. During the initial days of my joining, I came across the below slangs that were foreign to me
      • Scrum Team: A scrum team typically consists of five to nine people that include a Scrum Master, s/w engineers, testing engineers, and a technical writer.
      • Stories: I used to wonder why they call the feature request as stories. Is it some new adventure stories of Hardy boys or Enid Blyton’s? But I liked the term ‘stories’, It describes why you want that feature to be included in the application.
      • Product Backlog: The “product backlog” is the list of stories in order of priority. The stories at the bottom of the backlog tend to be just ideas and perhaps still rather big chunks. They must be broken down into smaller stories as they approach the top of the list. Some people use the concept of an “epic” to group related stories and keep them together as they approach the top of the list. The requirements are collected in a prioritized product backlog by a product owner.
      • Sprint Backlog: The “sprint backlog” is the list of stories to be tackled in a particular sprint. During the sprint planning meeting, the project team determines which backlog items go into the sprint. No one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. The sprint must end on time. If requirements are not completed for any reason, they are left out of the release and returned to the product backlog.
      • Sprint: The iterations and incremental cycles in Agile are called sprints. This is an analogy to what happens in a race. We essentially "sprint" towards a race for completion of the development of software, testing, and documentation. The “sprint” is a period often three weeks during which the development happens. During the sprint, the Scrum team works in close cooperation and meet every day to discuss and resolve any problem.
      • Sprint Planning Meeting: There’s a planning meeting at the beginning of the sprint and a retrospective meeting towards the end. The idea is that each sprint delivers a potentially shippable product. In the retrospective meeting, each members' performance is evaluated. Members are free to criticize one another. During my tenure, the ID team received both appreciation and criticisms. But at all times, we took the criticisms in a positive manner and ensured that mistakes were not repeated.
      • Scrum defines 3 roles: The product owner creates and prioritizes the backlog, defines the stories, decides what goes into the next sprint. The scrum master works with the team, fixing anything that’s stopping the team from working. The team does the development.
      • Story Points: When estimating the stories, they use “story points” depending on the number of man hours and resources to finish the task. The story points are expressed as a number, based on the relative complexity of the work required. All the members are given a points card and each member decides points that need to be allocated for completing a task. And based on the majority of votes, the points are allocated. And they need to justify, why they think, the user story deserves that much points.
      • Burndown Chart: This is a graph and lets the team know how much work is left and completed in the sprint. We used Rally to generate the chart. Using this tool, any member of the team or a person outside the team can see at a glance whether the team will complete the work for the sprint.
      The good part about Agile development is that writers are involved in the product planning, and the documentation development timeline is factored into the product release. Being part of an Agile team has the advantage of making you and your work far more visible. We all met in a meeting room for the sprint planning to commit the deliverables. We used a tool by name Rally to define our goals, achievements, pending tasks, etc.

      In an Agile environment, developers, QAs, and writers work together to meet the deadlines. In addition to the documentation, I also tested new features and logged the defects. This helped me in gaining good product knowledge. 

      Two key points in ensuring a successful scrum are 
      • having a set of agreed deliverables and 
      • breaking the assignments into small tasks that can be estimated and tracked 
      In Agile, any problem that member's face is the team’s problem. The role of the Scrum Master is to get rid of any impediments interfering with your work. For example, if you cannot start your documentation because developers haven’t finished coding, then that becomes an obstacle. You can request them for a sample prototype. You do not have to wait until the completion of the coding to start the documentation since that can cause your work to spill over to the next sprint. 

      I believe that every company that hires a technical writer should have a well-defined process. It's paramount for documentation development to be integrated with the software development.

      If you have any questions, email me at