Blog Archives

Doc fixits and content strategy at Write the Docs Sydney on Tuesday

The next Write the Docs meetup in Sydney is just around the corner:

Sydney: Content strategy and doc fixits

Tuesday, Jul 3, 2018, 6:00 PM

Atlassian
341 George St, Sydney NSW 2000 Sydney, AU

28 Documentarians Attending

Join us to chat about docs – why they’re a Good Thing and how to make them even better. Tech writers, engineers, editors, product managers, more – if you’re interested in docs, you’re welcome. —————— Presenter 1: Michalina Ziemba **Five steps to successful content strategy** In her talk, Michalina will share examples and practical tips …

Check out this Meetup →

What’s happening

We have two presentations lined up, preceded by pizza and chatting!

  • Michalina will talk about five steps to successful content strategy.
  • I’ll follow with a presentation on doc fixits: What is a doc fixit (hint: a way of fixing doc bugs en masse), why would you want one, and what can you do with it once you have it?

Date, time, and location

Tuesday 3 July 2018, at 6pm. We aim to finish around 7.45pm.

At the Atlassian offices, 341 George St, Sydney.

Would you like to join us?

If you’re interested in technical documentation, you’re welcome! Sign up at the meetup and we’ll see you there.

Advertisements

Next Sydney Write the Docs meetup at Atlassian, July 3rd

We’ve just announced the next Write the Docs meetup in Sydney:

Sydney: Content strategy and more

Tuesday, Jul 3, 2018, 6:00 PM

Atlassian
341 George St, Sydney NSW 2000 Sydney, AU

3 Documentarians Attending

Join us to chat about docs – why they’re a Good Thing and how to make them even better. Tech writers, engineers, editors, product managers, more – if you’re interested in docs, you’re welcome. —————— Presenter 1: Michalina Ziemba Five steps to successful content strategy —————— More details and more presentations in the work…

Check out this Meetup →

What happens at the meetup

We currently have one speaker, Michalina, who will talk about five steps to successful content strategy.

There’ll be more speakers, and the opportunity to chat to old and new friends.

Who can attend?

If you’re interested in technical documentation, you’re welcome!

Date, time, and location

Tuesday 3 July 2018, at 6pm. We aim to finish around 7.30pm.

At the Atlassian offices, 341 George St, Sydney.

Want to air your ideas?

If you have an idea for a presentation or a lightning talk, let me know.

Thoughts on a remote Write the Docs meetup

On Wednesday this week, the Write the Docs (WtD) Australia group held a meetup entirely in cyberspace. Or, in the cloud, remote, virtual… whatever you’d like to call it. 🙂 Here are some thoughts on the experience.

Huge kudos to Swapnil Ogale for thinking up the idea of holding a remote meetup, organising it, and running it. It was a great idea and worked very well.

To attend the meetup, we all logged in to a GoToMeeting session. The meetup consisted of a few lightning talks and a couple of presentations. You can see the lineup in the meetup details.

The biggest takeaway for me is this:

People really do want to share their thoughts and experiences with others.

The lightning talks were a great way of doing that. Some presenters had slides, others just spoke from the heart. The variety of topics was intriguing, and listening to the talks was rewarding.

The chat screen was alive and humming throughout the meetup, with people commenting on the topic that the presenter was currently discussing, and on related topics, and on completely unrelated matters too. It was fun and enlightening to be able to watch the presentation and the chat at the same time. This is something that an in-person meetup doesn’t offer. During an in-person meetup, people sit quietly during the presentation, for the most part, and discussion happens afterwards.

It was good not to have to travel. I enjoyed the luxury of going straight home from work, powering up the computer, attending the meetup, then stepping out of the room to join my husband for dinner.

As with all meetups, whether virtual or in person, it was great to see everyone. Especially the speakers who enabled their video cameras so we could see their faces while they spoke.

The remote meetup was also a slightly scary experience, especially for me as a presenter.

I’ve jotted down some notes of what I found scary (I scare easily), primarily so people know they should persevere if they run into technical glitches when connecting to a remote meetup or presenting at one. Things usually work out!

