Enduring the Editing Process - A Perspective

A few years ago, I was asked by an IT Director how it was I endured - and actually embraced - the editing process with our CIO. She was repeatedly frustrated by the process, having spent a lot of time and energy in writing a document, only to have him "re-write" it or edit it heavily. I understood her viewpoint, and in fact, early in my corporate writing career had felt similar frustration, but here's what I've learned (as I shared with her).

- I don't know what I don't know. And I know I don't know.

That is, I know there are conversations, strategies, perspectives, and perceptions that exist outside of my bubble. I can't write to address those if I'm not aware of them. But the CIO is not only aware, but is held accountable to any negative consequences. He adds value to my writing, because he can fine-tune it to meet the need of the organization on a level I just don't have visibility.

- It's not about what I write, but about meeting a need.

My job is not simply to write. It's to meet a specific need, to communicate a specific message, to influence a specific behavior, to manage a specific perception (or set of perceptions). And sometimes it's all of the above. Just as I don't want to use a clunky program written by a programmer who didn't understand the end-user's needs or how the business works, I don't want to create communications that don't meet the needs of my customers. The point for me isn't to write and be validated as a good writer - by the fact that I have a job and remain in that job means I have value - but instead the point is to meet the need of the organization or the customer - including the CIO.

- The world can change at any time.

Dynamics inside the corporate world continually adapt and change. What was true one day may not be true the next. It is the way of things. I may not know that some event that morning changed how a document should or needs to read. I need to be prepared to adapt; and know that it isn't personal, but a reflection of a change in the world around me.


- I turn it into a game.

To avoid getting personally bent-out-of-shape, I play games with the editing process. I take the approach of listening and learning as much as I can to the banter and conversation and edits, absorbing that, and then try to hit the next draft or the next deliverable closer the next time. I score myself based on how closely I hit the mark the next time around or by whether a new direction is decided upon based on concerns or questions I've posed.

It's about meeting the need. I love technology because of what it can do; But I won't use it unless it practically meets my needs. The same goes for a communication deliverable, particularly those I create - does it meet the need?

If not, I'm happy to have the editing. My writing is better for it and the need is better met.

Update: For more on how to have better communications with your IT management, end users, and co-workers, I invite you to join me for my IT Communication Skills Training course at http://ITCommunicationSkills.com

Edits are not personal

Writing is a personal, subjective task. Writing words, the right words, for a specific audience is often a challenge, particularly if you aren't yet well-tuned with the audience or the perceptions the audience has of you.

Managing perception is a key component for a healthy IT organization. Perception of IT can swing wildly - set off by print routing, the wording in a message, too much spam, how a user interface works or doesn't work. Unfortunately (or in some cases, fortunately), perceptions aren't always reality. And because important decisions are made (or not made) based on others perceptions, managing communications becomes an important task for IT leaders.

So, this said, it is important realize when your words are being edited by another, it is not because they are wrong, but rather because there are perceptions that are being managed. As writers/communicators, we don't always know how others perceive us; nor do we always know what decisions will be made from our words. Editing is not about criticising the writer, but instead about reaching the audience in the clearest, manner available - that meets the needs of the organization.

As writers who must undergo a committee-style review and edit cycle, it is important to divorce yourself personally from your words, and recognize that it is not you they are editing, it is the message. Each member of the committee brings forth a unique understanding of how others may percieve and react to the wording. And for reasons we may not see or understand the committee may need to alter the wording to manage perceptions in a different manner.

Decisions will be impacted by the message and the perceptions the message creates. You may not know what those decisions are or how the perceptions will shape the IT organization's future. But someone else does.

My advice is to be open and please - oh please - don't take edits personally. It's really not intended as such. They are just a matter of shaping a message to suit a specific purpose and need.

Update: For more on how to have better communications with your IT management, end users, and co-workers, I invite you to join me for my IT Communication Skills Training course at http://ITCommunicationSkills.com

Improve Your Communication by Answering these Five Questions

Tip: Become aware of communication preferences for those you regularly communicate with; if appropriate create a checklist for future use. Having this information on hand allows you to proactively tailor your communication to your audience and improve the chance of clear communication.

Do they prefer email, phone, or hall-way conversations?
I once worked for a Manager who wouldn't return email; his motto was "If it is really important, they'll call." Whereas another person I worked with hardly ever returned calls, but always answered email. Simply asking is the best way to get this information.

