|
03/03/2019
|
31971941
|
Memorize the company's style and grammatical guides. Seriously!
|
|
03/01/2019
|
31926954
|
Instead of saying no to a project, I ask for clarification from the scrum master or product owner about prioritization of projects.
Be accessible. When my engineers have time to work with me, I make time immediately to be available to them. This includes working collaboratively with them directly in the doc especially when editing or writing rough draft content. I have a stand up workstation which makes it easier for us to see the content together. Thank you, Tom, for sharing these strategies.
|
|
02/26/2019
|
31739309
|
When working in a centralized writing team with limited bandwidth, I find it helpful to find new ways to leverage engineering contributions. My impact then goes from, what can I as an individual produce, but what can I as an enabler get an entire team of people to buy into. This could mean teaching engineers about doc platforms, creating templates, sharing best practices, or focusing on information architecture more than content creation. (However, I love to write, so I find ways to write content that would be hard or cumbersome for engineers to create themselves.)
|
|
02/22/2019
|
31517635
|
Help engineering teams in tasks that are not necessarily your tech writing tasks (writing/reviewing their internal docs, backup their scrum master, etc.) In return they might be more eager to accelerate/unblock your in your work when you need their help.
|
|
02/21/2019
|
31443125
|
We try to "infect" other departments at our company with good practices. If the engineers know that Documentation is going to ask them a million questions, and if Documentation always shares those questions, it raises the probability that the engineers will start saving themselves some headache by giving us what we need before we ask for it!
|
|
02/21/2019
|
31437076
|
Focus on time management skills
|
|
02/20/2019
|
31344207
|
I love this blog and content! It's exciting to read tips from a fellow technical writer.
|
|
02/19/2019
|
31278681
|
At Worldpay, in the craziest periods I was switching between 4-5 projects across multiple APIs (ahem learn to say no better!). I was prone to what I randomly called: "Project switch bleed" (not the best name, granted...) - a phenomenon that lost me around 15-20 minutes concentration time while I proverbially swam to the surface of one lake, only to dive deep into the next! A tip from this is: Time box longer periods in your calendar to focus on one thing at a time - switching between two or more tasks that require extreme focus and concentration costs valuable time. I still responded quickly to emails and messages, but sometimes my response would be: "Thanks for your message - busy right now but I'll get back to you later" [mark unread!]. At least people knew I was aware of them that way.
Another strategy was to stay aware of the overall company strategy, in terms of product priorities. This was a great piece of leverage when too many Project Managers were knocking on my door, because I could remind them that these two projects over here are priority 1 - with powerful backing from above if needed!
Two great techniques I discovered were borne of a mandatory regulatory change leading to everybody scrambling like mad to actually build something, let alone document it. The only way to meet the deadline was to combine the writing, reviewing and feedback into the same sessions. This is where technique: 1) co-writing, came into play. I literally sat with the experts and downloaded their knowledge onto paper as they dictated it to me. I wrote well enough so that I could understand it, and tidied it later. Essentially though, we combined forces to write the docs together - instantly closing feedback loops and resolving questions on the fly. Here led to my discovery of technique 2) Doc demos. Instead of sending out cold emails and getting either no response, or vague responses leading to more questions (or an uncertainty of what they really checked), I booked meetings and got reviewers in the room with me, and walked through it together - again, closing questions on the fly and ensuring that they actually checked the understanding. It was amazing how many times people had to 'check it worked that way', or had to align their understanding of the truth. Valuable not just for me, but for the experts too!
Finally, when I did have to send guidance out for review, I honed a tried and tested three colour text highlight system with Flare, to make reviewers' lives easier (which ignored any content from previous releases, already reviewed, but still had it there for context):
- Blue is for you (questions in the doc, in context, directed at experts, conditionalised out of the final release)
- Green should be seen (areas I felt needed particular focus, or bits that adjacent blue questions were referring to)
- Yellow is mellow (internal only tech writer thoughts - explaining why certain things are done or a bit more context for understanding)
:)
|
|
02/15/2019
|
31074379
|
I don't tend to record conversations as they are often 'ad-hoc'. I generally rely on my note-taking skills (I've been taking notes for decades). My problem then is to organise and re-read my notes efficiently.
|
|
02/12/2019
|
30915434
|
organize emails by urgency instead of responding right away to all - which need a response today, this week, or this month?
create an intake process with a standard set of information that needs to be provided to complete a project (test environment, launch date, etc.)
|
4,087
130
130
100%
0
13 mins
Loading...
