In the debate over whether to rely on outsourcing or develop skills in-house, I come down firmly on the side of learning skills yourself.

I wrote this article about keeping skills in house for DBW in July 2015. Read the full article at Digital Book World.

In the debate over whether to rely on outsourcing or develop skills in-house, I come down firmly on the side of learning skills yourself.

A major reason for this is personal satisfaction: competence and capability make you feel good about yourself. And by extension, a happy, motivated workforce makes for better publishing.

Another motivation is corporate worth. When the time comes to value your company—at divestment or when you’re looking to raise capital—skilled staff are a corporate asset and therefore increase the value of your company. Without the necessary skills, you’re nothing more than a trading hub: a shell company in which your staff are expert in briefing third parties, in networking and in the publishing process, but not in much else.

An even more important reason to add skills, though, is so you can know when you’re having the wool pulled over your eyes.

Have you ever had to brief an agency on something you don’t know much about? A website, perhaps? An app to accompany a print book, or a digital marketing project, heavy on the technical side? You know what you want the end result to look like, and you know what the user experience should be, but how you get there—well, that’s why you need an agency, because you don’t have the skills to do it yourself.

And so you have very little way of knowing if the response you receive from your tender is a decent, cost-effective solution. If not, it could be because the suppliers are borderline malicious—quoting a lot of money for not much work, because they know you’ve got no way of knowing. Or they could simply be incompetent, able to throw a website together but far from a well-written one. It’ll be one that might be difficult (read: costly) for other programmers to maintain. Either way, you can’t know if you’re getting a good deal or not.

Moreover, even if you get lucky and find an honest, reliable supplier, when you have to instruct other people you inevitably introduce distance from the original idea. The creative nugget at the heart of the project has to be explained, diluted and compromised. If you were building things yourself, on the other hand, you’d do justice to your creative idea, and it would be a hundred times less stressful (I promise you) than it is trying to get someone else to do what you want.

Even worse, if you brief outside suppliers and work with them, you’re giving them premium access to your precious domain knowledge and your hard-earned understanding of the publishing problem you’re trying to solve. You’re also allowing them to make money off you and internalize the knowledge that they didn’t work for.

If your vendor supplies generic services—an ecommerce web developer for all kinds of products, say, rather than a publishing-specific ecommerce web developer—they price in the additional risk of not knowing about your sector. That’s an extra cost.

And if you outsource, you can say goodbye to the process being in any way agile. Up-front design of major projects is exceedingly difficult—especially when it’s your first time designing, say, a transactional website. But if you want to get a cost for a project up front, you have to spec it out up front, almost guaranteeing that the project will go over budget and miss its deadline.

However, if you create your products and solutions yourself, you’re in complete control and there’s no disconnect between your idea and the execution.

Here’s how we write features for Bibliocloud, the publishing management app that I and other publishers use to run our companies: first, we encounter a real life problem. Then we simply write code to fix it. For instance, I once sold French rights to a book that I hadn’t actually licensed the French rights for. This problem took a good week of frantic and hugely embarrassing phone calls to untangle. So we wrote a feature into Bibliocloud to stop that from ever happening again.

These features are driven by real world problems, and I have the programming skills to fix them. Nowadays, you don’t even have to be a “proper” programmer. There’s an embarrassment of toolsets on the market that allow you to develop technical products and solutions in-house with only a smidgeon of technical know-how. Shopify for ecommerce, InDesign CC for ebooks, Trello for project management: none of these solutions require programming knowledge, and they allow you to remain in control.

The alternative to in-house skills? Outsourcing. Being dependent on others. Not having complete control.

For those who say publishing is about people, not coding or technical competence or project management skills, I can assure you that people are the first to suffer when things go off the rails. It’s a miserable existence to wake up every morning thinking, “There must be a better way,” or to feel slighted and foolish when people make money off you. I’d rather read a hundred technical manuals than feel out of my element, lectured to and exploited by outsiders, outdated, stung for a fortune or taken for a ride. How about you?

Emma and the Bibliocloud team are running the second Try Programming course in Oxford, UK on Monday, September 14th on behalf of the Oxford Publishing Group. Book here.

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. It's us in the industry who need to be able to code
  5. Menial publishing jobs are destroying our future
  6. A manifesto for skills
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. Prizes galore
  12. And now we are five
  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. A publisher’s guide to APIs
  28. A day in the life of a programmer
  29. How APIs can make publishing more efficient
  30. eCommerce

  31. To go direct, publishers must mean business
  32. Why publishers must use direct sales
  33. Inbound marketing
  34. Don’t outsource your publishing business away
  35. Who has the balance of power over data?
  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. Three ways to do more with ONIX
  42. A non-technical, beginners’ guide to ONIX for Books
  43. How to create a catalogue automatically using ONIX and InDesign
  44. ONIX Changes
  45. BIC, Thema and artificial intelligence...
  46. Skills

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

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