Making Collaboration Happen

By Managing Perceptions and Controlling Emotions

Pawan Nayar

8 December 2001

This presentation discusses ...• Importance of collaboration in technical communication• Existing perceptions that hamper collaboration• Important milestones in a typical document development life

cycle (DLC) for initiating/sustaining collaboration• Tips/best practices for effective collaboration/document review

… in a manner that helps you to• Identify unnecessary perceptions and emotions • Take actions that develop better professional relationship, and as a consequence, facilitate better collaboration

• Technology & pace of development makes writing difficult

• Technical communicators are NOT always technical people

• Document should be zero-defect

• Clarity, consistency, and correctness

• Organizations need to groom their talent

• Technical communicators write for typically 8 software developers

• Need for outsourcing, telecommuting and cross-geography product development

• Technical communication is difficult

Importance of Collaboration in Technical Communication

Collaboration: Opportunities and Challenges

Roles CollaborationOpportunity

Perceptions/emotions toavoid

1. TechnicalCommunicator(TC) /InstructionalDesigner (ID)

Peer review Sharing best

practices Improvement

suggestions Load sharing

Promises to review docs,seldom reviews them

Tries experimentation onother’s deliverables

Does not add value

2. TechnicalEditor

Grammaticalcorrectness

Structuringsuggestions

Ideas for writingdifficult topics

Consistency in ruleusage

Competitiveevaluation

Over-reviews Tries to enforce own style

of writing Highlights spelling errors

and seldom congratulatesquality work

Differs in successivereviews

Roles CollaborationOpportunity

Perceptions/emotions toavoid

3. Graphic/Multimedia Artist

Design cover page Create complex

flows Create element/logo

banks

Tries to be creative ratherthan logical

Is fussy about details

4. Integrator/Internalprogrammers(Delivery Editor)

Create/implementmetatags, templates,document formats

Makes complex processes Needs to be reminded of

pending work

5. DocumentationManager

Feedback onproductivity

Career coaching Top-level doc review

Actions are pre-decided Always assigns difficult work

to me Seldom recognizes good

work6. StrategyManager/Consultant

Customer interaction Future processes

Is a white-elephant Is theoretical not practical

Collaboration: Opportunities and Challenges

Roles CollaborationOpportunity

Perceptions/emotions toavoid

7. Developmentengineers (R&D)

Explain algorithm/technology

Ensure technicalaccuracy

Reviews doc only on reminder Considers doc review of low

priority

8. ProductValidation (PV)/Testers

Define usage Explain flows – how

products behave withother products

Either under-reviews or over-reviews

Demands to write everything,rather than the must

9. ProgramManagement

Define deliverables Set relative priority

Seldom decides. Throws backthe question

10. TechnicalMarketing/Sales

Define productroadmap

Customer interaction

Other than marketing literatureseldom interested in reviews

11. Support staff Define product usage Customer interaction

Departmental equations Too fussy

Collaboration: Opportunities and Challenges

Documentation Development Life Cycle

Objectives• Define long-lasting vision and set the scope for the current

release. • Define processes, standards• Set minimum pass-fail requirements

Issues/Perceptions to Avoid• General focus is more on product (read code) features. • Typical document development process may not interest all

.

Envisioning/Planning Phases

Objectives• Create quality deliverables. • Ensure proper reviews and QA• Improve processes

Issues/Perceptions to Avoid• Too many activities or crunched deadlines may lower

priority of reviews/ collaboration• Low focus on doc review because of immediate/other

priorities

Developing/Stabilizing Phases

• Be convinced about your project. Sell it.• Identify the core set of reviewers

– Know your product’s most frequent complainer– Bug/enhancement requestors

• Identify external requirements– Any internal/external conference– Marketing commitments, key customer requests

• Inform reviewers in time

• Make writing process democratic. Seek inputs. (Cont’d)

Getting the Review Commitment

• Maintain Relations– Write occasionally even without work– Remember other person’s important days/moments.

Congratulate on time. Show gratitude in right way.

• Self-perception management– Be sincere yourself - follow up till you get a reply– The other party is there to help. Do not read a NO for a

review as anything more than the word NO. You can still follow up - seek an alternate time

– Ensure you commit to other’s schedule. If not, inform any change in plans.

• Personalize Interaction

Getting the Review Commitment

• Inform the progress. – Send people book’s TOC for review– One mail/ month helps sustains interest– Clarify how the other person will be impacted if she does not

review. Do you need to raise alarm!

• Use roles strengths to ask relevant questions:– R&D - How product works, internal technology, and algorithms

