Learning from Netflix

You’ll find our latest post for the Society for Technical Communication on its Notebook blog. It’s called Letter from the UK: Learning from Netflix:

“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.”

See: Letter from the UK: Learning from Netflix

Should Technical Authors be allowed to work from home?

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

  1. 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.
  2. There’s less need for office space and related costs (telephones, desktop computers etc).
  3. Staff may be less stressed. Brad Harrington, executive director of the Boston College Center for Work & Family, claims people who work from home tend to have less stress and are more productive, partly because they don’t invest time and money in commuting, and they can have a better work/life balance.
  4. You may get more flexibility over staff availability. Without the need to commute, staff may be more willing to work out-of-hours.
  5. You have a wider pool of people interested in your vacancies if you can offer some flexibility in working hours and location.

The case against allowing remote working

  1. You’re more likely to build up a company culture if everyone is working in the same space together. This is particularly important for start-up businesses.
  2. It’s easier to network with others. These contacts could boost your careers in the future.
  3. It’s easier to monitor the work staff are carrying out.
  4. It’s can be faster to make decisions (as you can carry out impromptu meetings).
  5. According to Marissa Meyer, face-to-face meetings boost the quality of decisions and business ideas:

“Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings.”

Our opinion

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.

What’s your opinion?

You can use the comment box below.

See also: Cherryleaf recruiting services

Webinar: Towards an Agile authoring methodology – learning from Lean

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.

Promo code: WS030513

Register for Towards an Agile Authoring Methodology – Learning From Lean

Webinar – Planning user documentation when you’re a startup business

We’re currently working on 40 minute webinar on:

  • Planning user documentation when you’re a startup business

If you have any questions on this topic, you can email these to us prior to the event. We’ll do our best to make sure we address them in the webinar.

Send us an email with your question

Details on the date for this webinar will be published in the Events section of the Cherryleaf Web site.

 

Is your Technical Author a “Quant” or a “Pundit”?

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.

Continue reading

5 Whys – what does this mean for Technical Authors?

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.

  1. Why? – The battery is dead. (first why)
  2. Why? – The alternator is not functioning. (second why)
  3. Why? – The alternator belt has broken. (third why)
  4. Why? – The alternator belt was well beyond its useful service life and not replaced. (fourth why)
  5. 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.

Why Technical Authors make the best Project Managers for Agile projects

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.

Do you agree?

Disclosure: Red Gate is a client of ours.

Do you need a Documentation Manager when Technical Authors are embedded into Agile project teams?

Earlier this week, I was asked my opinion on whether a Documentation Manager was needed when the individual Technical Authors are embedded into Agile project teams.

My response was that a Documentation Manager mainly provides people management, project management, process management and content management. If a Technical Author is a member of a software project team, then that team’s Project Manager is probably providing the people management and the project management to the writer.

That leaves the need for someone to manage the processes and manage the content. I suggested managing the content could be done by someone with the role of Editor (or “Content Wrangler”). They might also look after the processes, or they could have another writer take on that responsibility.

It’s then a decision as to whether the organisation sees these roles as senior to the technical writing positions, or as a specialism and consequently on the same job grade.

It does leave the management of the writers’ career progression falling through the cracks, unfortunately.

How do others deal with this issue?

Setting a marketing strategy for a Technical Publications Dept

A good Technical Publications manager will, naturally, set a strategy for their department. In addition to the HR, technical and project management aspects, there’s another factor to consider – the marketing strategy for the department.

Sales consultant Richard White advises businesses define and describe the archetypes for their particular product or service. He means the types of people who might buy your product or service. Many Technical Authors develop personas representing the variety of different end users, which is a similar exercise. However, when it comes to defining those who fund and initiate the services of the Tech Pubs department, who or what are those archetypes?

One archetype can be ‘the uncertain manager’. They know a product should come with user assistance (e.g. user guides and online Help), but they are uncertain of the value of providing it. This means they can’t quantify how much money to invest in the department (or in a contractor, a technical writing company etc).

So how should you market the Tech Pubs Dept. to this archetype?

In this situation, it’s a case of helping them determine the value of user documentation. Measurement tools (such as our free support call cost reduction calculator) can help, but it’s also important to understand what issues they have and need to solve. You may need to frame the value of the department with reference to their challenges.

If you can think of any problems and needs an ‘uncertain manager’ might have, do list them below. How do you think you could demonstrate your value to them? We welcome your thoughts.

Turning employees’ knowledge into an asset for the organisation

In July 2010, Mark Prisk, UK Minister of State for Business and Enterprise said:

As the events of the past two years have made painfully clear, we must leave behind the over reliance on financial services and support a renewal in modern manufacturing, so we are able to grasp the huge opportunities of the low carbon age. The ideas, skills and innovations of manufacturers will be just as important to our economic future, as the mills and mines were in our past.

Ten years ago, you’d find many consultants raising the issue that an organisation’s ‘knowledge assets’ walk out the door every evening.

Today, that’s still pretty much the case.

Organisations found it was difficult to capture the knowledge locked in employees’ brains. Many invested in expensive systems that offered poor authoring environments and complex ontologies. Retrieving the recorded knowledge could be a dreadful user experience as well.

With the economic future of countries such as the UK being based partly on creating wealth from the ‘knowledge economy’ and Intellectual Property, and with the recent, exciting, developments in technology (such as the semantic web, screencasts, wikis and open source software) now is the ideal time to revisit the issue of how to capture, collaborate and disseminate knowledge within and without the organisation. For a business working in a difficult climate, it can be the equivalent of finding loose change down the back of the sofa.