How do you arrange people in a modern company?

It’s an endlessly interesting question, and one that needs a new answer with every shift in technology and the markets.

Do we use the 240-year-old Wealth of Nations by Adam Smith as our handbook? Smith’s ‘division of labour’ argument makes sense for the manufacture of pins, but what relevance does it have to the two creative industries that I’m interested in: publishing and software creation? Sure, there are certain technical elements to writing software—and some expert niches in publishing—that lend themselves to specialisation. But they’re fewer than you’d think. To force people to confine themselves entirely to one functional silo is to waste the creative potential of a good human brain, and the cross-fertilization opportunities of human experience.

There is a neat parallel between the best way to design a systems landscape, and the best way to design a network of people. When we implement Bibliocloud for publishers, the difficult bit is never the training or the data import. The difficult bit is the integration with legacy systems. It’s one of the reasons why we’ve built Bibliocloud to have such a wide breadth of functionality, so we have to integrate with as few systems as possible, and ideally with those of our choosing (the ones with decent APIs).

And it’s the same with people. The fun bit of any job is actually doing the job—and the worst bit is trying to get other people to help you, support you, to do the bit of the process that you need them to do before you can do your bit.

Systems implementation pain is in the interface with other systems; job pain is in the interface with other people.

So why not design teams so there’s a limit on the extent of that interfacing requirement?

Why not have the same breadth of functionality in your job as ERP vendors like us build into their software, for the same reason: so that you have as much control, elegance and simplicity as possible? And, as a nice side effect, you design far richer and more varied jobs.

‘Far richer and more varied jobs’ People cost companies a fortune in payroll, and so you want to get the most out of them. Putting them into functional silos does two things:

It radically increases the amount of time your people spend inwardly-focussed in the company, persuading each other to do things, and It radically decreases the creative output of people, because their sphere of thought and influence is limited to one specific area. Think of the digital ghettos that have formed of late in publishers, where management have cleaved off the “digital team” into their own corner, split apart from editorial and marketing, tasked with following their own separate agenda and priorities.

How much more interesting their output would be if they were integrated within the engine room of the company, present at the inception and during the development of books, rather than operating as a bolted-on afterthought, producing bolted-on afterthoughts.

‘Try to limit the number of times a task has to be handed off’ At my publishing company, we take this to extremes. One person does everything to do with a book, from acquisition to AI. Publishing isn’t engineering or medicine: every task in publishing can be learned by an enthusiastic person with a training budget, an eye for a nicely-turned phrase and a certain facility with Photoshop. But most companies won’t be quite as radical. Even so, you should try to limit the number of times a task has to be handed off to another person or department: that’s where the cost and complication lies.

The modern company needs to consider what success looks like for the whole mission, not just for each individual, and department, and then measure the whole joined-up team on that group achievement. So the trick becomes defining what that mission is. For us, success means “make things better”, not “produce software”, and that simple goal allows us to do away with more granular schemes of control, and enables a flatter hierarchy. Command and control isn’t necessary when everyone knows the grand plan and has the liberty and trust to do away with careful monitoring.

Specificity can be helpful here, though. Rather than your generic “become number one in the market”, make your goals more human-scale. Make them span all the roles in a process, and directly relate them to the work that people do. Success can mean “produce a high quality book, market it to the right audience and sell as many as possible” — which everyone involved in the book can understand, can relate to their role, can buy-in to and can feel proud of their contribution to: from the person who typesets, to the person who commissions, to the person who does the quarterly sales presentations.

Having control over a vast amount of the creative and business process may be daunting, but it’s a recipe for simplicity.

When you are all focussed on the same fundamental goal, you might have programmers participating in marketing, PR having input to editorial, editors helping with sales, production interested in customer service.

You’ve got a joined up process and goals that make sense to individuals and the company alike — a necessary state of being for a fluid, nimble, modern company.

Originally written for and published by The FutureBook, January 2016


    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