Expert publishing blog opinions are solely those of the blogger and not necessarily endorsed by DBW.
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.
To get all the ebook and digital publishing news you need every day in your inbox at 8:00 AM, sign up for the DBW Daily today!