used– Testing - Real life usage of product– Support engineers - Usability, installation, FAQs– Marketing - What’s new

• All mails for review must be detailed and complete

Creating the First Cut

Need• New document needs multiple

review rounds• People generally do one review

round• Not all reviewers are free

together• You get questions that

subsequent reviewers answer• Doc improves in iterative

cycles

Proposed Style• Stagger review• Target most passionate person first• Incorporate suggestions, send to a

group• Club questions• Rotate questions to the source for

answers• When doc is fairly stable, target

big groups for reviews

Scheduling of Reviews

Facts• All suggestions may not require

fix• Not all areas are reviewed in

equal detail • You don’t get all review in one

go• Some suggestions may impact

fixes to work not in your domain• Reviewer expects thanks,

responsiveness

Proposed Response Style• Fix each suggestion on merit and

communicate it• Make it easy for review • Clarify. Seek clarifications• Explain your perspective• Inform all impacted people• Thank where required• Don’t be monotonous • Be careful about what you write and

how

Fixing Review Comments - Lessons

• Review of docs is a continual process• Onus of subsequent reviews lies with the TC

– Target different people for different review rounds

– Rotate between questions/ portions of book/ don’t give full doc to person unless he/she agrees to.

– Fix what you commit. Remember any suggestion you don’t fix and is caught in second round, ends the deal.

• Track changes– Track who said what, when, and how

– Track changes in source files

– Keep original requestor informed of any fixes caused by subsequent review

Follow Up and Subsequent Reviews

• Analyze performance on relationship– Did you just complete work or made friends

– How was the success rate on getting reviews

• Perform root cause analysis of mistakes/oversights• Categorize suggestions into areas where you have

enhancements for next project. • Raise bug/enhancement requests.• Analyze your communication - mails/ verbal

commitments

Retrospection

Your suffering is over.

Please feel free to share your emotions or previously built perceptions.

By note

It is not important to believe everything. It is important to believe what you believe. Check whether the belief is not a hangover of an impromptu emotion or a residual perception. Check again whether you believe in the cause of the belief that caused the belief in the first place.

Thanks

• Importance of collaboration in technical communication• Perceptions hamper collaboration• Collaboration requires timing, commitment and enthusiasm• Tips/best practices for effective collaboration

Summary - You learned ...

OverheardMany members of our group do not work and those who work are individualists. They are

seldom interested in what the other person is doing or what can be done to improve their work. As a result, I do not care for what they do. May God keep this industry, and all of who deserve continue to get their salary, and others get what they deserve.

Possibility 1You are right in your judgment but then lack of teamwork is not going to help you either. Need

some change in culture.

Possibility 2The other person does not suggest/help/review because • you may have never asked• she is not sure whether it would be appreciated• she is short of time

Reality• You may not like being told what to do.• You may not have helped the other person.• You may lack trust, risk-taking, or appreciation of the other person’s work.

• There’s something in it for you • You learn something that you IMMEDIATELY need• It is an official need• It will help you train/educate others• It is highly visible. It rewards or helps build relations.Example - Support staff may like to review docs on buggy areas of

code or new features highly valuable.

• You have the time• You know/ trust the requestor

• You know the requestor • You know you will get credit

• You are capable/ the right person to reviewCase - You may not review a doc if it exposes your limited

knowledge

Why should you review a doc?

– Attach all files (pdf, database) and copy them to a shared region. Include source files

– Explain the essence of the doc again.

– Mention all known problems and solutions. Include backward compatibility issues

– Explain how to start instructions

– Remind them again - you are waiting for the review

– Be polite. Thank them for their effort

– If possible, send individual mails

– Follow up on mails till you get a review or reasons why the review may not be completed

While sending a doc for review

First Cut• You had promised but …

• Would you be able to review this document.

• This is the first cut ...

• This is the final cut ...

Perhaps better ...• I was wondering whether you have completed

the document review …

• Your valuable inputs will help me improve the quality of this document

• I have completed writing the …

• The document is fairly complete in structure and content. However, there’s still scope of improvement and your feedback ...

Be careful about how you write ...

– Could you have cut the communication short (needless rounds)

– Did unnecessary perceptions kill your time - did you follow up on them to remove them

– Were there statements that you should not have made

– Did you over/under commit

– Were you encouraged to share/hide feedback with peers/CFT/supervisor

– Did you think you should have given up - why? May not share - ask yourself and perhaps you will get more answers

– Did you thank the person who made the maximum contribution and did you tell the ‘capable’ persons with lesser inputs how they could have done better

Analyze Your Communication