"There is a neat parallel between the best way to design a systems landscape, and the best way to design a network of people." All ears? Me, too. And Bibliocloud's Emma Barnes posits a merciful observation: Job pain, like hell, is other people. (Not you, dear reader, the other people.) "Systems implementation pain, Barnes tells us, "is in the interface with other systems; job pain is in the interface with other people." And after all this cloying HR lingo about "reaching out" to each other in business, I'm sitting up—how about you?—when Barnes asks: "Why not design teams so there’s a limit on the extent of that interfacing requirement?"—Porter Anderson
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.
Image - iStockphoto: Alan Lagadu