Reflecting on a Work Anniversary

I've been the technical editor for for the past five years. It popped up to my LinkedIn network. Several people congratulated me on my work anniversary.

I have learned many things in the past five years:

  • Sometimes, people need “permission” to write what they feel. (They're concerned they will be too bold, too loud, too something.)
  • Some people need help finding the “right” structure for their writing. Sometimes, that structure is about how to find the time to write. Sometimes, that's the article structure.
  • Some people need help learning what and how people read on the web.

The biggest thing I have learned is this:

If I tell people the results I need, they will then deliver those results.

It's the same way on your projects, too. Tell people the results you want. I bet they will deliver those results, if at all possible.

I have asked these questions:

  • Can you tell a story here to illustrate your point?
  • Can you expand this bullet to tell the story? I am sure there is something quite interesting here.
  • I'm confused. Passive voice does that to me. Can you make this active?

I have more questions up my sleeve, and that's fine. Notice that I don't “criticize” the writing. I don't like criticism. I much prefer knowing what to do to improve. I bet you do, too. That's why I ask for what I want.

If you use agile and have a story to tell, I'm interested. Let me help you publish your story. Send me an email.

If you would like to write better, let me know if you would like to be a part of my next non-fiction writing workshop. I have a wait list for the August workshop. I'll definitely run it again.

I thank you for all your good wishes, and I do hope I can continue this (part-time) gig. It's quite fun!

2 thoughts on “Reflecting on a Work Anniversary”

  1. Reminds me of a time, early in my career, when I edited tech books. “For Dummies” books, to be exact. Their HQ is in my town. There I learned how to make my queries be about the reader, not the writer. “I think the reader might be confused here. Can you clarify what you mean by xyz?”

    That helped me when I became a software tester: my bug reports are never about the developer, but about the user (or the business).

    1. James, you learned a valuable lesson re the reports about the effects of the problem, not the creator of the problem.

      I think I learned that lesson because I was a developer before becoming a tester. I had not enjoyed comments such as, “What were you thinking?” That was not helpful. I asked for feedback about the user, output, or something else, and discovered what the real problem was.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: