Making decisions in an information vacuum is a publishing speciality.

Every time we acquire a book, we have to weigh up any number of factors: some predictable, some entirely made up. Often it comes down to what I’ll euphemistically call “passion”: he or she who shouts loudest, wins, because editorial decisions, no matter how analytical the approach, always come down to something of a leap of faith. (If they weren’t, every book would be a bestseller.)

But our familiarity with making such leaps for subjective decisions means we don’t get much practice at making other decisions more rigorously.

Choosing a new platform for your B2C Web site, for example. You know what it should do, and how it should look, but you don’t know which platform to choose. It’s a decision that will have far-reaching, long-lasting effects on your company. So it’s worth trying to adopt the most rigorous, least risky approach to decision-making.

The first thing to do is to ditch the hubris. No-one knows everything about everything. Accept that you are not an expert at specifying a Web site. Your plan should involve asking for help and accepting that your gut feeling on subjects you know little about is probably wrong. Your brief should include an information-gathering aspect, tapping in-house expertise, and also that of external contacts who can share their insight. Ask people who’ve done this all before a hundred times to help you — and then trust them, unlike the managers in this short, fly-on-the-wall comedy sketch. (I’ve been in meetings like that a horrible number of times).

Above video: The Expert, written & Directed by Lauris Beinerts, based on a short story, The Meeting, by Alexey Berezin.

One approach to information-gathering is to learn a bit about the field, yourself.

It’s like if you’re planning to go on holiday to France. You want to know enough French to get from the airport to your hotel, and to enquire about the regional cheeses. Enough to have good manners, and to show some interest in what people are saying. Same with technology. A month’s interested evening reading will get you to the able to ask sensible questions stage. If your interest is piqued, and you want to know more, there is no shortage of crash courses on programming — in fact, I run one periodically, tailored just for publishers — and the Internet is awash with information.

If you’re the person who signs the cheques, the happy side-effect is that you’ll know enough to sensibly, knowingly challenge your team to build new, interesting things that will add to your bottom line. You’ll adjust your recruitment strategy to attract technologically-competent people to your team. Your strategic planning will improve when you know what’s possible, what’s easy and what’s not. It’ll be easier for you to sign-off — or not — on your IT project implementation planning. If you don’t know anything about code, you don’t know what you don’t know, and that’s dangerous.

If you are a technical expert and need to convince the hierarchy to sign the cheque for the platform of your choice, there’s one rule: don’t use jargon. If you’re lucky enough to have a boss who will listen to and act upon your opinion, it’s incumbent on you to find a way to translate your technical understanding into what it means for the business. You’re the French fromagier in my increasingly tortured French holiday analogy. Use simple, familiar words with the plucky tourist who’s trying his best in pidgin French, and maybe you’ll be able to sell him some of your unpasteurised Camembert. (Ideally, he’ll just hold out cupped palms full of coins and note that he doesn’t understand, and you’ll pick out the ones you want.)

If you know that WordPress is a mess under the hood, explain about the cost, time and business-risk implications of maintaining and extending horrible code, rather than trying to get your boss to care about how awful it is to have SQL embedded at the view layer, and that code should be ordered according to the MVC principle. You might be better at communicating in writing rather than face-to-face. A good boss, keen on reaching the right decision for the good of the company, will understand that and read your recommendations, rather than insist that you pitch your opinion in front of everyone.

Whether you take the blue “learning the technology” pill, or the red “trusting your experts” pill, you should always use a decision-making framework: a tool to help you take the emotion and confusion out of complex decisions.

Something like the Kepner-Trego matrix (see below) helps you to figure out what business objectives you’re trying to achieve, and which option is going to help you the most. You write down the things you must have, and the things you want. You might want to be able to integrate with your title management system, meet your functional spec, and to avoid buying a physical server.

Then you score your desires, giving them a weighting out of 100. Integration with your title management system would be very nice, so it gets a 20. Getting up and running quickly would be handy but it’s not the end of the world: it gets a 10. Costing no more than £3k is a must. Then you score your options against your desires, rejecting any which don’t achieve your musts. Multiply the scores by the weighting and you get a score for each of your options. It’s amazing how this approach helps to cut through the confusion of a complex decision to achieve clarity of thought.

Here’s an example.

For emma barnes futurebook piece of 25th march

To help create your Kepner-Trego matrix, you should keep asking the question, “What problem does this solve?“ For a B2C Web site decision, is your problem Amazon’s market share of your online sales? Or that there’s nowhere on the Internet for people to see all the photos from your books? Is it that your authors aren’t proud of you and won’t refer their contacts to your Web site? Or do you have no way for readers to join your mailing list? You need to articulate your problems if you’ve got a hope of finding a solution.

How much should you spend? When it comes to knowing how much money is reasonable for any technology project, you should consider the uniqueness of your requirements, and the complexity of the required functionality. The problem of selling books on a Web site is fairly complex, but it has been solved tens of thousands of times over: you shouldn’t pay someone to reinvent the wheel. Build on the shoulders of giants.

Conversely, Foyles’ recently-commissioned app, which allowed shoppers to search inside the real-life store, is a fairly simple piece of programming, but it’s unique and new. And it should cost more. Doing something for the first time costs money, not necessarily in hammering out lines of code, but in paying for the spark of invention.

When any decision needs to be made, keep asking, “What’s the problem?” until you get to the nub of things.

Make decisions knowingly. Then you’ll be sure that you’re getting a solution, not another problem.


    Most popular

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

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. Sara O'Connor to join the team!
  12. And now we are five
  13. Prizes galore
  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. A publisher’s guide to APIs
  27. What publishers need to know about Ruby on Rails
  28. How APIs can make publishing more efficient
  29. A day in the life of a programmer
  30. eCommerce

  31. To go direct, publishers must mean business
  32. Don’t outsource your publishing business away
  33. Who has the balance of power over data?
  34. Inbound marketing
  35. The business case for going direct
  36. Why publishers must use direct sales
  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. ONIX Changes
  44. BIC, Thema and artificial intelligence...
  45. How to create a catalogue automatically using ONIX and InDesign
  46. Skills

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

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