Whatever the other Manifestos for the Future of the Book Business are—whatever exciting areas people propose for change in the industry, whether it’s in digital, or business workflows or product development—our people do not have the skills to make it happen.

I was amazed at the response to the FutureBook piece Menial publishing jobs are destroying our future, which questioned:

  • Why, as an industry, we still get humans to do the work of computers
  • Why we keep entry-level positions secretarial, and
  • Why we don’t provide the right sort of training to equip our people for the future.

I thought it’d be accused of hyperbole. Instead, the response was quite the opposite.

People sent sackfuls of public and private messages of fervent agreement and thanks for writing about the problem.

It seems that there’s a groundswell of discontent throughout the junior ranks, horrified at what is evident to any impartial observer: we don’t train our people and we don’t expect them to be formally skilled.

So here’s what we should do about it.

Educate senior management about what code can do

If senior management were technical—if they knew what computers can do—they wouldn’t stand for the gross waste of time and creativity in their companies.

So let’s launch a series of non-technical yet software-specific, capability-focussed seminars for senior managers. A simple example: show senior managers 20 people editing one Google spreadsheet at the same time. It’s free, accessible, requires no extra training, no servers, and it removes the costs, errors and embarrassment that stems from having more than one version of the truth. Trello, Pandadocs, Capsule, Google Drive, Dropbox, Pipedrive, Slack, FogBugz— many cloud-based apps are cheap and solve some entrenched publishing problems.

Recognise that technical skills take time to develop

Publishing is not a sector used to taking the long view. If you’re designing a new jet engine, you know it’s going to take a decade before your investment of time and effort pays off. Publishers should recognise that an investment in providing staff with technical skills training will not pay off this quarter, or the next.

In five years time, you’ll have the right workforce for the market, and they’ll be motivated, grateful and hyper-productive.

Develop an industry Management Training Scheme

Make it competitive, difficult and ambitious.

Have it run over three years. Provide a formal qualification at the end. Have its syllabus include financial management, project management, management skills such as influencing, negotiation, and decision making, and code. Get employers to subsidise attendance and allow delegates to attend week-long sessions, four times a year.

Radically raise our expectations of our suppliers

Suppliers to publishing are divided cleanly into two groups: those who know what an API is, and those who don’t.

We must insist that our suppliers move beyond the 1980s, as a matter of urgency—because if they haven’t, it’s costing us time and money. We simply cannot accept the fact that major businesses still build data workflows centred around the .csv format and exchange of spreadsheets, or that professional typesetters can’t automate catalogue production from ONIX in InDesign. We cannot tolerate the inflated costs of external experts who are fleecing us because we don’t know how to build things ourselves.

Most of all, we can’t tolerate that our industry does not have the competence to recognise this.

Update our Occupational Standards

Revise the otherwise excellent Book and Journal Publishing National Occupational Standards to include technical skills. They don’t go far enough in ensuring a technically skilled workforce.

Harness the evident discontent amongst junior publishers

People are angry about having to prove themselves in menial roles.

Let’s harness the power of this sentiment and give people a platform on which to discuss change, without fear of retribution by their management. A StackExchange site for publishing? Meet-ups, like we do in tech?

There’s a groundswell of opinion on this and we should find ways to raise our voices coherently.

Make us competent, make us proud, make us flourish

I want to work in a flourishing industry known for its competence, kindness, innovation and creativity. As time goes on, our current expectations of what junior roles should be is going to look and feel more and more Stone Age—with radical implications for our future viability.

Originally written for and published by The FutureBook, October 2015

Archives

    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Learning how to code, the long way around
  4. A manifesto for skills
  5. It's us in the industry who need to be able to code
  6. Menial publishing jobs are destroying our future
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. And now we are five
  12. Prizes galore
  13. Sara O'Connor to join the team!
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. What publishers need to know about Ruby on Rails
  27. How APIs can make publishing more efficient
  28. A day in the life of a programmer
  29. A publisher’s guide to APIs
  30. eCommerce

  31. Don’t outsource your publishing business away
  32. Inbound marketing
  33. Who has the balance of power over data?
  34. To go direct, publishers must mean business
  35. Why publishers must use direct sales
  36. The business case for going direct
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. BIC, Thema and artificial intelligence...
  42. Three ways to do more with ONIX
  43. How to create a catalogue automatically using ONIX and InDesign
  44. A non-technical, beginners’ guide to ONIX for Books
  45. ONIX Changes
  46. Skills

  47. A taste of code
  48. Mechanical sympathy
  49. Publishers can learn a few things from programmers
  50. Embrace the code
  51. Strategy

  52. A company of one's own.
  53. Responsibility, Authority, Capability
  54. Five things I've learned since moving into enterprise product management
  55. The search for publishing's holy grails
  56. Sometimes, size matters
  57. Managing expectations
  58. Rejuvenation
  59. Decisions, decisions
  60. The real price of a strategy shift
  61. Why ‘easy’ publishing solutions hardly ever are
  62. Technical debt
  63. Start with Why – How to refine your publishing mission
  64. The right tool for the job
  65. No computer system can fix a broken publisher
  66. Creative industries and the division of labour