How do they like to be addressed - Mr. Smith, Fred Smith, Fred, Hey You...?
One person I worked with always preferred to be addressed formally (Mr. Smith) and was offended if people, especially subordinates and vendors got too chummy with him. Others prefer to go on a first name basis. Culture and upbringing plays a role in people's preferences.

Do they prefer having a conversation, a formal presentation, an email and then phone conversation, or something in between?
I've worked with several C-level executives who are wary of formal presentations, but instead prefer to have interactive conversations, with supporting documentation to review in more depth if questions come up. Others prefer the formal presentation approach. These preferences are often learned by trial and error, by being aware of the reactions you recieve in your communications.

What type of questions do they ask?
By logging the types of questions being asked, you can then proactively anticipate questions that will be asked in the next communication and incorporate the answers, or have them available 'in your hip pocket' for reference should the questions come up again.

Are there words or colors they do not like?
The last Director I worked for got distracted whenever the word "going" was used. The C-level executives preferred presentations on a white or light background. Another director hated Orange, while others didn't like shades of green. One shut down if purple was used. Colors impact us emotionally and psychologically. Paying attention to color choices will impact the effectiveness of your communication.

What distracts you?

Understanding and profiling your audience's preferences allows you to communicate with them better, more effectively over time. It shows respect and cuts down on re-iterative discussions.

Update: For more on how to remove the distractions and effectively communicate with your co-workers, end users, and management, I invite you to join me for my IT Communication Skills Training course at http://ITCommunicationSkills.com

Behind the title is a human

People with titles of authority (managers, VPs, CIOS, CEOs) should be respected for the risks and responsibilities they assume, decisions they need to make, and the paths they have created. But too often people who report to them forget that behind the title is a human - A real person, not just a title, who has feelings, desires, challenges, likes and dislikes, and families.

Sometimes we get too close to what we are trying to communicate that we forget that the person we are talking to (or writing to) is being pulled in many different directions. If we can eliminate distractions within our control and remember we are talking/writing to a person, we make it easier for them to absorb our message.

Update: For more on how to remove the distractions and effectively communicate technology, I invite you to join me for my IT Communication Skills Training course at http://ITCommunicationSkills.com

Essential Skills for IT personnel who want to grow

Moving forward requires growth - personal growth, professional growth, technical growth. But knowing what areas to grow in is sometimes a challenge. When appropriate, I am of the mind to ask - "What skills do I need to grow to help you (or the business) succeed?". But since that isn't always possible, I also listen when others share their insights on what skills they need. If you are a technologist, realize that the truly transferable skills of business knowledge, communication, and financial acumen are highly sought after. But don't take my word for it - read it in these Computerworld articles:

• Most Valued Skills
  
  
• Smart Career Advice

Today's issue of Computerworld contained several articles on building project management and business analysis skills. In my opinion and experience, these two skills are essential in any career path and very transferable in and out of the technology world.

SLAs can improve IT/Business Alignment

Service Level Agreements (SLAs) between IT organizations and vendors help ensure expectations are clearly communicated and service delivery meets expectations. Instituting SLAs between supported business areas and the IT organization can also help improve IT/Business Alignment. While it takes time to sit down and discuss (and document) the expectations, it gives everyone a common frame of reference on which to move forward.

A couple points to consider:

