We wondered how this diagram would look if it related to content strategy. We came up with a diagram that describes the critical risk factors in content strategy – the aspects you will need to ensure you get right within the management culture that exists inside your organisation:
“Netflix can track and analyse, in minute detail, the behaviour of every person who watches a programme on its service. The rumour is that Netflix used its “big data” to decide what would be the best programme to make for its audience …. In some cases, unfortunately, technical publications teams are more in the dark about their customers than the TV networks.”
With the recent media attention on Yahoo’s announcement that it is banning its staff from “remote” working, we thought it might be useful to look at the case for and against Technical Authors working from home.
The case for allowing remote working
They can do their jobs more productively without interruption from others. When Technical Authors are writing (which is approximately 50% of their time), it can often help their concentration if they can work in a distraction-free environment.
There’s less need for office space and related costs (telephones, desktop computers etc).
“Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings.”
Being a Technical Author is one of those roles where remote working can work well. However, it’s best to be able to have both options available – to have people who can come into the office within a short space of time, should there be an emergency. There’s a great deal of value in meeting people face-to-face, and to be part of a company culture (especially within startups), but it can help enormously if you can write in a distraction-free environment.
If you do work from home, you need to have a productive working environment, and be able to be self-disciplined.
Agile programming has grown in popularity and it has led to new challenges for those involved in providing user assistance for those applications. So is it time for technical authors to develop an equivalent method for developing content for these projects? Is it time to develop an “Agile authoring” methodology? Also, if we want to move away from a hand-crafted approach to developing content and towards a more engineering-like approach, what can we learn from the latest techniques being applied in manufacturing?
Such a method needs to complement Agile programming, but it may be a mistake to take Agile programming as the starting point for developing it. The developers of Agile drew upon the principles of Lean manufacturing, and perhaps technical authors should do the same.
In this webinar, we will explain how the principles of Lean manufacturing can be applied to developing and managing content. It’s a way of writing that focuses on maximizing the value to the user and minimizing waste. It involves measuring the processes and value of what has been delivered so that iterative improvements can be made over time.
This webinar will be hosted by the Society for Technical Communication.
The US Presidential elections have just ended, and the big winners were the “Quants” – the statisticians such as Nate Silver, who used statistical models of big data sets to accurately predict the electoral college vote results. In competition with the Quants were the “Pundits”. These were the commentators on politics, some of whom said they were using gut feel to make their predictions. Pretty much all of the Pundits failed to predict the results accurately.
It is our experience that there is a similar difference between different Technical Publications teams.
The “5 Whys” is a question-and-answer technique used to discover the root cause of a defect or problem. It is an approach used in the Lean manufacturing methodology, as well as the Six Sigma business management strategy. Here’s an example of the 5 Whys technique:
Problem: The vehicle will not start.
Why? – The battery is dead. (first why)
Why? – The alternator is not functioning. (second why)
Why? – The alternator belt has broken. (third why)
Why? – The alternator belt was well beyond its useful service life and not replaced. (fourth why)
Why? – The vehicle was not maintained according to the recommended service schedule. (fifth why, the root cause)
Solution: Start maintaining the vehicle according to the recommended service schedule.
Some consultants suggest that if you use the 5 Whys approach you’ll conclude you should fix a fault in a product rather than create reams of documentation explaining how to get around the problem. However, if the cause is of the problem is at the customer’s side (for example, their computer has an out-of-date driver), how do you fix the problem? You could control the issue by only selling to those who have the appropriate setup (or training), but, if you want to get the customer to resolve an issue at their end, then the user documentation may be the best way to do it.
Sometimes, the 5 Whys approach will identify the need for a proportionate intermediate fix. Again, User documentation is often the most effective solution, in those situations.
Red Gate Software’s Dominic Smith mentioned in his presentation at UAEurope conference that the company had found Technical Authors were ideally suited to take on the role of Project Manager for small Agile software development projects. In fact, Red Gate had morphed most of its Technical Authors into to a hybrid Project Manager role.
Dominic made a strong case why Technical Authors made good Agile software project managers:
They are focused on the user
They understand the user
They understand a lot of the technological aspects
They are used to delivering projects on time
They are more extravert and people-orientated than programmers (yes, this is broad generalisation)
They ensure User Assistance isn’t forgotten in the project plan, and that it is considered from the very start
They can provide a business focus to the project, and are able to kill projects that don’t make business sense any more.