10X productivity tips

Countries	Responses
US	45.86%
IN	11.28%
GB	4.51%
IE	3.76%
PL	3.01%
RO	3.01%
AU	3.01%
CA	2.26%
NZ	2.26%
FR	1.50%
UA	1.50%
CN	1.50%
HK	1.50%
DE	1.50%
PT	1.50%
SE	1.50%
BY	0.75%
IT	0.75%
PK	0.75%
HR	0.75%
Unknown	0.75%
DK	0.75%
HU	0.75%
AP	0.75%
ES	0.75%
EU	0.75%
IL	0.75%
BE	0.75%
FI	0.75%
SG	0.75%
Total	100.00%

What's your secret to being more productive (10X) at work?

Answer

Count

Percent

20%	40%	60%	80%	100%

Record meetings with engineers to listen again later

52

13.1%

Respond quickly to emails and messages

70

17.63%

Iterate on content with ever-expanding layers of reviewers

45

11.34%

Put some work back on those who request it

40

10.08%

Learn to say no so you can focus on fewer projects with deeper engagement

45

11.34%

Work embedded in small engineering teams rather than as a centralized doc group

44

11.08%

Work overtime (either arriving early, leaving late, or sacrificing evenings/weekends)

17

4.28%

Sharpen my technical skills so that I can write with greater ease

74

18.64%

I have no inside tips on this topic

4

1.01%

Other

6

1.51%

Total

397

100 %

Whats your secret to being more productive (10X) at work? - Text Data for Other

03/03/2019	31971941	Send summaries of review meetings immediately to stakeholders. Especially clarify the next steps. Clearly designate the party or organization is responsible for a next step and when. Never take on too many next steps myself.
02/18/2019	31195436	Know my numbers - how long does it take to write 100 words? How long does each review participant need? What is the direct cost for translations? What are the indirect costs? What does each part of my work contribute? What does it cost?
02/10/2019	30814302	Use Slack or another messaging app to get quick feedback
02/10/2019	30813651	Don't polish every word - good enough is good enough
02/08/2019	30715686	Use some Product Management techniques
02/08/2019	30714056	Coffee

If desired, share other strategies or thoughts around productivity strategies you follow.

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.)

I enjoyed reading this post.

Answer

Count

Percent

20%	40%	60%	80%	100%

Strongly disagree

18

13.53%

Disagree

0

0%

Neutral

2

1.5%

Agree

31

23.31%

Strongly agree

82

61.65%

Total

133

100 %