• Adapt your SLA discussions to meet the business' culture. Some cultures are not condusive to a formal SLA process. Even if you don't put formal SLAs in place, having the conversations around expectations is beneficial.
  
  
• Document SLA discussions - Even it you don't formally institute SLAs, the process of initiating conversations and discussing expectations still opens up avenues of communication and creates bridges and alignment.
  
  
• Keep discussions positive and service oriented - create win-win for both the business and IT. Discussions should not be "us" and "them" type discussions. Instead, it should be "how can we best serve your needs" type discussions.
  
  
• Be accountable to what the business considers important. Track your statistics and progress against the SLAs. (Or, if you don't put formal SLAs in place, you at least now know what is important to the business and what they would consider credible statistics in which to measure how IT is really doing.

IT is so often only remembered when there is a problem. Understanding expectations and reporting your progress against those statistics goes a long way towards building trust and credibility with the business.

For more questions to ask during the SLA process, see this Computerworld article by Steve Case.

Defining Requirements and Selecting Vendors

Rick Proctor, VP of IT at Thomas Nelson Publishers, Inc. reminds us that it is our responsibility to help the business clearly define their requirements and to really understand what a vendor's solution can (and cannot) do before implementing the solution. His advice is one of communication and how essential it is to clearly communicate not only with the business but also with the vendors.

For more on the importance of communicating with vendors and understanding business need, check out this Computerworld article about working with vendors. I worked with Loreen for over three years; she is amazing at setting expectations and communicating with staff, the business and vendors.

Lessons in Business Continuity

This morning, I am again reminded the importance of back-ups. I went to retrieve some files from my old laptop, only to discover that they were corrupted during the last operating system upgrade. Thankfully, I ensured that I had a backup before I did the upgrade (Murphy's Law!!) and was able to pull the files from the backup CD.

Doing back-ups and having a Business Continuity/Disaster Recovery plan seem like a no brainers - but then why are they so often not where dollars are spent in an IT organization?

Only when the benefits or the consequences (aka Risks) of not having a backup or business continuity plan becomes clear, does buy-in happen. Unfortunately, it takes time (and funding) to pull together a truely workable and effective business continuity plan. And it takes time to achieve corporate buy-in that time and money be spent in this area.

How can you accelerate the buy-in process?

A couple ideas:

• Identify areas of risk to the business.

  For example, what is the impact to the business if the ability to recieve orders via EDI is cut off?

  What is the impact to the business if the building floods and the servers that maintain inventory and distribution counts are cut unavailable?
  

• Identify solutions that can be implemented in a multi-step fashion focusing on the highest return with the lowest outlay ('the low hanging fruit')

  
  

• Pitch your ideas laterally as well as upward, create buyin by focusing on how the business will be positively affected. I.e., avoid focusing doomsday, catestrophic events but instead focus on real-world everyday possibilities.

Business continuity is a huge topic which I could write on for days, but in reality what I write isn't important - what's important is how you present your proposals and your ability to gain approval for business critical solutions (even if the business doesn't recognize their criticality.)

Selling Your Proposal - Achieving Buy-in

Michael Hyatt's post on How to Sell Your Boss is a wonderful primer on how to achieve upward buy-in. If you are interested in gaining executive insight on how to achieve buy-in - READ THIS.

Features vs. Benefits - Another view

Michael Fortin offers a more in depth definition of how to determine the difference between features and benefits.

Features vs. Benefits

Are you highlighting the features or the benefits?

A feature is what it does.

A benefit is the result.

For example, What's unique about a PDA contacts list? For the product I'm currently writing about - it's the 'time bomb' feature. The contacts list self-destructs if it isn't synched to the enterprise database within a given period of time. Cool - but why?

The result is that sales people cannot (easily) take the contacts list with them, when they leave the company. The benefit is that the software safeguards the company's sales contact information (intellectual property).

David Garfinkel provides a good example of this using a fan analogy in his post on Tuesday.

While all the fuss between features and benefits usually has to do with sales and marketing products, the techniques also work for internal documentation, user documentation, and management reports. After all, achieving buy-in is about getting users and management to agree to use or endorse the technology you have in place or in the solutions you are proposing.

Asset or Liability?

Is Information Technology an asset or a liability? Is it a unavoidable cost of doing business in the 21st century or is it a business enabler improving the business' bottom line?

The answer to this can be swayed based on how you perceive IT and how you are communicating the value of your technology solutions.

Learn the Business

Understanding business process and how your business is using technology currently in place is one important step toward solid communication and 'right-sizing' technology solutions.

But assuming you are already doing that, let's take it one step further - How can you proactively meet your businesses technology needs?

• Read business industry publications (i.e., trade magazines and websites) - Every industry has its own set of trade publications. If you don't know what they are, search online, ask those in the business what they are reading, and/or keep your eyes out for what is showing up on people's to-do stacks and break room tables.
  
  
• Ask those working in the business what they do and take time to learn how that fits into the overall picture.
  
  
• Listen carefully and listen with the intent to absorb what they are saying - not with the intent to respond or show your expertise.

In short - Be curious, ask questions, and re-iterate (or confirm) what you hear/read.

Use Statistics to build Credibility

Statistics and numbers increase the credibility of your message - whenever possible include them.

However - be sure that you:

• Are using credible statistics, from reliable data
  
• Can show the supporting data and/or source of your statistics/numbers
  
• are comparing 'apples to apples' (i.e., relevent and comparable) information
  

Participating in benchmark studies, reading industry best practices (e.g., from Gartner or Meta), and maintaining high standards in your own record keeping of stastical data goes a long way towards providing sources of statistical data.