We didn’t know which online platform we’d use until a until a few minutes before the meetup: candidates included Google Hangouts, YouTube streaming, or GoToMeeting. We eventually went with GoToMeeting, which worked well once it was working. I was on a Linux laptop, and the GoToMeeting compatibility checker told me I’d be unable to install the software (eek, but I’m presenting a talk!) but then it mentioned I could use the web interface. Why not just tell me all will be OK and leave it at that? Then GoToMeeting demanded a password, which I did not have. Swapnil was on that immediately, and sent a message to the group saying we should just enter a single space, which worked.

The next hiccup was audio. I couldn’t get mine working with the meetup platform on my laptop, so I dialled in on my mobile phone. All good, but five minutes later the meetup platform managed to find the audio on my laptop after all. Major audio feedback. So I had to decide whether to trust the software and kill the phone call, or mute the software and go ahead with the phone. I killed the phone call, which turned out OK, Luckily so, because by this time it was my turn to give my lightning talk.

When you’re presenting to a remote audience, it’s like talking into the void, You have no idea if people are still there. And I couldn’t get my speaker notes to play well with the meetup platform, so I had to speak without them. That went OK too!

Phew, presentation finished. It was very nice to hear people come back on the audio connection, and nice seeing the comments in the chat room about my talk.

My final thought is:

What a great community we have. Let’s do it again!

The art, and the power, of saying no

Recently, I needed to let a product team know that our tech writing team couldn’t take on the task of creating a particular doc. The doc was outside our normal area of responsibility, but one where we could certainly have added value. The problem was, we just didn’t have bandwidth. My manager showed me a published procedure which outlines our priorities. It was very useful to be able to refer the product team to the procedure, and to have at my disposal those words in the procedure which had been so carefully written for just this sort of situation. I was also able to offer the product manager our help in reviewing the doc once the engineering and product teams had created it.

This experience led me to think about the art, and the power, of saying no.

Saying no feels bad. You’re letting the side down. You and your team are underachieving.

Not so. I’ve come to the realisation that saying no is a good thing, provided it’s done under the right circumstances and in the right way. It’s good not only for you, but also for the people you say no to, for your manager, and for your team members. Even more, it’s good for the organisation as a whole.

How so?

When an organisation has had the luxury of a tech writer or two for a while, people start appreciating the skills we offer. They start asking us to create documents that are urgent, high profile, sales critical, and more, but that are sometimes outside our scope.

It’s fine to help out if the tech writing team has time. But often the team is fully taken up in other work that’s of equally high priority, and which is part of our primary responsibility. In such cases, it does the team and the organisation a disservice to say yes. Writers will end up working overtime, or the  docs under our primary care will suffer.

If we say no, people in the organisation may realise they need to hire more tech writers. In many cases they already know they need more writers, and our saying no can give them the data they need for their hiring requests.

Tips

If time allows, it’s good to be able to offer a little more than just a “no”. Here are a few ideas. Some of them involve preparation ahead of time, under the assumption that you’ll have to say no at some time:

  • Write up your team’s policy and responsibilities clearly, so you have somewhere to direct people to when they ask the impossible. Don’t be afraid to adjust the policy doc as time goes on, and as your team changes or you discover more situations which you can or cannot support. The team’s policy is not set in stone. It changes with your team, your stakeholders’ teams, and the organisation as a whole.
  • If you have a helpful suggestion or recommendation, include it when you say no. For example, point people to templates and style guides that will help them write the doc themselves. Look for existing documentation that may be similar to what they want.
  • If you have the bandwidth, offer to review the final draft after another team has created it and pushed it through initial review.
  • Encourage the product and engineering teams to contribute to the docs on an ongoing basis, so that they’ll feel able to write their own doc in this sort of situation. Create a quick-start guide to your doc tools and review procedures, and point them to that guide. On the topic of writing such a guide, you may find this post useful: the importance of audience.

Have you found yourself in a position where you’ve had to say no, even though you know that you and your team would add value to a task if you had bandwidth? I’d love to hear any tips you have on how to handle this sort of situation, and what you’ve learned from saying no.

%d bloggers like this: